37 lines
2.5 KiB
Markdown
37 lines
2.5 KiB
Markdown
# 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.
|