Code

Opened 23 months ago

Last modified 11 months ago

#18427 new Bug

limit_choices_to won't limit correctly

Reported by: thanos@… 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

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.

Attachments (0)

Change History (5)

comment:1 Changed 23 months ago by Nuno Maltez <nuno@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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

comment:2 Changed 13 months ago by aaugustin

  • Component changed from Uncategorized to contrib.admin

comment:3 Changed 13 months ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

Looks like a bug.

comment:4 Changed 11 months ago by svisser

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 Changed 11 months ago by svisser

This seems similar to #20228; fixing one may also provide a stepping stone to fixing the other.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.