Permissions interface

The surface area of the django-tutelary permissions management part of the example application is surprisingly small:

Model annotations

The permissioned_model decorator or function is used to register action names for models and to provide django-tutelary with the information it needs to derive object paths for model instances.

View permissioning

We use the PermissionRequiredMixin in all of our view classes to enable django-tutelary permission checking for them. We only need to derive our own mixin here because we want custom behaviour in “no permissions” cases.

Policy handling

Policies are at the heart of django-tutelary, and all applications using policy-based permissions need to manage them somehow. I’ve tried not to impose any real requirements on this aspect of applications that use django-tutelary: policies are just normal Django models, and you can manage them more or less as you want in your applications. The example application manages django-tutelary policies as just another kind of object, using common CRUD operations (themselves permissioned by django-tutelary).

Custom backend

We need to enable the django-tutelary permissions backend in our settings file. In the example application, we further derive a custom backend to allow for switching between users without authentication for the purposes of the example.