[Django] #18096: Overiding delete permissions in the Admin
Django
-------------------------------+--------------------
Reporter: anonymous | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 1.4
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
The ModelAdmin delete permission is controlled by the
get_delete_permission function which can be overridden by subclasses.
However when actually deleting an object the permission checking is passed
off to util.get_deleted_objects and then in format callback it does this.
{{{
p = '%s.%s' % (opts.app_label,
opts.get_delete_permission())
}}}
Which goes back to checking the permissions on the models meta class.
Which makes whatever behavior you specified in get_delete_permission
irrelevant.
--
Ticket URL: <https://code.djangoproject.com/ticket/18096>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: closed
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by ptone):
* status: new => closed
* needs_better_patch: => 0
* resolution: => needsinfo
* needs_tests: => 0
* needs_docs: => 0
Comment:
I think you may be confusing get_delete_permission - which is an
undocumented accessor that can return the permission label from models,
with ModelAdmin.has_delete_permission which does the permission checking
for the admin, and is what you would override in a ModelAdmin subclass
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_delete_permission
If this was a typo - and in fact you are saying has_delete_permission is
not behaving as documented - please feel free to reopen.
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:1>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: closed
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Comment (by anonymous):
Yes this was a typo, has_delete_permission is the method. The default
implementation calls opts.get_delete_permission(). The point that
regardless of what you say in has_delete_permission the check in
opt.get_delete_permission must pass otherwise the delete will not be
allowed is still valid.
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:2>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: reopened
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Changes (by anonymous):
* status: closed => reopened
* resolution: needsinfo =>
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:3>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: reopened
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Comment (by koenb):
You will only encounter this when you relax the delete permission in your
custom has_delete_permission method.
I am not convinced that doing so is a good design. In time you will be
very confused that a user can delete objects while not having the proper
permission to do so.
I would propose not fixing this in code, but adding a note to the
documentation clarifying that the has_delete_permission method is meant to
further restrict the delete permission (e.g. on a per object basis).
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:4>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: reopened
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
Has patch: 0 | decision needed
Needs tests: 0 | Needs documentation: 1
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by msopacua):
* cc: msopacua (added)
* needs_docs: 0 => 1
* stage: Unreviewed => Design decision needed
Comment:
(Documentation needs updating.)
However, the reporter has a point that there is no way to relax
permissions for which there is a common use case, the "owner of object"
state, which can only be determined at runtime. For example, an editor
will have delete/change permissions by default, but a reporter will only
be able to edit it's own articles and may be denied editing when he
submitted the work for review. Lastly, the grammar police can only edit an
article when the article is submitted for final review. It is equally
confusing (not to mention more work) to create artificial permissions on
the model and separate views and templates in the admin for the model that
bypass the standard change/delete mechanisms.
On the other hand, the admin does a good job but is meant to be replaced
for more complicated projects / applications. Core team therefore needs to
decide where this "more complicated" area starts.
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:5>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jacob):
* stage: Design decision needed => Accepted
Comment:
Agreed that it should be possible to relax permissions, so marking
accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:7>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: closed
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Mohd Atif Reyaz Khan):
* status: new => closed
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:8>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: closed
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Mohd Atif Reyaz Khan):
* cc: Mohd Atif Reyaz Khan (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:9>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by Tim McCurrach):
I think this can now be closed. It looks like this issue was fixed in
https://github.com/django/django/commit/3eb9127678e
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:10>
Django
Reporter: anonymous | Owner: nobody
Type: Bug | Status: closed
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => fixed
Comment:
Agreed, thanks for checking. Fixed in
3eb9127678e292ef2645b632199f3e9c876ad999.
--
Ticket URL: <https://code.djangoproject.com/ticket/18096#comment:11>