Opened 13 years ago
Last modified 12 years ago
#18427 new Bug
limit_choices_to won't limit correctly
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.4 |
Severity: | Normal | Keywords: | limit_choices_to admin |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Pull Requests: | How to create a pull request | ||
Description ¶
If you set limit_choices_to, and then you hit the plus icon to add something to that list, that something will be one of your choices regardless of whether it confronts to the limit_choices_to restriction.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (5)
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 12 years ago
Component: | Uncategorized → contrib.admin |
---|
comment:4 by , 12 years ago
Not as easy as it looks.
It happens because the response that response_add
sends (in django.contrib.admin.options.ModelAdmin
) unconditionally calls the JavaScript that updates the admin control. In practise the foreign key configuration may be complex so it may not be obvious to the user why the newly added object does not appear in the list. So it seems to me one would also need to inform the user about this.
Also, creating the new object happens by posting to the add_view
and that view doesn't know what happens afterwards with that object. Solving this ticket would need a way of reevaluating the constraints in limit_choices_to
but also elegantly communicate that to the front-end.
comment:5 by , 12 years ago
This seems similar to #20228; fixing one may also provide a stepping stone to fixing the other.
I can confirm this really happens: after you create a new object that does not fit the limit_choices_to restriction using the "plus icon", it will be selected in the form field, and listed in the dropdown.
However, saving will fail with the appropriate error message and the new object is removed from the dropdown.
I'm changing to "Design decision needed" because I'm not sure there's an easy fix and if this widget behaves likes this, well, "by design".