group_required decorator

[daniel.walz@…]

To use view authorization together with groups, a decorator is needed in the style of @login_required.
I added to contrib.auth.models a function to the class User named is_in_group(group). For convenience the function handles the argument group as instance of Group, the name or the primary key of the group.
In contrib.auth.decorators I added a new decorator group_required(group).

[Aymeric Augustin]

The expected way to achieve this is to define a custom permission, give it to your group and use @permission_required.

@group_required is a bad idea because it introduces a tight coupling between the groups in your database and your code.

[Chris Curvey]

I'm confused. Having a tight coupling with the rows in the groups table is bad, but having a tight coupling with the rows in the permissions table is OK?

It the "Django Way" is going to be "use permissions", then we need a way to create new permissions through the admin interface (just as you can create groups through the admin interface.)

[Aymeric Augustin]

Let me try to clarify this.

---

Permissions are ​defined in code and used by code -- mostly by the permission_required decorator.

They're copied to the database during syncdb for convenience. It makes it easier to attribute them to groups. But that's just a copy, the authoritative version is still defined by the Python code.

We must not make it possible to create permissions through the admin. Otherwise how could you be sure that the correct set of permissions -- those used by your code -- exist?

---

On the other hand, groups aren't defined in code (unless you've customized things, in which case you can write your own group_required).

[daniel.walz@…]

I just dropped the use of the group_required to follow your suggestion.
Although I found it very unhandy to create the permissions in the shell.
Do I understand it right, that the syncdb is creating the standard permissions from the model.py, or do I define prototypes for custom permissions anywhere in the code, where syncdb reads it and puts it into the auth tables?
If so I would be eger to know that, because that would be the way, I define the permission and the use of the permission in the same place i.e. the code. That would make sense to me.
If there is no such place and I have to create the (custom) permissions in the shell anyway, I would suggest to meke it possible to create the permissions in the admin interface and keep the staff out of that feature so that they can't mess with the system (and the administrator can do that anyway.

BTW. If someone wants to use my code, the AnonymousUser needs the method "def is_in_group(self, group): return False" to work... sorry for that.

[Aymeric Augustin]

My previous comment contains a link to the documentation of "how to create custom permissions" :)

[daniel.walz@…]

Replying to aaugustin:

My previous comment contains a link to the documentation of "how to create custom permissions" :)

Oops, thanks
I just overlooked it, because I read the answer in my mail, where the link was no link ;)