[Django] #29502: AutocompleteJsonView doesn't work if user has "view" but not "change"
Django
-------------------------------------------+------------------------
Reporter: Matthew Frazier | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 2.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------------+------------------------
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
[[https://github.com/django/django/blob/d2ca28db54a5871d851cdd9184f4cf0d31aff946/django/contrib/admin/views/autocomplete.py#L52|line
52 of django/contrib/admin/views/autocomplete.py]]
--
Ticket URL: <https://code.djangoproject.com/ticket/29502>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Matthew Frazier | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Matthew Frazier):
* Attachment "Django bug report - autocomplete.png" added.
Django
Reporter: Matthew Frazier | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Carlton Gibson):
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
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.)
--
Ticket URL: <https://code.djangoproject.com/ticket/29502#comment:1>
Django
Reporter: Matthew Frazier | Owner: Carlton
| Gibson
Type: Bug | Status: assigned
Component: contrib.admin | Version: 2.1
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Carlton Gibson):
* owner: nobody => Carlton Gibson
* status: new => assigned
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29502#comment:2>
Django
Reporter: Matthew Frazier | Owner: Carlton
| Gibson
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29502#comment:3>
Django
Reporter: Matthew Frazier | Owner: Carlton
| Gibson
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Tim Graham):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/29502#comment:4>
Django
Reporter: Matthew Frazier | Owner: Carlton
| Gibson
Component: contrib.admin | Version: 2.1
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"5b733171813f8ddc7af84abe79f2646204b9c6ca" 5b73317]:
{{{
#!CommitTicketReference repository=""
revision="5b733171813f8ddc7af84abe79f2646204b9c6ca"
Fixed #29502 -- Allowed users with the view permission to use
autocomplete_fields.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29502#comment:5>
Django
Reporter: Matthew Frazier | Owner: Carlton
| Gibson
Type: Bug | Status: closed
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"67fc680c43b4f4fddb7bf4988088b1ef7f36bbdd" 67fc680c]:
{{{
#!CommitTicketReference repository=""
revision="67fc680c43b4f4fddb7bf4988088b1ef7f36bbdd"
[2.1.x] Fixed #29502 -- Allowed users with the view permission to use
autocomplete_fields.
Backport of 5b733171813f8ddc7af84abe79f2646204b9c6ca from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29502#comment:6>