4.0 KiB
Tasks for Feature: Tenant RBAC v1
This document outlines the implementation tasks for the Tenant RBAC v1 feature, ordered by dependency.
Phase 1: Setup & Database
- T001 Create migration for
tenant_membershipstable indatabase/migrations/ - T002 Create
TenantMembershipmodel inapp/Models/TenantMembership.php - T003 Add relationships to
UserandTenantmodels forTenantMembershipinapp/Models/User.phpandapp/Models/Tenant.php - T004 Create
TenantMembershipFactoryindatabase/factories/TenantMembershipFactory.php
Phase 2: Foundational RBAC Core
- T005 [P] Create a
TenantCapabilitiesenum or class to register all capabilities inapp/Enums/TenantCapabilities.php - T006 [P] Create a service or helper to map roles to capabilities in
app/Services/RBAC/RoleMapper.php - T007 Register the core
tenant.canGate inapp/Providers/AuthServiceProvider.php - T008 [P] Create
TenantMembershipPolicyinapp/Policies/TenantMembershipPolicy.php - T009 Register
TenantMembershipPolicyinapp/Providers/AuthServiceProvider.php - T010 Create unit test for role-capability mapping in
tests/Unit/TenantRBACTest.php
Phase 3: User Story 1 - Membership Management UI
Goal: As a Tenant Owner, I want to manage members and their roles. Independent Test Criteria: An owner can add, edit, and remove members. Non-owners cannot. The last owner cannot be removed or demoted.
- T011 [US1] Create
MembersRelationManagerforTenantResourceinapp/Filament/Resources/TenantResource/RelationManagers/MembersRelationManager.php - T012 [US1] Implement table columns (user name, email, role) in
MembersRelationManager - T013 [US1] Implement "Add Member" action, accessible only to owners, in
MembersRelationManager - T014 [US1] Implement "Change Role" action, accessible only to owners, in
MembersRelationManager - T015 [US1] Implement "Remove Member" action, accessible only to owners, in
MembersRelationManager - T016 [US1] Add "last owner" protection logic to the "Change Role" and "Remove Member" actions.
- T017 [US1] Create feature test for membership management UI and authorization in
tests/Feature/Filament/TenantMembersTest.php
Phase 4: User Story 2 - Authorization Enforcement
Goal: As a user, my actions are authorized based on my role, and I cannot access unauthorized resources. Independent Test Criteria: Routes and actions are protected based on the defined capability matrix.
- T018 [US2] Implement tenant scoping middleware to enforce FR-011 (non-member returns 404).
- T019 [US2] Apply
tenant.cangate checks to all relevant Filament pages, actions, and relation managers. - T020 [US2] Add audit logging for all membership changes (add, edit, remove) as per FR-010.
- T021 [US2] Add feature tests to verify that different roles have the correct access levels across the application.
Phase 5: Polish & Finalization
- T022 [P] Review all code for adherence to project conventions.
- T023 [P] Ensure all new UI text is translatable.
- T024 Run
./vendor/bin/pint --dirtyto format all changed files. - T025 Run the full test suite (
./vendor/bin/sail test) to ensure no regressions.
Dependencies
- US1 (Membership Management) depends on Phase 1 and Phase 2.
- US2 (Authorization Enforcement) depends on Phase 1 and Phase 2. US1 should be completed first to allow for testing with different roles.
Parallel Execution
- Within Phase 2, task T005, T006 and T008 can be worked on in parallel.
- Within Phase 3, after T011 is complete, the actions (T013, T014, T015) can be developed in parallel.
Implementation Strategy
The implementation will follow an MVP-first approach. The initial focus will be on completing Phase 1 and 2 to establish the core data model and RBAC logic. Then, Phase 3 will be implemented to provide the essential UI for managing memberships. Phase 4 will be a sweep to enforce the new authorization rules across the application.