Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#29502 closed Bug (fixed)

AutocompleteJsonView doesn't work if user has "view" but not "change"

Reported by: Matthew Frazier Owned by: Carlton Gibson
Component: contrib.admin Version: 2.1
Severity: Release blocker Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no


If a ForeignKey to a model is in autocomplete_fields and the user has the view permission but not change, then the autocomplete field doesn't work - the view returns 403 errors, and so the field shows "The results could not be loaded." The value that was already on the model will be retained when the model is saved, but if the model is new and the field is required, this prevents the user from saving the model.

The fix is probably as simple as changing has_change_permission to has_view_permission on line 52 of django/contrib/admin/views/

Attachments (1)

Django bug report - autocomplete.png (4.7 KB) - added by Matthew Frazier 5 years ago.

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by Matthew Frazier

comment:1 Changed 5 years ago by Carlton Gibson

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

OK, yes. Thanks for the report.

This should probably be weakened to view or change. (Although, change currently implies view.)

It might be worth an addition to the autocomplete_fields docs, noting that the permission to the related object is required.
(There's a slight inconsistency in that no permission to the related model is needed if you don't use autocomplete.)

comment:2 Changed 5 years ago by Carlton Gibson

Has patch: set
Owner: changed from nobody to Carlton Gibson
Status: newassigned

comment:3 Changed 5 years ago by Matthew Frazier

To deal with the inconsistency you mentioned, the autocomplete view for a model could accept query arguments: for_app=[APP]&for_model=[MODEL]&fk=[FOREIGN_KEY]. If those arguments are present it would look up the ModelAdmin for the indicated app and model, verify that the user has_add_permission or has_change_permission on the indicated model, and verify that fk refers to the model being autocompleted.

This would allow a ForeignKey to work the same way whether it was in autocomplete_fields or not, but it would make the patch more involved. It also introduces a slight security risk: if a model A has a ForeignKey to another model B, then the user can still look up the values of B even if the ModelAdmin to A doesn't permit them to edit the ForeignKey to B.

Another option that eliminates that security risk, but increases complexity even more, is to store the models a user needs access to autocomplete in their session. That is probably too much work with too much potential security exposure to include in 2.1.0 since the beta is supposed to go out today.

comment:4 Changed 5 years ago by Tim Graham

Triage Stage: AcceptedReady for checkin

comment:5 Changed 5 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In 5b73317:

Fixed #29502 -- Allowed users with the view permission to use autocomplete_fields.

comment:6 Changed 5 years ago by Tim Graham <timograham@…>

In 67fc680c:

[2.1.x] Fixed #29502 -- Allowed users with the view permission to use autocomplete_fields.

Backport of 5b733171813f8ddc7af84abe79f2646204b9c6ca from master

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