Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#13175 closed (fixed)

"+ Add another [...]" bug with final_attrs['id']

Reported by: rasca Owned by: DrMeers
Component: contrib.admin Version: master
Severity: Keywords: inline javascript
Cc: rasca7@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

When adding a new inline in the admin through "+ Add another [...]" the id of the inputs is different from what final_attrs.id says it should be.

For example when rendering a widget that prints final_attrs.id I get

id_sponsor_set-4-logo

but actually the id is

id_sponsor_set-3-logo

To make this clear (can't express myself clearly) you can try changing line 218 from django/forms/widgets.py to

212	    def render(self, name, value, attrs=None):
213	        if value is None: value = ''
214	        final_attrs = self.build_attrs(attrs, type=self.input_type, name=name)
215	        if value != '':
216	            # Only add the 'value' attribute if a value is non-empty.
217	            final_attrs['value'] = force_unicode(formats.localize_input(value))
218	        return mark_safe(u'<input%s />' % flatatt(final_attrs))

218	        return mark_safe(u'expected id: %s <input%s />' % (final_attrs['id'], flatatt(final_attrs)))

and add a new inline through the link and check what's been printed with the id of an input inside the newly created inline

This small changes breaks many 3rd party apps.

Attachments (1)

inline-prefix.diff (5.3 KB) - added by DrMeers 5 years ago.
Javascript fixes

Download all attachments as: .zip

Change History (7)

comment:1 Changed 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

"Breaks many 3rd party apps" isn't an especially helpful statement. An example of a breaking application, or a snippet of code that demonstrates why this is a problem in practice would be exceedingly useful.

The contents of final_attrs doesn't contain an integer. It contains prefix, which is then dynamically substituted as the new row is added. If you look at the form values being submitted, the additional form values are correctly enumerated. I'm guessing the problem here has something to do with the way the substitution takes place.

I'll accept this on the basis that the prefix substitution appears to be behaving inconsistently.

comment:2 Changed 5 years ago by rasca

Sorry, I wasn't so clear in what was happening, that's why I included the code change to demonstrate.

It breaks for example django-filebrowser and every other app that uses this prefix as a reference for a particular field in JavaScript.

comment:3 Changed 5 years ago by DrMeers

  • Owner changed from nobody to DrMeers
  • Status changed from new to assigned

Changed 5 years ago by DrMeers

Javascript fixes

comment:4 Changed 5 years ago by DrMeers

  • Has patch set
  • Keywords inline javascript added

Appears to have been a simple zero-based indexing error. The attached patch should resolve the issue.

comment:5 Changed 5 years ago by jezdez

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [12871]) Fixed #13175 - Fixed an off-by-one error in the admin inline JavaScript that resulted in wrong form field prefixes. Thanks DrMeers for the patch.

comment:6 Changed 4 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Note: See TracTickets for help on using tickets.
Back to Top