I haven't needed to explain why permission has been granted, but I have had admins asking me why a user is getting permission denied for a particular view. To answer that, you would
1. Get the url 2. Resolve that to a view 3. Look up the view in the correct views.py, and check which permissions the permissions_required decorator was using We managed to automate 1. and 2. but not 3. In Django 1.9, the permission_denied view takes the exception as the second argument. If the permission_denied decorator included the permission names in the message when raising PermissionDenied, we would be able to display the list of permissions in the template. Even better, you could show the missing permissions, although that would require a larger patch. Another option would be for the permission_required decorator to set a _permissions attribute on the decorated view, containing the list of permissions. A custom permission_denied view could then introspect the view. cheers, Alasdair On Tuesday, 26 April 2016 14:17:37 UTC+1, guettli wrote: > > I would like to decouple the permission checking in django. > > Current draw-back: If you use decorators like [login_required][1], then > you can't know in advance whether a user has the permission to do so or not. > > I would like to split this into two steps: > > 1. check permissions > 1. call the view. > > > # Use Case 1: Admin tool > I want an tool for admins where they can check the access-permissions of > users. This requires: > > 1. The check must not use the current `request.user` since this is the > wrong user object. > 1. The check must not actually call the view, since this might alter data. > > # Use Case 2: Show Link as disabled. > > I want to show links as disabled (grayed out and without "href") if a user > does not have the permission to see linked page. > > # Dream > Returning a boolean for "ok" and "permission denied" is nice. But the big > benefit would be if the admin could get a **reason**. > > Example: > > 1. Admin opens "Check Perm Tool" > 1. He selects a view/URL > 1. The admin hits "submit" > > > Result: > > ------------------------------ > | User | Allowed | Reason > ------------------------------ > | fooadmin | Yes | is_superuser > | foouser | No | missing permission "view-bar-at-midnight" > | foobar | Yes | User has permission "view-bar-at-midnight" > > # Question > How to get this dream come true? > > > [1]: > https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required > > > > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/59576592-4a44-4d91-b6d4-bde192d8a753%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
