Context
All team members currently have the same access level. No role-based access control exists for multi-user merchant accounts.
Current Limitation/Problem
Any team member can modify billing settings, delete subscriptions, or change plan configurations. No audit trail per action.
Expected Outcome
RBAC system with predefined roles (Admin, Billing, Support, Viewer) and custom roles with resource-level permissions in resource:action format.
Acceptance Criteria
Permission model: resource:action format (subscription:create, invoice:read, plan:modify, settings:admin)
Predefined roles: Admin (all:), Billing (billing: , invoice:), Support (subscription:read, invoice:read), Viewer ( :read)
Custom roles: create with arbitrary permission set from available permissions
Middleware: requirePermission('subscription:cancel') decorator on all protected endpoints
Role management UI: create/edit/delete roles, assign to users
Permission audit log: record action, actor ID, resource, outcome (allow/deny), timestamp
Edge case: role deleted while users assigned (fallback to Viewer role)
Edge case: permission escalation prevention (user cannot self-promote)
Technical Scope
backend/auth/rbac/ - RBAC service, PermissionRegistry, RoleService
backend/auth/rbac/roles/ - predefined role definitions
backend/auth/middleware/ - requirePermission middleware factory
backend/auth/controller/ - role and permission management REST API
mobile/app/screens/ - RoleManagementScreen
db/schema/ - roles, role_permissions, user_roles tables
Context
All team members currently have the same access level. No role-based access control exists for multi-user merchant accounts.
Current Limitation/Problem
Any team member can modify billing settings, delete subscriptions, or change plan configurations. No audit trail per action.
Expected Outcome
RBAC system with predefined roles (Admin, Billing, Support, Viewer) and custom roles with resource-level permissions in resource:action format.
Acceptance Criteria
Technical Scope