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
2.8 KiB
2.8 KiB
Data Model — Verification Surfaces Unification (Spec 084)
This feature reuses existing persisted entities. The main change is a stronger invariant about OperationRun.context.verification_report for blocked verification completions.
Entities
OperationRun
Source of truth for observability and verification report storage.
- Table:
operation_runs - Key fields (existing):
id(int)workspace_id(int)tenant_id(int, nullable for some platform runs; verification is tenant-associated)type(string) — verification usesprovider.connection.checkstatus(string) — includes active vs completedoutcome(string) — includessucceeded,failed,blockedcontext(json/jsonb) — storesverification_reportand run metadatafailure_summary(array/json)- timestamps:
created_at,started_at,completed_at
Verification context (provider connection check)
For OperationRun.type = provider.connection.check, the context is expected to include:
provider(string)module(string)provider_connection_id(int)target_scope(object):entra_tenant_id(string)- optionally
entra_tenant_name(string)
verification_report(object) — see “VerificationReport” below
Additionally, for blocked starts (preflight):
reason_code(string)next_steps(array of{label, url})verification_reportMUST exist once the run is completed asblocked.
VerificationReport (stored document)
A stored document under operation_runs.context.verification_report.
- Schema:
specs/075-verification-v1-5/contracts/verification-report.v1_5.schema.json - Key properties:
schema_versionflow(aligns withOperationRun.type)generated_atfingerprintprevious_report_idsummary.overall,summary.countschecks[]
Invariant introduced by this feature
- If a verification run completes with outcome
blocked,verification_reportMUST be present and schema-valid. - For in-progress runs,
verification_reportmay be absent until the job writes it.
TenantOnboardingSession (existing)
Onboarding stores pointers to the current verification run.
state.verification_operation_run_id(int)state.provider_connection_id(int)
Relationships
OperationRunbelongs toTenant(tenant-scoped verification)VerificationCheckAcknowledgementbelongs toOperationRun(acknowledgements enrich viewer; unchanged)
State transitions
For provider.connection.check:
queued/running→completed- Outcomes:
succeededwhen provider connection is healthy and permission inventory refresh succeedsfailedwhen provider check fails (withfailure_summary)blockedwhen prerequisites prevent starting (preflight), still with a stub report
No database schema migrations are expected for this feature.