Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#13175 closed (fixed)

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

Reported by: rasca Owned by: Simon Meers
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:


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

For example when rendering a widget that prints I get


but actually the id is


To make this clear (can't express myself clearly) you can try changing line 218 from django/forms/ 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 Simon Meers 7 years ago.
Javascript fixes

Download all attachments as: .zip

Change History (7)

comment:1 Changed 7 years ago by Russell Keith-Magee

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted

"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 7 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 7 years ago by Simon Meers

Owner: changed from nobody to Simon Meers
Status: newassigned

Changed 7 years ago by Simon Meers

Attachment: inline-prefix.diff added

Javascript fixes

comment:4 Changed 7 years ago by Simon Meers

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 7 years ago by Jannis Leidel

Resolution: fixed
Status: assignedclosed

(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 5 years ago by Jacob

milestone: 1.2

Milestone 1.2 deleted

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