TenantAtlas/specs/065-tenant-rbac-v1/tasks.md
2026-01-27 23:47:28 +01:00

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_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.