Roles, goals, permissions, and expected behavior for every consumer of the Settings
module. Permission values are exact from src/modules/rbac/permissions.constants.ts.
Critical caveat: the settings controller carries no @Permissions metadata
(settings.controller.ts:19 — JWT guard only), so settings.read/update/delete
(permissions.constants.ts:75-77) are declared but not enforced today (OQ-2). The UI
still gates on them for forward-compatibility; the server is the authority only for
authentication, not permission.
isPlatformAdmin bypasses the tenant scope entirely (base.repository.ts:21-23; set in jwt-auth.guard.ts:54)
Frequency
On-demand support/diagnostics
Goal
Compare tenant configs; fix a broken setting during support
Restrictions
Platform admin must hold a real tenant JWT; its GET /settings returns all tenants' settings merged (no tenant filter) — the UI must show a "cross-tenant view" warning if surfaced
Org embedded settings (S4 tabs in Organizations module)
✓
—
✓
—
Feature flags (sibling surface)
✓
—
✓
—
Server-side truth: authentication only (JWT). Permission gating is client-side
(route guard reads user.permissions) until @Permissions('settings.*') lands on
settings.controller.ts — mirror the pattern of files.controller.ts:30 /
webhooks.controller.ts:22 when that happens.