GLOBAL_PERMS

[Curtis Maloney]

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 Permission.content_type to be null

2. Adjust everything else to cope with that

3. Add new setting "GLOBAL_PERMS"

4. Teach create_permissions to honor that.

5. Write minimal test and documentation.

Would welcome further input.

--
C

[Markus Holtermann]

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 independent apps and both use a permission can_do_foo, one
can't distinguish between those two, right?

- What do you think about adding an 'app_label' to the Permission model
that can be used instead of a content type. That could solve the issue
from the previous point? content_type and app_label would be
exclusive?

- I dislike the seetings approach of GLOBAL_PERMS and would rather see
users writing explicit data migrations.

/Markus

>--
>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-develop...@googlegroups.com.
>To post to this group, send email to django-d...@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/1a028faa-beb1-7e67-69a7-a9c1028a4e17%40tinbrain.net.
>For more options, visit https://groups.google.com/d/optout.

[Josh Smeaton]

- 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 avoid the ceremony of creating forward/back functions, and having to remember the model layout for Permissions.

Something like:

migrations.CreatePermission(app_label, permission_name)

or django.contrib.auth.CreatePermission (which is actually an Operation) if we want to avoid contrib polluting migrations proper. 

I haven't fully thought through the implications, but every time I need to write a data migration I spend more time than I'd like to admit searching for a previous data migration from which to copy.

[Curtis Maloney]

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 mention on #django next time it
comes up :)

> - How do you envision 3rd party apps handling their own permissions? If
>  I install 2 independent apps and both use a permission can_do_foo, one
>  can't distinguish between those two, right?

I had considered this, and yes would much rather some sort of per-app
permissions. For some years now the model-centric view many people take
of their designs has bothered me.

> - What do you think about adding an 'app_label' to the Permission model
>  that can be used instead of a content type. That could solve the issue
>  from the previous point? content_type and app_label would be
>  exclusive?

Oh, absolutely! A solid mechanism for per-app permissions would win me
over in a second.

Would we keep the existing syntax of "{scope}.{codename}" and fallback
scope from model to app label? Or have a different syntax for app-level
permissions, like "{app_label}:{codename}"?

And if so, how would that be handled in templates?

Also would we add get_app_permissions() to the auth API?

> - I dislike the seetings approach of GLOBAL_PERMS and would rather see
>  users writing explicit data migrations.

I was specifically aiming for something almost as simple as the
per-model custom permissions.

Could we add it to AppConfig? Feels like the right place to me.

--
C

[Curtis Maloney]

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 consider adding a
> first class permission type, to avoid the ceremony of creating
> forward/back functions, and having to remember the model layout for
> Permissions.
>
> Something like:
>
> migrations.CreatePermission(app_label, permission_name)

Certainly, if we go the data migration path I'd go this way...

--
C

[Curtis Maloney]

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.permissions [optional].

I've also implemented a "create_app_permissions" function which will ...
do just that. Call it whenever you like :)

Basic tests are working, as well as added ones.

No documentation or changelog as yet...

--
C

[Scot Hacker]

On Saturday, December 30, 2017 at 1:32:21 AM UTC-8, Curtis Maloney wrote:

So, after a discussion with a new user on #django today I decided to
make "permissions not bound to models" a first-class feature.

I'd recommend that anyone working on such a feature take a good look at django-rules. It works on a per-app or per-project basis, is not necessarily bound to models (but can be), has a good system for detecting conflicting rules that might be set in different parts of the codebase, and provides some nice helpers for keeping statements and conditions concise. Useful both for full-view protection and for in-template fragments. I do find the distinction is makes between `make_rule` and `make_perm` somewhat arbitrary and confusing, but otherwise they've done great work with it so far.

https://github.com/dfunckt/django-rules

./s