ahmido
2bf5de4663
Summary Consolidates the “Tenant Operate Hub” work (Spec 085) and the follow-up adjustments from the 086 session merge into a single branch ready to merge into dev. Primary focus: stabilize Ops/Operate Hub UX flows, tighten/align authorization semantics, and make the full Sail test suite green. Key Changes Ops UX / Verification Readonly members can view verification operation runs (reports) while starting verification remains restricted. Normalized failure reason-code handling and aligned UX expectations with the provider reason-code taxonomy. Onboarding wizard UX “Start verification” CTA is hidden while a verification run is active; “Refresh” is shown during in-progress runs. Treats provider_permission_denied as a blocking reason (while keeping legacy compatibility). Test + fixture hardening Standardized use of default provider connection fixtures in tests where sync/restore flows require it. Fixed multiple Filament URL/tenant-context test cases to avoid 404s and reduce tenancy routing brittleness. Policy sync / restore safety Enrollment configuration type collision classification tests now exercise the real sync path (with required provider connection present). Restore edge-case safety tests updated to reflect current provider-connection requirements. Testing vendor/bin/sail artisan test --compact (green) vendor/bin/sail bin pint --dirty (green) Notes Includes merged 086 session work already (no separate PR needed). Co-authored-by: Ahmed Darrazi <ahmeddarrazi@ebc83aaa-d947-4a08-b88e-bd72ac9645f7.fritz.box> Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.fritz.box> Reviewed-on: #103
64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# Data Model: Tenant Operate Hub / Tenant Overview IA
|
|
|
|
**Date**: 2026-02-09
|
|
**Branch**: 085-tenant-operate-hub
|
|
|
|
This feature is primarily UI/IA + navigation behavior. It introduces **no new database tables**.
|
|
|
|
## Entities (existing)
|
|
|
|
### Workspace
|
|
- Purpose: primary isolation boundary and monitoring scope.
|
|
- Source of truth: `workspaces` + membership.
|
|
|
|
### Tenant
|
|
- Purpose: managed environment; tenant-plane routes live under `/admin/t/{tenant}`.
|
|
- Access: entitlement-based.
|
|
|
|
### OperationRun
|
|
- Purpose: canonical run tracking for all operational workflows.
|
|
- Surface:
|
|
- Index: `/admin/operations`
|
|
- Detail: `/admin/operations/{run}`
|
|
|
|
### Alert (placeholder)
|
|
- Purpose: future operator signals.
|
|
- Surface: `/admin/alerts`.
|
|
|
|
### Audit Event / Audit Log (placeholder)
|
|
- Purpose: immutable record of sensitive actions.
|
|
- Surface: `/admin/audit-log`.
|
|
|
|
## Session / Context State (existing)
|
|
|
|
### Workspace context
|
|
- Key: `WorkspaceContext::SESSION_KEY` (`current_workspace_id`)
|
|
- Meaning: selected workspace id for the current session.
|
|
|
|
### Last tenant per workspace (session-based)
|
|
- Key: `WorkspaceContext::LAST_TENANT_IDS_SESSION_KEY` (`workspace_last_tenant_ids`)
|
|
- Shape:
|
|
- Map keyed by workspace id string → tenant id int
|
|
- Example:
|
|
- `{"12": 345}`
|
|
- APIs:
|
|
- `WorkspaceContext::rememberLastTenantId(int $workspaceId, int $tenantId, Request $request)`
|
|
- `WorkspaceContext::lastTenantId(Request $request): ?int`
|
|
- `WorkspaceContext::clearLastTenantId(Request $request)`
|
|
|
|
### Filament tenant context
|
|
- Source: `Filament::getTenant()` (may persist across panels depending on Filament tenancy configuration).
|
|
- Used to determine “active tenant context” for Monitoring UX.
|
|
|
|
**Spec 085 scope note**: Monitoring may use session-based last-tenant memory as a tenant-context signal when Filament tenant context is absent (e.g., when navigating from the tenant panel into central Monitoring). It must not be inferred from arbitrary deep links.
|
|
|
|
### Stale tenant context behavior (no entitlement)
|
|
|
|
- If tenant context is active but the user is not entitled, Monitoring pages behave as workspace-wide views and must not display tenant identity.
|
|
|
|
## Validation / Rules
|
|
|
|
- Tenant context MUST NOT be implicitly mutated by canonical monitoring pages.
|
|
- Deny-as-not-found (404) applies when the actor is not entitled to tenant/workspace scope.
|
|
- Forbidden (403) applies only after membership is established but capability is missing.
|