organization_id.Tenant boundaries and permission model
¶ Tenancy and RBAC
ReplyBox treats organisation membership as the first boundary, then layers permissions on top. Every user-facing data path should prove both the tenant and the action.
Request boundary
¶ Membership first, permission second
A valid user identity is not enough. Public routes need the organisation boundary and the permission gate for the requested action.
require_permission().RBAC model
¶ Seeded permissions become organisation roles
ReplyBox seeds 16 permissions and 4 system role templates. System roles are read-only in the UI; custom roles are editable.
apps/api/app/seeds/permissions.py.
owner, admin, agent, and viewer.
require_permission().
Documented exception
¶ The disciplinary provider is pinned and narrow
The pinned /api/v1/disciplinary/* provider integration is the documented server-to-server exception.
Fixed bearer tokenAuthentication is provider-specific, not a general user session.
Fixed boundaryIt is limited to its configured organisation and channel.
No inbox accessThe exception does not grant the provider inbox API access.
Deep-linking
¶ Tenant ids are pointers, not grants
External links can point the UI at the right workspace, but they never prove access by themselves.
Include the workspace idLinks such as "View attachments in ReplyBox" must include the target organization/workspace id so page queries target the correct workspace.
Re-check membershipThe API must verify membership on every request, and the frontend should switch active workspace only when the current user is a member.
Do not reveal existenceLack of membership and non-existent organisations should produce the same no-access behaviour.