#9983 closed (fixed)
Javascript issue on admin interface with prepopulated_fields
| Reported by: | Matias Surdi | Owned by: | Carl Meyer |
|---|---|---|---|
| Component: | contrib.admin | Version: | 1.0 |
| Severity: | Keywords: | ||
| Cc: | kevin@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I've noticed that if you have a ModelAdmin with the prepopulated_fields
attribute set to:
prepopulated_fields = {"object_identifier": ("object_type",)}
where the field "object_type" is a dropdown box (that is, has a
choices=CHOICES argument) then the javascript that autofills the
"object_identifier" field does not work properly when you choose an
element with the mouse (what most users do).
To solve this, I modified
./django/contrib/admin/templates/admin/prepopulated_fields_js.html
replacing the event "onkeyup" on line 5 for "onchange".
I think this change should be applied to trunk.
Attachments (2)
Change History (16)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
| milestone: | → 1.1 |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 16 years ago
| Component: | Uncategorized → django.contrib.admin |
|---|
by , 16 years ago
| Attachment: | populatedfields_9983.diff added |
|---|
comment:5 by , 16 years ago
Ok, I have a patch for a bit of a dual-fix.
1) Listens to both events so that mouse or keyboard will get the autopopulation of the field.
2) Handle the 'choice' instance by using the name and not the value of the select box.
Let me know if it looks good.
comment:6 by , 16 years ago
| Has patch: | set |
|---|
by , 16 years ago
| Attachment: | populatedfields_9983_2.diff added |
|---|
comment:7 by , 16 years ago
| Cc: | added |
|---|
comment:8 by , 16 years ago
The following is also another similar patch for this issue:
http://code.djangoproject.com/ticket/9110
comment:10 by , 15 years ago
| milestone: | 1.2 → 1.3 |
|---|
I'm going to bump this off the 1.2 milestone, for a couple reasons:
- There are several tickets (this one, #9110, #9264 and #9784) all exposing cases where the event handling for
prepopulated_fieldsfalls over in specific edge cases, so the real solution is not to fix any of these individually but rather to makeprepopulate_frommore robust. - I suspect the admin-ui work will be coming up for discussion in the 1.3 timeframe, and that's a more solid place to talk about dealing with this.
comment:11 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
Closed #9110 as dupe of this; the patch here seems to have gotten more attention.
comment:13 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
(In [12937]) Fixed #13068, #9264, #9983, #9784 - regression with pre-populated fields and javascript inlines, and related bugs.
Thanks to hejsan for the report, and to Sean Brant and Carl Meyer for the patch.
#13068 is a regression caused by the new javascript inline forms in the
admin. The others were existing javascript bugs with prepopulated fields.
Since the solution depends on jQuery and would likely be very hard to
backport without it, it will not be backported to 1.1.X.
If I'm not mistaken, the side effect of using onchange would be that prepopulated fields based on text inputs won't update until the user exits the text input, rather than updating on every keystroke. That seems like a regression to me. Would it be possible to support both cases by hooking into both onkeyup and onchange?