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

[rasca]

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.

[Russell Keith-Magee]

"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.

[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.

[Simon Meers]

Javascript fixes

[Simon Meers]

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

[Jannis Leidel]

(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.

[Jacob]

Milestone 1.2 deleted