OUTCOMES
What this Prompt helps you deliver
- The role-permission matrix is explicit
- Backend and client authorization boundaries agree
BEFORE YOU START
Before you start
- The customer organization structure is described
- Key actions and sensitive data are listed
What AI should inspect first
docs/principleapps/tabtin_djangoapps/tabtin-electronREADY TO RUN
Complete Prompt
Copy the complete Prompt with its execution and acceptance boundaries.
Adapt TabTin authorization for my business after understanding the Organization tenant boundary and Workspace/Project relationship. Read AGENTS.md, docs/principle, apps/tabtin_django, and apps/tabtin-electron. Collect user types, hierarchy, domain objects, sensitive fields, actions, and approvals. Map current membership, query filtering, backend checks, and client visibility. Never weaken cross-Organization isolation or substitute UI hiding for authorization.
Create a role × action matrix for view, create, edit, delete, export, and grant. Reuse OrganizationMember and domain services where possible; new access is deny-by-default and least privilege. Enforce authorization consistently in queries, object access, APIs, background jobs, and exports. Clients may tailor available actions but must handle 401, 403, and missing resources. Keep API evolution additive: optional fields and safe defaults for released clients.
Test owner, administrator, editor, viewer, non-member, and cross-Organization access over lists, details, jobs, and exports. Revoke membership and verify sessions/caches lose access. Report the matrix, backend/client gates, compatibility conclusion, evidence, and high-risk decisions. Never use superuser as a normal flow or create migrations/commits without request.