ahmido
d90fb0f963
PR Body Implements Spec 065 “Tenant RBAC v1” with capabilities-first RBAC, tenant membership scoping (Option 3), and consistent Filament action semantics. Key decisions / rules Tenancy Option 3: tenant switching is tenantless (ChooseTenant), tenant-scoped routes stay scoped, non-members get 404 (not 403). RBAC model: canonical capability registry + role→capability map + Gates for each capability (no role-string checks in UI logic). UX policy: for tenant members lacking permission → actions are visible but disabled + tooltip (avoid click→403). Security still enforced server-side. What’s included Capabilities foundation: Central capability registry (Capabilities::*) Role→capability mapping (RoleCapabilityMap) Gate registration + resolver/manager updates to support tenant-scoped authorization Filament enforcement hardening across the app: Tenant registration & tenant CRUD properly gated Backup/restore/policy flows aligned to “visible-but-disabled” where applicable Provider operations (health check / inventory sync / compliance snapshot) guarded and normalized Directory groups + inventory sync start surfaces normalized Policy version maintenance actions (archive/restore/prune/force delete) gated SpecKit artifacts for 065: spec.md, plan/tasks updates, checklists, enforcement hitlist Security guarantees Non-member → 404 via tenant scoping/membership guards. Member without capability → 403 on execution, even if UI is disabled. No destructive actions execute without proper authorization checks. Tests Adds/updates Pest coverage for: Tenant scoping & membership denial behavior Role matrix expectations (owner/manager/operator/readonly) Filament surface checks (visible/disabled actions, no side effects) Provider/Inventory/Groups run-start authorization Verified locally with targeted vendor/bin/sail artisan test --compact … Deployment / ops notes No new services required. Safe change: behavior is authorization + UI semantics; no breaking route changes intended. Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Reviewed-on: #79
35 lines
1.2 KiB
Markdown
35 lines
1.2 KiB
Markdown
# Specification Quality Checklist: Tenant RBAC v1
|
|
|
|
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
|
**Created**: 2026-01-27
|
|
**Feature**: [specs/065-tenant-rbac-v1/spec.md](specs/065-tenant-rbac-v1/spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [X] No implementation details (languages, frameworks, APIs)
|
|
- [X] Focused on user value and business needs
|
|
- [X] Written for non-technical stakeholders
|
|
- [X] All mandatory sections completed
|
|
|
|
## Requirement Completeness
|
|
|
|
- [X] No [NEEDS CLARIFICATION] markers remain
|
|
- [X] Requirements are testable and unambiguous
|
|
- [X] Success criteria are measurable
|
|
- [X] Success criteria are technology-agnostic (no implementation details)
|
|
- [X] All acceptance scenarios are defined
|
|
- [X] Edge cases are identified
|
|
- [X] Scope is clearly bounded
|
|
- [X] Dependencies and assumptions identified
|
|
|
|
## Feature Readiness
|
|
|
|
- [X] All functional requirements have clear acceptance criteria
|
|
- [X] User scenarios cover primary flows
|
|
- [X] Feature meets measurable outcomes defined in Success Criteria
|
|
- [X] No implementation details leak into specification
|
|
|
|
## Notes
|
|
|
|
- The provided spec is very detailed and already meets all quality criteria. No issues were found.
|