ahmido
3490fb9e2c
Summary
Implements Spec 067 “RBAC Troubleshooting & Tenant UI Bugfix Pack v1” for the tenant admin plane (/admin) with strict RBAC UX semantics:
Non-member tenant scope ⇒ 404 (deny-as-not-found)
Member lacking capability ⇒ 403 server-side, while the UI stays visible-but-disabled with standardized tooltips
What changed
Tenant view header actions now use centralized UI enforcement (no “normal click → error page” for readonly members).
Archived tenants remain resolvable in tenant-scoped routes for entitled members; an “Archived” banner is shown.
Adds tenant-scoped diagnostics page (/admin/t/{tenant}/diagnostics) with safe repair actions (confirmation + authorization + audit log).
Adds/updates targeted Pest tests to lock the 404 vs 403 semantics and action UX.
Implementation notes
Livewire v4.0+ compliance: Uses Filament v5 + Livewire v4 conventions; widget Blade views render a single root element.
Provider registration: Laravel 11+ providers stay in providers.php (no changes required).
Global search: No global search behavior/resources changed in this PR.
Destructive actions:
Tenant archive/restore/force delete and diagnostics repairs execute via ->action(...) and include ->requiresConfirmation().
Server-side authorization is enforced (non-members 404, insufficient capability 403).
Assets: No new assets. No change to php artisan filament:assets expectations.
Tests
Ran:
vendor/bin/sail bin pint --dirty
vendor/bin/sail artisan test --compact (focused files for Spec 067)
Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box>
Reviewed-on: #84
1.9 KiB
1.9 KiB
Specification Quality Checklist: RBAC Troubleshooting & Tenant UI Bugfix Pack v1
Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-01-31 Feature: spec.md
Content Quality
- No implementation details beyond constitution-required constraints (RBAC semantics, canonical capability registry references)
- Focused on user value and business needs
- Written for non-technical stakeholders (with minimal, clearly-scoped technical constraints where required)
- All mandatory sections completed
Requirement Completeness
- No [NEEDS CLARIFICATION] markers remain
- Requirements are testable and unambiguous
- Success criteria are measurable
- Success criteria are technology-agnostic (no implementation details)
- All acceptance scenarios are defined
- Edge cases are identified
- Scope is clearly bounded
- Dependencies and assumptions identified
Feature Readiness
- All functional requirements have clear acceptance criteria
- User scenarios cover primary flows
- Feature meets measurable outcomes defined in Success Criteria
- No implementation details leak into specification (outside the minimal, constitution-required constraints)
Notes
-
Items marked incomplete require spec updates before
/speckit.clarifyor/speckit.plan -
Open issues identified by consistency analysis:
- Diagnostics + duplicates repair lacks explicit test coverage (spec FR-006).
- Repair actions require explicit audit trail tasks/tests (spec FR-008).
- SC-001 relies on an undefined “standard click paths” set.
- Spec/plan include some implementation-detail language that should be reduced.
-
Status:
- Duplicate membership coverage is addressed by tasks T019 and T023.
- Repair audit trail coverage is addressed by tasks T020 and T023.
- SC-001 was reworded to remove the undefined 95% threshold.
- Plan template placeholders were removed.