ahmido
0e2adeab71
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
58 lines
2.0 KiB
Markdown
58 lines
2.0 KiB
Markdown
# 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.
|