Files
igny8/master-docs/40-product/ROLE-DEFINITIONS.md
IGNY8 VPS (Salman) 3cbed65601 revamps docs complete
2025-12-07 14:14:29 +00:00

2.5 KiB

Role Definitions

Purpose

Define each role available in IGNY8, what it can access, and where those permissions are enforced.

Code Locations (exact paths)

  • Role field: backend/igny8_core/auth/models.py (User.role)
  • Permission classes: backend/igny8_core/auth/permissions.py (IsOwnerOrAdmin, IsEditorOrAbove, IsViewerOrAbove, AccountPermission)
  • Frontend guards: frontend/src/App.tsx (ProtectedRoute, ModuleGuard), frontend/src/store/authStore.ts (role persisted in state)

Roles and Capabilities (backend-enforced)

  • developer: Treated as admin-level for debugging; passes owner/admin checks.
  • owner: Full tenant control (users, billing, plans, sites, automation).
  • admin: Nearly full control; same as owner for most modules except potential business policy differences (not differentiated in code).
  • editor: Can create/update planner/writer/automation configs; cannot perform owner/admin-only billing or team admin actions.
  • viewer: Read-only access where IsViewerOrAbove is applied; cannot mutate resources.
  • system_bot: Reserved for system automation; not typically used via UI; expected to bypass some checks when invoked server-side (still scoped to account).

Enforcement Points

  • DRF permissions: Applied per view/action using classes above; combined with account/site/sector scoping from base viewsets.
  • Middleware: AccountContextMiddleware must set request.account and reject inactive accounts before permissions run.
  • Site scoping: For non-admins, SiteUserAccess limits visible sites in SiteViewSet.

Cross-Module Impact

  • Planner/Writer/Automation: IsEditorOrAbove gates writes; viewers read only.
  • Billing: owner/admin (and developer) expected for invoices/payments/plan changes; editors/viewers not permitted to mutate.
  • Integration: editor+ for connect/test/sync; viewer may read status where allowed.
  • System settings: owner/admin for account/system settings; others limited.

Tenancy Rules

  • Roles operate within the resolved request.account; there is no cross-tenant role scope. API key flows bypass user roles but remain account-scoped.

How Developers Should Work With This Module

  • When adding a new endpoint, pick the minimal role needed and reuse existing permission classes.
  • If introducing finer-grained roles, extend permissions.py centrally and update ModuleGuard to mirror backend expectations.
  • Keep User.role values consistent; avoid hardcoding role strings outside permission helpers.