ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

spec: clarify 066 rbac ui enforcement defaults

Browse Source
This commit is contained in:
Ahmed Darrazi 2026-01-28 23:22:54 +01:00
parent e5ad9b6cf8
commit 07dda36d6e
1 changed files with 12 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
specs/066-rbac-ui-enforcement-helper/spec.md
View File

@ -5,6 +5,14 @@ # Feature Specification: RBAC UI Enforcement Helper v1
**Status**: Draft **Status**: Draft
**Input**: Provide a suite-wide, consistent way to enforce tenant RBAC for admin UI actions (buttons/actions in lists, records, and bulk actions) without copy/paste authorization logic. **Input**: Provide a suite-wide, consistent way to enforce tenant RBAC for admin UI actions (buttons/actions in lists, records, and bulk actions) without copy/paste authorization logic.
## Clarifications
### Session 2026-01-28
- Q: For Bulk Actions with mixed-permission records (some authorized, some not), what should the default behavior be? → A: All-or-nothing (if any selected record would be unauthorized, the bulk action is disabled for members and execution fails with 403 for members / 404 for non-members).
- Q: Should the helper render actions at all for non-members (in case a tenant page is reachable via misrouting), or always hide them? → A: Hide for non-members in UI, but still enforce 404 server-side for any execution attempt.
- Q: How strict should the “no ad-hoc authorization patterns in app/Filament/**” guard be in v1? → A: CI-failing (new ad-hoc patterns fail tests/CI).
## User Scenarios & Testing *(mandatory)* ## User Scenarios & Testing *(mandatory)*
<!-- <!--
@ -75,7 +83,7 @@ ### Edge Cases
- Membership is revoked while the user has the page open (execution must still enforce 404 semantics). - Membership is revoked while the user has the page open (execution must still enforce 404 semantics).
- Capability changes mid-session (UI may be stale; server enforcement remains correct). - Capability changes mid-session (UI may be stale; server enforcement remains correct).
- Bulk actions with mixed-permission records (the safe default behavior is enforced consistently). - Bulk actions with mixed-permission records: all-or-nothing (disable + tooltip for members; 403 on execution for members; 404 semantics for non-members).
- Target record is deleted/archived between render and execution (no information leakage in errors). - Target record is deleted/archived between render and execution (no information leakage in errors).
## Requirements *(mandatory)* ## Requirements *(mandatory)*
@ -109,6 +117,7 @@ ### Functional Requirements
- **FR-001**: The system MUST provide a single, centrally maintained enforcement mechanism that can be applied to tenant-scoped admin actions (including header actions, record actions, and bulk actions). - **FR-001**: The system MUST provide a single, centrally maintained enforcement mechanism that can be applied to tenant-scoped admin actions (including header actions, record actions, and bulk actions).
- **FR-002**: For tenant-scoped actions, the system MUST enforce membership as deny-as-not-found: users not entitled to the tenant scope MUST receive 404 semantics for action execution. - **FR-002**: For tenant-scoped actions, the system MUST enforce membership as deny-as-not-found: users not entitled to the tenant scope MUST receive 404 semantics for action execution.
- **FR-002a**: For users not entitled to the tenant scope, the UI SHOULD NOT render tenant-scoped actions (default: hidden), while server-side execution MUST still enforce 404 semantics.
- **FR-003**: For tenant members, the system MUST enforce capability denial as 403 when executing an action without permission. - **FR-003**: For tenant members, the system MUST enforce capability denial as 403 when executing an action without permission.
- **FR-004**: For tenant members lacking capability, the UI MUST render actions as visible-but-disabled and MUST show a standard tooltip explaining the missing permission. - **FR-004**: For tenant members lacking capability, the UI MUST render actions as visible-but-disabled and MUST show a standard tooltip explaining the missing permission.
- **FR-005**: The enforcement mechanism MUST also enforce the same rules server-side (UI state is never sufficient). - **FR-005**: The enforcement mechanism MUST also enforce the same rules server-side (UI state is never sufficient).
@ -119,7 +128,8 @@ ### Functional Requirements
- 403 responses for insufficient capability without object details. - 403 responses for insufficient capability without object details.
- **FR-009**: v1 MUST include limited adoption by migrating 3–6 exemplar action surfaces to the new pattern to prove the approach. - **FR-009**: v1 MUST include limited adoption by migrating 3–6 exemplar action surfaces to the new pattern to prove the approach.
- **FR-010**: v1 MUST include regression tests that cover: non-member → 404, member without capability → disabled UI + 403 on execution, member with capability → allowed. - **FR-010**: v1 MUST include regression tests that cover: non-member → 404, member without capability → disabled UI + 403 on execution, member with capability → allowed.
- **FR-011**: v1 SHOULD include an automated guard that flags new ad-hoc authorization patterns in tenant-scoped admin UI code. - **FR-010a**: For bulk actions with mixed-permission records, the default behavior MUST be all-or-nothing (members see disabled + tooltip; execution denies with 403; non-members receive 404 semantics).
- **FR-011**: v1 MUST include an automated, CI-failing guard that flags new ad-hoc authorization patterns in tenant-scoped admin UI code.
- **FR-012**: The enforcement mechanism MUST avoid introducing avoidable performance regressions (no per-record membership lookups during render). - **FR-012**: The enforcement mechanism MUST avoid introducing avoidable performance regressions (no per-record membership lookups during render).
- **FR-013**: The enforcement mechanism MUST NOT trigger outbound HTTP calls during render; it is DB-only. - **FR-013**: The enforcement mechanism MUST NOT trigger outbound HTTP calls during render; it is DB-only.