065-tenant-rbac-v1 #79
63
specs/065-tenant-rbac-v1/tasks.md
Normal file
63
specs/065-tenant-rbac-v1/tasks.md
Normal file
@ -0,0 +1,63 @@
|
||||
# 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_memberships` table in `database/migrations/`
|
||||
- [ ] T002 Create `TenantMembership` model in `app/Models/TenantMembership.php`
|
||||
- [ ] T003 Add relationships to `User` and `Tenant` models for `TenantMembership` in `app/Models/User.php` and `app/Models/Tenant.php`
|
||||
- [ ] T004 Create `TenantMembershipFactory` in `database/factories/TenantMembershipFactory.php`
|
||||
|
||||
## Phase 2: Foundational RBAC Core
|
||||
|
||||
- [ ] T005 [P] Create a `TenantCapabilities` enum or class to register all capabilities in `app/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.can` Gate in `app/Providers/AuthServiceProvider.php`
|
||||
- [ ] T008 [P] Create `TenantMembershipPolicy` in `app/Policies/TenantMembershipPolicy.php`
|
||||
- [ ] T009 Register `TenantMembershipPolicy` in `app/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 `MembersRelationManager` for `TenantResource` in `app/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.can` gate 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 --dirty` to 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.
|
||||
Loading…
Reference in New Issue
Block a user