So, after a discussion with a new user on #django today I decided to
make "permissions not bound to models" a first-class feature.
So I've written a simple patch that is in
https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1
Basically:
1. Allow Perm
Thank you for looking into this!
Another benefit alongside ease of install and discoverability, is that it
makes the requirements files of projects using Django more self-documenting
(in that it avoids stray dependency entries that appear to be unused, but
actually aren't - and so need a commen
Thanks Curtis,
I had a quick look. Some thoughts (in no particular order):
- IMO a nice idea. I've attached all model independent permissions to
the user model in the past to work around the limitation.
- How do you envision 3rd party apps handling their own permissions? If
I install 2 indepe
>
>
> - I dislike the seetings approach of GLOBAL_PERMS and would rather see
> users writing explicit data migrations.
>
I don't favour either setting or migration based perms, but if you're going
to go with migration based, then please also consider adding a first class
permission type, to
Triaged
---
https://code.djangoproject.com/ticket/28959 - Clicking "No, take me back"
on the delete selected inline foreign key / one-to-one field confirmation
page does nothing (accepted)
https://code.djangoproject.com/ticket/28961 - Convert result of predicate
in the function django.u
On 12/31/2017 12:50 AM, Markus Holtermann wrote:
Thanks Curtis,
I had a quick look. Some thoughts (in no particular order):
- IMO a nice idea. I've attached all model independent permissions to
the user model in the past to work around the limitation.
Certainly a good one I'll remember to m
On 12/31/2017 11:51 AM, Josh Smeaton wrote:
- I dislike the seetings approach of GLOBAL_PERMS and would rather see
users writing explicit data migrations.
I don't favour either setting or migration based perms, but if you're
going to go with migration based, then please also consid
So, I've taken a different approach, following Markus' idea, and added
"app_label" to Permission.
I probably still need to add a check to ensure you don't set app_label
_and_ content_type, but that can wait for now.
You can now define new app-level permissions on the app's
AppConfig.permis
