permissible 0.3.1__tar.gz

permissible-0.3.1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Gaussian
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

permissible-0.3.1/PKG-INFO

@@ -0,0 +1,164 @@
+Metadata-Version: 2.2
+Name: permissible
+Version: 0.3.1
+Summary: Extended, flexible and powerful object-level and rule-driven permissions for Django & Django REST framework
+Project-URL: Homepage, https://github.com/gaussian/permissible
+Project-URL: Issues, https://github.com/gaussian/permissible/issues
+Requires-Python: >=3.12
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: Django<6,>=5
+Requires-Dist: djangorestframework>=3
+Requires-Dist: django-guardian
+Requires-Dist: djangorestframework-guardian
+
+`permissible` is a module to make it easier to configure object-level permissions,
+and to help unify the different places performing permissions checks (including DRF
+and Django admin) to create a full permissions check that can work without any
+further architectural pondering.
+
+It is built on top of django-guardian but can be easily configured for other
+object-level libraries.
+
+
+# Introduction
+
+This module allows us to define permission requirements in our Models
+(similarly to how django-rules does it in Model.Meta). Given that different
+view engines (e.g. DRF vs Django's admin) have different implementations for
+checking permissions, this allows us to centralize the permissions
+configuration and keep the code clear and simple. This approach also allows
+us to unify permissions checks across both Django admin and DRF (and indeed
+any other place you use PermissibleMixin).
+
+# Installation
+
+Install with `pip install https://github.com/gaussian/permissible.git`.
+
+
+# Features
+
+## Feature 1: Consistent permissions configuration
+
+In its simplest form, `permissible` can be used just for its permissions
+configuration. This has no impact on your database, and does not rely on any
+particular object-level permissions library. (It does require one; we prefer
+django-guardian.)
+
+Here, we add the `PermissibleMixin` to each model we want to protect, and
+define "permissions maps" that define what permissions are needed for each action
+that is taken on an object in the model (e.g. a "retrieve" action on a "survey").
+(We can also use classes like `PermissibleSelfOnlyMixin` to define good default
+permission maps for our models.)
+
+With the permissions configured, now we can force different views to use them:
+- If you would like the permissions to work for API views (via
+django-rest-framework): Add `PermissiblePerms` to the `permission_classes` for
+the viewsets for our models
+- If you would like the permissions to work in the Django admin: Add
+`PermissibleAdminMixin` to the admin classes for our models
+
+That's it. Actions are now protected by permissions checks. But there is no easy
+way to create the permissions in the first place. That's where the next two
+features come in.
+
+
+## Feature 2: Simple permissions assignment using "root" models
+
+The `permissible` library can also help automatically assign permissions based on
+certain "root" models. The root model is the model we should check permissions
+against. For instance, the root model for a "project file" might be a "project",
+in which case having certain permissions on the "project" would confer other
+permissions for the "project files", even though no specific permission exists
+for the "project file".
+Of course, it's easy to link a "project" to a "project file" through a foreign key.
+But `permissible` solves the problem of tying this to the Django `Group` model,
+which is what we use for permissions.
+
+To accomplish this, `permissible` provides two base model classes that you should use:
+1. **`PermRoot`**: Make the root model (e.g. `Team`) derive from `PermRoot`
+2. **`PermRootGroup`**: Create a new model that derives from `PermRootGroup`
+and has a `ForeignKey` to the root model
+
+You can then simply adjust your permissions maps in `PermissibleMixin` to
+incorporate checking of the root model for permissions. See the documentation for
+`PermDef` and `PermissibleMixin.has_object_permissions` for info and examples.
+
+You can also use `PermRootAdminMixin` to help you manage the `PermRoot` records.
+
+
+## Feature 3: Assignment on record creation
+
+`permissible` can automatically assign object permissions on object creation,
+through use of 3 view-related mixins:
+- `admin.PermissibleObjectAssignMixin` (for admin classes - give creating user all
+permissions)
+- `serializers.PermissibleObjectAssignMixin` (for serializers - give creating user
+all permissions)
+- `serializers.PermissibleRootObjectAssignMixin` (for serializers for root models
+like "Team" or "Project - add creating user to all root model's Groups)
+
+NOTE: this feature is dependent on django-guardian, as it uses the `assign_perm`
+shortcut. Also, `admin.PermissibleObjectAssignMixin` extends the
+`ObjectPermissionsAssignmentMixin` mixin from djangorestframework-guardian.
+
+
+# Full instructions
+
+1. 
+
+
+# Example flow
+
+- The application has the following models:
+    - `User` (inherits Django's base abstract user model)
+    - `Group` (Django's model)
+    - `Team` (inherits `PermRoot`)
+    - `TeamGroup` (inherits `PermRootGroup`)
+    - `TeamInfo` (contains a foreign key to `Team`)
+   
+### Create a team
+ - A new team is created (via Django admin), which triggers the creation of appropriate
+ groups and assignment of permissions:
+    - `Team.save()` creates several `TeamGroup` records, one for each possible role
+    (e.g. member, owner)
+    - For each `TeamGroup`, the `save()` method triggers the creation of a new `Group`,
+    and assigns permissions to each of these groups, in accordance with
+    `PermRootGroup.role_definitions`:
+        - `TeamGroup` with "Member" role is given no permissions
+        - `TeamGroup` with "Viewer" role is given "view_team" permission
+        - `TeamGroup` with "Contributor" role is given "contribute_to_team" and "view_team"
+        permissions
+        - `TeamGroup` with "Admin" role is given "change_team", "contribute_to_team" and
+        "view_team" permissions
+        - `TeamGroup` with "Owner" role is given "delete", "change_team", "contribute_to_team"
+        and "view_team" permissions
+        - (NOTE: this behavior can be customized)
+    - Note that no one is given permission to create `Team` to begin with - it must have
+    been created by a superuser or someone who was manually given such permission in the admin
+
+### Create a user
+- A new user is created (via Django admin), and added to the relevant groups (e.g. members, admins)
+
+### Edit a team-related record
+- The user tries to edit a `TeamInfo` record, either via API (django-rest-framework) or Django
+ admin, triggering the following checks:
+    - View/viewset checks global permissions
+    - View/viewset checks object permissions:
+        - Checking object permission directly FAILS (as this user was not given any permission for
+        this object in particular)
+        - Checking permission for root object (i.e. team) SUCCEEDS if the user was added to the
+        correct groups
+
+### Create a team-related record
+- The user tries to create a `TeamInfo` record, either via API (django-rest-framework) or Django
+ admin, triggering the following checks:
+    - View/viewset checks global permissions
+    - View/viewset checks creation permissions:
+        - Checking object permission directly FAILS as this object doesn't have an ID yet, so
+        can't have any permissions associated with it
+        - Checking permission for root object (i.e. team) SUCCEEDS if the user was added to the
+        correct groups
+    - View/viewset does not check object permission (this is out of our control, and makes sense
+    as there is no object)
+- Upon create

permissible-0.3.1/README.md

@@ -0,0 +1,150 @@
+`permissible` is a module to make it easier to configure object-level permissions,
+and to help unify the different places performing permissions checks (including DRF
+and Django admin) to create a full permissions check that can work without any
+further architectural pondering.
+
+It is built on top of django-guardian but can be easily configured for other
+object-level libraries.
+
+
+# Introduction
+
+This module allows us to define permission requirements in our Models
+(similarly to how django-rules does it in Model.Meta). Given that different
+view engines (e.g. DRF vs Django's admin) have different implementations for
+checking permissions, this allows us to centralize the permissions
+configuration and keep the code clear and simple. This approach also allows
+us to unify permissions checks across both Django admin and DRF (and indeed
+any other place you use PermissibleMixin).
+
+# Installation
+
+Install with `pip install https://github.com/gaussian/permissible.git`.
+
+
+# Features
+
+## Feature 1: Consistent permissions configuration
+
+In its simplest form, `permissible` can be used just for its permissions
+configuration. This has no impact on your database, and does not rely on any
+particular object-level permissions library. (It does require one; we prefer
+django-guardian.)
+
+Here, we add the `PermissibleMixin` to each model we want to protect, and
+define "permissions maps" that define what permissions are needed for each action
+that is taken on an object in the model (e.g. a "retrieve" action on a "survey").
+(We can also use classes like `PermissibleSelfOnlyMixin` to define good default
+permission maps for our models.)
+
+With the permissions configured, now we can force different views to use them:
+- If you would like the permissions to work for API views (via
+django-rest-framework): Add `PermissiblePerms` to the `permission_classes` for
+the viewsets for our models
+- If you would like the permissions to work in the Django admin: Add
+`PermissibleAdminMixin` to the admin classes for our models
+
+That's it. Actions are now protected by permissions checks. But there is no easy
+way to create the permissions in the first place. That's where the next two
+features come in.
+
+
+## Feature 2: Simple permissions assignment using "root" models
+
+The `permissible` library can also help automatically assign permissions based on
+certain "root" models. The root model is the model we should check permissions
+against. For instance, the root model for a "project file" might be a "project",
+in which case having certain permissions on the "project" would confer other
+permissions for the "project files", even though no specific permission exists
+for the "project file".
+Of course, it's easy to link a "project" to a "project file" through a foreign key.
+But `permissible` solves the problem of tying this to the Django `Group` model,
+which is what we use for permissions.
+
+To accomplish this, `permissible` provides two base model classes that you should use:
+1. **`PermRoot`**: Make the root model (e.g. `Team`) derive from `PermRoot`
+2. **`PermRootGroup`**: Create a new model that derives from `PermRootGroup`
+and has a `ForeignKey` to the root model
+
+You can then simply adjust your permissions maps in `PermissibleMixin` to
+incorporate checking of the root model for permissions. See the documentation for
+`PermDef` and `PermissibleMixin.has_object_permissions` for info and examples.
+
+You can also use `PermRootAdminMixin` to help you manage the `PermRoot` records.
+
+
+## Feature 3: Assignment on record creation
+
+`permissible` can automatically assign object permissions on object creation,
+through use of 3 view-related mixins:
+- `admin.PermissibleObjectAssignMixin` (for admin classes - give creating user all
+permissions)
+- `serializers.PermissibleObjectAssignMixin` (for serializers - give creating user
+all permissions)
+- `serializers.PermissibleRootObjectAssignMixin` (for serializers for root models
+like "Team" or "Project - add creating user to all root model's Groups)
+
+NOTE: this feature is dependent on django-guardian, as it uses the `assign_perm`
+shortcut. Also, `admin.PermissibleObjectAssignMixin` extends the
+`ObjectPermissionsAssignmentMixin` mixin from djangorestframework-guardian.
+
+
+# Full instructions
+
+1. 
+
+
+# Example flow
+
+- The application has the following models:
+    - `User` (inherits Django's base abstract user model)
+    - `Group` (Django's model)
+    - `Team` (inherits `PermRoot`)
+    - `TeamGroup` (inherits `PermRootGroup`)
+    - `TeamInfo` (contains a foreign key to `Team`)
+   
+### Create a team
+ - A new team is created (via Django admin), which triggers the creation of appropriate
+ groups and assignment of permissions:
+    - `Team.save()` creates several `TeamGroup` records, one for each possible role
+    (e.g. member, owner)
+    - For each `TeamGroup`, the `save()` method triggers the creation of a new `Group`,
+    and assigns permissions to each of these groups, in accordance with
+    `PermRootGroup.role_definitions`:
+        - `TeamGroup` with "Member" role is given no permissions
+        - `TeamGroup` with "Viewer" role is given "view_team" permission
+        - `TeamGroup` with "Contributor" role is given "contribute_to_team" and "view_team"
+        permissions
+        - `TeamGroup` with "Admin" role is given "change_team", "contribute_to_team" and
+        "view_team" permissions
+        - `TeamGroup` with "Owner" role is given "delete", "change_team", "contribute_to_team"
+        and "view_team" permissions
+        - (NOTE: this behavior can be customized)
+    - Note that no one is given permission to create `Team` to begin with - it must have
+    been created by a superuser or someone who was manually given such permission in the admin
+
+### Create a user
+- A new user is created (via Django admin), and added to the relevant groups (e.g. members, admins)
+
+### Edit a team-related record
+- The user tries to edit a `TeamInfo` record, either via API (django-rest-framework) or Django
+ admin, triggering the following checks:
+    - View/viewset checks global permissions
+    - View/viewset checks object permissions:
+        - Checking object permission directly FAILS (as this user was not given any permission for
+        this object in particular)
+        - Checking permission for root object (i.e. team) SUCCEEDS if the user was added to the
+        correct groups
+
+### Create a team-related record
+- The user tries to create a `TeamInfo` record, either via API (django-rest-framework) or Django
+ admin, triggering the following checks:
+    - View/viewset checks global permissions
+    - View/viewset checks creation permissions:
+        - Checking object permission directly FAILS as this object doesn't have an ID yet, so
+        can't have any permissions associated with it
+        - Checking permission for root object (i.e. team) SUCCEEDS if the user was added to the
+        correct groups
+    - View/viewset does not check object permission (this is out of our control, and makes sense
+    as there is no object)
+- Upon create

permissible-0.3.1/permissible/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.3.1"

permissible-0.3.1/permissible/admin.py

@@ -0,0 +1,160 @@
+"""
+`permissible` (a `neutron` module by Gaussian)
+Author: Kut Akdogan & Gaussian Holdings, LLC. (2016-)
+"""
+
+from collections import OrderedDict
+from itertools import chain
+
+from django.contrib import admin
+from django.contrib.admin.widgets import AutocompleteSelect
+from django.contrib.auth import get_user_model
+from django.core.exceptions import ValidationError
+from django import forms
+from django.http import Http404
+from django.template.response import TemplateResponse
+from django.urls import path, reverse
+from django.utils.html import format_html
+
+from .models import PermissibleMixin
+
+User = get_user_model()
+
+
+class PermissibleAdminMixin(object):
+    """
+    Restricts viewing, editing, changing, and deleting on an object to those
+    who have the necessary permissions for that object.
+
+    Models that are to be protected in this way should use `PermissibleMixin`,
+    and the necessary permissions should be configured using `global_action_perm_map`
+    and `obj_action_perm_map` from that mixin.
+
+    Requires use of an object-level permissions library/schema such as
+    django-guardian.
+    """
+
+    def _has_permission(self, action: str, request, obj: PermissibleMixin):
+        assert issubclass(self.model, PermissibleMixin), \
+            "Must use `PermissibleMixin` on the model class"
+
+        # Permission checks
+        perm_check_kwargs = {
+            "user": request.user,
+            "action": action,
+            "context": {"request": request}
+        }
+        if not obj:
+            if not self.model.has_global_permission(**perm_check_kwargs):
+                return False
+            if action != "create":
+                # Not sure how we"d reach here...
+                return False
+            # For "create" action, we must create a dummy object from request data
+            # and use it to check permissions against
+            obj = self.model.make_objs_from_data(request.data)[0]
+        return obj.has_object_permission(**perm_check_kwargs)
+
+    def has_add_permission(self, request, obj=None):
+        return self._has_permission("create", request=request, obj=obj)
+
+    def has_change_permission(self, request, obj=None):
+        return self._has_permission("update", request=request, obj=obj)
+
+    def has_delete_permission(self, request, obj=None):
+        return self._has_permission("destroy", request=request, obj=obj)
+
+    def has_view_permission(self, request, obj=None):
+        return self._has_permission("retrieve", request=request, obj=obj) or \
+               self._has_permission("update", request=request, obj=obj)
+
+
+class PermissibleObjectAssignMixin(object):
+    pass
+
+
+class PermRootForm(forms.Form):
+    add = forms.BooleanField(initial=True, required=False, label="Add groups (uncheck to remove)")
+
+    def __init__(self, perm_root_class, *args, **kwargs):
+        super().__init__(*args, **kwargs)
+
+        perm_root_group_class = perm_root_class.get_group_join_rel().related_model
+        role_choices = ((role_value, role_label)
+                        for role_value, (role_label, _) in perm_root_group_class.ROLE_DEFINITIONS.items())
+
+        # Get related field, to make an autocomplete widget
+        users_field = perm_root_class._meta.get_field("users")
+
+        self.fields.update(dict(
+            user=forms.ModelChoiceField(queryset=User.objects.all(),
+                                        widget=AutocompleteSelect(users_field, admin.site)),
+            roles=forms.MultipleChoiceField(choices=role_choices)
+        ))
+
+
+class PermRootAdminMixin(object):
+    def get_urls(self):
+        urls = super().get_urls()
+        custom_urls = [
+            path("<object_id>/permissible/", self.admin_site.admin_view(self.permissible_view), name=self.get_permissible_change_url_name())
+        ]
+        return custom_urls + urls
+
+    def permissible_view(self, request, object_id):
+        obj = self.model.objects.get(pk=object_id)
+
+        if not self.has_change_permission(request=request, obj=obj):
+            raise Http404("Lacking permission")
+
+        if request.method == "POST":
+            form = PermRootForm(self.model, request.POST)
+            if form.is_valid():
+                roles = form.cleaned_data["roles"] or []
+                if not request.user.is_superuser and any(r in roles for r in ("adm", "own")):
+                    raise ValidationError(f"Bad roles, must be superuser: {roles}")
+                user = form.cleaned_data["user"]
+                if form.cleaned_data["add"]:
+                    obj.add_user_to_groups(user=user, roles=roles)
+                else:
+                    obj.remove_user_from_groups(user=user, roles=roles)
+        else:
+            form = PermRootForm(self.model)
+
+        unordered_role_to_users = {perm_root_group.role: [
+            str(u) for u in perm_root_group.group.user_set.values_list(User.USERNAME_FIELD, flat=True)
+        ] for perm_root_group in obj.get_group_joins().all()}
+
+        base_roles = ("own", "adm", "con", "view", "mem")
+        role_to_users = OrderedDict()
+        for role in base_roles:
+            role_to_users[role] = unordered_role_to_users.get(role, [])
+        for role in unordered_role_to_users.keys():
+            if role not in base_roles:
+                role_to_users[role] = unordered_role_to_users.get(role, [])
+
+        users = list(set(chain(*role_to_users.values())))
+
+        context = {
+            "title": f"Add users to permissible groups of {obj}",
+            "form": form,
+            "role_to_users": role_to_users,
+            "users": users,
+            "opts": self.model._meta,
+            # Include common variables for rendering the admin template.
+            **self.admin_site.each_context(request),
+        }
+        return TemplateResponse(request, "admin/permissible_changeform.html", context)
+
+    readonly_fields = (
+        "permissible_groups_link",
+    )
+
+    def get_permissible_change_url_name(self):
+        return "%s_%s_permissible_change" % (self.model._meta.app_label, self.model._meta.model_name)
+
+    def permissible_groups_link(self, obj):
+        url = reverse("admin:" + self.get_permissible_change_url_name(), args=(obj.pk,))
+        link_text = "Edit permissible groups"
+        html_format_string = "<a href=' {url}'>{link_text}</a>"     # SPACE IS NEEDED!
+        return format_html(html_format_string, url=url, text=link_text)

permissible-0.3.1/permissible/features/environment.py

@@ -0,0 +1,3 @@
+# TODO: make this more DRY
+def before_scenario(context, scenario):
+    context.responses = []

permissible-0.3.1/permissible/filters.py

@@ -0,0 +1,84 @@
+"""
+`permissible` (a `neutron` module by Gaussian)
+Author: Kut Akdogan & Gaussian Holdings, LLC. (2016-)
+"""
+
+from django.conf import settings
+from rest_framework import filters
+from rest_framework.exceptions import PermissionDenied
+from rest_framework_guardian.filters import ObjectPermissionsFilter
+
+
+class PermissibleFilter(ObjectPermissionsFilter):
+    """
+    Same as django-rest-framework-guardian's `ObjectPermissionsFilter`,
+    but does not perform filtering for detail routes (i.e. routes that
+    retrieve a specific object).
+    """
+
+    def filter_queryset(self, request, queryset, view):
+        if view.detail:
+            return queryset
+        else:
+            return super().filter_queryset(request, queryset, view)
+
+
+class PermissibleRootFilter(filters.BaseFilterBackend):
+    """
+    For a defined set of fields on the view (`view.filter_perm_fields`),
+    check permission on each field AND filter down to that field.
+
+    e.g. for listable "survey questions", we might want to return those
+    survey questions that are owned by "surveys" to which this user has
+    access
+
+    NOTE: as with `PermissibleFilter`, we do not perform filtering for
+    detail routes (i.e. routes that retrieve a specific object).
+    """
+
+    def filter_queryset(self, request, queryset, view):
+        if view.detail:
+            return queryset
+
+        assert hasattr(view, "filter_perm_fields"), \
+            "Badly configured view, need `filter_perm_fields`."
+
+        assert not any("__" in f for f in view.filter_perm_fields), \
+            f"Cannot yet accommodate joined fields in `PermissibleRootFilter`: {view.filter_perm_fields}"
+
+        # For each "permission" field, check permissions, then filter the queryset
+        for perm_filterset_fields, needed_short_perm_code in view.filter_perm_fields:
+
+            # Get related object (e.g. "Team" from "team_id"), nested if need be
+            model_class = queryset.model
+            related_obj = None
+            if not isinstance(perm_filterset_fields, (tuple, list)):
+                perm_filterset_fields = (perm_filterset_fields,)
+            field_for_filter, pk_for_filter = None, None
+            for i, perm_filterset_field in enumerate(perm_filterset_fields):
+                related_model = model_class._meta.get_field(perm_filterset_field).related_model
+                # First item - get the ID value from the query params object
+                if i == 0:
+                    related_pk = request.query_params.get(perm_filterset_field)
+                    field_for_filter = perm_filterset_field
+                    pk_for_filter = related_pk
+                # Not the first item, i.e. this is nested - get ID value by traversing the nesting
+                else:
+                    related_obj.refresh_from_db()
+                    related_pk = getattr(related_obj, perm_filterset_field)
+                related_obj = related_model(pk=related_pk)
+                model_class = related_model
+
+            # Check permission for related object
+            perm = f"{related_model._meta.app_label}.{needed_short_perm_code}_{related_model._meta.model_name}"
+            if not request.user.has_perm(perm, related_obj):
+                message = "Permission denied in filter"
+                if settings.DEBUG or settings.IS_TEST:
+                    message += f" - {perm}"
+                raise PermissionDenied(message)
+
+            # Filter, but only by the first perm_filterset_field (`field_for_filter`,
+            # the one that is not nested) as we followed the chain of ownership
+            queryset = queryset.filter(**{field_for_filter: pk_for_filter})
+
+        return queryset

permissible-0.3.1/permissible/models/__init__.py

@@ -0,0 +1,5 @@
+from .perm_root import PermRootGroup, PermRoot, PermRootUser, build_role_field
+from .base import BasePermRoot, PermRootModelMetaclass
+from .permissible_mixin import PermissibleMixin, PermissibleSelfOnlyMixin, PermissibleRootOnlyMixin, \
+    PermissibleBasicRootOnlyMixin, PermissibleSelfOrRootMixin, PermissibleDenyDefaultMixin
+# from .tests import TestPermissibleFromSelf, TestPermRoot, TestPermRootGroup, TestPermRootUser, TestPermissibleFromRoot

permissible-0.3.1/permissible/models/base.py

@@ -0,0 +1,28 @@
+"""
+`permissible` (a `neutron` module by Gaussian)
+Author: Kut Akdogan & Gaussian Holdings, LLC. (2016-)
+"""
+
+from django.db import models
+
+from .permissible_mixin import PermissibleMixin
+from .metaclasses import AbstractModelMetaclass, ExtraPermModelMetaclass
+
+
+class PermRootModelMetaclass(ExtraPermModelMetaclass, AbstractModelMetaclass):
+    permission_definitions = (
+        ("add_on_{}", "Can add related records onto {}"),
+        ("change_on_{}", "Can change related records on {}"),
+        ("change_permission_{}", "Can change permissions of {}"),
+    )
+
+
+class BasePermRoot(PermissibleMixin, models.Model, metaclass=PermRootModelMetaclass):
+    """
+    A model that acts as the root for a permission hierarchy. This model is primarily
+    used as a base class for PermRoot (which has considerable functionality), but
+    can also be used directly as a way to add root object permissions without
+    the associated PermRootGroup and PermRootUser models and functionality.
+    """
+    class Meta:
+        abstract = True

permissible-0.3.1/permissible/models/metaclasses.py

@@ -0,0 +1,32 @@
+"""
+`permissible` (a `neutron` module by Gaussian)
+Author: Kut Akdogan & Gaussian Holdings, LLC. (2016-)
+"""
+
+from abc import ABCMeta
+from typing import Iterable, Tuple
+
+from django.db import models
+
+
+class AbstractModelMetaclass(ABCMeta, models.base.ModelBase):
+    pass
+
+
+class ExtraPermModelMetaclass(models.base.ModelBase):
+    """
+    Metaclass to allow model to automatically create extra permissions.
+    """
+    permission_definitions = ()     # type: Iterable[Tuple[str, str]]
+
+    def __new__(mcs, name, bases, attrs):
+        new_class = super().__new__(mcs, name, bases, attrs)
+
+        new_class._meta.permissions = new_class._meta.permissions or tuple()
+        new_class._meta.permissions += tuple(
+            (codename.format(new_class._meta.model_name), description.format(new_class._meta.verbose_name))
+            for codename, description in mcs.permission_definitions
+        )
+        new_class._meta.original_attrs["permissions"] = new_class._meta.permissions
+
+        return new_class