Opened 14 years ago

Closed 14 years ago

Last modified 12 years ago

#13175 closed (fixed)

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

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

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 Simon Meers 14 years ago.
Javascript fixes

Download all attachments as: .zip

Change History (7)

comment:1 by Russell Keith-Magee, 14 years ago

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 by rasca, 14 years ago

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

Owner: changed from nobody to Simon Meers
Status: newassigned

by Simon Meers, 14 years ago

Attachment: inline-prefix.diff added

Javascript fixes

comment:4 by Simon Meers, 14 years ago

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

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 by Jacob, 12 years ago

milestone: 1.2

Milestone 1.2 deleted

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