Roles, permissions and feature flags

pleate_backend.rbac builds on Django auth instead of replacing it. A role is a Django Group with a RoleInfo row (description, is_default); global permissions keep working through ModelBackend; ObjectPermissionBackend adds permissions on single objects, held by a user directly or through a role. Feature flags live in the same app because they answer the same question: may this user see this?

In Python

from pleate_backend.rbac.services import (
    assign_role, remove_role, set_roles, has_role,
    grant, revoke, users_with_perm, clear_object_permissions,
    feature_enabled, enabled_features,
)

assign_role(user, "editor")
set_roles(user, ["editor", "viewer"])
has_role(user, "editor")                           # True

grant(user, "catalog.change_product", product)     # this product only
grant(editors_group, "catalog.view_product", product)
user.has_perm("catalog.change_product", product)   # object level, through the backend
users_with_perm("catalog.change_product", product)
clear_object_permissions(product)                  # before deleting it

feature_enabled(user, "new-editor")

Roles flagged is_default are given to every new account (on user_signed_up), which is the usual way to grant a baseline such as catalog.view_product.

Permission classes

pleate_backend.rbac.permissions provides DRF permission factories. Each call returns a class, so they compose with | and & like DRF's own.

from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated
from pleate_backend.rbac.permissions import HasFeature, HasObjectPerm, HasRole, ModelPerm

class ProductViewSet(viewsets.ModelViewSet):
    # Read for everyone with view_product, write with add/change/delete_product
    permission_classes = [IsAuthenticated, ModelPerm("catalog.product")]

class PriceViewSet(viewsets.ModelViewSet):
    # Managers, or anyone granted change_price on that specific price list
    permission_classes = [IsAuthenticated, HasRole("manager") | HasObjectPerm("catalog.change_price")]

class InsightsView(APIView):
    permission_classes = [IsAuthenticated, HasFeature("insights")]

On the frontend

/auth/me carries extra.roles, extra.permissions (sorted global app.codename strings) and extra.features, so the UI can hide what the API would refuse:

const { hasPermission, hasRole, hasFeature } = useMe();

{hasPermission("catalog.change_product") && <Button>Edit</Button>}
{hasFeature("new-editor") ? <NewEditor /> : <Editor />}

Feature flags

A flag is on for a user when any of these holds:

The rollout bucket is sha256("<key>:<user id>") % 100: stable for a user, independent between flags, and raising the percentage only adds users, never swaps them.

Endpoints

Mounted at /api/rbac. Role and permission endpoints need is_staff or auth.change_group; flag management needs is_staff or the matching pleate_rbac.*_feature permission. All of them except features/me need a signed in session: an API key gets api_key_not_allowed.

Without superuser rights you can only put permissions you hold yourself in a role, edit, delete, give or take roles whose permissions you hold, never change your own roles, and never set or unset is_default.

Error codes

Most are validation codes: the response is a validation_error and the code sits on the field in fields.

The admin registers Group (with its RoleInfo inline), RoleInfo, ObjectPermission and Feature. There are no settings.