ahmido
1e0f21365b
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
185 lines
15 KiB
Markdown
185 lines
15 KiB
Markdown
---
|
|
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
|
|
|
|
- [x] Lane assignment stays `fast-feedback` and `confidence` and remains the narrowest sufficient proof.
|
|
- [x] 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.
|
|
- [x] Shared helpers stay cheap by default; only one new grant factory is expected.
|
|
- [x] Planned validation commands cover grant lifecycle, request flow, approval, recovery boundary, history export, and one narrow browser smoke without widening into heavy-governance lanes.
|
|
- [x] The declared surface test profile remains `standard-native-filament`, `shared-detail-family`, `monitoring-state-page`, and `exception-coded-surface` only.
|
|
- [x] 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.
|
|
|
|
- [x] 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.
|
|
- [x] 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`.
|
|
- [x] 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`.
|
|
- [x] 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.
|
|
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] T020 [US2] Update `apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php` so the header action and warning copy reflect the combined recovery boundary.
|
|
- [x] 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
|
|
|
|
- [x] 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
|
|
|
|
- [x] T023 [US3] Update `apps/platform/app/Filament/Pages/Monitoring/AuditLog.php` so the page supports a support-access filter preset and workspace-scoped export.
|
|
- [x] 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.
|
|
|
|
- [x] 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`.
|
|
- [x] 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`.
|
|
- [x] 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`.
|
|
- [x] T028 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`.
|
|
- [x] 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.
|
|
- [x] 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`
|