ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
db83112edc
TenantAtlas/specs/276-support-access-governance/tasks.md
ahmido 1e0f21365b PR: 276-support-access-governance → platform-dev (#332) 
Automated PR created via MCP by Copilot on user request: "pr gegen platform-dev".

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #332
2026-05-05 21:54:26 +00:00

15 KiB
Raw Blame History

description
Task list for Enterprise Access Boundary & Support Access Governance v1

Tasks: Enterprise Access Boundary & Support Access Governance v1

Input: Design documents from specs/276-support-access-governance/
Prerequisites: specs/276-support-access-governance/spec.md, specs/276-support-access-governance/plan.md, specs/276-support-access-governance/checklists/requirements.md, specs/276-support-access-governance/research.md, specs/276-support-access-governance/data-model.md, specs/276-support-access-governance/quickstart.md, specs/276-support-access-governance/contracts/workspace-support-access-governance.logical.openapi.yaml

Tests: REQUIRED (Pest). Keep proof bounded to one new Unit family under tests/Unit/System/ plus focused extensions to existing Feature families for system, auth, settings, monitoring, and access-log behavior. Operations: No new OperationRun family. Support-access lifecycle is DB-backed and audit-backed only. RBAC: Wrong-plane and non-member access remain 404; in-scope actors missing capability remain 403. /system owns request or end; /admin owns approval and workspace-visible history. Shared Pattern Reuse: Reuse ViewWorkspace, WorkspaceSettings, AuditLog, AccessLogs, BreakGlassSession, and existing audit infrastructure. Do not create a second support console. Filament / Panel Guardrails: Filament remains v5 on Livewire v4. Provider registration remains unchanged in apps/platform/bootstrap/providers.php. No new panel, no new globally searchable resource, and no new asset strategy are allowed. Organization: Tasks are grouped by user story so request flow, approval and recovery boundary, and customer-visible history remain independently implementable and testable. This package is a bounded follow-through over current support seams, not an IAM rewrite. Review Outcome: acceptable-special-case Workflow Outcome: keep Test-governance Outcome: keep

Test Governance Checklist

  • Lane assignment stays fast-feedback and confidence and remains the narrowest sufficient proof.
  • New or changed tests stay in apps/platform/tests/Unit/System/, apps/platform/tests/Feature/System/, apps/platform/tests/Feature/Auth/, apps/platform/tests/Feature/Filament/Settings/, apps/platform/tests/Feature/Monitoring/, and one narrow apps/platform/tests/Browser/ smoke file required by the implementation-loop gate.
  • Shared helpers stay cheap by default; only one new grant factory is expected.
  • Planned validation commands cover grant lifecycle, request flow, approval, recovery boundary, history export, and one narrow browser smoke without widening into heavy-governance lanes.
  • The declared surface test profile remains standard-native-filament, shared-detail-family, monitoring-state-page, and exception-coded-surface only.
  • Any drift toward impersonation, SCIM, or a second support console resolves as reject-or-split, not hidden scope.

Phase 1: Setup (Shared Context)

Purpose: Confirm the current support and recovery seams before any implementation change.

  • T001 Review specs/276-support-access-governance/spec.md, specs/276-support-access-governance/plan.md, specs/276-support-access-governance/checklists/requirements.md, specs/276-support-access-governance/research.md, specs/276-support-access-governance/data-model.md, specs/276-support-access-governance/quickstart.md, docs/audits/2026-03-09-enterprise-rbac-scope-audit.md, and docs/HANDOVER.md together so the slice stays on current support seams.
  • T002 [P] Confirm the current request and recovery surfaces in apps/platform/app/Filament/System/Pages/Directory/ViewWorkspace.php, apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php, and apps/platform/app/Services/Auth/BreakGlassSession.php.
  • T003 [P] Confirm the current customer-visible history seams in apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php and apps/platform/app/Filament/Pages/Monitoring/AuditLog.php.
  • T004 [P] Confirm the current system security history seams in apps/platform/app/Filament/System/Pages/Security/AccessLogs.php, apps/platform/app/Services/SystemConsole/SystemConsoleAuditLogger.php, and apps/platform/app/Support/Audit/AuditActionId.php.

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Lock the new grant truth, audit action family, and shared resolver before surface changes begin.

Critical: No user-story work should begin until this phase is complete.

  • T005 [P] Add failing unit coverage in apps/platform/tests/Unit/System/SupportAccessGrantResolverTest.php to prove scope validation, dedupe rules, approval-mode selection, active summary output, and expiry behavior.
  • T006 [P] Add or extend feature coverage in apps/platform/tests/Feature/System/SupportAccessRequestFlowTest.php and apps/platform/tests/Feature/System/Spec114/AccessLogsTest.php to lock request, end, and system history behavior.
  • T007 [P] Add or extend feature coverage in apps/platform/tests/Feature/Auth/BreakGlassModeTest.php and apps/platform/tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php to lock break-glass separation and the combined recovery boundary. Existing BreakGlassModeTest.php required no edit; it was re-run, while combined boundary regression coverage was added around recovery.
  • T008 [P] Add or extend feature coverage in apps/platform/tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php and apps/platform/tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php to lock owner approval and workspace-scoped history export.
  • T009 Create apps/platform/database/migrations/*_create_support_access_grants_table.php, apps/platform/app/Models/SupportAccessGrant.php, and apps/platform/database/factories/SupportAccessGrantFactory.php for workspace-owned grant history.
  • T010 Implement apps/platform/app/Services/Auth/SupportAccessGrantResolver.php and apps/platform/app/Services/Auth/SupportAccessGrantManager.php to own request, approval, denial, activation, expiry, end, and dedupe behavior.
  • T011 Extend apps/platform/app/Support/Audit/AuditActionId.php, apps/platform/app/Support/Auth/PlatformCapabilities.php, apps/platform/app/Services/Audit/WorkspaceAuditLogger.php, and apps/platform/app/Services/SystemConsole/SystemConsoleAuditLogger.php for stable support-access audit actions and the new platform capability. Repo truth: the existing audit loggers already accept stable action IDs, so no direct logger edit was required.

Checkpoint: One workspace-owned support-access truth exists and all affected surfaces can depend on the same grant state.

Phase 3: User Story 1 - Request and activate bounded workspace support access (Priority: P1)

Goal: Authorized platform users can request or end workspace-scoped support access from the existing system workspace detail page.

Independent Test: Open ViewWorkspace, request audit_view, confirm the active summary and system audit trail update, then end the grant again.

Tests for User Story 1

  • T012 [P] [US1] Extend apps/platform/tests/Feature/System/SupportAccessRequestFlowTest.php to prove request validation, immediate activation for audit_view, early end, ownerless waiver activation, and wrong-plane or wrong-capability denials.
  • T013 [P] [US1] Extend apps/platform/tests/Feature/System/Spec114/AccessLogsTest.php to prove support-access events appear in the existing system access log family.

Implementation for User Story 1

  • T014 [US1] Update apps/platform/app/Filament/System/Pages/Directory/ViewWorkspace.php so the page renders current support-access posture and owns Request support access plus End support access actions.
  • T015 [US1] Update apps/platform/app/Filament/System/Pages/Security/AccessLogs.php so support-access lifecycle events are included in the existing system security history scope with the new stable audit action family.
  • T016 [US1] Add any bounded summary presenter or helper needed so the system detail page shows scope, requester, reason, approval state, and expiry without duplicating grant logic.

Checkpoint: The system workspace detail page becomes the one ordinary support-access entry point.

Phase 4: User Story 2 - Approve risky recovery and keep break-glass separate (Priority: P1)

Goal: Workspace owners approve high-risk recovery requests, and the existing owner-repair utility requires both support access and break-glass.

Independent Test: Request workspace_recovery, approve it from workspace settings, activate break-glass, and confirm RepairWorkspaceOwners only succeeds when both prerequisites are active.

Tests for User Story 2

  • T017 [P] [US2] Extend apps/platform/tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php to prove pending recovery requests, owner approval, owner denial, and ownerless waiver messaging.
  • T018 [P] [US2] Extend apps/platform/tests/Feature/System/SupportAccessRecoveryBoundaryTest.php and apps/platform/tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php to prove recovery requires the correct workspace-scoped grant plus active break-glass and that audit_view never satisfies the recovery path.

Implementation for User Story 2

  • T019 [US2] Update apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php so workspace owners can approve or deny pending workspace_recovery requests and inspect the current support-access summary.
  • T020 [US2] Update apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php so the header action and warning copy reflect the combined recovery boundary.
  • T021 [US2] Keep BreakGlassSession separate and ensure the recovery page consumes support-access state without turning break-glass into ordinary support access.

Checkpoint: Risky recovery support becomes explicitly approved and visibly distinct from ordinary support access.

Phase 5: User Story 3 - Inspect and export customer-visible support-access history (Priority: P2)

Goal: Workspace actors can inspect and export support-access history from existing admin audit surfaces.

Independent Test: Open the admin audit log in a workspace with support-access events, filter to support access, and export the filtered history.

Tests for User Story 3

  • T022 [P] [US3] Extend apps/platform/tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php to prove workspace-scoped filtering, selected-event inspection, and export behavior.

Implementation for User Story 3

  • T023 [US3] Update apps/platform/app/Filament/Pages/Monitoring/AuditLog.php so the page supports a support-access filter preset and workspace-scoped export.
  • T024 [US3] Confirm the new export path reuses current audit-history semantics instead of creating a second support-history surface.

Checkpoint: Customer-visible support-access history becomes inspectable and exportable from the current admin audit family.

Phase 6: Polish & Cross-Cutting Validation

Purpose: Validate the bounded slice and stop before it widens.

  • T025 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/System/SupportAccessGrantResolverTest.php.
  • T026 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/SupportAccessRequestFlowTest.php tests/Feature/System/SupportAccessRecoveryBoundaryTest.php tests/Feature/Auth/BreakGlassModeTest.php tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php tests/Feature/System/Spec114/AccessLogsTest.php.
  • T027 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php.
  • T028 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent.
  • T029 [P] Review touched code to confirm Filament stays on Livewire v4, provider registration remains unchanged in apps/platform/bootstrap/providers.php, no globally searchable resource is added, no new asset strategy appears, and no impersonation bridge slipped in.
  • T030 [P] Record the final guardrail and test-governance outcome in the active feature close-out without reopening SCIM, delegated admin browsing, or full IAM scope.

Dependencies & Execution Order

Phase Dependencies

  • Phase 1 (Setup): no dependencies; start immediately.
  • Phase 2 (Foundational): depends on Phase 1 and blocks all user stories.
  • Phase 3 (US1): depends on Phase 2 and establishes the bounded support-access entry point.
  • Phase 4 (US2): depends on Phase 2 and should land with US1 so recovery enforcement consumes the finished grant truth.
  • Phase 5 (US3): depends on Phase 2 and should land after US1 so history export reflects the final grant lifecycle.
  • Phase 6 (Polish): depends on all desired user stories being complete.

User Story Dependencies

  • US1 (P1): independently testable after Phase 2 and delivers the ordinary support-access lifecycle.
  • US2 (P1): independently testable after Phase 2 and should ship with US1 so recovery uses the same grant truth.
  • US3 (P2): independently testable after Phase 2 and can follow once support-access events exist.

Within Each User Story

  • Write the listed Pest coverage first and make it fail for the intended gap.
  • Keep implementation inside the current model, resolver, system detail, settings, history, and recovery seams named above.
  • Re-run the narrowest relevant validation command after each story checkpoint before moving on.

Implementation Strategy

Suggested MVP Scope

  • MVP = US1 + US2 together. The feature is only valuable when workspace support access exists and the recovery path actually depends on it.

Incremental Delivery

  1. Complete Phase 1 and Phase 2.
  2. Deliver US1 so support access can be requested and ended safely.
  3. Deliver US2 so risky recovery consumes the same support-access truth.
  4. Add US3 for customer-visible history and export.
  5. Finish with the focused validation and drift-review tasks in Phase 6.

Team Strategy

  1. Settle persistence and resolver shape first.
  2. Parallelize failing tests within each story before runtime edits.
  3. Serialize merges around ViewWorkspace, WorkspaceSettings, RepairWorkspaceOwners, and AuditLog so support vocabulary and history semantics stay coherent.

Deferred Follow-Ups / Non-Goals

  • impersonation or delegated admin browsing
  • SCIM or broader SSO follow-through
  • support ticket or case integration
  • broader support scope catalogs beyond audit_view and workspace_recovery