ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
0e2adeab71
TenantAtlas/specs/084-verification-surfaces-unification/quickstart.md
ahmido 0e2adeab71 feat(verification): unify verification surfaces (Spec 084) (#102) 
Implements Spec 084 (verification-surfaces-unification).

Highlights
- Unifies tenant + onboarding verification start on `provider.connection.check` (OperationRun-based, enqueue-only).
- Ensures completed blocked runs persist a schema-valid `context.verification_report` stub (DB-only viewers never show “unavailable”).
- Adds tenant embedded verification report widget with DB-only rendering + canonical tenantless “View run” links.
- Enforces 404/403 semantics for tenantless run viewing (workspace membership + tenant entitlement required; otherwise 404).
- Fixes admin panel widgets to resolve tenant from record context so Owners can start verification and recent operations renders correctly.

Tests
- Ran: `vendor/bin/sail artisan test --compact tests/Feature/Verification/ tests/Feature/ProviderConnections/ProviderOperationBlockedGuidanceSpec081Test.php tests/Feature/Onboarding/OnboardingVerificationTest.php tests/Feature/RunAuthorizationTenantIsolationTest.php tests/Feature/Filament/TenantVerificationReportWidgetTest.php tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`

Notes
- Filament v5 / Livewire v4 compatible.
- No new assets; no changes to provider registration.

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box>
Reviewed-on: #102
2026-02-09 11:28:09 +00:00

2.0 KiB
Raw Blame History

Quickstart — Verification Surfaces Unification (Spec 084)

Local setup

  • Start containers: vendor/bin/sail up -d
  • Run tests (targeted): vendor/bin/sail artisan test --compact

Manual verification (UI)

1) Tenant detail: start verification

  1. Open a tenant record in the admin panel.
  2. Use the header action: “Verify configuration”.
  3. Confirm the action.

Expected:

  • A queued OperationRun of type provider.connection.check is created or deduped.
  • A notification includes “View run”, linking to the canonical tenantless route /admin/operations/{run}.

1b) Tenant list: row action verify

  1. Open the tenant list in the admin panel.
  2. On any active tenant row, choose “Verify configuration”.

Expected:

  • Uses the same provider.connection.check start/dedupe semantics as tenant detail.
  • Notification “View run” links to /admin/operations/{run}.

2) Tenant detail: embedded viewer

Expected:

  • The tenant page shows the latest verification run attempt.
  • If no run exists yet, it shows an empty state with “Start verification”.
  • If a run is active and no report exists yet, it shows a DB-only “in progress” state.
  • When completed, the viewer shows the stored report.

3) Blocked run report stub

Create a situation where verification is blocked (e.g., missing provider connection / consent).

Expected:

  • A completed blocked OperationRun exists.
  • The embedded viewer (and the operations run viewer) renders a stub report (no “report unavailable” state for completed blocked runs).

4) Onboarding: verify access

  1. Go to managed tenant onboarding.
  2. In the “Verify access” step, click “Start verification”.

Expected:

  • Same semantics: run started/deduped/busy and “View run” links to /admin/operations/{run}.

Authorization checks

Expected:

  • Missing workspace membership or tenant entitlement: 404 (deny-as-not-found) for tenant routes and canonical run viewer of tenant-associated runs.
  • Member without capability: action visible-but-disabled with helper text; server enforces 403 if invoked.