Compare commits
1 Commits
dev
...
181-restor
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
1e2958df27 |
8
.github/agents/copilot-instructions.md
vendored
8
.github/agents/copilot-instructions.md
vendored
@ -137,10 +137,6 @@ ## Active Technologies
|
||||
- PostgreSQL unchanged; existing `operation_runs` JSONB-backed `context`, `summary_counts`, and `failure_summary`; no schema change (178-ops-truth-alignment)
|
||||
- PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4 + Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `RestoreRunResource`, `RestoreService`, `RestoreRiskChecker`, `RestoreDiffGenerator`, `OperationRunResource`, `TenantlessOperationRunViewer`, shared badge infrastructure, and existing RBAC or write-gate helpers (181-restore-safety-integrity)
|
||||
- PostgreSQL with existing `restore_runs` and `operation_runs` records plus JSON or array-backed `metadata`, `preview`, `results`, and `context`; no schema change planned (181-restore-safety-integrity)
|
||||
- PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4 + Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `BackupSetResource`, `BackupItemsRelationManager`, `PolicyVersionResource`, `RestoreRunResource`, `CreateRestoreRun`, `AssignmentBackupService`, `VersionService`, `PolicySnapshotService`, `RestoreRiskChecker`, `BadgeRenderer`, `PolicySnapshotModeBadge`, `EnterpriseDetailBuilder`, and existing RBAC helpers (176-backup-quality-truth)
|
||||
- PostgreSQL with existing tenant-owned `backup_sets`, `backup_items`, `policy_versions`, and restore wizard input state; JSON-backed `metadata`, `snapshot`, `assignments`, and `scope_tags`; no schema change planned (176-backup-quality-truth)
|
||||
- PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4 + Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `DashboardKpis`, `NeedsAttention`, `BackupSetResource`, `BackupScheduleResource`, `BackupQualityResolver`, `BackupQualitySummary`, `ScheduleTimeService`, shared badge infrastructure, and existing RBAC helpers (180-tenant-backup-health)
|
||||
- PostgreSQL with existing tenant-owned `backup_sets`, `backup_items`, and `backup_schedules` records plus existing JSON-backed backup metadata; no schema change planned (180-tenant-backup-health)
|
||||
|
||||
- PHP 8.4.15 (feat/005-bulk-operations)
|
||||
|
||||
@ -160,8 +156,8 @@ ## Code Style
|
||||
PHP 8.4.15: Follow standard conventions
|
||||
|
||||
## Recent Changes
|
||||
- 180-tenant-backup-health: Added PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4 + Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `DashboardKpis`, `NeedsAttention`, `BackupSetResource`, `BackupScheduleResource`, `BackupQualityResolver`, `BackupQualitySummary`, `ScheduleTimeService`, shared badge infrastructure, and existing RBAC helpers
|
||||
- 176-backup-quality-truth: Added PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4 + Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `BackupSetResource`, `BackupItemsRelationManager`, `PolicyVersionResource`, `RestoreRunResource`, `CreateRestoreRun`, `AssignmentBackupService`, `VersionService`, `PolicySnapshotService`, `RestoreRiskChecker`, `BadgeRenderer`, `PolicySnapshotModeBadge`, `EnterpriseDetailBuilder`, and existing RBAC helpers
|
||||
- 181-restore-safety-integrity: Added PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4 + Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `RestoreRunResource`, `RestoreService`, `RestoreRiskChecker`, `RestoreDiffGenerator`, `OperationRunResource`, `TenantlessOperationRunViewer`, shared badge infrastructure, and existing RBAC or write-gate helpers
|
||||
- 178-ops-truth-alignment: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `OperationRun`, `OperationLifecyclePolicy`, `OperationRunFreshnessState`, `OperationUxPresenter`, `OperationRunLinks`, `ActiveRuns`, `StuckRunClassifier`, `WorkspaceOverviewBuilder`, dashboard widgets, workspace widgets, and system ops pages
|
||||
- 177-inventory-coverage-truth: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `InventoryItem`, `OperationRun`, `InventoryCoverage`, `InventoryPolicyTypeMeta`, `CoverageCapabilitiesResolver`, `InventoryKpiHeader`, `InventoryCoverage` page, and `OperationRunResource` enterprise-detail stack
|
||||
<!-- MANUAL ADDITIONS START -->
|
||||
<!-- MANUAL ADDITIONS END -->
|
||||
|
||||
@ -1,192 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Console\Commands;
|
||||
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Policy;
|
||||
use App\Models\Tenant;
|
||||
use App\Models\TenantMembership;
|
||||
use App\Models\User;
|
||||
use App\Models\UserTenantPreference;
|
||||
use App\Models\Workspace;
|
||||
use App\Models\WorkspaceMembership;
|
||||
use Illuminate\Console\Command;
|
||||
use Illuminate\Support\Facades\Hash;
|
||||
use Illuminate\Support\Facades\Schema;
|
||||
|
||||
class SeedBackupHealthBrowserFixture extends Command
|
||||
{
|
||||
protected $signature = 'tenantpilot:backup-health:seed-browser-fixture {--force-refresh : Rebuild the fixture backup basis even if it already exists}';
|
||||
|
||||
protected $description = 'Seed a local/testing browser fixture for the Spec 180 blocked backup drill-through scenario.';
|
||||
|
||||
public function handle(): int
|
||||
{
|
||||
if (! app()->environment(['local', 'testing'])) {
|
||||
$this->error('This fixture command is limited to local and testing environments.');
|
||||
|
||||
return self::FAILURE;
|
||||
}
|
||||
|
||||
$fixture = config('tenantpilot.backup_health.browser_smoke_fixture');
|
||||
|
||||
if (! is_array($fixture)) {
|
||||
$this->error('The backup-health browser smoke fixture is not configured.');
|
||||
|
||||
return self::FAILURE;
|
||||
}
|
||||
|
||||
$workspaceConfig = is_array($fixture['workspace'] ?? null) ? $fixture['workspace'] : [];
|
||||
$userConfig = is_array($fixture['user'] ?? null) ? $fixture['user'] : [];
|
||||
$scenarioConfig = is_array($fixture['blocked_drillthrough'] ?? null) ? $fixture['blocked_drillthrough'] : [];
|
||||
$tenantRouteKey = (string) ($scenarioConfig['tenant_id'] ?? $scenarioConfig['tenant_external_id'] ?? '18000000-0000-4000-8000-000000000180');
|
||||
|
||||
$workspace = Workspace::query()->updateOrCreate(
|
||||
['slug' => (string) ($workspaceConfig['slug'] ?? 'spec-180-backup-health-smoke')],
|
||||
['name' => (string) ($workspaceConfig['name'] ?? 'Spec 180 Backup Health Smoke')],
|
||||
);
|
||||
|
||||
$password = (string) ($userConfig['password'] ?? 'password');
|
||||
|
||||
$user = User::query()->updateOrCreate(
|
||||
['email' => (string) ($userConfig['email'] ?? 'smoke-requester+180@tenantpilot.local')],
|
||||
[
|
||||
'name' => (string) ($userConfig['name'] ?? 'Spec 180 Requester'),
|
||||
'password' => Hash::make($password),
|
||||
'email_verified_at' => now(),
|
||||
],
|
||||
);
|
||||
|
||||
$tenant = Tenant::query()->updateOrCreate(
|
||||
['external_id' => $tenantRouteKey],
|
||||
[
|
||||
'workspace_id' => (int) $workspace->getKey(),
|
||||
'name' => (string) ($scenarioConfig['tenant_name'] ?? 'Spec 180 Blocked Backup Tenant'),
|
||||
'tenant_id' => $tenantRouteKey,
|
||||
'app_client_id' => (string) ($scenarioConfig['app_client_id'] ?? '18000000-0000-4000-8000-000000000182'),
|
||||
'app_client_secret' => null,
|
||||
'app_certificate_thumbprint' => null,
|
||||
'app_status' => 'ok',
|
||||
'app_notes' => null,
|
||||
'status' => Tenant::STATUS_ACTIVE,
|
||||
'environment' => 'dev',
|
||||
'is_current' => false,
|
||||
'metadata' => ['fixture' => 'spec-180-browser-smoke'],
|
||||
'rbac_status' => 'ok',
|
||||
'rbac_last_checked_at' => now(),
|
||||
],
|
||||
);
|
||||
|
||||
WorkspaceMembership::query()->updateOrCreate(
|
||||
['workspace_id' => (int) $workspace->getKey(), 'user_id' => (int) $user->getKey()],
|
||||
['role' => 'owner'],
|
||||
);
|
||||
|
||||
TenantMembership::query()->updateOrCreate(
|
||||
['tenant_id' => (int) $tenant->getKey(), 'user_id' => (int) $user->getKey()],
|
||||
['role' => 'owner', 'source' => 'manual', 'source_ref' => 'spec-180-browser-smoke'],
|
||||
);
|
||||
|
||||
if (Schema::hasColumn('users', 'last_workspace_id')) {
|
||||
$user->forceFill(['last_workspace_id' => (int) $workspace->getKey()])->save();
|
||||
}
|
||||
|
||||
if (Schema::hasTable('user_tenant_preferences')) {
|
||||
UserTenantPreference::query()->updateOrCreate(
|
||||
['user_id' => (int) $user->getKey(), 'tenant_id' => (int) $tenant->getKey()],
|
||||
['last_used_at' => now()],
|
||||
);
|
||||
}
|
||||
|
||||
$policy = Policy::query()->updateOrCreate(
|
||||
[
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'external_id' => (string) ($scenarioConfig['policy_external_id'] ?? 'spec-180-rbac-stale-policy'),
|
||||
'policy_type' => (string) ($scenarioConfig['policy_type'] ?? 'settingsCatalogPolicy'),
|
||||
],
|
||||
[
|
||||
'display_name' => (string) ($scenarioConfig['policy_name'] ?? 'Spec 180 RBAC Smoke Policy'),
|
||||
'platform' => 'windows',
|
||||
'last_synced_at' => now(),
|
||||
'metadata' => ['fixture' => 'spec-180-browser-smoke'],
|
||||
],
|
||||
);
|
||||
|
||||
$backupSet = BackupSet::withTrashed()->firstOrNew([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => (string) ($scenarioConfig['backup_set_name'] ?? 'Spec 180 Blocked Stale Backup'),
|
||||
]);
|
||||
|
||||
$backupSet->forceFill([
|
||||
'created_by' => (string) $user->email,
|
||||
'status' => 'completed',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subHours(max(25, (int) ($scenarioConfig['stale_age_hours'] ?? 48))),
|
||||
'metadata' => ['fixture' => 'spec-180-browser-smoke'],
|
||||
'deleted_at' => null,
|
||||
])->save();
|
||||
|
||||
if (method_exists($backupSet, 'trashed') && $backupSet->trashed()) {
|
||||
$backupSet->restore();
|
||||
}
|
||||
|
||||
$backupItem = BackupItem::withTrashed()->firstOrNew([
|
||||
'backup_set_id' => (int) $backupSet->getKey(),
|
||||
'policy_identifier' => (string) ($scenarioConfig['policy_external_id'] ?? 'spec-180-rbac-stale-policy'),
|
||||
'policy_type' => (string) ($scenarioConfig['policy_type'] ?? 'settingsCatalogPolicy'),
|
||||
]);
|
||||
|
||||
$backupItem->forceFill([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'policy_id' => (int) $policy->getKey(),
|
||||
'platform' => 'windows',
|
||||
'captured_at' => $backupSet->completed_at,
|
||||
'payload' => [
|
||||
'id' => (string) ($scenarioConfig['policy_external_id'] ?? 'spec-180-rbac-stale-policy'),
|
||||
'name' => (string) ($scenarioConfig['policy_name'] ?? 'Spec 180 RBAC Smoke Policy'),
|
||||
],
|
||||
'metadata' => [
|
||||
'policy_name' => (string) ($scenarioConfig['policy_name'] ?? 'Spec 180 RBAC Smoke Policy'),
|
||||
'fixture' => 'spec-180-browser-smoke',
|
||||
],
|
||||
'assignments' => [],
|
||||
'deleted_at' => null,
|
||||
])->save();
|
||||
|
||||
if (method_exists($backupItem, 'trashed') && $backupItem->trashed()) {
|
||||
$backupItem->restore();
|
||||
}
|
||||
|
||||
if ((bool) $this->option('force-refresh')) {
|
||||
$backupSet->forceFill([
|
||||
'completed_at' => now()->subHours(max(25, (int) ($scenarioConfig['stale_age_hours'] ?? 48))),
|
||||
])->save();
|
||||
|
||||
$backupItem->forceFill([
|
||||
'captured_at' => $backupSet->completed_at,
|
||||
])->save();
|
||||
}
|
||||
|
||||
$this->table(
|
||||
['Fixture', 'Value'],
|
||||
[
|
||||
['Workspace', (string) $workspace->name],
|
||||
['User email', (string) $user->email],
|
||||
['User password', $password],
|
||||
['Tenant', (string) $tenant->name],
|
||||
['Tenant external id', (string) $tenant->external_id],
|
||||
['Dashboard URL', "/admin/t/{$tenant->external_id}"],
|
||||
['Fixture login URL', route('admin.local.backup-health-browser-fixture-login', absolute: false)],
|
||||
['Blocked route', "/admin/t/{$tenant->external_id}/backup-sets"],
|
||||
['Locally denied capability', 'tenant.view'],
|
||||
],
|
||||
);
|
||||
|
||||
$this->info('The dashboard remains visible for this fixture user, while backup drill-through routes stay forbidden via a local/testing-only capability deny seam.');
|
||||
|
||||
return self::SUCCESS;
|
||||
}
|
||||
}
|
||||
@ -395,7 +395,6 @@ public static function table(Table $table): Table
|
||||
return $nextRun->format('M j, Y H:i:s');
|
||||
}
|
||||
})
|
||||
->description(fn (BackupSchedule $record): ?string => static::scheduleFollowUpDescription($record))
|
||||
->sortable(),
|
||||
])
|
||||
->filters([
|
||||
@ -1150,31 +1149,4 @@ protected static function dayOfWeekOptions(): array
|
||||
7 => 'Sunday',
|
||||
];
|
||||
}
|
||||
|
||||
protected static function scheduleFollowUpDescription(BackupSchedule $record): ?string
|
||||
{
|
||||
if (! $record->is_enabled || $record->trashed()) {
|
||||
return null;
|
||||
}
|
||||
|
||||
$graceCutoff = now('UTC')->subMinutes(max(1, (int) config('tenantpilot.backup_health.schedule_overdue_grace_minutes', 30)));
|
||||
$lastRunStatus = strtolower(trim((string) $record->last_run_status));
|
||||
$isOverdue = $record->next_run_at?->lessThan($graceCutoff) ?? false;
|
||||
$neverSuccessful = $record->last_run_at === null
|
||||
&& ($isOverdue || ($record->created_at?->lessThan($graceCutoff) ?? false));
|
||||
|
||||
if ($neverSuccessful) {
|
||||
return 'No successful run has been recorded yet.';
|
||||
}
|
||||
|
||||
if ($isOverdue) {
|
||||
return 'This schedule looks overdue.';
|
||||
}
|
||||
|
||||
if (in_array($lastRunStatus, ['failed', 'partial', 'skipped', 'canceled'], true)) {
|
||||
return 'The last run needs follow-up.';
|
||||
}
|
||||
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
@ -3,11 +3,7 @@
|
||||
namespace App\Filament\Resources\BackupScheduleResource\Pages;
|
||||
|
||||
use App\Filament\Resources\BackupScheduleResource;
|
||||
use App\Models\Tenant;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\BackupHealth\TenantBackupHealthResolver;
|
||||
use App\Support\Filament\CanonicalAdminTenantFilterState;
|
||||
use Filament\Facades\Filament;
|
||||
use Filament\Resources\Pages\ListRecords;
|
||||
use Illuminate\Database\Eloquent\ModelNotFoundException;
|
||||
|
||||
@ -68,23 +64,4 @@ private function syncCanonicalAdminTenantFilterState(): void
|
||||
tenantFilterName: null,
|
||||
);
|
||||
}
|
||||
|
||||
public function getSubheading(): ?string
|
||||
{
|
||||
if (request()->string('backup_health_reason')->toString() !== TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP) {
|
||||
return null;
|
||||
}
|
||||
|
||||
$tenant = Filament::getTenant();
|
||||
|
||||
if (! $tenant instanceof Tenant) {
|
||||
return 'One or more enabled schedules need follow-up.';
|
||||
}
|
||||
|
||||
/** @var TenantBackupHealthResolver $resolver */
|
||||
$resolver = app(TenantBackupHealthResolver::class);
|
||||
$summary = $resolver->assess($tenant)->scheduleFollowUp->summaryMessage;
|
||||
|
||||
return $summary ?? 'One or more enabled schedules need follow-up.';
|
||||
}
|
||||
}
|
||||
|
||||
@ -18,9 +18,6 @@
|
||||
use App\Services\OperationRunService;
|
||||
use App\Services\Operations\BulkSelectionIdentity;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\BackupHealth\TenantBackupHealthResolver;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\Filament\TablePaginationProfiles;
|
||||
@ -164,15 +161,6 @@ public static function table(Table $table): Table
|
||||
->persistFiltersInSession()
|
||||
->persistSearchInSession()
|
||||
->persistSortInSession()
|
||||
->modifyQueryUsing(fn (Builder $query): Builder => $query->with([
|
||||
'items' => fn ($itemQuery) => $itemQuery->select([
|
||||
'id',
|
||||
'backup_set_id',
|
||||
'payload',
|
||||
'metadata',
|
||||
'assignments',
|
||||
]),
|
||||
]))
|
||||
->columns([
|
||||
Tables\Columns\TextColumn::make('name')
|
||||
->searchable()
|
||||
@ -184,11 +172,6 @@ public static function table(Table $table): Table
|
||||
->icon(BadgeRenderer::icon(BadgeDomain::BackupSetStatus))
|
||||
->iconColor(BadgeRenderer::iconColor(BadgeDomain::BackupSetStatus)),
|
||||
Tables\Columns\TextColumn::make('item_count')->label('Items')->numeric()->sortable(),
|
||||
Tables\Columns\TextColumn::make('backup_quality')
|
||||
->label('Backup quality')
|
||||
->state(fn (BackupSet $record): string => static::backupQualitySummary($record)->compactSummary)
|
||||
->description(fn (BackupSet $record): string => static::backupQualitySummary($record)->nextAction)
|
||||
->wrap(),
|
||||
Tables\Columns\TextColumn::make('created_by')->label('Created by')->toggleable(isToggledHiddenByDefault: true),
|
||||
Tables\Columns\TextColumn::make('completed_at')->label('Completed')->dateTime()->since()->sortable(),
|
||||
Tables\Columns\TextColumn::make('created_at')->label('Captured')->dateTime()->since()->sortable()->toggleable(isToggledHiddenByDefault: true),
|
||||
@ -676,23 +659,6 @@ private static function enterpriseDetailPage(BackupSet $record): EnterpriseDetai
|
||||
$metadataKeyCount = count($metadata);
|
||||
$relatedContext = static::relatedContextEntries($record);
|
||||
$isArchived = $record->trashed();
|
||||
$qualitySummary = static::backupQualitySummary($record);
|
||||
$backupHealthAssessment = static::backupHealthContinuityAssessment($record);
|
||||
$qualityBadge = match (true) {
|
||||
$qualitySummary->totalItems === 0 => $factory->statusBadge('No items', 'gray'),
|
||||
$qualitySummary->hasDegradations() => $factory->statusBadge('Degraded input', 'warning', 'heroicon-m-exclamation-triangle'),
|
||||
default => $factory->statusBadge('No degradations', 'success', 'heroicon-m-check-circle'),
|
||||
};
|
||||
$backupHealthBadge = $backupHealthAssessment instanceof TenantBackupHealthAssessment
|
||||
? $factory->statusBadge(
|
||||
static::backupHealthContinuityLabel($backupHealthAssessment),
|
||||
$backupHealthAssessment->tone(),
|
||||
'heroicon-m-exclamation-triangle',
|
||||
)
|
||||
: null;
|
||||
$descriptionHint = $backupHealthAssessment instanceof TenantBackupHealthAssessment
|
||||
? trim($backupHealthAssessment->headline.' '.($backupHealthAssessment->supportingMessage ?? ''))
|
||||
: 'Backup quality, lifecycle status, and related operations stay ahead of raw backup metadata.';
|
||||
|
||||
return EnterpriseDetailBuilder::make('backup_set', 'tenant')
|
||||
->header(new SummaryHeaderData(
|
||||
@ -701,46 +667,14 @@ private static function enterpriseDetailPage(BackupSet $record): EnterpriseDetai
|
||||
statusBadges: [
|
||||
$factory->statusBadge($statusSpec->label, $statusSpec->color, $statusSpec->icon, $statusSpec->iconColor),
|
||||
$factory->statusBadge($isArchived ? 'Archived' : 'Active', $isArchived ? 'warning' : 'success'),
|
||||
...array_filter([$backupHealthBadge]),
|
||||
$qualityBadge,
|
||||
],
|
||||
keyFacts: [
|
||||
$factory->keyFact('Items', $record->item_count),
|
||||
...array_filter([
|
||||
$backupHealthAssessment instanceof TenantBackupHealthAssessment
|
||||
? $factory->keyFact('Backup posture', static::backupHealthContinuityLabel($backupHealthAssessment), badge: $backupHealthBadge)
|
||||
: null,
|
||||
]),
|
||||
$factory->keyFact('Backup quality', $qualitySummary->compactSummary),
|
||||
$factory->keyFact('Created by', $record->created_by),
|
||||
$factory->keyFact('Completed', static::formatDetailTimestamp($record->completed_at)),
|
||||
$factory->keyFact('Captured', static::formatDetailTimestamp($record->created_at)),
|
||||
],
|
||||
descriptionHint: $descriptionHint,
|
||||
))
|
||||
->decisionZone($factory->decisionZone(
|
||||
facts: array_values(array_filter([
|
||||
$backupHealthAssessment instanceof TenantBackupHealthAssessment
|
||||
? $factory->keyFact('Backup posture', static::backupHealthContinuityLabel($backupHealthAssessment), badge: $backupHealthBadge)
|
||||
: null,
|
||||
$factory->keyFact('Backup quality', $qualitySummary->compactSummary, badge: $qualityBadge),
|
||||
$factory->keyFact('Degraded items', $qualitySummary->degradedItemCount),
|
||||
$factory->keyFact('Metadata only', $qualitySummary->metadataOnlyCount),
|
||||
$factory->keyFact('Assignment issues', $qualitySummary->assignmentIssueCount),
|
||||
$factory->keyFact('Orphaned assignments', $qualitySummary->orphanedAssignmentCount),
|
||||
$factory->keyFact('Integrity warnings', $qualitySummary->integrityWarningCount),
|
||||
$qualitySummary->unknownQualityCount > 0
|
||||
? $factory->keyFact('Unknown quality', $qualitySummary->unknownQualityCount)
|
||||
: null,
|
||||
])),
|
||||
primaryNextStep: $factory->primaryNextStep(
|
||||
$qualitySummary->nextAction,
|
||||
'Backup quality',
|
||||
),
|
||||
description: 'Start here to judge whether this backup set looks strong or weak as restore input before reading diagnostics or raw metadata.',
|
||||
compactCounts: $factory->countPresentation(summaryLine: $qualitySummary->summaryMessage),
|
||||
attentionNote: $backupHealthAssessment?->positiveClaimBoundary ?? $qualitySummary->positiveClaimBoundary,
|
||||
title: 'Backup quality',
|
||||
descriptionHint: 'Lifecycle status, recovery readiness, and related operations stay ahead of raw backup metadata.',
|
||||
))
|
||||
->addSection(
|
||||
$factory->factsSection(
|
||||
@ -766,12 +700,11 @@ private static function enterpriseDetailPage(BackupSet $record): EnterpriseDetai
|
||||
->addSupportingCard(
|
||||
$factory->supportingFactsCard(
|
||||
kind: 'status',
|
||||
title: 'Backup quality counts',
|
||||
title: 'Recovery readiness',
|
||||
items: [
|
||||
$factory->keyFact('Degraded items', $qualitySummary->degradedItemCount),
|
||||
$factory->keyFact('Metadata only', $qualitySummary->metadataOnlyCount),
|
||||
$factory->keyFact('Assignment issues', $qualitySummary->assignmentIssueCount),
|
||||
$factory->keyFact('Orphaned assignments', $qualitySummary->orphanedAssignmentCount),
|
||||
$factory->keyFact('Backup state', $statusSpec->label, badge: $factory->statusBadge($statusSpec->label, $statusSpec->color, $statusSpec->icon, $statusSpec->iconColor)),
|
||||
$factory->keyFact('Archived', $isArchived),
|
||||
$factory->keyFact('Metadata keys', $metadataKeyCount),
|
||||
],
|
||||
),
|
||||
$factory->supportingFactsCard(
|
||||
@ -807,64 +740,4 @@ private static function formatDetailTimestamp(mixed $value): string
|
||||
|
||||
return $value->toDayDateTimeString();
|
||||
}
|
||||
|
||||
private static function backupQualitySummary(BackupSet $record): \App\Support\BackupQuality\BackupQualitySummary
|
||||
{
|
||||
if ($record->trashed()) {
|
||||
$record->setRelation('items', $record->items()->withTrashed()->select([
|
||||
'id',
|
||||
'backup_set_id',
|
||||
'payload',
|
||||
'metadata',
|
||||
'assignments',
|
||||
])->get());
|
||||
} elseif (! $record->relationLoaded('items')) {
|
||||
$record->loadMissing([
|
||||
'items' => fn ($query) => $query->select([
|
||||
'id',
|
||||
'backup_set_id',
|
||||
'payload',
|
||||
'metadata',
|
||||
'assignments',
|
||||
]),
|
||||
]);
|
||||
}
|
||||
|
||||
return app(BackupQualityResolver::class)->summarizeBackupSet($record);
|
||||
}
|
||||
|
||||
private static function backupHealthContinuityAssessment(BackupSet $record): ?TenantBackupHealthAssessment
|
||||
{
|
||||
$requestedReason = request()->string('backup_health_reason')->toString();
|
||||
|
||||
if (! in_array($requestedReason, [
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED,
|
||||
], true)) {
|
||||
return null;
|
||||
}
|
||||
|
||||
/** @var TenantBackupHealthResolver $resolver */
|
||||
$resolver = app(TenantBackupHealthResolver::class);
|
||||
$assessment = $resolver->assess((int) $record->tenant_id);
|
||||
|
||||
if ($assessment->latestRelevantBackupSetId !== (int) $record->getKey()) {
|
||||
return null;
|
||||
}
|
||||
|
||||
if ($assessment->primaryReason !== $requestedReason) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return $assessment;
|
||||
}
|
||||
|
||||
private static function backupHealthContinuityLabel(TenantBackupHealthAssessment $assessment): string
|
||||
{
|
||||
return match ($assessment->primaryReason) {
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE => 'Latest backup is stale',
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED => 'Latest backup is degraded',
|
||||
default => ucfirst($assessment->posture),
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
@ -3,7 +3,6 @@
|
||||
namespace App\Filament\Resources\BackupSetResource\Pages;
|
||||
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\Filament\CanonicalAdminTenantFilterState;
|
||||
use Filament\Resources\Pages\ListRecords;
|
||||
|
||||
@ -41,14 +40,4 @@ protected function getTableEmptyStateActions(): array
|
||||
BackupSetResource::makeCreateAction(),
|
||||
];
|
||||
}
|
||||
|
||||
public function getSubheading(): ?string
|
||||
{
|
||||
return match (request()->string('backup_health_reason')->toString()) {
|
||||
TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS => 'No usable completed backup basis is currently available for this tenant.',
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE => 'The latest backup detail is no longer available, so this view stays on the backup-set list.',
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED => 'The latest backup detail is no longer available, so this view stays on the backup-set list.',
|
||||
default => null,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
@ -11,7 +11,6 @@
|
||||
use App\Models\User;
|
||||
use App\Services\OperationRunService;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\Badges\TagBadgeDomain;
|
||||
@ -280,32 +279,11 @@ public function table(Table $table): Table
|
||||
->sortable()
|
||||
->searchable()
|
||||
->getStateUsing(fn (BackupItem $record) => $record->resolvedDisplayName()),
|
||||
Tables\Columns\TextColumn::make('snapshot_mode')
|
||||
->label('Snapshot')
|
||||
->badge()
|
||||
->state(fn (BackupItem $record): string => $this->backupItemQualitySummary($record)->snapshotMode)
|
||||
->formatStateUsing(BadgeRenderer::label(BadgeDomain::PolicySnapshotMode))
|
||||
->color(BadgeRenderer::color(BadgeDomain::PolicySnapshotMode))
|
||||
->icon(BadgeRenderer::icon(BadgeDomain::PolicySnapshotMode))
|
||||
->iconColor(BadgeRenderer::iconColor(BadgeDomain::PolicySnapshotMode)),
|
||||
Tables\Columns\TextColumn::make('policyVersion.version_number')
|
||||
->label('Version')
|
||||
->badge()
|
||||
->default('—')
|
||||
->getStateUsing(fn (BackupItem $record): ?int => $record->policyVersion?->version_number),
|
||||
Tables\Columns\TextColumn::make('backup_quality')
|
||||
->label('Backup quality')
|
||||
->state(fn (BackupItem $record): string => $this->backupItemQualitySummary($record)->compactSummary)
|
||||
->description(function (BackupItem $record): string {
|
||||
$summary = $this->backupItemQualitySummary($record);
|
||||
|
||||
if ($summary->assignmentCaptureReason === 'separate_role_assignments') {
|
||||
return 'Assignments are captured separately for this item type.';
|
||||
}
|
||||
|
||||
return $summary->nextAction;
|
||||
})
|
||||
->wrap(),
|
||||
Tables\Columns\TextColumn::make('policy_type')
|
||||
->label('Type')
|
||||
->badge()
|
||||
@ -502,11 +480,6 @@ private function backupItemInspectUrl(BackupItem $record): ?string
|
||||
return PolicyResource::getUrl('view', ['record' => $resolvedRecord->policy_id], tenant: $tenant);
|
||||
}
|
||||
|
||||
private function backupItemQualitySummary(BackupItem $record): \App\Support\BackupQuality\BackupQualitySummary
|
||||
{
|
||||
return app(BackupQualityResolver::class)->forBackupItem($record);
|
||||
}
|
||||
|
||||
private function resolveOwnerScopedBackupItemId(BackupSet $backupSet, mixed $record): int
|
||||
{
|
||||
$recordId = $this->normalizeBackupItemKey($record);
|
||||
|
||||
@ -21,9 +21,6 @@
|
||||
use App\Services\OperationRunService;
|
||||
use App\Services\Operations\BulkSelectionIdentity;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\Badges\TagBadgeDomain;
|
||||
use App\Support\Badges\TagBadgeRenderer;
|
||||
use App\Support\Baselines\PolicyVersionCapturePurpose;
|
||||
@ -110,7 +107,7 @@ public static function actionSurfaceDeclaration(): ActionSurfaceDeclaration
|
||||
->satisfy(ActionSurfaceSlot::InspectAffordance, ActionSurfaceInspectAffordance::ClickableRow->value)
|
||||
->satisfy(ActionSurfaceSlot::ListRowMoreMenu, 'Secondary row actions are grouped under "More".')
|
||||
->satisfy(ActionSurfaceSlot::ListBulkMoreGroup, 'Bulk actions are grouped under "More".')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'Empty-state CTA routes operators to backup sets when no versions are available yet.')
|
||||
->exempt(ActionSurfaceSlot::ListEmptyState, 'Empty-state CTA is intentionally omitted; versions appear after policy sync/capture workflows.')
|
||||
->exempt(ActionSurfaceSlot::DetailHeader, 'View page header actions are intentionally minimal for now.');
|
||||
}
|
||||
|
||||
@ -132,37 +129,6 @@ public static function infolist(Schema $schema): Schema
|
||||
->color(TagBadgeRenderer::color(TagBadgeDomain::Platform)),
|
||||
Infolists\Components\TextEntry::make('created_by')->label('Actor'),
|
||||
Infolists\Components\TextEntry::make('captured_at')->dateTime(),
|
||||
Section::make('Backup quality')
|
||||
->schema([
|
||||
Infolists\Components\TextEntry::make('quality_snapshot_mode')
|
||||
->label('Snapshot')
|
||||
->badge()
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->snapshotMode)
|
||||
->formatStateUsing(BadgeRenderer::label(BadgeDomain::PolicySnapshotMode))
|
||||
->color(BadgeRenderer::color(BadgeDomain::PolicySnapshotMode))
|
||||
->icon(BadgeRenderer::icon(BadgeDomain::PolicySnapshotMode))
|
||||
->iconColor(BadgeRenderer::iconColor(BadgeDomain::PolicySnapshotMode)),
|
||||
Infolists\Components\TextEntry::make('quality_summary')
|
||||
->label('Backup quality')
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->compactSummary),
|
||||
Infolists\Components\TextEntry::make('quality_assignment_signal')
|
||||
->label('Assignment quality')
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionAssignmentQualityLabel($record)),
|
||||
Infolists\Components\TextEntry::make('quality_next_action')
|
||||
->label('Next action')
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->nextAction),
|
||||
Infolists\Components\TextEntry::make('quality_integrity_warning')
|
||||
->label('Integrity note')
|
||||
->state(fn (PolicyVersion $record): ?string => static::policyVersionQualitySummary($record)->integrityWarning)
|
||||
->visible(fn (PolicyVersion $record): bool => static::policyVersionQualitySummary($record)->hasIntegrityWarning())
|
||||
->columnSpanFull(),
|
||||
Infolists\Components\TextEntry::make('quality_boundary')
|
||||
->label('Boundary')
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->positiveClaimBoundary)
|
||||
->columnSpanFull(),
|
||||
])
|
||||
->columns(2)
|
||||
->columnSpanFull(),
|
||||
Section::make('Related context')
|
||||
->schema([
|
||||
Infolists\Components\ViewEntry::make('related_context')
|
||||
@ -562,19 +528,6 @@ public static function table(Table $table): Table
|
||||
->searchable()
|
||||
->getStateUsing(fn (PolicyVersion $record): string => static::resolvedDisplayName($record)),
|
||||
Tables\Columns\TextColumn::make('version_number')->sortable(),
|
||||
Tables\Columns\TextColumn::make('snapshot_mode')
|
||||
->label('Snapshot')
|
||||
->badge()
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->snapshotMode)
|
||||
->formatStateUsing(BadgeRenderer::label(BadgeDomain::PolicySnapshotMode))
|
||||
->color(BadgeRenderer::color(BadgeDomain::PolicySnapshotMode))
|
||||
->icon(BadgeRenderer::icon(BadgeDomain::PolicySnapshotMode))
|
||||
->iconColor(BadgeRenderer::iconColor(BadgeDomain::PolicySnapshotMode)),
|
||||
Tables\Columns\TextColumn::make('backup_quality')
|
||||
->label('Backup quality')
|
||||
->state(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->compactSummary)
|
||||
->description(fn (PolicyVersion $record): string => static::policyVersionQualitySummary($record)->nextAction)
|
||||
->wrap(),
|
||||
Tables\Columns\TextColumn::make('policy_type')
|
||||
->badge()
|
||||
->formatStateUsing(TagBadgeRenderer::label(TagBadgeDomain::PolicyType))
|
||||
@ -583,7 +536,7 @@ public static function table(Table $table): Table
|
||||
->badge()
|
||||
->formatStateUsing(TagBadgeRenderer::label(TagBadgeDomain::Platform))
|
||||
->color(TagBadgeRenderer::color(TagBadgeDomain::Platform)),
|
||||
Tables\Columns\TextColumn::make('created_by')->label('Actor')->toggleable(isToggledHiddenByDefault: true),
|
||||
Tables\Columns\TextColumn::make('created_by')->label('Actor'),
|
||||
Tables\Columns\TextColumn::make('captured_at')->dateTime()->sortable(),
|
||||
])
|
||||
->filters([
|
||||
@ -625,7 +578,7 @@ public static function table(Table $table): Table
|
||||
return $resolver->isMember($user, $tenant);
|
||||
})
|
||||
->disabled(function (PolicyVersion $record): bool {
|
||||
if (static::policyVersionQualitySummary($record)->snapshotMode === 'metadata_only') {
|
||||
if (($record->metadata['source'] ?? null) === 'metadata_only') {
|
||||
return true;
|
||||
}
|
||||
|
||||
@ -664,7 +617,7 @@ public static function table(Table $table): Table
|
||||
return 'You do not have permission to create restore runs.';
|
||||
}
|
||||
|
||||
if (static::policyVersionQualitySummary($record)->snapshotMode === 'metadata_only') {
|
||||
if (($record->metadata['source'] ?? null) === 'metadata_only') {
|
||||
return 'Disabled for metadata-only snapshots (Graph did not provide policy settings).';
|
||||
}
|
||||
|
||||
@ -689,7 +642,7 @@ public static function table(Table $table): Table
|
||||
abort(403);
|
||||
}
|
||||
|
||||
if (static::policyVersionQualitySummary($record)->snapshotMode === 'metadata_only') {
|
||||
if (($record->metadata['source'] ?? null) === 'metadata_only') {
|
||||
Notification::make()
|
||||
->title('Restore disabled for metadata-only snapshot')
|
||||
->body('This snapshot only contains metadata; Graph did not provide policy settings to restore.')
|
||||
@ -746,15 +699,11 @@ public static function table(Table $table): Table
|
||||
|
||||
$backupItemMetadata = [
|
||||
'source' => 'policy_version',
|
||||
'snapshot_source' => $record->snapshotSource(),
|
||||
'display_name' => $policy->display_name,
|
||||
'policy_version_id' => $record->id,
|
||||
'policy_version_number' => $record->version_number,
|
||||
'version_captured_at' => $record->captured_at?->toIso8601String(),
|
||||
'redaction_version' => $record->redaction_version,
|
||||
'warnings' => $record->warningMessages(),
|
||||
'assignments_fetch_failed' => $record->assignmentsFetchFailed(),
|
||||
'has_orphaned_assignments' => $record->hasOrphanedAssignments(),
|
||||
];
|
||||
|
||||
$integrityWarning = RedactionIntegrity::noteForPolicyVersion($record);
|
||||
@ -942,13 +891,7 @@ public static function table(Table $table): Table
|
||||
])
|
||||
->emptyStateHeading('No policy versions')
|
||||
->emptyStateDescription('Capture or sync policy snapshots to build a version history.')
|
||||
->emptyStateIcon('heroicon-o-clock')
|
||||
->emptyStateActions([
|
||||
Actions\Action::make('open_backup_sets')
|
||||
->label('Open backup sets')
|
||||
->url(fn (): string => BackupSetResource::getUrl('index', tenant: static::resolveTenantContextForCurrentPanel()))
|
||||
->color('gray'),
|
||||
]);
|
||||
->emptyStateIcon('heroicon-o-clock');
|
||||
}
|
||||
|
||||
public static function getEloquentQuery(): Builder
|
||||
@ -1037,23 +980,6 @@ private static function primaryRelatedAction(): Actions\Action
|
||||
->color('gray');
|
||||
}
|
||||
|
||||
private static function policyVersionQualitySummary(PolicyVersion $record): \App\Support\BackupQuality\BackupQualitySummary
|
||||
{
|
||||
return app(BackupQualityResolver::class)->forPolicyVersion($record);
|
||||
}
|
||||
|
||||
private static function policyVersionAssignmentQualityLabel(PolicyVersion $record): string
|
||||
{
|
||||
$summary = static::policyVersionQualitySummary($record);
|
||||
|
||||
return match (true) {
|
||||
$summary->hasAssignmentIssues && $summary->hasOrphanedAssignments => 'Assignment fetch failed and orphaned targets were detected.',
|
||||
$summary->hasAssignmentIssues => 'Assignment fetch failed during capture.',
|
||||
$summary->hasOrphanedAssignments => 'Orphaned assignment targets were detected.',
|
||||
default => 'No assignment issues were detected from captured metadata.',
|
||||
};
|
||||
}
|
||||
|
||||
private static function primaryRelatedEntry(PolicyVersion $record): ?RelatedContextEntry
|
||||
{
|
||||
return app(RelatedNavigationResolver::class)
|
||||
|
||||
@ -27,7 +27,6 @@
|
||||
use App\Services\OperationRunService;
|
||||
use App\Services\Operations\BulkSelectionIdentity;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\Filament\FilterOptionCatalog;
|
||||
@ -129,8 +128,24 @@ public static function form(Schema $schema): Schema
|
||||
->schema([
|
||||
Forms\Components\Select::make('backup_set_id')
|
||||
->label('Backup set')
|
||||
->options(fn () => static::restoreBackupSetOptions())
|
||||
->helperText(fn (Get $get): string => static::restoreBackupSetHelperText($get('backup_set_id')))
|
||||
->options(function () {
|
||||
$tenantId = static::resolveTenantContextForCurrentPanelOrFail()->getKey();
|
||||
|
||||
return BackupSet::query()
|
||||
->when($tenantId, fn ($query) => $query->where('tenant_id', $tenantId))
|
||||
->orderByDesc('created_at')
|
||||
->get()
|
||||
->mapWithKeys(function (BackupSet $set) {
|
||||
$label = sprintf(
|
||||
'%s • %s items • %s',
|
||||
$set->name,
|
||||
$set->item_count ?? 0,
|
||||
optional($set->created_at)->format('Y-m-d H:i')
|
||||
);
|
||||
|
||||
return [$set->id => $label];
|
||||
});
|
||||
})
|
||||
->reactive()
|
||||
->afterStateUpdated(function (Set $set): void {
|
||||
$set('scope_mode', 'all');
|
||||
@ -148,7 +163,7 @@ public static function form(Schema $schema): Schema
|
||||
->bulkToggleable()
|
||||
->reactive()
|
||||
->afterStateUpdated(fn (Set $set) => $set('group_mapping', []))
|
||||
->helperText(fn (): string => static::restoreItemQualityHelperText()),
|
||||
->helperText('Search by name, type, or ID. Preview-only types stay in dry-run; leave empty to include all items. Include foundations (scope tags, assignment filters) with policies to re-map IDs.'),
|
||||
Section::make('Group mapping')
|
||||
->description('Some source groups do not exist in the target tenant. Map them or choose Skip.')
|
||||
->schema(function (Get $get): array {
|
||||
@ -176,7 +191,7 @@ public static function form(Schema $schema): Schema
|
||||
|
||||
$cacheNotice = match (true) {
|
||||
! $hasCachedGroups => 'No cached groups found. Run "Sync Groups" first.',
|
||||
$isStale => "Cached groups may be stale (>{$stalenessDays} days). Consider running \"Sync Groups\".",
|
||||
$isStale => "Cached groups may be stale (>${stalenessDays} days). Consider running \"Sync Groups\".",
|
||||
default => null,
|
||||
};
|
||||
|
||||
@ -295,12 +310,28 @@ public static function getWizardSteps(): array
|
||||
{
|
||||
return [
|
||||
Step::make('Select Backup Set')
|
||||
->description('What are we restoring from? Backup quality is visible here before safety checks run.')
|
||||
->description('What are we restoring from?')
|
||||
->schema([
|
||||
Forms\Components\Select::make('backup_set_id')
|
||||
->label('Backup set')
|
||||
->options(fn () => static::restoreBackupSetOptions())
|
||||
->helperText(fn (Get $get): string => static::restoreBackupSetHelperText($get('backup_set_id')))
|
||||
->options(function () {
|
||||
$tenantId = static::resolveTenantContextForCurrentPanelOrFail()->getKey();
|
||||
|
||||
return BackupSet::query()
|
||||
->when($tenantId, fn ($query) => $query->where('tenant_id', $tenantId))
|
||||
->orderByDesc('created_at')
|
||||
->get()
|
||||
->mapWithKeys(function (BackupSet $set) {
|
||||
$label = sprintf(
|
||||
'%s • %s items • %s',
|
||||
$set->name,
|
||||
$set->item_count ?? 0,
|
||||
optional($set->created_at)->format('Y-m-d H:i')
|
||||
);
|
||||
|
||||
return [$set->id => $label];
|
||||
});
|
||||
})
|
||||
->reactive()
|
||||
->afterStateUpdated(function (Set $set, Get $get): void {
|
||||
$groupMapping = static::groupMappingPlaceholders(
|
||||
@ -331,7 +362,7 @@ public static function getWizardSteps(): array
|
||||
->required(),
|
||||
]),
|
||||
Step::make('Define Restore Scope')
|
||||
->description('What exactly should be restored? Item quality hints appear here before restore risk checks.')
|
||||
->description('What exactly should be restored?')
|
||||
->schema([
|
||||
Forms\Components\Radio::make('scope_mode')
|
||||
->label('Scope')
|
||||
@ -454,7 +485,7 @@ public static function getWizardSteps(): array
|
||||
->visible(fn (Get $get): bool => $get('scope_mode') === 'selected')
|
||||
->action(fn (Set $set) => $set('backup_item_ids', [], shouldCallUpdatedHooks: true)),
|
||||
])
|
||||
->helperText(fn (): string => static::restoreItemQualityHelperText()),
|
||||
->helperText('Search by name or ID. Include foundations (scope tags, assignment filters) with policies to re-map IDs. Options are grouped by category, type, and platform.'),
|
||||
Section::make('Group mapping')
|
||||
->description('Some source groups do not exist in the target tenant. Map them or choose Skip.')
|
||||
->schema(function (Get $get): array {
|
||||
@ -489,7 +520,7 @@ public static function getWizardSteps(): array
|
||||
|
||||
$cacheNotice = match (true) {
|
||||
! $hasCachedGroups => 'No cached groups found. Run "Sync Groups" first.',
|
||||
$isStale => "Cached groups may be stale (>{$stalenessDays} days). Consider running \"Sync Groups\".",
|
||||
$isStale => "Cached groups may be stale (>${stalenessDays} days). Consider running \"Sync Groups\".",
|
||||
default => null,
|
||||
};
|
||||
|
||||
@ -1461,7 +1492,6 @@ private static function restoreItemOptionData(?int $backupSetId): array
|
||||
|
||||
foreach ($items as $item) {
|
||||
$meta = static::typeMeta($item->policy_type);
|
||||
$qualitySummary = static::backupItemQualitySummary($item);
|
||||
$typeLabel = $meta['label'] ?? $item->policy_type;
|
||||
$category = $meta['category'] ?? 'Policies';
|
||||
$restore = $meta['restore'] ?? 'enabled';
|
||||
@ -1476,7 +1506,6 @@ private static function restoreItemOptionData(?int $backupSetId): array
|
||||
$category,
|
||||
$typeLabel,
|
||||
$platform,
|
||||
'quality: '.$qualitySummary->compactSummary,
|
||||
"restore: {$restore}",
|
||||
$versionNumber ? "version: {$versionNumber}" : null,
|
||||
$item->hasAssignments() ? "assignments: {$item->assignment_count}" : null,
|
||||
@ -1542,111 +1571,12 @@ private static function restoreItemGroupedOptions(?int $backupSetId): array
|
||||
]));
|
||||
|
||||
$groups[$groupLabel] ??= [];
|
||||
$groups[$groupLabel][$item->id] = static::restoreItemSelectionLabel($item);
|
||||
$groups[$groupLabel][$item->id] = $item->resolvedDisplayName();
|
||||
}
|
||||
|
||||
return $groups;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array<int, string>
|
||||
*/
|
||||
private static function restoreBackupSetOptions(): array
|
||||
{
|
||||
$tenantId = static::resolveTenantContextForCurrentPanelOrFail()->getKey();
|
||||
|
||||
return BackupSet::query()
|
||||
->where('tenant_id', $tenantId)
|
||||
->with([
|
||||
'items' => fn ($query) => $query->select([
|
||||
'id',
|
||||
'backup_set_id',
|
||||
'payload',
|
||||
'metadata',
|
||||
'assignments',
|
||||
]),
|
||||
])
|
||||
->orderByDesc('created_at')
|
||||
->get()
|
||||
->mapWithKeys(fn (BackupSet $set): array => [
|
||||
(int) $set->getKey() => static::restoreBackupSetSelectionLabel($set),
|
||||
])
|
||||
->all();
|
||||
}
|
||||
|
||||
private static function restoreBackupSetSelectionLabel(BackupSet $set): string
|
||||
{
|
||||
$qualitySummary = static::backupSetQualitySummary($set);
|
||||
|
||||
return implode(' • ', array_filter([
|
||||
$set->name,
|
||||
sprintf('%d items', (int) ($set->item_count ?? 0)),
|
||||
optional($set->created_at)->format('Y-m-d H:i'),
|
||||
$qualitySummary->compactSummary,
|
||||
]));
|
||||
}
|
||||
|
||||
private static function restoreBackupSetHelperText(mixed $backupSetId): string
|
||||
{
|
||||
$default = 'Backup quality hints describe input strength only. They do not approve restore execution or prove recoverability.';
|
||||
|
||||
if (! is_numeric($backupSetId)) {
|
||||
return $default;
|
||||
}
|
||||
|
||||
$tenant = static::resolveTenantContextForCurrentPanel();
|
||||
|
||||
if (! $tenant instanceof Tenant) {
|
||||
return $default;
|
||||
}
|
||||
|
||||
$backupSet = BackupSet::query()
|
||||
->where('tenant_id', (int) $tenant->getKey())
|
||||
->with([
|
||||
'items' => fn ($query) => $query->select([
|
||||
'id',
|
||||
'backup_set_id',
|
||||
'payload',
|
||||
'metadata',
|
||||
'assignments',
|
||||
]),
|
||||
])
|
||||
->find((int) $backupSetId);
|
||||
|
||||
if (! $backupSet instanceof BackupSet) {
|
||||
return $default;
|
||||
}
|
||||
|
||||
$summary = static::backupSetQualitySummary($backupSet);
|
||||
|
||||
return $summary->compactSummary.'. '.$summary->positiveClaimBoundary;
|
||||
}
|
||||
|
||||
private static function restoreItemSelectionLabel(BackupItem $item): string
|
||||
{
|
||||
$summary = static::backupItemQualitySummary($item);
|
||||
|
||||
return implode(' • ', array_filter([
|
||||
$item->resolvedDisplayName(),
|
||||
$summary->compactSummary,
|
||||
]));
|
||||
}
|
||||
|
||||
private static function restoreItemQualityHelperText(): string
|
||||
{
|
||||
return 'Quality hints describe input strength before risk checks. Include foundations with policies when you need ID re-mapping context.';
|
||||
}
|
||||
|
||||
private static function backupSetQualitySummary(BackupSet $backupSet): \App\Support\BackupQuality\BackupQualitySummary
|
||||
{
|
||||
return app(BackupQualityResolver::class)->summarizeBackupSet($backupSet);
|
||||
}
|
||||
|
||||
private static function backupItemQualitySummary(BackupItem $backupItem): \App\Support\BackupQuality\BackupQualitySummary
|
||||
{
|
||||
return app(BackupQualityResolver::class)->forBackupItem($backupItem);
|
||||
}
|
||||
|
||||
public static function createRestoreRun(array $data): RestoreRun
|
||||
{
|
||||
$tenant = static::resolveTenantContextForCurrentPanel();
|
||||
|
||||
@ -4,25 +4,18 @@
|
||||
|
||||
namespace App\Filament\Widgets\Dashboard;
|
||||
|
||||
use App\Filament\Resources\BackupScheduleResource;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Resources\FindingResource;
|
||||
use App\Models\Finding;
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\Tenant;
|
||||
use App\Models\User;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupHealth\BackupHealthActionTarget;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\BackupHealth\TenantBackupHealthResolver;
|
||||
use App\Support\OperationRunLinks;
|
||||
use App\Support\OpsUx\ActiveRuns;
|
||||
use App\Support\Rbac\UiTooltips;
|
||||
use Filament\Facades\Filament;
|
||||
use Filament\Widgets\StatsOverviewWidget;
|
||||
use Filament\Widgets\StatsOverviewWidget\Stat;
|
||||
use Illuminate\Database\Eloquent\ModelNotFoundException;
|
||||
use Illuminate\Support\Str;
|
||||
|
||||
class DashboardKpis extends StatsOverviewWidget
|
||||
{
|
||||
@ -45,8 +38,6 @@ protected function getStats(): array
|
||||
}
|
||||
|
||||
$tenantId = (int) $tenant->getKey();
|
||||
$backupHealth = $this->backupHealthAssessment($tenant);
|
||||
$backupHealthAction = $this->resolveBackupHealthAction($tenant, $backupHealth->primaryActionTarget);
|
||||
|
||||
$openDriftFindings = (int) Finding::query()
|
||||
->where('tenant_id', $tenantId)
|
||||
@ -88,10 +79,6 @@ protected function getStats(): array
|
||||
$findingsHelperText = $this->findingsHelperText($tenant);
|
||||
|
||||
return [
|
||||
Stat::make('Backup posture', Str::headline($backupHealth->posture))
|
||||
->description($this->backupHealthDescription($backupHealth, $backupHealthAction['helperText']))
|
||||
->color($backupHealth->tone())
|
||||
->url($backupHealthAction['actionUrl']),
|
||||
Stat::make('Open drift findings', $openDriftFindings)
|
||||
->description($openDriftUrl === null && $openDriftFindings > 0
|
||||
? $findingsHelperText
|
||||
@ -137,7 +124,6 @@ protected function getStats(): array
|
||||
private function emptyStats(): array
|
||||
{
|
||||
return [
|
||||
Stat::make('Backup posture', '—'),
|
||||
Stat::make('Open drift findings', 0),
|
||||
Stat::make('High severity active findings', 0),
|
||||
Stat::make('Active operations', 0),
|
||||
@ -173,106 +159,4 @@ private function canOpenFindings(Tenant $tenant): bool
|
||||
&& $user->canAccessTenant($tenant)
|
||||
&& $user->can(Capabilities::TENANT_FINDINGS_VIEW, $tenant);
|
||||
}
|
||||
|
||||
private function backupHealthAssessment(Tenant $tenant): TenantBackupHealthAssessment
|
||||
{
|
||||
/** @var TenantBackupHealthResolver $resolver */
|
||||
$resolver = app(TenantBackupHealthResolver::class);
|
||||
|
||||
return $resolver->assess($tenant);
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array{actionUrl: string|null, helperText: string|null}
|
||||
*/
|
||||
private function resolveBackupHealthAction(Tenant $tenant, ?BackupHealthActionTarget $target): array
|
||||
{
|
||||
if (! $target instanceof BackupHealthActionTarget) {
|
||||
return [
|
||||
'actionUrl' => null,
|
||||
'helperText' => null,
|
||||
];
|
||||
}
|
||||
|
||||
if (! $this->canOpenBackupSurfaces($tenant)) {
|
||||
return [
|
||||
'actionUrl' => null,
|
||||
'helperText' => UiTooltips::INSUFFICIENT_PERMISSION,
|
||||
];
|
||||
}
|
||||
|
||||
return match ($target->surface) {
|
||||
BackupHealthActionTarget::SURFACE_BACKUP_SETS_INDEX => [
|
||||
'actionUrl' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'helperText' => null,
|
||||
],
|
||||
BackupHealthActionTarget::SURFACE_BACKUP_SCHEDULES_INDEX => [
|
||||
'actionUrl' => BackupScheduleResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'helperText' => null,
|
||||
],
|
||||
BackupHealthActionTarget::SURFACE_BACKUP_SET_VIEW => $this->resolveBackupSetAction($tenant, $target),
|
||||
default => [
|
||||
'actionUrl' => null,
|
||||
'helperText' => null,
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array{actionUrl: string|null, helperText: string|null}
|
||||
*/
|
||||
private function resolveBackupSetAction(Tenant $tenant, BackupHealthActionTarget $target): array
|
||||
{
|
||||
if (! is_numeric($target->recordId)) {
|
||||
return [
|
||||
'actionUrl' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'helperText' => 'The latest backup detail is no longer available.',
|
||||
];
|
||||
}
|
||||
|
||||
try {
|
||||
BackupSetResource::resolveScopedRecordOrFail($target->recordId);
|
||||
|
||||
return [
|
||||
'actionUrl' => BackupSetResource::getUrl('view', [
|
||||
'record' => $target->recordId,
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'helperText' => null,
|
||||
];
|
||||
} catch (ModelNotFoundException) {
|
||||
return [
|
||||
'actionUrl' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'helperText' => 'The latest backup detail is no longer available.',
|
||||
];
|
||||
}
|
||||
}
|
||||
|
||||
private function backupHealthDescription(TenantBackupHealthAssessment $assessment, ?string $helperText): string
|
||||
{
|
||||
$description = $assessment->supportingMessage ?? $assessment->headline;
|
||||
|
||||
if ($helperText === null) {
|
||||
return $description;
|
||||
}
|
||||
|
||||
return trim($description.' '.$helperText);
|
||||
}
|
||||
|
||||
private function canOpenBackupSurfaces(Tenant $tenant): bool
|
||||
{
|
||||
$user = auth()->user();
|
||||
|
||||
return $user instanceof User
|
||||
&& $user->canAccessTenant($tenant)
|
||||
&& $user->can(Capabilities::TENANT_VIEW, $tenant);
|
||||
}
|
||||
}
|
||||
|
||||
@ -5,18 +5,12 @@
|
||||
namespace App\Filament\Widgets\Dashboard;
|
||||
|
||||
use App\Filament\Pages\BaselineCompareLanding;
|
||||
use App\Filament\Resources\BackupScheduleResource;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Resources\FindingResource;
|
||||
use App\Models\FindingException;
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\Tenant;
|
||||
use App\Models\User;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupHealth\BackupHealthActionTarget;
|
||||
use App\Support\BackupHealth\BackupHealthDashboardSignal;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\BackupHealth\TenantBackupHealthResolver;
|
||||
use App\Support\Baselines\TenantGovernanceAggregate;
|
||||
use App\Support\Baselines\TenantGovernanceAggregateResolver;
|
||||
use App\Support\OperationRunLinks;
|
||||
@ -24,7 +18,6 @@
|
||||
use App\Support\Rbac\UiTooltips;
|
||||
use Filament\Facades\Filament;
|
||||
use Filament\Widgets\Widget;
|
||||
use Illuminate\Database\Eloquent\ModelNotFoundException;
|
||||
|
||||
class NeedsAttention extends Widget
|
||||
{
|
||||
@ -48,17 +41,9 @@ protected function getViewData(): array
|
||||
$tenantId = (int) $tenant->getKey();
|
||||
$aggregate = $this->governanceAggregate($tenant);
|
||||
$compareAssessment = $aggregate->summaryAssessment;
|
||||
$backupHealth = $this->backupHealthAssessment($tenant);
|
||||
|
||||
$items = [];
|
||||
|
||||
if (($backupHealthItem = $this->backupHealthAttentionItem($tenant, $backupHealth)) instanceof BackupHealthDashboardSignal) {
|
||||
$items[] = array_merge(
|
||||
$backupHealthItem->toArray(),
|
||||
$this->backupHealthActionPayload($tenant, $backupHealthItem->actionTarget, $backupHealthItem->actionLabel)
|
||||
);
|
||||
}
|
||||
|
||||
$overdueOpenCount = $aggregate->overdueOpenFindingsCount;
|
||||
$lapsedGovernanceCount = $aggregate->lapsedGovernanceCount;
|
||||
$expiringGovernanceCount = $aggregate->expiringGovernanceCount;
|
||||
@ -194,7 +179,6 @@ protected function getViewData(): array
|
||||
|
||||
if ($items === []) {
|
||||
$healthyChecks = [
|
||||
...array_filter([$this->backupHealthHealthyCheck($backupHealth)]),
|
||||
[
|
||||
'title' => 'Baseline compare looks trustworthy',
|
||||
'body' => $aggregate->headline,
|
||||
@ -267,154 +251,4 @@ private function governanceAggregate(Tenant $tenant): TenantGovernanceAggregate
|
||||
|
||||
return $aggregate;
|
||||
}
|
||||
|
||||
private function backupHealthAssessment(Tenant $tenant): TenantBackupHealthAssessment
|
||||
{
|
||||
/** @var TenantBackupHealthResolver $resolver */
|
||||
$resolver = app(TenantBackupHealthResolver::class);
|
||||
|
||||
return $resolver->assess($tenant);
|
||||
}
|
||||
|
||||
private function backupHealthAttentionItem(Tenant $tenant, TenantBackupHealthAssessment $assessment): ?BackupHealthDashboardSignal
|
||||
{
|
||||
if (! $assessment->hasActiveReason()) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return new BackupHealthDashboardSignal(
|
||||
title: $this->backupHealthAttentionTitle($assessment),
|
||||
body: $assessment->supportingMessage ?? $assessment->headline,
|
||||
tone: $assessment->tone(),
|
||||
badge: 'Backups',
|
||||
badgeColor: $assessment->tone(),
|
||||
actionTarget: $assessment->primaryActionTarget,
|
||||
actionLabel: $assessment->primaryActionTarget?->label,
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array{title: string, body: string}|null
|
||||
*/
|
||||
private function backupHealthHealthyCheck(TenantBackupHealthAssessment $assessment): ?array
|
||||
{
|
||||
if (! $assessment->healthyClaimAllowed) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return [
|
||||
'title' => 'Backups are recent and healthy',
|
||||
'body' => $assessment->supportingMessage ?? 'The latest completed backup is recent and shows no material degradation.',
|
||||
];
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array{actionLabel: string|null, actionUrl: string|null, actionDisabled: bool, helperText: string|null}
|
||||
*/
|
||||
private function backupHealthActionPayload(Tenant $tenant, ?BackupHealthActionTarget $target, ?string $label): array
|
||||
{
|
||||
if (! $target instanceof BackupHealthActionTarget) {
|
||||
return [
|
||||
'actionLabel' => $label,
|
||||
'actionUrl' => null,
|
||||
'actionDisabled' => false,
|
||||
'helperText' => null,
|
||||
];
|
||||
}
|
||||
|
||||
if (! $this->canOpenBackupSurfaces($tenant)) {
|
||||
return [
|
||||
'actionLabel' => $label ?? $target->label,
|
||||
'actionUrl' => null,
|
||||
'actionDisabled' => true,
|
||||
'helperText' => UiTooltips::INSUFFICIENT_PERMISSION,
|
||||
];
|
||||
}
|
||||
|
||||
return match ($target->surface) {
|
||||
BackupHealthActionTarget::SURFACE_BACKUP_SETS_INDEX => [
|
||||
'actionLabel' => $label ?? $target->label,
|
||||
'actionUrl' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'actionDisabled' => false,
|
||||
'helperText' => null,
|
||||
],
|
||||
BackupHealthActionTarget::SURFACE_BACKUP_SCHEDULES_INDEX => [
|
||||
'actionLabel' => $label ?? $target->label,
|
||||
'actionUrl' => BackupScheduleResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'actionDisabled' => false,
|
||||
'helperText' => null,
|
||||
],
|
||||
BackupHealthActionTarget::SURFACE_BACKUP_SET_VIEW => $this->backupHealthBackupSetActionPayload($tenant, $target, $label),
|
||||
default => [
|
||||
'actionLabel' => $label,
|
||||
'actionUrl' => null,
|
||||
'actionDisabled' => false,
|
||||
'helperText' => null,
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array{actionLabel: string|null, actionUrl: string|null, actionDisabled: bool, helperText: string|null}
|
||||
*/
|
||||
private function backupHealthBackupSetActionPayload(Tenant $tenant, BackupHealthActionTarget $target, ?string $label): array
|
||||
{
|
||||
if (! is_numeric($target->recordId)) {
|
||||
return [
|
||||
'actionLabel' => 'Open backup sets',
|
||||
'actionUrl' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'actionDisabled' => false,
|
||||
'helperText' => 'The latest backup detail is no longer available.',
|
||||
];
|
||||
}
|
||||
|
||||
try {
|
||||
BackupSetResource::resolveScopedRecordOrFail($target->recordId);
|
||||
|
||||
return [
|
||||
'actionLabel' => $label ?? $target->label,
|
||||
'actionUrl' => BackupSetResource::getUrl('view', [
|
||||
'record' => $target->recordId,
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'actionDisabled' => false,
|
||||
'helperText' => null,
|
||||
];
|
||||
} catch (ModelNotFoundException) {
|
||||
return [
|
||||
'actionLabel' => 'Open backup sets',
|
||||
'actionUrl' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => $target->reason,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
'actionDisabled' => false,
|
||||
'helperText' => 'The latest backup detail is no longer available.',
|
||||
];
|
||||
}
|
||||
}
|
||||
|
||||
private function backupHealthAttentionTitle(TenantBackupHealthAssessment $assessment): string
|
||||
{
|
||||
return match ($assessment->primaryReason) {
|
||||
TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS => 'No usable backup basis',
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE => 'Latest backup is stale',
|
||||
TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED => 'Latest backup is degraded',
|
||||
TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP => 'Backup schedules need follow-up',
|
||||
default => $assessment->headline,
|
||||
};
|
||||
}
|
||||
|
||||
private function canOpenBackupSurfaces(Tenant $tenant): bool
|
||||
{
|
||||
$user = auth()->user();
|
||||
|
||||
return $user instanceof User
|
||||
&& $user->canAccessTenant($tenant)
|
||||
&& $user->can(Capabilities::TENANT_VIEW, $tenant);
|
||||
}
|
||||
}
|
||||
|
||||
@ -86,63 +86,6 @@ public function assignmentsFetchFailed(): bool
|
||||
return $this->metadata['assignments_fetch_failed'] ?? false;
|
||||
}
|
||||
|
||||
public function assignmentCaptureReason(): ?string
|
||||
{
|
||||
$reason = $this->metadata['assignment_capture_reason'] ?? null;
|
||||
|
||||
return is_string($reason) && trim($reason) !== ''
|
||||
? trim($reason)
|
||||
: null;
|
||||
}
|
||||
|
||||
public function snapshotSource(): ?string
|
||||
{
|
||||
$source = $this->metadata['snapshot_source']
|
||||
?? $this->metadata['source']
|
||||
?? null;
|
||||
|
||||
return is_string($source) && trim($source) !== ''
|
||||
? trim($source)
|
||||
: null;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return list<string>
|
||||
*/
|
||||
public function warningMessages(): array
|
||||
{
|
||||
$warnings = $this->metadata['warnings'] ?? [];
|
||||
|
||||
if (! is_array($warnings)) {
|
||||
return [];
|
||||
}
|
||||
|
||||
return collect($warnings)
|
||||
->filter(fn (mixed $warning): bool => is_string($warning) && trim($warning) !== '')
|
||||
->map(fn (string $warning): string => trim($warning))
|
||||
->values()
|
||||
->all();
|
||||
}
|
||||
|
||||
public function integrityWarning(): ?string
|
||||
{
|
||||
$warning = $this->metadata['integrity_warning'] ?? null;
|
||||
|
||||
return is_string($warning) && trim($warning) !== ''
|
||||
? trim($warning)
|
||||
: null;
|
||||
}
|
||||
|
||||
public function protectedPathsCount(): int
|
||||
{
|
||||
return max(0, (int) ($this->metadata['protected_paths_count'] ?? 0));
|
||||
}
|
||||
|
||||
public function hasCapturedPayload(): bool
|
||||
{
|
||||
return is_array($this->payload) && $this->payload !== [];
|
||||
}
|
||||
|
||||
public function isFoundation(): bool
|
||||
{
|
||||
$types = array_column(config('tenantpilot.foundation_types', []), 'type');
|
||||
|
||||
@ -4,7 +4,6 @@
|
||||
|
||||
use App\Support\Baselines\PolicyVersionCapturePurpose;
|
||||
use App\Support\Concerns\DerivesWorkspaceIdFromTenant;
|
||||
use App\Support\RedactionIntegrity;
|
||||
use Illuminate\Database\Eloquent\Factories\HasFactory;
|
||||
use Illuminate\Database\Eloquent\Model;
|
||||
use Illuminate\Database\Eloquent\Relations\BelongsTo;
|
||||
@ -60,55 +59,6 @@ public function baselineProfile(): BelongsTo
|
||||
return $this->belongsTo(BaselineProfile::class);
|
||||
}
|
||||
|
||||
public function snapshotSource(): ?string
|
||||
{
|
||||
$source = $this->metadata['source']
|
||||
?? $this->metadata['snapshot_source']
|
||||
?? null;
|
||||
|
||||
return is_string($source) && trim($source) !== ''
|
||||
? trim($source)
|
||||
: null;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return list<string>
|
||||
*/
|
||||
public function warningMessages(): array
|
||||
{
|
||||
$warnings = $this->metadata['warnings'] ?? [];
|
||||
|
||||
if (! is_array($warnings)) {
|
||||
return [];
|
||||
}
|
||||
|
||||
return collect($warnings)
|
||||
->filter(fn (mixed $warning): bool => is_string($warning) && trim($warning) !== '')
|
||||
->map(fn (string $warning): string => trim($warning))
|
||||
->values()
|
||||
->all();
|
||||
}
|
||||
|
||||
public function assignmentsFetchFailed(): bool
|
||||
{
|
||||
return (bool) ($this->metadata['assignments_fetch_failed'] ?? false);
|
||||
}
|
||||
|
||||
public function hasOrphanedAssignments(): bool
|
||||
{
|
||||
return (bool) ($this->metadata['has_orphaned_assignments'] ?? false);
|
||||
}
|
||||
|
||||
public function integrityWarning(): ?string
|
||||
{
|
||||
return RedactionIntegrity::noteForPolicyVersion($this);
|
||||
}
|
||||
|
||||
public function hasCapturedPayload(): bool
|
||||
{
|
||||
return is_array($this->snapshot) && $this->snapshot !== [];
|
||||
}
|
||||
|
||||
public function scopePruneEligible($query, int $days = 90)
|
||||
{
|
||||
return $query
|
||||
|
||||
@ -52,12 +52,6 @@ public function can(User $user, Tenant $tenant, string $capability): bool
|
||||
return false;
|
||||
}
|
||||
|
||||
if ($this->isLocallyDeniedByBackupHealthBrowserFixture($user, $tenant, $capability)) {
|
||||
$this->logDenial($user, $tenant, $capability);
|
||||
|
||||
return false;
|
||||
}
|
||||
|
||||
$allowed = RoleCapabilityMap::hasCapability($role, $capability);
|
||||
|
||||
if (! $allowed) {
|
||||
@ -67,39 +61,6 @@ public function can(User $user, Tenant $tenant, string $capability): bool
|
||||
return $allowed;
|
||||
}
|
||||
|
||||
private function isLocallyDeniedByBackupHealthBrowserFixture(User $user, Tenant $tenant, string $capability): bool
|
||||
{
|
||||
if (! app()->environment(['local', 'testing'])) {
|
||||
return false;
|
||||
}
|
||||
|
||||
$fixture = config('tenantpilot.backup_health.browser_smoke_fixture.blocked_drillthrough');
|
||||
|
||||
if (! is_array($fixture)) {
|
||||
return false;
|
||||
}
|
||||
|
||||
$fixtureUserEmail = config('tenantpilot.backup_health.browser_smoke_fixture.user.email');
|
||||
|
||||
if (! is_string($fixtureUserEmail) || $fixtureUserEmail === '' || $user->email !== $fixtureUserEmail) {
|
||||
return false;
|
||||
}
|
||||
|
||||
$fixtureTenantExternalId = $fixture['tenant_external_id'] ?? null;
|
||||
|
||||
if (! is_string($fixtureTenantExternalId) || $fixtureTenantExternalId === '' || $tenant->external_id !== $fixtureTenantExternalId) {
|
||||
return false;
|
||||
}
|
||||
|
||||
$deniedCapabilities = $fixture['capability_denials'] ?? [];
|
||||
|
||||
if (! is_array($deniedCapabilities)) {
|
||||
return false;
|
||||
}
|
||||
|
||||
return in_array($capability, $deniedCapabilities, true);
|
||||
}
|
||||
|
||||
private function logDenial(User $user, Tenant $tenant, string $capability): void
|
||||
{
|
||||
$key = implode(':', [(string) $user->getKey(), (string) $tenant->getKey(), $capability]);
|
||||
|
||||
@ -1,17 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupHealth;
|
||||
|
||||
use Carbon\CarbonInterface;
|
||||
|
||||
final readonly class BackupFreshnessEvaluation
|
||||
{
|
||||
public function __construct(
|
||||
public ?CarbonInterface $latestCompletedAt,
|
||||
public CarbonInterface $cutoffAt,
|
||||
public bool $isFresh,
|
||||
public string $policySource = 'configured_window',
|
||||
) {}
|
||||
}
|
||||
@ -1,51 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupHealth;
|
||||
|
||||
final readonly class BackupHealthActionTarget
|
||||
{
|
||||
public const SURFACE_BACKUP_SETS_INDEX = 'backup_sets_index';
|
||||
|
||||
public const SURFACE_BACKUP_SET_VIEW = 'backup_set_view';
|
||||
|
||||
public const SURFACE_BACKUP_SCHEDULES_INDEX = 'backup_schedules_index';
|
||||
|
||||
public function __construct(
|
||||
public string $surface,
|
||||
public ?int $recordId,
|
||||
public string $label,
|
||||
public string $reason,
|
||||
) {}
|
||||
|
||||
public static function backupSetsIndex(string $reason, string $label = 'Open backup sets'): self
|
||||
{
|
||||
return new self(
|
||||
surface: self::SURFACE_BACKUP_SETS_INDEX,
|
||||
recordId: null,
|
||||
label: $label,
|
||||
reason: $reason,
|
||||
);
|
||||
}
|
||||
|
||||
public static function backupSetView(int $recordId, string $reason, string $label = 'Open latest backup'): self
|
||||
{
|
||||
return new self(
|
||||
surface: self::SURFACE_BACKUP_SET_VIEW,
|
||||
recordId: $recordId,
|
||||
label: $label,
|
||||
reason: $reason,
|
||||
);
|
||||
}
|
||||
|
||||
public static function backupSchedulesIndex(string $reason, string $label = 'Open backup schedules'): self
|
||||
{
|
||||
return new self(
|
||||
surface: self::SURFACE_BACKUP_SCHEDULES_INDEX,
|
||||
recordId: null,
|
||||
label: $label,
|
||||
reason: $reason,
|
||||
);
|
||||
}
|
||||
}
|
||||
@ -1,47 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupHealth;
|
||||
|
||||
final readonly class BackupHealthDashboardSignal
|
||||
{
|
||||
public function __construct(
|
||||
public string $title,
|
||||
public string $body,
|
||||
public string $tone,
|
||||
public ?string $badge = null,
|
||||
public ?string $badgeColor = null,
|
||||
public ?BackupHealthActionTarget $actionTarget = null,
|
||||
public bool $actionDisabled = false,
|
||||
public ?string $helperText = null,
|
||||
public ?string $actionLabel = null,
|
||||
public ?string $supportingMessage = null,
|
||||
) {}
|
||||
|
||||
/**
|
||||
* @return array{
|
||||
* title: string,
|
||||
* body: string,
|
||||
* badge: string|null,
|
||||
* badgeColor: string|null,
|
||||
* actionLabel: string|null,
|
||||
* actionDisabled: bool,
|
||||
* helperText: string|null,
|
||||
* supportingMessage: string|null
|
||||
* }
|
||||
*/
|
||||
public function toArray(): array
|
||||
{
|
||||
return [
|
||||
'title' => $this->title,
|
||||
'body' => $this->body,
|
||||
'badge' => $this->badge,
|
||||
'badgeColor' => $this->badgeColor,
|
||||
'actionLabel' => $this->actionLabel,
|
||||
'actionDisabled' => $this->actionDisabled,
|
||||
'helperText' => $this->helperText,
|
||||
'supportingMessage' => $this->supportingMessage,
|
||||
];
|
||||
}
|
||||
}
|
||||
@ -1,19 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupHealth;
|
||||
|
||||
final readonly class BackupScheduleFollowUpEvaluation
|
||||
{
|
||||
public function __construct(
|
||||
public bool $hasEnabledSchedules,
|
||||
public int $enabledScheduleCount,
|
||||
public int $overdueScheduleCount,
|
||||
public int $failedRecentRunCount,
|
||||
public int $neverSuccessfulCount,
|
||||
public bool $needsFollowUp,
|
||||
public ?int $primaryScheduleId,
|
||||
public ?string $summaryMessage,
|
||||
) {}
|
||||
}
|
||||
@ -1,60 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupHealth;
|
||||
|
||||
use App\Support\BackupQuality\BackupQualitySummary;
|
||||
use Carbon\CarbonInterface;
|
||||
|
||||
final readonly class TenantBackupHealthAssessment
|
||||
{
|
||||
public const POSTURE_ABSENT = 'absent';
|
||||
|
||||
public const POSTURE_STALE = 'stale';
|
||||
|
||||
public const POSTURE_DEGRADED = 'degraded';
|
||||
|
||||
public const POSTURE_HEALTHY = 'healthy';
|
||||
|
||||
public const REASON_NO_BACKUP_BASIS = 'no_backup_basis';
|
||||
|
||||
public const REASON_LATEST_BACKUP_STALE = 'latest_backup_stale';
|
||||
|
||||
public const REASON_LATEST_BACKUP_DEGRADED = 'latest_backup_degraded';
|
||||
|
||||
public const REASON_SCHEDULE_FOLLOW_UP = 'schedule_follow_up';
|
||||
|
||||
public function __construct(
|
||||
public int $tenantId,
|
||||
public string $posture,
|
||||
public ?string $primaryReason,
|
||||
public string $headline,
|
||||
public ?string $supportingMessage,
|
||||
public ?int $latestRelevantBackupSetId,
|
||||
public ?CarbonInterface $latestRelevantCompletedAt,
|
||||
public ?BackupQualitySummary $qualitySummary,
|
||||
public BackupFreshnessEvaluation $freshnessEvaluation,
|
||||
public BackupScheduleFollowUpEvaluation $scheduleFollowUp,
|
||||
public bool $healthyClaimAllowed,
|
||||
public ?BackupHealthActionTarget $primaryActionTarget,
|
||||
public string $positiveClaimBoundary,
|
||||
) {}
|
||||
|
||||
public function hasActiveReason(): bool
|
||||
{
|
||||
return $this->primaryReason !== null;
|
||||
}
|
||||
|
||||
public function tone(): string
|
||||
{
|
||||
return match ($this->primaryReason ?? $this->posture) {
|
||||
self::REASON_NO_BACKUP_BASIS => 'danger',
|
||||
self::REASON_LATEST_BACKUP_STALE => 'warning',
|
||||
self::REASON_LATEST_BACKUP_DEGRADED => 'warning',
|
||||
self::REASON_SCHEDULE_FOLLOW_UP => 'warning',
|
||||
self::POSTURE_HEALTHY => 'success',
|
||||
default => 'gray',
|
||||
};
|
||||
}
|
||||
}
|
||||
@ -1,321 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupHealth;
|
||||
|
||||
use App\Models\BackupSchedule;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Tenant;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Carbon\CarbonInterface;
|
||||
use Illuminate\Support\Arr;
|
||||
|
||||
final class TenantBackupHealthResolver
|
||||
{
|
||||
private const POSITIVE_CLAIM_BOUNDARY = 'Backup health reflects backup inputs only and does not prove restore success.';
|
||||
|
||||
public function __construct(
|
||||
private readonly BackupQualityResolver $backupQualityResolver,
|
||||
) {}
|
||||
|
||||
public function assess(Tenant|int $tenant): TenantBackupHealthAssessment
|
||||
{
|
||||
$tenantId = $tenant instanceof Tenant
|
||||
? (int) $tenant->getKey()
|
||||
: (int) $tenant;
|
||||
|
||||
$now = CarbonImmutable::now('UTC');
|
||||
$latestBackupSet = $this->latestRelevantBackupSet($tenantId);
|
||||
$qualitySummary = $latestBackupSet instanceof BackupSet
|
||||
? $this->backupQualityResolver->summarizeBackupSet($latestBackupSet)
|
||||
: null;
|
||||
$freshnessEvaluation = $this->freshnessEvaluation($latestBackupSet?->completed_at, $now);
|
||||
$scheduleFollowUp = $this->scheduleFollowUpEvaluation($tenantId, $now);
|
||||
|
||||
if (! $latestBackupSet instanceof BackupSet) {
|
||||
return new TenantBackupHealthAssessment(
|
||||
tenantId: $tenantId,
|
||||
posture: TenantBackupHealthAssessment::POSTURE_ABSENT,
|
||||
primaryReason: TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS,
|
||||
headline: 'No usable backup basis is available.',
|
||||
supportingMessage: $this->combineMessages([
|
||||
'Create or finish a backup set before relying on restore input.',
|
||||
$scheduleFollowUp->summaryMessage,
|
||||
]),
|
||||
latestRelevantBackupSetId: null,
|
||||
latestRelevantCompletedAt: null,
|
||||
qualitySummary: null,
|
||||
freshnessEvaluation: $freshnessEvaluation,
|
||||
scheduleFollowUp: $scheduleFollowUp,
|
||||
healthyClaimAllowed: false,
|
||||
primaryActionTarget: BackupHealthActionTarget::backupSetsIndex(TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS),
|
||||
positiveClaimBoundary: self::POSITIVE_CLAIM_BOUNDARY,
|
||||
);
|
||||
}
|
||||
|
||||
if (! $freshnessEvaluation->isFresh) {
|
||||
return new TenantBackupHealthAssessment(
|
||||
tenantId: $tenantId,
|
||||
posture: TenantBackupHealthAssessment::POSTURE_STALE,
|
||||
primaryReason: TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
headline: 'Latest backup is stale.',
|
||||
supportingMessage: $this->combineMessages([
|
||||
$this->latestBackupAgeMessage($latestBackupSet->completed_at, $now),
|
||||
$qualitySummary?->hasDegradations() === true ? 'The latest completed backup is also degraded.' : null,
|
||||
$scheduleFollowUp->summaryMessage,
|
||||
]),
|
||||
latestRelevantBackupSetId: (int) $latestBackupSet->getKey(),
|
||||
latestRelevantCompletedAt: $latestBackupSet->completed_at,
|
||||
qualitySummary: $qualitySummary,
|
||||
freshnessEvaluation: $freshnessEvaluation,
|
||||
scheduleFollowUp: $scheduleFollowUp,
|
||||
healthyClaimAllowed: false,
|
||||
primaryActionTarget: BackupHealthActionTarget::backupSetView(
|
||||
recordId: (int) $latestBackupSet->getKey(),
|
||||
reason: TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
),
|
||||
positiveClaimBoundary: self::POSITIVE_CLAIM_BOUNDARY,
|
||||
);
|
||||
}
|
||||
|
||||
if ($qualitySummary?->hasDegradations() === true) {
|
||||
return new TenantBackupHealthAssessment(
|
||||
tenantId: $tenantId,
|
||||
posture: TenantBackupHealthAssessment::POSTURE_DEGRADED,
|
||||
primaryReason: TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED,
|
||||
headline: 'Latest backup is degraded.',
|
||||
supportingMessage: $this->combineMessages([
|
||||
$qualitySummary->summaryMessage,
|
||||
$this->latestBackupAgeMessage($latestBackupSet->completed_at, $now),
|
||||
$scheduleFollowUp->summaryMessage,
|
||||
]),
|
||||
latestRelevantBackupSetId: (int) $latestBackupSet->getKey(),
|
||||
latestRelevantCompletedAt: $latestBackupSet->completed_at,
|
||||
qualitySummary: $qualitySummary,
|
||||
freshnessEvaluation: $freshnessEvaluation,
|
||||
scheduleFollowUp: $scheduleFollowUp,
|
||||
healthyClaimAllowed: false,
|
||||
primaryActionTarget: BackupHealthActionTarget::backupSetView(
|
||||
recordId: (int) $latestBackupSet->getKey(),
|
||||
reason: TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED,
|
||||
),
|
||||
positiveClaimBoundary: self::POSITIVE_CLAIM_BOUNDARY,
|
||||
);
|
||||
}
|
||||
|
||||
$scheduleNeedsFollowUp = $scheduleFollowUp->needsFollowUp;
|
||||
|
||||
return new TenantBackupHealthAssessment(
|
||||
tenantId: $tenantId,
|
||||
posture: TenantBackupHealthAssessment::POSTURE_HEALTHY,
|
||||
primaryReason: $scheduleNeedsFollowUp ? TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP : null,
|
||||
headline: $scheduleNeedsFollowUp
|
||||
? 'Backup schedules need follow-up.'
|
||||
: 'Backups are recent and healthy.',
|
||||
supportingMessage: $scheduleNeedsFollowUp
|
||||
? $this->combineMessages([
|
||||
'The latest completed backup is recent and shows no material degradation.',
|
||||
$scheduleFollowUp->summaryMessage,
|
||||
])
|
||||
: $this->latestBackupAgeMessage($latestBackupSet->completed_at, $now),
|
||||
latestRelevantBackupSetId: (int) $latestBackupSet->getKey(),
|
||||
latestRelevantCompletedAt: $latestBackupSet->completed_at,
|
||||
qualitySummary: $qualitySummary,
|
||||
freshnessEvaluation: $freshnessEvaluation,
|
||||
scheduleFollowUp: $scheduleFollowUp,
|
||||
healthyClaimAllowed: ! $scheduleNeedsFollowUp,
|
||||
primaryActionTarget: $scheduleNeedsFollowUp
|
||||
? BackupHealthActionTarget::backupSchedulesIndex(TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP)
|
||||
: null,
|
||||
positiveClaimBoundary: self::POSITIVE_CLAIM_BOUNDARY,
|
||||
);
|
||||
}
|
||||
|
||||
private function latestRelevantBackupSet(int $tenantId): ?BackupSet
|
||||
{
|
||||
/** @var BackupSet|null $backupSet */
|
||||
$backupSet = BackupSet::query()
|
||||
->withTrashed()
|
||||
->where('tenant_id', $tenantId)
|
||||
->whereNotNull('completed_at')
|
||||
->orderByDesc('completed_at')
|
||||
->orderByDesc('id')
|
||||
->with([
|
||||
'items' => fn ($query) => $query->select([
|
||||
'id',
|
||||
'tenant_id',
|
||||
'backup_set_id',
|
||||
'payload',
|
||||
'metadata',
|
||||
'assignments',
|
||||
]),
|
||||
])
|
||||
->first([
|
||||
'id',
|
||||
'tenant_id',
|
||||
'workspace_id',
|
||||
'name',
|
||||
'status',
|
||||
'item_count',
|
||||
'created_by',
|
||||
'completed_at',
|
||||
'created_at',
|
||||
'metadata',
|
||||
'deleted_at',
|
||||
]);
|
||||
|
||||
return $backupSet;
|
||||
}
|
||||
|
||||
private function freshnessEvaluation(?CarbonInterface $latestCompletedAt, CarbonImmutable $now): BackupFreshnessEvaluation
|
||||
{
|
||||
$cutoffAt = $now->subHours($this->freshnessHours());
|
||||
|
||||
return new BackupFreshnessEvaluation(
|
||||
latestCompletedAt: $latestCompletedAt,
|
||||
cutoffAt: $cutoffAt,
|
||||
isFresh: $latestCompletedAt?->greaterThanOrEqualTo($cutoffAt) ?? false,
|
||||
);
|
||||
}
|
||||
|
||||
private function scheduleFollowUpEvaluation(int $tenantId, CarbonImmutable $now): BackupScheduleFollowUpEvaluation
|
||||
{
|
||||
$graceCutoff = $now->subMinutes($this->scheduleOverdueGraceMinutes());
|
||||
$schedules = BackupSchedule::query()
|
||||
->where('tenant_id', $tenantId)
|
||||
->where('is_enabled', true)
|
||||
->orderBy('next_run_at')
|
||||
->orderBy('id')
|
||||
->get([
|
||||
'id',
|
||||
'tenant_id',
|
||||
'last_run_status',
|
||||
'last_run_at',
|
||||
'next_run_at',
|
||||
'created_at',
|
||||
]);
|
||||
|
||||
$enabledScheduleCount = $schedules->count();
|
||||
$overdueScheduleCount = 0;
|
||||
$failedRecentRunCount = 0;
|
||||
$neverSuccessfulCount = 0;
|
||||
$primaryScheduleId = null;
|
||||
|
||||
foreach ($schedules as $schedule) {
|
||||
$isOverdue = $schedule->next_run_at?->lessThan($graceCutoff) ?? false;
|
||||
$lastRunStatus = strtolower(trim((string) $schedule->last_run_status));
|
||||
$needsFollowUpAfterRun = in_array($lastRunStatus, ['failed', 'partial', 'skipped', 'canceled'], true);
|
||||
$neverSuccessful = $schedule->last_run_at === null
|
||||
&& ($isOverdue || ($schedule->created_at?->lessThan($graceCutoff) ?? false));
|
||||
|
||||
if ($isOverdue) {
|
||||
$overdueScheduleCount++;
|
||||
}
|
||||
|
||||
if ($needsFollowUpAfterRun) {
|
||||
$failedRecentRunCount++;
|
||||
}
|
||||
|
||||
if ($neverSuccessful) {
|
||||
$neverSuccessfulCount++;
|
||||
}
|
||||
|
||||
if ($primaryScheduleId === null && ($neverSuccessful || $isOverdue || $needsFollowUpAfterRun)) {
|
||||
$primaryScheduleId = (int) $schedule->getKey();
|
||||
}
|
||||
}
|
||||
|
||||
return new BackupScheduleFollowUpEvaluation(
|
||||
hasEnabledSchedules: $enabledScheduleCount > 0,
|
||||
enabledScheduleCount: $enabledScheduleCount,
|
||||
overdueScheduleCount: $overdueScheduleCount,
|
||||
failedRecentRunCount: $failedRecentRunCount,
|
||||
neverSuccessfulCount: $neverSuccessfulCount,
|
||||
needsFollowUp: $overdueScheduleCount > 0 || $failedRecentRunCount > 0 || $neverSuccessfulCount > 0,
|
||||
primaryScheduleId: $primaryScheduleId,
|
||||
summaryMessage: $this->scheduleSummaryMessage(
|
||||
enabledScheduleCount: $enabledScheduleCount,
|
||||
overdueScheduleCount: $overdueScheduleCount,
|
||||
failedRecentRunCount: $failedRecentRunCount,
|
||||
neverSuccessfulCount: $neverSuccessfulCount,
|
||||
),
|
||||
);
|
||||
}
|
||||
|
||||
private function latestBackupAgeMessage(?CarbonInterface $completedAt, CarbonImmutable $now): ?string
|
||||
{
|
||||
if (! $completedAt instanceof CarbonInterface) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return sprintf(
|
||||
'The latest completed backup was %s.',
|
||||
$completedAt->diffForHumans($now, [
|
||||
'parts' => 2,
|
||||
'join' => true,
|
||||
'short' => false,
|
||||
'syntax' => CarbonInterface::DIFF_RELATIVE_TO_NOW,
|
||||
]),
|
||||
);
|
||||
}
|
||||
|
||||
private function freshnessHours(): int
|
||||
{
|
||||
return max(1, (int) config('tenantpilot.backup_health.freshness_hours', 24));
|
||||
}
|
||||
|
||||
private function scheduleOverdueGraceMinutes(): int
|
||||
{
|
||||
return max(1, (int) config('tenantpilot.backup_health.schedule_overdue_grace_minutes', 30));
|
||||
}
|
||||
|
||||
private function scheduleSummaryMessage(
|
||||
int $enabledScheduleCount,
|
||||
int $overdueScheduleCount,
|
||||
int $failedRecentRunCount,
|
||||
int $neverSuccessfulCount,
|
||||
): ?string {
|
||||
if ($enabledScheduleCount === 0) {
|
||||
return null;
|
||||
}
|
||||
|
||||
if ($neverSuccessfulCount > 0) {
|
||||
return $neverSuccessfulCount === 1
|
||||
? 'One enabled schedule has not produced a successful run yet.'
|
||||
: sprintf('%d enabled schedules have not produced a successful run yet.', $neverSuccessfulCount);
|
||||
}
|
||||
|
||||
if ($overdueScheduleCount > 0) {
|
||||
return $overdueScheduleCount === 1
|
||||
? 'One enabled schedule looks overdue.'
|
||||
: sprintf('%d enabled schedules look overdue.', $overdueScheduleCount);
|
||||
}
|
||||
|
||||
if ($failedRecentRunCount > 0) {
|
||||
return $failedRecentRunCount === 1
|
||||
? 'One enabled schedule needs follow-up after the last run.'
|
||||
: sprintf('%d enabled schedules need follow-up after the last run.', $failedRecentRunCount);
|
||||
}
|
||||
|
||||
return null;
|
||||
}
|
||||
|
||||
/**
|
||||
* @param array<int, string|null> $messages
|
||||
*/
|
||||
private function combineMessages(array $messages): ?string
|
||||
{
|
||||
$parts = array_values(array_filter(
|
||||
Arr::flatten($messages),
|
||||
static fn (mixed $message): bool => is_string($message) && $message !== ''
|
||||
));
|
||||
|
||||
if ($parts === []) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return implode(' ', $parts);
|
||||
}
|
||||
}
|
||||
@ -1,474 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupQuality;
|
||||
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\PolicyVersion;
|
||||
use Illuminate\Support\Collection;
|
||||
use Illuminate\Support\Str;
|
||||
|
||||
final class BackupQualityResolver
|
||||
{
|
||||
public function summarizeBackupSet(BackupSet $backupSet): BackupQualitySummary
|
||||
{
|
||||
$items = $backupSet->relationLoaded('items')
|
||||
? $backupSet->items
|
||||
: $backupSet->items()->get();
|
||||
|
||||
return $this->summarizeBackupItems(
|
||||
$items,
|
||||
max((int) ($backupSet->item_count ?? 0), $items->count()),
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* @param iterable<BackupItem> $items
|
||||
*/
|
||||
public function summarizeBackupItems(iterable $items, ?int $totalItems = null): BackupQualitySummary
|
||||
{
|
||||
$itemSummaries = Collection::make($items)
|
||||
->map(fn (BackupItem $item): BackupQualitySummary => $this->forBackupItem($item))
|
||||
->values();
|
||||
|
||||
$resolvedTotalItems = max($itemSummaries->count(), (int) ($totalItems ?? 0));
|
||||
$metadataOnlyCount = $itemSummaries->where('metadataOnlyCount', '>', 0)->count();
|
||||
$assignmentIssueCount = $itemSummaries->where('assignmentIssueCount', '>', 0)->count();
|
||||
$orphanedAssignmentCount = $itemSummaries->where('orphanedAssignmentCount', '>', 0)->count();
|
||||
$integrityWarningCount = $itemSummaries->where('integrityWarningCount', '>', 0)->count();
|
||||
$unknownQualityCount = $itemSummaries->where('unknownQualityCount', '>', 0)->count();
|
||||
$degradedItemCount = $itemSummaries->filter(
|
||||
fn (BackupQualitySummary $summary): bool => $summary->hasDegradations()
|
||||
)->count();
|
||||
|
||||
$degradationFamilies = $this->orderedFamilies(
|
||||
$itemSummaries
|
||||
->flatMap(fn (BackupQualitySummary $summary): array => $summary->degradationFamilies)
|
||||
->all(),
|
||||
);
|
||||
|
||||
$qualityHighlights = $this->setHighlights(
|
||||
totalItems: $resolvedTotalItems,
|
||||
degradedItemCount: $degradedItemCount,
|
||||
metadataOnlyCount: $metadataOnlyCount,
|
||||
assignmentIssueCount: $assignmentIssueCount,
|
||||
orphanedAssignmentCount: $orphanedAssignmentCount,
|
||||
integrityWarningCount: $integrityWarningCount,
|
||||
unknownQualityCount: $unknownQualityCount,
|
||||
);
|
||||
|
||||
$compactSummary = $qualityHighlights === []
|
||||
? $this->defaultSetCompactSummary($resolvedTotalItems)
|
||||
: implode(' • ', $qualityHighlights);
|
||||
|
||||
$summaryMessage = match (true) {
|
||||
$resolvedTotalItems === 0 => 'No backup items were captured in this set.',
|
||||
$degradedItemCount === 0 => sprintf(
|
||||
'No degradations were detected across %d captured item%s.',
|
||||
$resolvedTotalItems,
|
||||
$resolvedTotalItems === 1 ? '' : 's',
|
||||
),
|
||||
default => sprintf(
|
||||
'%d of %d captured item%s show degraded input quality.',
|
||||
$degradedItemCount,
|
||||
$resolvedTotalItems,
|
||||
$resolvedTotalItems === 1 ? '' : 's',
|
||||
),
|
||||
};
|
||||
|
||||
$nextAction = match (true) {
|
||||
$resolvedTotalItems === 0 => 'Create or refresh a backup set before starting a restore review.',
|
||||
$degradedItemCount > 0 => 'Open the backup set detail and inspect degraded items before continuing into restore.',
|
||||
default => 'Open the backup set detail to verify item-level context before relying on it for restore work.',
|
||||
};
|
||||
|
||||
return new BackupQualitySummary(
|
||||
kind: 'backup_set',
|
||||
snapshotMode: $this->aggregateSnapshotMode($resolvedTotalItems, $metadataOnlyCount, $unknownQualityCount),
|
||||
totalItems: $resolvedTotalItems,
|
||||
degradedItemCount: $degradedItemCount,
|
||||
metadataOnlyCount: $metadataOnlyCount,
|
||||
assignmentIssueCount: $assignmentIssueCount,
|
||||
orphanedAssignmentCount: $orphanedAssignmentCount,
|
||||
integrityWarningCount: $integrityWarningCount,
|
||||
unknownQualityCount: $unknownQualityCount,
|
||||
hasAssignmentIssues: $assignmentIssueCount > 0,
|
||||
hasOrphanedAssignments: $orphanedAssignmentCount > 0,
|
||||
assignmentCaptureReason: null,
|
||||
integrityWarning: null,
|
||||
degradationFamilies: $degradationFamilies,
|
||||
qualityHighlights: $qualityHighlights,
|
||||
compactSummary: $compactSummary,
|
||||
summaryMessage: $summaryMessage,
|
||||
nextAction: $nextAction,
|
||||
positiveClaimBoundary: $this->positiveClaimBoundary(),
|
||||
);
|
||||
}
|
||||
|
||||
public function forBackupItem(BackupItem $backupItem): BackupQualitySummary
|
||||
{
|
||||
$snapshotMode = $this->resolveSnapshotMode(
|
||||
source: $backupItem->snapshotSource(),
|
||||
warnings: $backupItem->warningMessages(),
|
||||
hasCapturedPayload: $backupItem->hasCapturedPayload(),
|
||||
);
|
||||
|
||||
$assignmentCaptureReason = $backupItem->assignmentCaptureReason();
|
||||
$integrityWarning = $backupItem->integrityWarning();
|
||||
$hasAssignmentIssues = $backupItem->assignmentsFetchFailed();
|
||||
$hasOrphanedAssignments = $backupItem->hasOrphanedAssignments();
|
||||
|
||||
$degradationFamilies = $this->singleRecordFamilies(
|
||||
snapshotMode: $snapshotMode,
|
||||
hasAssignmentIssues: $hasAssignmentIssues,
|
||||
hasOrphanedAssignments: $hasOrphanedAssignments,
|
||||
integrityWarning: $integrityWarning,
|
||||
);
|
||||
|
||||
$qualityHighlights = $this->singleRecordHighlights(
|
||||
snapshotMode: $snapshotMode,
|
||||
hasAssignmentIssues: $hasAssignmentIssues,
|
||||
hasOrphanedAssignments: $hasOrphanedAssignments,
|
||||
integrityWarning: $integrityWarning,
|
||||
assignmentCaptureReason: $assignmentCaptureReason,
|
||||
);
|
||||
|
||||
return new BackupQualitySummary(
|
||||
kind: 'backup_item',
|
||||
snapshotMode: $snapshotMode,
|
||||
totalItems: 1,
|
||||
degradedItemCount: $degradationFamilies === [] ? 0 : 1,
|
||||
metadataOnlyCount: $snapshotMode === 'metadata_only' ? 1 : 0,
|
||||
assignmentIssueCount: $hasAssignmentIssues ? 1 : 0,
|
||||
orphanedAssignmentCount: $hasOrphanedAssignments ? 1 : 0,
|
||||
integrityWarningCount: $integrityWarning !== null ? 1 : 0,
|
||||
unknownQualityCount: $degradationFamilies === ['unknown_quality'] ? 1 : 0,
|
||||
hasAssignmentIssues: $hasAssignmentIssues,
|
||||
hasOrphanedAssignments: $hasOrphanedAssignments,
|
||||
assignmentCaptureReason: $assignmentCaptureReason,
|
||||
integrityWarning: $integrityWarning,
|
||||
degradationFamilies: $degradationFamilies,
|
||||
qualityHighlights: $qualityHighlights,
|
||||
compactSummary: $this->compactSummaryFromHighlights($qualityHighlights, $snapshotMode),
|
||||
summaryMessage: $this->singleRecordSummaryMessage($qualityHighlights, $snapshotMode),
|
||||
nextAction: $degradationFamilies === []
|
||||
? 'Open the linked detail if you need deeper restore context.'
|
||||
: 'Inspect the linked detail before relying on this backup item for restore.',
|
||||
positiveClaimBoundary: $this->positiveClaimBoundary(),
|
||||
);
|
||||
}
|
||||
|
||||
public function forPolicyVersion(PolicyVersion $policyVersion): BackupQualitySummary
|
||||
{
|
||||
$snapshotMode = $this->resolveSnapshotMode(
|
||||
source: $policyVersion->snapshotSource(),
|
||||
warnings: $policyVersion->warningMessages(),
|
||||
hasCapturedPayload: $policyVersion->hasCapturedPayload(),
|
||||
);
|
||||
|
||||
$integrityWarning = $policyVersion->integrityWarning();
|
||||
$hasAssignmentIssues = $policyVersion->assignmentsFetchFailed();
|
||||
$hasOrphanedAssignments = $policyVersion->hasOrphanedAssignments();
|
||||
|
||||
$degradationFamilies = $this->singleRecordFamilies(
|
||||
snapshotMode: $snapshotMode,
|
||||
hasAssignmentIssues: $hasAssignmentIssues,
|
||||
hasOrphanedAssignments: $hasOrphanedAssignments,
|
||||
integrityWarning: $integrityWarning,
|
||||
);
|
||||
|
||||
$qualityHighlights = $this->singleRecordHighlights(
|
||||
snapshotMode: $snapshotMode,
|
||||
hasAssignmentIssues: $hasAssignmentIssues,
|
||||
hasOrphanedAssignments: $hasOrphanedAssignments,
|
||||
integrityWarning: $integrityWarning,
|
||||
);
|
||||
|
||||
return new BackupQualitySummary(
|
||||
kind: 'policy_version',
|
||||
snapshotMode: $snapshotMode,
|
||||
totalItems: 1,
|
||||
degradedItemCount: $degradationFamilies === [] ? 0 : 1,
|
||||
metadataOnlyCount: $snapshotMode === 'metadata_only' ? 1 : 0,
|
||||
assignmentIssueCount: $hasAssignmentIssues ? 1 : 0,
|
||||
orphanedAssignmentCount: $hasOrphanedAssignments ? 1 : 0,
|
||||
integrityWarningCount: $integrityWarning !== null ? 1 : 0,
|
||||
unknownQualityCount: $degradationFamilies === ['unknown_quality'] ? 1 : 0,
|
||||
hasAssignmentIssues: $hasAssignmentIssues,
|
||||
hasOrphanedAssignments: $hasOrphanedAssignments,
|
||||
assignmentCaptureReason: null,
|
||||
integrityWarning: $integrityWarning,
|
||||
degradationFamilies: $degradationFamilies,
|
||||
qualityHighlights: $qualityHighlights,
|
||||
compactSummary: $this->compactSummaryFromHighlights($qualityHighlights, $snapshotMode),
|
||||
summaryMessage: $this->singleRecordSummaryMessage($qualityHighlights, $snapshotMode),
|
||||
nextAction: $degradationFamilies === []
|
||||
? 'Open the version detail if you need raw settings or diff context.'
|
||||
: 'Prefer a stronger version or inspect the version detail before restore.',
|
||||
positiveClaimBoundary: $this->positiveClaimBoundary(),
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* @param list<string> $warnings
|
||||
*/
|
||||
private function resolveSnapshotMode(?string $source, array $warnings, bool $hasCapturedPayload): string
|
||||
{
|
||||
if ($source === 'metadata_only' || $this->warningsIndicateMetadataOnly($warnings)) {
|
||||
return 'metadata_only';
|
||||
}
|
||||
|
||||
if ($hasCapturedPayload) {
|
||||
return 'full';
|
||||
}
|
||||
|
||||
return 'unknown';
|
||||
}
|
||||
|
||||
/**
|
||||
* @param list<string> $warnings
|
||||
*/
|
||||
private function warningsIndicateMetadataOnly(array $warnings): bool
|
||||
{
|
||||
return Collection::make($warnings)
|
||||
->contains(function (mixed $warning): bool {
|
||||
if (! is_string($warning)) {
|
||||
return false;
|
||||
}
|
||||
|
||||
$normalized = Str::lower($warning);
|
||||
|
||||
return str_contains($normalized, 'metadata')
|
||||
&& (
|
||||
str_contains($normalized, 'only')
|
||||
|| str_contains($normalized, 'fallback')
|
||||
);
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* @return list<string>
|
||||
*/
|
||||
private function singleRecordFamilies(
|
||||
string $snapshotMode,
|
||||
bool $hasAssignmentIssues,
|
||||
bool $hasOrphanedAssignments,
|
||||
?string $integrityWarning,
|
||||
): array {
|
||||
$families = [];
|
||||
|
||||
if ($snapshotMode === 'metadata_only') {
|
||||
$families[] = 'metadata_only';
|
||||
}
|
||||
|
||||
if ($hasAssignmentIssues) {
|
||||
$families[] = 'assignment_capture_issue';
|
||||
}
|
||||
|
||||
if ($hasOrphanedAssignments) {
|
||||
$families[] = 'orphaned_assignments';
|
||||
}
|
||||
|
||||
if ($integrityWarning !== null) {
|
||||
$families[] = 'integrity_warning';
|
||||
}
|
||||
|
||||
if ($families === [] && $snapshotMode === 'unknown') {
|
||||
$families[] = 'unknown_quality';
|
||||
}
|
||||
|
||||
return $this->orderedFamilies($families);
|
||||
}
|
||||
|
||||
/**
|
||||
* @return list<string>
|
||||
*/
|
||||
private function singleRecordHighlights(
|
||||
string $snapshotMode,
|
||||
bool $hasAssignmentIssues,
|
||||
bool $hasOrphanedAssignments,
|
||||
?string $integrityWarning,
|
||||
?string $assignmentCaptureReason = null,
|
||||
): array {
|
||||
$highlights = [];
|
||||
|
||||
if ($snapshotMode === 'metadata_only') {
|
||||
$highlights[] = 'Metadata only';
|
||||
}
|
||||
|
||||
if ($hasAssignmentIssues) {
|
||||
$highlights[] = 'Assignment fetch failed';
|
||||
} elseif ($assignmentCaptureReason === 'separate_role_assignments') {
|
||||
$highlights[] = 'Assignments captured separately';
|
||||
}
|
||||
|
||||
if ($hasOrphanedAssignments) {
|
||||
$highlights[] = 'Orphaned assignments';
|
||||
}
|
||||
|
||||
if ($integrityWarning !== null) {
|
||||
$highlights[] = 'Integrity warning';
|
||||
}
|
||||
|
||||
if ($snapshotMode === 'unknown' && $highlights === []) {
|
||||
$highlights[] = 'Unknown quality';
|
||||
}
|
||||
|
||||
return array_values(array_unique($highlights));
|
||||
}
|
||||
|
||||
private function compactSummaryFromHighlights(array $qualityHighlights, string $snapshotMode): string
|
||||
{
|
||||
if ($qualityHighlights !== []) {
|
||||
return implode(' • ', $qualityHighlights);
|
||||
}
|
||||
|
||||
return match ($snapshotMode) {
|
||||
'full' => 'Full payload',
|
||||
'unknown' => 'Unknown quality',
|
||||
default => 'No degradations detected',
|
||||
};
|
||||
}
|
||||
|
||||
private function singleRecordSummaryMessage(array $qualityHighlights, string $snapshotMode): string
|
||||
{
|
||||
if ($qualityHighlights === []) {
|
||||
return match ($snapshotMode) {
|
||||
'full' => 'No degradations were detected from the captured snapshot and assignment metadata.',
|
||||
'unknown' => 'Quality is unknown because this record lacks enough completeness metadata to justify a stronger claim.',
|
||||
default => 'No degradations were detected.',
|
||||
};
|
||||
}
|
||||
|
||||
return implode(' • ', $qualityHighlights).'.';
|
||||
}
|
||||
|
||||
private function aggregateSnapshotMode(int $totalItems, int $metadataOnlyCount, int $unknownQualityCount): string
|
||||
{
|
||||
if ($totalItems === 0) {
|
||||
return 'unknown';
|
||||
}
|
||||
|
||||
if ($metadataOnlyCount === $totalItems) {
|
||||
return 'metadata_only';
|
||||
}
|
||||
|
||||
if ($metadataOnlyCount === 0 && $unknownQualityCount === 0) {
|
||||
return 'full';
|
||||
}
|
||||
|
||||
return 'unknown';
|
||||
}
|
||||
|
||||
/**
|
||||
* @return list<string>
|
||||
*/
|
||||
private function orderedFamilies(array $families): array
|
||||
{
|
||||
$weights = [
|
||||
'metadata_only' => 10,
|
||||
'assignment_capture_issue' => 20,
|
||||
'orphaned_assignments' => 30,
|
||||
'integrity_warning' => 40,
|
||||
'unknown_quality' => 50,
|
||||
];
|
||||
|
||||
$families = array_values(array_unique(array_filter(
|
||||
$families,
|
||||
static fn (mixed $family): bool => is_string($family) && $family !== '',
|
||||
)));
|
||||
|
||||
usort($families, static function (string $left, string $right) use ($weights): int {
|
||||
return ($weights[$left] ?? 999) <=> ($weights[$right] ?? 999);
|
||||
});
|
||||
|
||||
return $families;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return list<string>
|
||||
*/
|
||||
private function setHighlights(
|
||||
int $totalItems,
|
||||
int $degradedItemCount,
|
||||
int $metadataOnlyCount,
|
||||
int $assignmentIssueCount,
|
||||
int $orphanedAssignmentCount,
|
||||
int $integrityWarningCount,
|
||||
int $unknownQualityCount,
|
||||
): array {
|
||||
if ($totalItems === 0) {
|
||||
return [];
|
||||
}
|
||||
|
||||
$highlights = [];
|
||||
|
||||
if ($degradedItemCount > 0) {
|
||||
$highlights[] = sprintf(
|
||||
'%d degraded item%s',
|
||||
$degradedItemCount,
|
||||
$degradedItemCount === 1 ? '' : 's',
|
||||
);
|
||||
}
|
||||
|
||||
if ($metadataOnlyCount > 0) {
|
||||
$highlights[] = sprintf(
|
||||
'%d metadata-only',
|
||||
$metadataOnlyCount,
|
||||
);
|
||||
}
|
||||
|
||||
if ($assignmentIssueCount > 0) {
|
||||
$highlights[] = sprintf(
|
||||
'%d assignment issue%s',
|
||||
$assignmentIssueCount,
|
||||
$assignmentIssueCount === 1 ? '' : 's',
|
||||
);
|
||||
}
|
||||
|
||||
if ($orphanedAssignmentCount > 0) {
|
||||
$highlights[] = sprintf(
|
||||
'%d orphaned assignment%s',
|
||||
$orphanedAssignmentCount,
|
||||
$orphanedAssignmentCount === 1 ? '' : 's',
|
||||
);
|
||||
}
|
||||
|
||||
if ($integrityWarningCount > 0) {
|
||||
$highlights[] = sprintf(
|
||||
'%d integrity warning%s',
|
||||
$integrityWarningCount,
|
||||
$integrityWarningCount === 1 ? '' : 's',
|
||||
);
|
||||
}
|
||||
|
||||
if ($unknownQualityCount > 0) {
|
||||
$highlights[] = sprintf(
|
||||
'%d unknown quality',
|
||||
$unknownQualityCount,
|
||||
);
|
||||
}
|
||||
|
||||
return $highlights;
|
||||
}
|
||||
|
||||
private function defaultSetCompactSummary(int $totalItems): string
|
||||
{
|
||||
if ($totalItems === 0) {
|
||||
return 'No items captured';
|
||||
}
|
||||
|
||||
return sprintf(
|
||||
'No degradations detected across %d item%s',
|
||||
$totalItems,
|
||||
$totalItems === 1 ? '' : 's',
|
||||
);
|
||||
}
|
||||
|
||||
private function positiveClaimBoundary(): string
|
||||
{
|
||||
return 'Input quality signals do not prove safe restore, restore readiness, or tenant-wide recoverability.';
|
||||
}
|
||||
}
|
||||
@ -1,44 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
namespace App\Support\BackupQuality;
|
||||
|
||||
final readonly class BackupQualitySummary
|
||||
{
|
||||
/**
|
||||
* @param list<string> $degradationFamilies
|
||||
* @param list<string> $qualityHighlights
|
||||
*/
|
||||
public function __construct(
|
||||
public string $kind,
|
||||
public string $snapshotMode,
|
||||
public int $totalItems,
|
||||
public int $degradedItemCount,
|
||||
public int $metadataOnlyCount,
|
||||
public int $assignmentIssueCount,
|
||||
public int $orphanedAssignmentCount,
|
||||
public int $integrityWarningCount,
|
||||
public int $unknownQualityCount,
|
||||
public bool $hasAssignmentIssues,
|
||||
public bool $hasOrphanedAssignments,
|
||||
public ?string $assignmentCaptureReason,
|
||||
public ?string $integrityWarning,
|
||||
public array $degradationFamilies,
|
||||
public array $qualityHighlights,
|
||||
public string $compactSummary,
|
||||
public string $summaryMessage,
|
||||
public string $nextAction,
|
||||
public string $positiveClaimBoundary,
|
||||
) {}
|
||||
|
||||
public function hasDegradations(): bool
|
||||
{
|
||||
return $this->degradationFamilies !== [];
|
||||
}
|
||||
|
||||
public function hasIntegrityWarning(): bool
|
||||
{
|
||||
return $this->integrityWarning !== null;
|
||||
}
|
||||
}
|
||||
@ -120,36 +120,6 @@
|
||||
],
|
||||
],
|
||||
|
||||
'backup_health' => [
|
||||
'freshness_hours' => (int) env('TENANTPILOT_BACKUP_HEALTH_FRESHNESS_HOURS', 24),
|
||||
'schedule_overdue_grace_minutes' => (int) env('TENANTPILOT_BACKUP_HEALTH_SCHEDULE_OVERDUE_GRACE_MINUTES', 30),
|
||||
'browser_smoke_fixture' => [
|
||||
'workspace' => [
|
||||
'name' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_WORKSPACE_NAME', 'Spec 180 Backup Health Smoke'),
|
||||
'slug' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_WORKSPACE_SLUG', 'spec-180-backup-health-smoke'),
|
||||
],
|
||||
'user' => [
|
||||
'name' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_USER_NAME', 'Spec 180 Requester'),
|
||||
'email' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_USER_EMAIL', 'smoke-requester+180@tenantpilot.local'),
|
||||
'password' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_USER_PASSWORD', 'password'),
|
||||
],
|
||||
'blocked_drillthrough' => [
|
||||
'tenant_name' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_TENANT_NAME', 'Spec 180 Blocked Backup Tenant'),
|
||||
'tenant_external_id' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_TENANT_EXTERNAL_ID', '18000000-0000-4000-8000-000000000180'),
|
||||
'tenant_id' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_TENANT_ID', '18000000-0000-4000-8000-000000000180'),
|
||||
'app_client_id' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_APP_CLIENT_ID', '18000000-0000-4000-8000-000000000182'),
|
||||
'policy_external_id' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_POLICY_EXTERNAL_ID', 'spec-180-rbac-stale-policy'),
|
||||
'policy_type' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_POLICY_TYPE', 'settingsCatalogPolicy'),
|
||||
'policy_name' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_POLICY_NAME', 'Spec 180 RBAC Smoke Policy'),
|
||||
'backup_set_name' => env('TENANTPILOT_BACKUP_HEALTH_SMOKE_BACKUP_SET_NAME', 'Spec 180 Blocked Stale Backup'),
|
||||
'stale_age_hours' => (int) env('TENANTPILOT_BACKUP_HEALTH_SMOKE_STALE_AGE_HOURS', 48),
|
||||
'capability_denials' => [
|
||||
\App\Support\Auth\Capabilities::TENANT_VIEW,
|
||||
],
|
||||
],
|
||||
],
|
||||
],
|
||||
|
||||
'allow_admin_maintenance_actions' => (bool) env('ALLOW_ADMIN_MAINTENANCE_ACTIONS', false),
|
||||
|
||||
'supported_policy_types' => [
|
||||
|
||||
@ -5,7 +5,7 @@ # Spec Candidates
|
||||
>
|
||||
> **Flow**: Inbox → Qualified → Planned → Spec created → moved to `Promoted to Spec`
|
||||
|
||||
**Last reviewed**: 2026-04-07 (added UI Discipline Trilogy: Record Page Header Discipline, Monitoring Surface Action Hierarchy, Governance Friction & Vocabulary Hardening)
|
||||
**Last reviewed**: 2026-03-28 (added request-scoped performance foundation candidates for derived state, governance aggregates, and workspace access context)
|
||||
|
||||
---
|
||||
|
||||
@ -1480,91 +1480,6 @@ ### Detail Page Hierarchy & Progressive Disclosure (UI/UX Audit)
|
||||
- **Status**: Directly covered by Spec 133 (View Page Template Standard for Enterprise Detail Screens). Spec 133 defines the shared enterprise detail-page composition standard including summary-first header, main-and-supporting layout, dedicated related-context section, secondary technical detail separation, optional section support, and degraded-state resilience. Spec.md, plan.md, research.md, data-model.md, and tasks.md (all tasks complete) exist for 4 initial target pages (BaselineSnapshot, BackupSet, EntraGroup, OperationRun). If additional pages require alignment beyond the initial 4 targets, that is a Spec 133 follow-up scope extension, not a new candidate.
|
||||
- **Reference specs**: 133
|
||||
|
||||
### Record Page Header Discipline & Contextual Navigation
|
||||
- **Type**: hardening
|
||||
- **Source**: Constitution compliance audit 2026-04 — systematic review of Record/Detail page header-action usage across all View/Detail surfaces
|
||||
- **Problem**: Many Record/Detail pages violate the Constitution by using header actions as a catch-all for navigation, secondary actions, and governance actions. The 5-second-scan rule is broken because the primary action is not clearly prioritized, related navigation sits in the wrong place (equal-weight header buttons instead of inline context), and danger/governance actions are not friction-separated. This is the largest systemic Constitution gap on current View/Detail surfaces.
|
||||
- **Why it matters**: As long as this pattern drift persists, the UI remains noisy and inconsistent despite strong foundations. Every new View page risks inheriting the same anti-pattern. Fixing this is the single largest visible lever to close the Constitution gap across the product.
|
||||
- **Proposed direction**:
|
||||
- Define a binding Constitution rule for Record/Detail page header actions: max one visible primary header action, no navigation in headers, related links inline at context, danger/governance actions separated, rare secondary actions in Action Group
|
||||
- Define a standard pattern for header actions on Record/Detail pages
|
||||
- Define a standard pattern for related-context navigation in Infolists (inline, operator-proximate)
|
||||
- Move navigation out of headers into field/status/relation context
|
||||
- Roll out the pattern to all affected View/Detail pages
|
||||
- **Affected surfaces**: Finding Exception, Finding, Tenant Review, Baseline Profile, Evidence Snapshot, Tenant, Provider Connection, and potentially Backup Set, Baseline Snapshot, and other View pages
|
||||
- **Non-goals**: Queue/Workbench surface restructuring (separate candidate), Monitoring header architecture (separate candidate), general visual redesign, deep layout polish of all pages
|
||||
- **Acceptance points**:
|
||||
- Record page Constitution rule is documented
|
||||
- Affected View pages have no navigation buttons as equal-weight header CTAs
|
||||
- Each View page has a clearly prioritized primary action
|
||||
- Danger actions are separated and friction-gated
|
||||
- Related navigation is inline and operator-proximate
|
||||
- **Dependencies**: Spec 133 (View Page Template Standard — provides the detail-page layout foundation this candidate builds on for header-action discipline)
|
||||
- **Related specs / candidates**: Monitoring Surface Action Hierarchy & Workbench Semantics (adjacent but distinct — queue/workbench surfaces need their own rules), Governance Friction & Operator Vocabulary Hardening (complements this with friction/reason-capture/vocabulary hardening)
|
||||
- **Strategic importance**: This is the central lever to eliminate the largest visible Constitution drift in the product. Recommended as the first of three coordinated UI-discipline specs.
|
||||
- **Priority**: high
|
||||
|
||||
### Monitoring Surface Action Hierarchy & Workbench Semantics
|
||||
- **Type**: hardening
|
||||
- **Source**: Constitution compliance audit 2026-04 — Queue/Monitoring/Workbench surfaces mix global surface controls, selection-aware object actions, context navigation, utility actions, and object workflow in the same header/action area
|
||||
- **Problem**: Queue and Monitoring surfaces mix global surface controls, selection-aware object actions, context navigation, filter/utility actions, and scope/back/context signals in the same equal-weight header area. This is a different problem than Record page header noise — it is an information architecture/workbench semantics question that needs its own rules rather than forcing the Record page header pattern onto surfaces with fundamentally different interaction models.
|
||||
- **Why it matters**: After Record page header cleanup, these surfaces would remain the next large inconsistent block. Applying Record page rules to Workbench/Queue surfaces would be a category error — they need their own action hierarchy that respects surface-level controls, selection-aware workflows, and scope context.
|
||||
- **Proposed direction**:
|
||||
- Define a Constitution/pattern rule for Queue/Workbench/Monitoring surfaces with clear action hierarchy layers: global surface actions, selection-aware object actions, context navigation, filter/utility actions, scope/back/context signals
|
||||
- Semantically clean up OperateHub/Monitoring headers so these layers are not presented as equal-weight header items
|
||||
- Extract scope and back-context from header-action noise
|
||||
- Correctly place selection-based workflow actions
|
||||
- Move navigation out of global headers
|
||||
- Make workbench/detail-pane/selection flows cleaner
|
||||
- **Affected surfaces**: Finding Exceptions Queue, Tenantless Operation Viewer, Operations, and potentially Alerts, Audit Log, and other Monitoring pages with OperateHub/scope/selection patterns
|
||||
- **Non-goals**: Solving all Record/View page problems (separate candidate), reinventing the sidebar/navigation, building new large Monitoring features
|
||||
- **Acceptance points**:
|
||||
- Queue/Monitoring Constitution rule is defined
|
||||
- Global and object-level actions are clearly separated
|
||||
- Selection-aware governance actions are not in the same header bucket as utility/navigation
|
||||
- Scope/back context is cleanly placed
|
||||
- Monitoring surfaces are noticeably calmer and faster to scan
|
||||
- **Dependencies**: Record Page Header Discipline (recommended to ship first — establishes the Record page header contract that this candidate explicitly does not reuse for Workbench surfaces)
|
||||
- **Related specs / candidates**: Record Page Header Discipline & Contextual Navigation (adjacent — Record pages vs Workbench surfaces), Governance Friction & Operator Vocabulary Hardening (complements with friction/vocabulary hardening)
|
||||
- **Strategic importance**: Prevents applying a wrong solution (Record page header rules) to a fundamentally different surface class. Recommended as the second of three coordinated UI-discipline specs.
|
||||
- **Priority**: high
|
||||
|
||||
### Governance Friction & Operator Vocabulary Hardening
|
||||
- **Type**: hardening
|
||||
- **Source**: Constitution compliance audit 2026-04 — residual gaps in friction, reason capture, and UI vocabulary consistency across governance-impacting actions
|
||||
- **Problem**: Smaller but important gaps exist in governance friction, reason capture, and UI vocabulary. These are not large enough for the Header/Workbench architecture specs but are critical for enterprise trust, auditability, and consistent operator language. Governance-changing actions lack consistent friction rules, reason capture is missing where governance truth or review/acceptance decisions are affected, danger/confirmation standards vary, and UI vocabulary has naming outliers that diverge from the Constitution.
|
||||
- **Why it matters**: This is the right finishing step after the two architecture-focused specs. Without it, the product would have clean action architecture but inconsistent governance friction and operator language — undermining the enterprise-trust story. It turns a "better UI" into a credible governance-of-record surface.
|
||||
- **Proposed direction**:
|
||||
- Close confirmation/reason-capture gaps across governance-impacting actions
|
||||
- Define a friction heuristic: when only confirm, when optional reason, when mandatory reason
|
||||
- Unify danger semantics across all destructive actions
|
||||
- Fix individual naming/label outliers that diverge from Constitution vocabulary
|
||||
- Harden action naming and operator-facing wording for remaining inconsistencies
|
||||
- **Affected surfaces**: Exception approval/reject flows, evidence/review publish/expire/revoke/renew patterns, individual Resources with inconsistent labels, shared helpers / review heuristics / guardrails where applicable
|
||||
- **Non-goals**: Large IA refactor, re-touching all Monitoring/Record patterns, cosmetic text changes without semantic relevance
|
||||
- **Acceptance points**:
|
||||
- Governance friction rules are clearly documented
|
||||
- Relevant actions have consistent confirmation/reason semantics
|
||||
- Danger semantics are unified
|
||||
- Named UI outliers are corrected
|
||||
- Operator-facing wording follows the Constitution more closely
|
||||
- **Dependencies**: Record Page Header Discipline (recommended first), Monitoring Surface Action Hierarchy (recommended second) — this spec is designed as the targeted finishing step
|
||||
- **Related specs / candidates**: Record Page Header Discipline & Contextual Navigation, Monitoring Surface Action Hierarchy & Workbench Semantics, Spec 156 (operator-outcome-taxonomy), Spec 157 (reason-code-translation)
|
||||
- **Strategic importance**: The targeted closer that turns structural UI improvements into a credible governance-of-record surface. Recommended as the third and final spec in the coordinated UI-discipline trilogy.
|
||||
- **Priority**: high
|
||||
|
||||
> **UI Discipline Trilogy — Sequencing Note**
|
||||
>
|
||||
> These three candidates form a coordinated trilogy that addresses the largest remaining Constitution drift in the product UI:
|
||||
>
|
||||
> 1. **Record Page Header Discipline & Contextual Navigation** — largest visible lever; establishes the binding header-action contract for all Record/Detail pages
|
||||
> 2. **Monitoring Surface Action Hierarchy & Workbench Semantics** — separates Workbench/Queue surfaces from Record page rules; defines the action hierarchy for Monitoring surfaces
|
||||
> 3. **Governance Friction & Operator Vocabulary Hardening** — targeted finishing step for friction, reason capture, and vocabulary consistency
|
||||
>
|
||||
> **Why this order:** Record pages are the most numerous and most directly visible gap. Monitoring surfaces need their own rules (not a Record page derivative). Governance friction is the smallest scope and benefits from the architectural cleanup of the first two specs.
|
||||
>
|
||||
> **Why three specs instead of one:** Each has different affected surfaces, different interaction models, and different implementation patterns. Merging them would create an unshippable monolith. Keeping them sequenced preserves independent delivery while converging on one coherent UI discipline.
|
||||
|
||||
---
|
||||
|
||||
## Planned
|
||||
|
||||
@ -25,7 +25,6 @@
|
||||
use Filament\Http\Middleware\DisableBladeIconComponents;
|
||||
use Filament\Http\Middleware\DispatchServingFilamentEvent;
|
||||
use Illuminate\Http\Request;
|
||||
use Illuminate\Support\Facades\Auth;
|
||||
use Illuminate\Support\Facades\Route;
|
||||
|
||||
Route::get('/', function () {
|
||||
@ -65,32 +64,6 @@
|
||||
->middleware('throttle:entra-callback')
|
||||
->name('auth.entra.callback');
|
||||
|
||||
Route::get('/admin/local/backup-health-browser-fixture-login', function (Request $request) {
|
||||
abort_unless(app()->environment(['local', 'testing']), 404);
|
||||
|
||||
$fixture = config('tenantpilot.backup_health.browser_smoke_fixture');
|
||||
$userEmail = is_array($fixture) ? data_get($fixture, 'user.email') : null;
|
||||
$tenantRouteKey = is_array($fixture)
|
||||
? (data_get($fixture, 'blocked_drillthrough.tenant_id') ?? data_get($fixture, 'blocked_drillthrough.tenant_external_id'))
|
||||
: null;
|
||||
|
||||
abort_unless(is_string($userEmail) && $userEmail !== '', 404);
|
||||
abort_unless(is_string($tenantRouteKey) && $tenantRouteKey !== '', 404);
|
||||
|
||||
$user = User::query()->where('email', $userEmail)->firstOrFail();
|
||||
$tenant = Tenant::query()->where('external_id', $tenantRouteKey)->firstOrFail();
|
||||
$workspace = Workspace::query()->whereKey($tenant->workspace_id)->firstOrFail();
|
||||
|
||||
Auth::login($user);
|
||||
$request->session()->regenerate();
|
||||
|
||||
$workspaceContext = app(WorkspaceContext::class);
|
||||
$workspaceContext->setCurrentWorkspace($workspace, $user, $request);
|
||||
$workspaceContext->rememberTenantContext($tenant, $request);
|
||||
|
||||
return redirect()->to('/admin/t/'.$tenant->external_id);
|
||||
})->name('admin.local.backup-health-browser-fixture-login');
|
||||
|
||||
Route::middleware(['web', 'auth', 'ensure-correct-guard:web'])
|
||||
->post('/admin/switch-workspace', SwitchWorkspaceController::class)
|
||||
->name('admin.switch-workspace');
|
||||
|
||||
@ -1,34 +0,0 @@
|
||||
# Specification Quality Checklist: Backup Quality Truth Surfaces
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-04-07
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- Validated on 2026-04-07. The spec keeps solution details out of the behavior sections; the only structural references are the mandatory surface-identification fields required by this repository's constitution and spec template.
|
||||
@ -1,498 +0,0 @@
|
||||
openapi: 3.1.0
|
||||
info:
|
||||
title: Backup Quality Truth Surface Contracts
|
||||
version: 1.0.0
|
||||
description: >-
|
||||
Internal reference contract for backup-quality truth surfaces. The application
|
||||
continues to return rendered HTML through Filament and Livewire. The vendor
|
||||
media types below document the structured list, detail, and selection models
|
||||
that must be derivable before rendering. This is not a public API commitment.
|
||||
paths:
|
||||
/admin/t/{tenant}/backup-sets:
|
||||
get:
|
||||
summary: Backup-set list surface
|
||||
description: >-
|
||||
Returns the rendered backup-set list page. The vendor media type documents
|
||||
the quality summary model that each visible row must expose.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered backup-set list page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.backup-set-collection+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BackupSetCollectionSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks backup or version viewing capability
|
||||
'404':
|
||||
description: Tenant scope is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/backup-sets/{backupSet}:
|
||||
get:
|
||||
summary: Backup-set detail surface
|
||||
description: >-
|
||||
Returns the rendered backup-set detail page. The vendor media type documents
|
||||
the summary-first quality model and the related per-item quality rows.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: backupSet
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered backup-set detail page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.backup-set-detail+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BackupSetDetailSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks required capability for a linked maintenance action
|
||||
'404':
|
||||
description: Backup set is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/policy-versions:
|
||||
get:
|
||||
summary: Policy-version list surface
|
||||
description: >-
|
||||
Returns the rendered policy-version list page. The vendor media type documents
|
||||
the snapshot mode and backup-quality model that each row must expose.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered policy-version list page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.policy-version-collection+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/PolicyVersionCollectionSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks policy-version viewing capability
|
||||
'404':
|
||||
description: Tenant scope is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/policy-versions/{policyVersion}:
|
||||
get:
|
||||
summary: Policy-version detail surface
|
||||
description: >-
|
||||
Returns the rendered policy-version detail page. The vendor media type documents
|
||||
the explicit backup-quality model that must be available before rendering.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: policyVersion
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered policy-version detail page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.policy-version-detail+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/PolicyVersionDetailSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks capability for a linked mutation action
|
||||
'404':
|
||||
description: Policy version is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/restore-runs/create:
|
||||
get:
|
||||
summary: Restore selection surface with backup-quality hints
|
||||
description: >-
|
||||
Returns the rendered restore wizard. The vendor media type documents the
|
||||
selection-stage backup-quality hints that must appear before risk checks.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: backup_set_id
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered restore wizard page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.restore-selection-quality+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/RestoreSelectionSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks restore capability
|
||||
'404':
|
||||
description: Restore surface is not visible because workspace or tenant membership is missing
|
||||
components:
|
||||
schemas:
|
||||
BackupSetCollectionSurface:
|
||||
type: object
|
||||
required:
|
||||
- rows
|
||||
properties:
|
||||
rows:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/BackupSetRow'
|
||||
BackupSetRow:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- name
|
||||
- lifecycleStatus
|
||||
- itemCount
|
||||
- qualitySummary
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
name:
|
||||
type: string
|
||||
lifecycleStatus:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
itemCount:
|
||||
type: integer
|
||||
capturedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
completedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
qualitySummary:
|
||||
$ref: '#/components/schemas/QualitySummary'
|
||||
BackupSetDetailSurface:
|
||||
type: object
|
||||
required:
|
||||
- header
|
||||
- qualitySummary
|
||||
- itemRows
|
||||
properties:
|
||||
header:
|
||||
$ref: '#/components/schemas/BackupSetHeader'
|
||||
qualitySummary:
|
||||
$ref: '#/components/schemas/QualitySummary'
|
||||
itemRows:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/BackupItemQualityRow'
|
||||
positiveClaimBoundary:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
BackupSetHeader:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- name
|
||||
- lifecycleStatus
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
name:
|
||||
type: string
|
||||
lifecycleStatus:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
archived:
|
||||
type: boolean
|
||||
itemCount:
|
||||
type: integer
|
||||
BackupItemQualityRow:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- label
|
||||
- policyType
|
||||
- snapshotCompleteness
|
||||
- assignmentCapture
|
||||
- hasDegradations
|
||||
- summaryMessage
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
label:
|
||||
type: string
|
||||
policyType:
|
||||
type: string
|
||||
platform:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
versionNumber:
|
||||
type:
|
||||
- integer
|
||||
- 'null'
|
||||
snapshotCompleteness:
|
||||
$ref: '#/components/schemas/SnapshotCompleteness'
|
||||
assignmentCapture:
|
||||
$ref: '#/components/schemas/AssignmentCapture'
|
||||
integrityWarning:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
hasDegradations:
|
||||
type: boolean
|
||||
degradationFamilies:
|
||||
type: array
|
||||
items:
|
||||
type: string
|
||||
summaryMessage:
|
||||
type: string
|
||||
nextAction:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
PolicyVersionCollectionSurface:
|
||||
type: object
|
||||
required:
|
||||
- rows
|
||||
properties:
|
||||
rows:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/PolicyVersionRow'
|
||||
PolicyVersionRow:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- label
|
||||
- versionNumber
|
||||
- snapshotCompleteness
|
||||
- hasDegradations
|
||||
- summaryMessage
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
label:
|
||||
type: string
|
||||
versionNumber:
|
||||
type: integer
|
||||
capturedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
snapshotCompleteness:
|
||||
$ref: '#/components/schemas/SnapshotCompleteness'
|
||||
assignmentCapture:
|
||||
$ref: '#/components/schemas/AssignmentCapture'
|
||||
integrityWarning:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
hasDegradations:
|
||||
type: boolean
|
||||
degradationFamilies:
|
||||
type: array
|
||||
items:
|
||||
type: string
|
||||
summaryMessage:
|
||||
type: string
|
||||
PolicyVersionDetailSurface:
|
||||
type: object
|
||||
required:
|
||||
- header
|
||||
- qualityFact
|
||||
- positiveClaimBoundary
|
||||
properties:
|
||||
header:
|
||||
$ref: '#/components/schemas/PolicyVersionHeader'
|
||||
qualityFact:
|
||||
$ref: '#/components/schemas/QualityFact'
|
||||
positiveClaimBoundary:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
PolicyVersionHeader:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- label
|
||||
- versionNumber
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
label:
|
||||
type: string
|
||||
versionNumber:
|
||||
type: integer
|
||||
capturedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
RestoreSelectionSurface:
|
||||
type: object
|
||||
required:
|
||||
- backupSetOptions
|
||||
- positiveClaimBoundary
|
||||
properties:
|
||||
backupSetOptions:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/RestoreBackupSetOption'
|
||||
itemOptions:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/RestoreBackupItemOption'
|
||||
positiveClaimBoundary:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
RestoreBackupSetOption:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- label
|
||||
- qualitySummary
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
label:
|
||||
type: string
|
||||
qualitySummary:
|
||||
$ref: '#/components/schemas/QualitySummary'
|
||||
RestoreBackupItemOption:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- label
|
||||
- qualityFact
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
label:
|
||||
type: string
|
||||
qualityFact:
|
||||
$ref: '#/components/schemas/QualityFact'
|
||||
QualitySummary:
|
||||
type: object
|
||||
required:
|
||||
- hasDegradations
|
||||
- degradedItemCount
|
||||
- metadataOnlyCount
|
||||
- assignmentIssueCount
|
||||
- orphanedAssignmentCount
|
||||
- summaryLabel
|
||||
properties:
|
||||
hasDegradations:
|
||||
type: boolean
|
||||
degradedItemCount:
|
||||
type: integer
|
||||
metadataOnlyCount:
|
||||
type: integer
|
||||
assignmentIssueCount:
|
||||
type: integer
|
||||
orphanedAssignmentCount:
|
||||
type: integer
|
||||
integrityWarningCount:
|
||||
type: integer
|
||||
unknownQualityCount:
|
||||
type: integer
|
||||
degradationFamilies:
|
||||
type: array
|
||||
items:
|
||||
type: string
|
||||
summaryLabel:
|
||||
type: string
|
||||
nextAction:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
QualityFact:
|
||||
type: object
|
||||
required:
|
||||
- snapshotCompleteness
|
||||
- assignmentCapture
|
||||
- hasDegradations
|
||||
- summaryMessage
|
||||
properties:
|
||||
snapshotCompleteness:
|
||||
$ref: '#/components/schemas/SnapshotCompleteness'
|
||||
assignmentCapture:
|
||||
$ref: '#/components/schemas/AssignmentCapture'
|
||||
integrityWarning:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
hasDegradations:
|
||||
type: boolean
|
||||
degradationFamilies:
|
||||
type: array
|
||||
items:
|
||||
type: string
|
||||
summaryMessage:
|
||||
type: string
|
||||
nextAction:
|
||||
$ref: '#/components/schemas/Fact'
|
||||
SnapshotCompleteness:
|
||||
type: object
|
||||
required:
|
||||
- mode
|
||||
- badgeLabel
|
||||
properties:
|
||||
mode:
|
||||
type: string
|
||||
enum:
|
||||
- full
|
||||
- metadata_only
|
||||
- unknown
|
||||
badgeLabel:
|
||||
type: string
|
||||
sourceSignal:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
AssignmentCapture:
|
||||
type: object
|
||||
required:
|
||||
- issuePresent
|
||||
- orphanedAssignments
|
||||
properties:
|
||||
issuePresent:
|
||||
type: boolean
|
||||
fetchFailed:
|
||||
type: boolean
|
||||
captureReason:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
orphanedAssignments:
|
||||
type: boolean
|
||||
assignmentCount:
|
||||
type:
|
||||
- integer
|
||||
- 'null'
|
||||
Fact:
|
||||
type: object
|
||||
required:
|
||||
- label
|
||||
properties:
|
||||
label:
|
||||
type: string
|
||||
description:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
@ -1,247 +0,0 @@
|
||||
# Data Model: Backup Quality Truth Surfaces
|
||||
|
||||
## Overview
|
||||
|
||||
This feature does not add or change a top-level persisted domain entity. It introduces a tighter derived backup-quality model around the existing tenant-owned backup, version, and restore-selection surfaces.
|
||||
|
||||
The central design task is to make existing backup truth visible without changing:
|
||||
|
||||
- `BackupSet`, `BackupItem`, or `PolicyVersion` ownership
|
||||
- existing backup or restore route identity
|
||||
- existing restore-safety, preview, and execution authority
|
||||
- existing audit and RBAC responsibilities
|
||||
- the no-new-table boundary of this feature
|
||||
|
||||
## Existing Persistent Entities
|
||||
|
||||
### 1. BackupSet
|
||||
|
||||
- Purpose: Tenant-owned backup collection that records lifecycle state and groups captured backup items.
|
||||
- Existing persistent fields used by this feature:
|
||||
- `id`
|
||||
- `tenant_id`
|
||||
- `name`
|
||||
- `status`
|
||||
- `item_count`
|
||||
- `metadata`
|
||||
- `created_by`
|
||||
- `completed_at`
|
||||
- `created_at`
|
||||
- Existing relationships used by this feature:
|
||||
- `tenant`
|
||||
- `items`
|
||||
- `restoreRuns`
|
||||
|
||||
#### Proposed nested metadata additions
|
||||
|
||||
None. Backup-set quality is derived from related backup items and existing set facts. No new backup-set status or metadata field is required.
|
||||
|
||||
### 2. BackupItem
|
||||
|
||||
- Purpose: Tenant-owned captured recovery input for one backed-up policy or foundation record.
|
||||
- Existing persistent fields used by this feature:
|
||||
- `id`
|
||||
- `tenant_id`
|
||||
- `backup_set_id`
|
||||
- `policy_id`
|
||||
- `policy_version_id`
|
||||
- `policy_identifier`
|
||||
- `policy_type`
|
||||
- `platform`
|
||||
- `payload`
|
||||
- `assignments`
|
||||
- `metadata`
|
||||
- `captured_at`
|
||||
- Existing relationships used by this feature:
|
||||
- `tenant`
|
||||
- `backupSet`
|
||||
- `policy`
|
||||
- `policyVersion`
|
||||
|
||||
#### Existing metadata signals used by this feature
|
||||
|
||||
| Key | Type | Meaning |
|
||||
|---|---|---|
|
||||
| `source` | string or null | Primary source marker; may be `metadata_only` |
|
||||
| `snapshot_source` | string or null | Copied source marker from a linked policy version when a backup item is created from a version |
|
||||
| `warnings` | array<string> | Warning messages; may include metadata-only fallback wording |
|
||||
| `assignments_fetch_failed` | boolean | Assignment capture failed for this item |
|
||||
| `assignment_capture_reason` | string or null | Informational reason such as `separate_role_assignments`; not all reasons are degradations |
|
||||
| `has_orphaned_assignments` | boolean | One or more resolved assignment targets were orphaned |
|
||||
| `assignment_count` | integer or null | Captured assignment count |
|
||||
| `scope_tag_ids` | array<int|string> | Captured scope-tag identifiers |
|
||||
| `scope_tag_names` | array<string> | Captured scope-tag names |
|
||||
| `integrity_warning` | string or null | Existing integrity or redaction warning copied into the backup item |
|
||||
| `protected_paths_count` | integer or null | Count of protected or redacted paths copied from the policy version context |
|
||||
|
||||
### 3. PolicyVersion
|
||||
|
||||
- Purpose: Tenant-owned immutable version record for a policy snapshot.
|
||||
- Existing persistent fields used by this feature:
|
||||
- `id`
|
||||
- `tenant_id`
|
||||
- `policy_id`
|
||||
- `version_number`
|
||||
- `snapshot`
|
||||
- `metadata`
|
||||
- `assignments`
|
||||
- `scope_tags`
|
||||
- `secret_fingerprints`
|
||||
- `redaction_version`
|
||||
- `captured_at`
|
||||
- `capture_purpose`
|
||||
- Existing relationships used by this feature:
|
||||
- `tenant`
|
||||
- `policy`
|
||||
- `operationRun`
|
||||
|
||||
#### Existing metadata signals used by this feature
|
||||
|
||||
| Key | Type | Meaning |
|
||||
|---|---|---|
|
||||
| `source` | string or null | Snapshot source marker; `metadata_only` is the primary degraded completeness signal |
|
||||
| `warnings` | array<string> | Snapshot warnings; may include metadata-only fallback language |
|
||||
| `assignments_fetch_failed` | boolean | Assignment capture failed during version capture |
|
||||
| `assignments_fetch_error` | string or null | Human-readable assignment capture error |
|
||||
| `assignments_fetch_error_code` | int or string or null | Technical assignment capture error code |
|
||||
| `has_orphaned_assignments` | boolean | One or more captured assignment targets were orphaned |
|
||||
| `capture_source` | string or null | Existing capture context such as `version_capture` |
|
||||
|
||||
#### Related persisted integrity context used by this feature
|
||||
|
||||
| Field | Type | Meaning |
|
||||
|---|---|---|
|
||||
| `secret_fingerprints` | array | Existing redaction context used to expose integrity notes on version-derived restore inputs |
|
||||
| `redaction_version` | integer | Existing redaction version for operator diagnostics |
|
||||
| `scope_tags` | array | Existing scope-tag context surfaced alongside quality truth where useful |
|
||||
|
||||
### 4. Restore selection context
|
||||
|
||||
- Purpose: Existing wizard state that lets operators choose a backup set and optional backup-item subset before running risk checks.
|
||||
- Existing state used by this feature:
|
||||
- `backup_set_id`
|
||||
- `scope_mode`
|
||||
- `backup_item_ids`
|
||||
- `group_mapping`
|
||||
- `is_dry_run`
|
||||
|
||||
No new persisted restore-selection state is planned. This feature only enriches the current rendered option models.
|
||||
|
||||
## Derived Models
|
||||
|
||||
### 1. SnapshotCompletenessFact
|
||||
|
||||
Derived completeness truth shared by backup items and policy versions.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `mode` | string | metadata-derived | `full`, `metadata_only`, or `unknown` |
|
||||
| `sourceSignal` | string or null | `metadata.source` or `metadata.snapshot_source` | Authoritative direct signal when present |
|
||||
| `warningEvidence` | list<string> | `metadata.warnings` | Secondary fallback signal |
|
||||
| `badgeState` | string | derived | Routes to the existing `PolicySnapshotModeBadge` state |
|
||||
|
||||
Rules:
|
||||
|
||||
- `metadata_only` when `source` or `snapshot_source` equals `metadata_only`, or when warning evidence clearly states metadata-only capture.
|
||||
- `full` only when there is no metadata-only evidence and the record contains enough captured payload context to justify a complete-snapshot claim.
|
||||
- `unknown` only when existing metadata cannot prove either `full` or `metadata_only`.
|
||||
|
||||
### 2. AssignmentCaptureFact
|
||||
|
||||
Derived assignment-quality truth for backup items and policy versions.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `fetchFailed` | boolean | `assignments_fetch_failed` | Primary degraded assignment signal |
|
||||
| `captureReason` | string or null | `assignment_capture_reason` | Informational reason; not always degraded |
|
||||
| `orphanedAssignments` | boolean | `has_orphaned_assignments` | Secondary degraded signal |
|
||||
| `assignmentCount` | integer or null | `assignment_count` or `assignments` length | Informational support data |
|
||||
| `issuePresent` | boolean | derived | True when fetch failed or orphaned targets exist |
|
||||
|
||||
Rules:
|
||||
|
||||
- `assignment_capture_reason = separate_role_assignments` is informative and must not be misread as a failure on its own.
|
||||
- `fetchFailed = true` is a degraded quality signal.
|
||||
- `orphanedAssignments = true` is a degraded quality signal even if fetch succeeded.
|
||||
|
||||
### 3. BackupItemQualityFact
|
||||
|
||||
Default item-level backup-quality model for backup items.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `backupItemId` | integer | record id | Identity |
|
||||
| `snapshotCompleteness` | `SnapshotCompletenessFact` | derived | Primary completeness truth |
|
||||
| `assignmentCapture` | `AssignmentCaptureFact` | derived | Assignment quality truth |
|
||||
| `integrityWarning` | string or null | `metadata.integrity_warning` | Existing integrity signal |
|
||||
| `degradationFamilies` | list<string> | derived | Examples: `metadata_only`, `assignment_capture_issue`, `orphaned_assignments`, `integrity_warning`, `unknown_quality` |
|
||||
| `hasDegradations` | boolean | derived | True when one or more degradation families apply |
|
||||
| `summaryMessage` | string | derived | Concise operator-facing truth |
|
||||
| `nextAction` | string | derived | Primary next step such as inspect detail or continue with caution |
|
||||
|
||||
### 4. BackupSetQualitySummary
|
||||
|
||||
Aggregate backup-quality truth for one backup set.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `backupSetId` | integer | record id | Identity |
|
||||
| `totalItems` | integer | `item_count` or related count | Informational total |
|
||||
| `degradedItemCount` | integer | aggregated item facts | Number of degraded items |
|
||||
| `metadataOnlyCount` | integer | aggregated item facts | Count of metadata-only items |
|
||||
| `assignmentIssueCount` | integer | aggregated item facts | Count of assignment capture failures |
|
||||
| `orphanedAssignmentCount` | integer | aggregated item facts | Count of orphaned-assignment signals |
|
||||
| `integrityWarningCount` | integer | aggregated item facts | Count of integrity warnings carried into backup items |
|
||||
| `unknownQualityCount` | integer | aggregated item facts | Count of items whose quality is truly unknown |
|
||||
| `degradationFamilies` | list<string> | derived | Set-level union of degradation families |
|
||||
| `summaryMessage` | string | derived | Compact summary for list and detail |
|
||||
| `nextAction` | string | derived | Open detail, inspect degraded items, prefer stronger version, or continue with caution |
|
||||
| `positiveClaimBoundary` | string | derived | Explains that quality does not equal safe restore or tenant recoverability |
|
||||
|
||||
Rules:
|
||||
|
||||
- Aggregate counts are computed from related `BackupItemQualityFact` values, never from `BackupSet.status`.
|
||||
- `completed but degraded` remains a display combination of lifecycle plus quality summary, not a new persisted backup-set status.
|
||||
|
||||
### 5. PolicyVersionQualityFact
|
||||
|
||||
Version-level backup-quality truth for policy versions.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `policyVersionId` | integer | record id | Identity |
|
||||
| `snapshotCompleteness` | `SnapshotCompletenessFact` | derived from version metadata | Primary completeness truth |
|
||||
| `assignmentCapture` | `AssignmentCaptureFact` | derived from version metadata and assignments | Assignment quality truth |
|
||||
| `integrityWarning` | string or null | derived from existing redaction or integrity context | Existing warning already present in current restore and version flows |
|
||||
| `degradationFamilies` | list<string> | derived | Same family as backup items where applicable |
|
||||
| `hasDegradations` | boolean | derived | True when one or more degradation families apply |
|
||||
| `summaryMessage` | string | derived | Concise operator-facing truth |
|
||||
| `nextAction` | string | derived | Prefer stronger version, inspect raw settings, or continue to restore with caution |
|
||||
|
||||
### 6. RestoreSelectionQualityHint
|
||||
|
||||
Selection-stage quality model for restore wizard step 1 and step 2.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `targetType` | string | derived | `backup_set` or `backup_item` |
|
||||
| `targetId` | integer | selected record id | Identity |
|
||||
| `summaryMessage` | string | derived | Early warning before risk checks |
|
||||
| `degradationFamilies` | list<string> | derived | Carries through set-level or item-level truth |
|
||||
| `nextAction` | string | derived | Inspect detail or continue with caution |
|
||||
| `positiveClaimBoundary` | string | derived | Explicitly states that input quality is not restore safety |
|
||||
|
||||
Rules:
|
||||
|
||||
- Step 1 uses `BackupSetQualitySummary` facts.
|
||||
- Step 2 uses `BackupItemQualityFact` facts.
|
||||
- Neither step may claim `safe to restore`, `restore ready`, or `tenant recoverable`.
|
||||
|
||||
## Validation Rules
|
||||
|
||||
- Never derive backup quality from `BackupSet.status`, `PolicyVersion` action availability, or restore gating alone.
|
||||
- `assignments_fetch_failed` and `has_orphaned_assignments` are distinct signals and must be surfaced separately where the UI can support it.
|
||||
- `assignment_capture_reason` is explanatory metadata, not automatically a degraded state.
|
||||
- `unknown quality` is permitted only when current metadata cannot justify `full` or `metadata_only` and cannot justify an assignment-quality claim.
|
||||
- `TENANT_VIEW` visibility for backup-quality truth must remain independent from `TENANT_MANAGE` restore capability.
|
||||
- Restore selection hints must explicitly preserve the claim boundary that backup quality is not restore safety.
|
||||
@ -1,288 +0,0 @@
|
||||
# Implementation Plan: Backup Quality Truth Surfaces
|
||||
|
||||
**Branch**: `176-backup-quality-truth` | **Date**: 2026-04-07 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/176-backup-quality-truth/spec.md`
|
||||
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/176-backup-quality-truth/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Harden the backup and versioning surfaces so operators can distinguish `stored` from `usable` and `degraded` recovery input before they reach restore-safety or execution surfaces. The implementation keeps `BackupSet`, `BackupItem`, and `PolicyVersion` as the existing sources of truth, introduces only a narrow derived backup-quality layer over current metadata and relationships, aggregates existing metadata-only and assignment-quality signals into summary facts, and hardens backup-set list and detail, backup-item relation, policy-version list and detail, and restore wizard step 1 and step 2 selection seams without adding a new persistence model.
|
||||
|
||||
Key approach: work inside the existing `BackupSetResource`, `BackupItemsRelationManager`, `PolicyVersionResource`, `RestoreRunResource`, and `CreateRestoreRun` seams; derive per-item and aggregate quality from existing metadata keys such as `source`, `snapshot_source`, `assignments_fetch_failed`, `assignment_capture_reason`, and `has_orphaned_assignments`; reuse Filament v5 tables, infolists, enterprise-detail builders, and shared badge infrastructure; keep all changes Livewire v4 compliant; avoid new tables, new Graph calls, and new asset registration; validate the result with focused Pest, Livewire, RBAC, and regression coverage.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4
|
||||
**Primary Dependencies**: Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `BackupSetResource`, `BackupItemsRelationManager`, `PolicyVersionResource`, `RestoreRunResource`, `CreateRestoreRun`, `AssignmentBackupService`, `VersionService`, `PolicySnapshotService`, `RestoreRiskChecker`, `BadgeRenderer`, `PolicySnapshotModeBadge`, `EnterpriseDetailBuilder`, and existing RBAC helpers
|
||||
**Storage**: PostgreSQL with existing tenant-owned `backup_sets`, `backup_items`, `policy_versions`, and restore wizard input state; JSON-backed `metadata`, `snapshot`, `assignments`, and `scope_tags`; no schema change planned
|
||||
**Testing**: Pest feature tests, Livewire page or action tests, unit tests for narrow derived backup-quality helpers, all run through Sail
|
||||
**Target Platform**: Laravel web application in Sail locally and containerized Linux deployment in staging and production
|
||||
**Project Type**: Laravel monolith web application
|
||||
**Performance Goals**: Keep backup, version, and restore-selection surfaces server-driven and DB-backed at render time, avoid new render-time external calls, preserve fast list scanability, and avoid introducing new N+1 query hotspots while computing quality summaries
|
||||
**Constraints**: No new backup-health table, no new Graph contract path, no new queue or `OperationRun`, no route identity change, no RBAC drift, no conflation of backup quality with restore safety or tenant recoverability, no page-local badge mappings, and no new global Filament assets
|
||||
**Scale/Scope**: One tenant-scoped backup-set list and detail flow, one backup-items relation-manager table, one tenant-scoped policy-version list and detail flow, restore wizard step 1 and step 2 selection surfaces, one narrow derived backup-quality helper layer, and focused regression coverage across truth presentation and RBAC behavior
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Passed before Phase 0 research. Re-checked after Phase 1 design and still passing.*
|
||||
|
||||
| Principle | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| Inventory-first | Pass | Backups and versions remain immutable snapshot truth; no inventory ownership rule changes |
|
||||
| Read/write separation | Pass | This slice is read-first truth hardening; existing restore and delete flows retain their current confirmations, audits, and tests |
|
||||
| Graph contract path | Pass | No new Graph endpoints, no new Graph calls, and no contract registry changes are introduced |
|
||||
| Deterministic capabilities | Pass | Existing capability registry, `CapabilityResolver`, and `UiEnforcement` remain authoritative |
|
||||
| RBAC-UX planes and 404 vs 403 | Pass | All changed surfaces remain tenant-scoped; non-members still get 404, in-scope members without mutation capability still get 403 on execution |
|
||||
| Workspace isolation | Pass | No workspace-scope broadening or cross-workspace visibility changes are planned |
|
||||
| Tenant isolation | Pass | `BackupSet`, `BackupItem`, and `PolicyVersion` stay tenant-owned and tenant-entitled across list, detail, and wizard selection surfaces |
|
||||
| Dangerous and destructive confirmations | Pass | Existing archive, restore, force-delete, and remove actions stay confirmation-gated and server-authorized |
|
||||
| Global search safety | Pass | This feature adds no new globally searchable resource. `PolicyVersionResource` remains non-globally-searchable. `BackupSetResource` already has a view page if current configuration exposes it to search, and this slice adds no new cross-tenant hints |
|
||||
| Run observability | Pass | No new long-running work or `OperationRun` usage is introduced |
|
||||
| Ops-UX 3-surface feedback | Pass | No new operation start, toast, progress, or terminal notification surface is added |
|
||||
| Ops-UX lifecycle ownership | Pass | `OperationRun.status` and `OperationRun.outcome` are untouched |
|
||||
| Ops-UX summary counts | Pass | No new `summary_counts` keys or operation metrics are required |
|
||||
| Data minimization | Pass | The slice reuses existing metadata and keeps diagnostics secondary; no new secret or raw payload exposure is planned |
|
||||
| Proportionality (PROP-001) | Pass | Added logic is limited to a narrow derived backup-quality helper and direct surface integration across existing resources |
|
||||
| Persisted truth (PERSIST-001) | Pass | No new table, column, or stored mirror is introduced; quality remains derived |
|
||||
| Behavioral state (STATE-001) | Pass | Quality distinctions remain derived presentation truth from existing metadata, not new persisted lifecycle state |
|
||||
| Badge semantics (BADGE-001) | Pass | Snapshot-mode rendering continues through `BadgeDomain::PolicySnapshotMode`; any new quality chips or labels stay inside shared badge or copy seams |
|
||||
| Filament-native UI (UI-FIL-001) | Pass | Existing Filament tables, infolists, enterprise-detail cards, and wizard form descriptions remain the primary seams |
|
||||
| UI naming (UI-NAMING-001) | Pass | The plan preserves operator vocabulary such as `metadata-only`, `assignment issues`, `degraded`, `full payload`, and `recovery input`, while avoiding `safe to restore` claims |
|
||||
| Operator surfaces (OPSURF-001) | Pass | Changed surfaces become more operator-first by surfacing quality summary before diagnostics or later restore checks |
|
||||
| Filament Action Surface Contract | Pass | No new inspect model, redundant View action, or empty action group is introduced; action placement remains unchanged |
|
||||
| Filament UX-001 | Pass with documented variance | Backup-set detail continues to use the existing enterprise-detail layout and relation manager, but the plan adds a summary-first quality section before technical detail |
|
||||
| Filament v5 / Livewire v4 compliance | Pass | The implementation stays inside the current Filament v5 and Livewire v4 stack |
|
||||
| Provider registration location | Pass | No provider or panel changes; Laravel 11+ registration remains in `bootstrap/providers.php` |
|
||||
| Asset strategy | Pass | No new panel assets are planned; deployment keeps the existing `php artisan filament:assets` step unchanged |
|
||||
|
||||
## Phase 0 Research
|
||||
|
||||
Research outcomes are captured in `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/176-backup-quality-truth/research.md`.
|
||||
|
||||
Key decisions:
|
||||
|
||||
- Derive backup quality from existing item and version metadata rather than introducing a persisted backup-health model.
|
||||
- Treat backup lifecycle status and backup quality as separate truths on every affected surface.
|
||||
- Reuse the central snapshot-mode badge and shared badge semantics instead of introducing page-local color or status logic.
|
||||
- Extend the existing backup-set enterprise-detail builder, backup-items relation manager, policy-version resource, and restore wizard descriptions instead of creating a parallel dashboard or UI shell.
|
||||
- Surface backup-set and item quality in restore wizard selection steps before the current restore-safety checks and preview steps, without turning quality hints into safety claims.
|
||||
- Keep quality truth visible for `TENANT_VIEW` users even when restore actions remain unavailable.
|
||||
- Use `unknown quality` only when the existing record does not contain authoritative metadata that can justify a stronger claim.
|
||||
- Extend the existing Pest and Livewire test surfaces rather than creating a new browser-first harness.
|
||||
|
||||
## Phase 1 Design
|
||||
|
||||
Design artifacts are created under `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/176-backup-quality-truth/`:
|
||||
|
||||
- `research.md`: design and framework decisions for deriving and surfacing backup quality
|
||||
- `data-model.md`: existing entities, current metadata signals, and narrow derived backup-quality models
|
||||
- `contracts/backup-quality-truth.openapi.yaml`: internal logical contract for backup-set list and detail, backup-item relation rows, policy-version list and detail, and restore wizard selection surfaces
|
||||
- `quickstart.md`: focused automated and manual validation workflow for backup-quality truth hardening
|
||||
|
||||
Design decisions:
|
||||
|
||||
- No schema migration is required; the design derives quality from existing `backup_items.metadata`, `policy_versions.metadata`, relationships, and current restore wizard state.
|
||||
- A narrow derived helper layer is justified because the same quality truth must appear consistently across backup-set list, backup-set detail, backup-items, policy versions, and restore selection surfaces.
|
||||
- Backup-set detail hardening stays inside `BackupSetResource::enterpriseDetailPage()` and existing enterprise-detail cards or sections rather than a new page shell.
|
||||
- Policy-version hardening stays inside the existing table and infolist schema, replacing disabled-action-only signaling with explicit quality truth.
|
||||
- Restore selection hardening stays inside `RestoreRunResource::getWizardSteps()` and `restoreItemOptionData()` so input quality appears before the existing checks and preview steps.
|
||||
- Snapshot mode remains the primary quality badge, while aggregate counts and next-action language stay derived and secondary.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/176-backup-quality-truth/
|
||||
├── spec.md
|
||||
├── plan.md
|
||||
├── research.md
|
||||
├── data-model.md
|
||||
├── quickstart.md
|
||||
├── contracts/
|
||||
│ └── backup-quality-truth.openapi.yaml
|
||||
├── checklists/
|
||||
│ └── requirements.md
|
||||
└── tasks.md
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
app/
|
||||
├── Filament/
|
||||
│ └── Resources/
|
||||
│ ├── BackupSetResource.php
|
||||
│ ├── PolicyVersionResource.php
|
||||
│ ├── RestoreRunResource.php
|
||||
│ └── BackupSetResource/
|
||||
│ └── RelationManagers/
|
||||
│ └── BackupItemsRelationManager.php
|
||||
├── Models/
|
||||
│ ├── BackupItem.php
|
||||
│ ├── BackupSet.php
|
||||
│ └── PolicyVersion.php
|
||||
├── Services/
|
||||
│ ├── AssignmentBackupService.php
|
||||
│ └── Intune/
|
||||
│ ├── PolicySnapshotService.php
|
||||
│ ├── RestoreRiskChecker.php
|
||||
│ ├── RestoreService.php
|
||||
│ └── VersionService.php
|
||||
└── Support/
|
||||
├── BackupQuality/
|
||||
│ ├── BackupQualityResolver.php
|
||||
│ └── BackupQualitySummary.php
|
||||
├── Badges/
|
||||
│ └── Domains/
|
||||
│ └── PolicySnapshotModeBadge.php
|
||||
├── Ui/
|
||||
│ └── EnterpriseDetail/
|
||||
|
||||
tests/
|
||||
├── Feature/
|
||||
│ ├── Filament/
|
||||
│ │ ├── BackupSetUiEnforcementTest.php
|
||||
│ │ ├── BackupSetEnterpriseDetailPageTest.php
|
||||
│ │ ├── BackupItemsRelationManagerFiltersTest.php
|
||||
│ │ ├── BackupQualityTruthSurfaceTest.php
|
||||
│ │ ├── PolicyVersionQualityTruthSurfaceTest.php
|
||||
│ │ ├── PolicyVersionTest.php
|
||||
│ │ ├── PolicyVersionRestoreViaWizardTest.php
|
||||
│ │ ├── RestoreItemSelectionTest.php
|
||||
│ │ └── RestoreSelectionQualityTruthTest.php
|
||||
│ └── Rbac/
|
||||
│ ├── BackupItemsRelationManagerUiEnforcementTest.php
|
||||
│ ├── BackupQualityVisibilityTest.php
|
||||
│ ├── CreateRestoreRunAuthorizationTest.php
|
||||
│ └── PolicyVersionsRestoreToIntuneUiEnforcementTest.php
|
||||
│ └── RestoreRiskChecksWizardTest.php
|
||||
└── Unit/
|
||||
├── Support/
|
||||
│ └── BackupQuality/
|
||||
│ ├── BackupQualityResolverTest.php
|
||||
│ └── BackupSetQualitySummaryTest.php
|
||||
├── AssignmentBackupServiceTest.php
|
||||
└── BackupItemTest.php
|
||||
```
|
||||
|
||||
**Structure Decision**: Standard Laravel monolith. The implementation stays inside existing Filament resources, existing models and services that already hold the underlying metadata, and the current test structure. Any new helper types stay under the existing `app/Support/BackupQuality/` namespace as a narrow derived layer shared across backup, version, and restore-selection surfaces.
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### Phase A — Introduce Narrow Derived Backup-Quality Facts
|
||||
|
||||
**Goal**: Create one reusable derivation path for backup quality from current metadata without adding a new persistence model.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| A.1 | New narrow helper(s) under `app/Support/` if needed | Introduce a minimal backup-quality resolver or read-model helper that computes snapshot mode, assignment capture issues, orphaned assignment flags, integrity warnings, aggregate counts, and next-action guidance from existing `BackupItem` and `PolicyVersion` metadata |
|
||||
| A.2 | `app/Models/BackupItem.php` and, only if clearly justified, `app/Models/PolicyVersion.php` | Add small convenience helpers for repeated metadata checks where this reduces duplication without embedding presentation language into the models |
|
||||
| A.3 | `app/Support/Badges/Domains/PolicySnapshotModeBadge.php` and shared copy seams only if needed | Reuse the current snapshot-mode badge as the canonical item or version completeness signal; add no new badge domain unless a shared value cannot be expressed through current badge semantics |
|
||||
|
||||
### Phase B — Harden Backup-Set List And Detail Truth
|
||||
|
||||
**Goal**: Make backup-set surfaces answer `stored versus degraded` before diagnostics or restore intent.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| B.1 | `app/Filament/Resources/BackupSetResource.php` | Add a compact backup-quality summary to the table that stays separate from lifecycle status and uses aggregate degraded counts rather than `status` to imply quality |
|
||||
| B.2 | `app/Filament/Resources/BackupSetResource.php` | Update `enterpriseDetailPage()` to place a quality summary card or section ahead of technical detail, including metadata-only count, assignment issue count, orphaned assignment count, one primary next action, and contextual related links that stay out of the header |
|
||||
| B.3 | `app/Filament/Resources/BackupSetResource.php` query seams | Ensure the list and detail surfaces eager-load or aggregate the needed backup-item quality facts without introducing a new N+1 hotspot |
|
||||
|
||||
### Phase C — Harden Backup-Item And Policy-Version Truth
|
||||
|
||||
**Goal**: Expose item-level and version-level input quality directly where operators inspect captured records.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| C.1 | `app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php` | Add per-item snapshot mode, assignment capture issue, and orphaned-assignment truth to the relation table, preserving the current inspect model and action placement |
|
||||
| C.2 | `app/Filament/Resources/PolicyVersionResource.php` | Add explicit snapshot mode or quality columns plus a single empty-state CTA to the policy-version list so metadata-only versions are visible at scan speed |
|
||||
| C.3 | `app/Filament/Resources/PolicyVersionResource.php` | Add an explicit backup-quality section to the policy-version detail infolist so restore availability no longer acts as the only quality signal |
|
||||
| C.4 | `app/Filament/Resources/PolicyVersionResource.php` | Preserve current restore-via-wizard gating and tooltip behavior while making quality truth visible independently from action disablement |
|
||||
|
||||
### Phase D — Harden Restore Selection Entry Points
|
||||
|
||||
**Goal**: Expose weak backup inputs before existing restore-safety checks and preview steps begin.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| D.1 | `app/Filament/Resources/RestoreRunResource.php` | Enrich backup-set option labels or helper copy on wizard step 1 with backup-quality summary facts and degraded counts |
|
||||
| D.2 | `app/Filament/Resources/RestoreRunResource.php` | Enrich `restoreItemOptionData()` so wizard step 2 descriptions include snapshot mode and item-level degradation truth before any risk checks run |
|
||||
| D.3 | `app/Filament/Resources/RestoreRunResource.php` and `app/Filament/Resources/RestoreRunResource/Pages/CreateRestoreRun.php` | Preserve the current step order and restore-safety authority, while ensuring backup-quality messaging stops short of `safe to restore` or `recovery guaranteed` language |
|
||||
|
||||
### Phase E — Regression Protection And Focused Verification
|
||||
|
||||
**Goal**: Lock the new truth semantics into automated tests without weakening existing backup or restore behavior.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| E.1 | Existing and new unit tests under `tests/Unit/Support/` | Add deterministic coverage for item-level quality derivation, aggregate backup-set counts, metadata-only detection, assignment failure mapping, and unknown-quality fallback |
|
||||
| E.2 | `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php` and new backup-set truth tests | Cover list or detail quality summary visibility, mixed-quality aggregation, and summary-first ordering |
|
||||
| E.3 | `tests/Feature/Filament/PolicyVersionTest.php`, `tests/Feature/Filament/PolicyVersionRestoreViaWizardTest.php`, and new policy-version truth tests | Cover snapshot mode visibility, explicit detail quality truth, and non-reliance on disabled actions |
|
||||
| E.4 | `tests/Feature/Filament/RestoreItemSelectionTest.php` and new restore-selection truth tests | Cover backup-set quality in step 1 and per-item quality in step 2 before risk checks |
|
||||
| E.5 | RBAC tests under `tests/Feature/Rbac/` | Preserve 404 versus 403 behavior and verify that `TENANT_VIEW` users still see quality truth without restore rights |
|
||||
| E.6 | `vendor/bin/sail bin pint --dirty --format agent` and focused Pest runs | Required formatting and targeted verification before implementation is considered complete |
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
### D-001 — Backup quality is derived from existing capture truth, not stored separately
|
||||
|
||||
The current product already records the signals that matter: metadata-only source markers, assignment fetch failures, orphaned assignments, warnings, and integrity hints. The missing piece is a consistent way to aggregate and display them across surfaces.
|
||||
|
||||
### D-002 — Backup lifecycle status and backup quality stay orthogonal
|
||||
|
||||
`completed`, `partial`, and `failed` remain capture-lifecycle truth. Aggregate backup-quality summaries answer whether the captured inputs appear strong or degraded as recovery input. The plan never reuses lifecycle status as a proxy for quality.
|
||||
|
||||
### D-003 — Snapshot completeness stays on the central badge system
|
||||
|
||||
The existing `PolicySnapshotModeBadge` already defines the primary `full` versus `metadata only` language. This slice reuses that badge instead of introducing a second status vocabulary for the same truth.
|
||||
|
||||
### D-004 — Restore selection surfaces expose input quality, not safety approval
|
||||
|
||||
Step 1 and step 2 only need to tell the operator whether the chosen backup set or items look degraded. Restore safety, preview decisions, and execution readiness remain owned by the later steps and existing restore-safety logic.
|
||||
|
||||
### D-005 — RBAC can suppress actions, not truth
|
||||
|
||||
Users with view rights must still see backup-quality truth even when restore entry points or maintenance actions are unavailable. Hiding or muting quality because of missing restore capability would falsify the surface.
|
||||
|
||||
### D-006 — Existing Filament seams are sufficient
|
||||
|
||||
The current enterprise-detail builder, table columns, infolist sections, and checkbox-list descriptions already provide the UI seams this slice needs. A dashboard, custom shell, or new client-side state layer would be disproportionate.
|
||||
|
||||
### D-007 — Unknown quality is an explicit fallback, not the default
|
||||
|
||||
The product should only emit `unknown quality` where current records truly lack authoritative metadata. If existing metadata can justify `metadata-only`, `assignment issue`, or `orphaned assignments`, the surface must say so directly.
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
| Risk | Impact | Likelihood | Mitigation |
|
||||
|------|--------|------------|------------|
|
||||
| Aggregation logic diverges between backup items, policy versions, and restore selection descriptions | High | Medium | Use one narrow derived helper path and cover it with mixed-quality unit and feature tests |
|
||||
| Quality summary introduces N+1 queries or heavy per-row work on backup-set list pages | High | Medium | Preload relations or aggregate counts deliberately and add list-focused regression coverage |
|
||||
| UI wording slips from backup quality into restore safety or tenant recoverability claims | High | Medium | Keep operator copy centralized and test for explicit non-claims on degraded and healthy-looking cases |
|
||||
| Read-only users lose quality visibility because existing restore gating is accidentally reused | High | Medium | Add dedicated RBAC visibility tests for `TENANT_VIEW` members without restore capability |
|
||||
| Metadata-only restore blocking semantics regress because selection hints are coupled too tightly to risk checks | Medium | Medium | Keep restore selection quality read-only and rerun focused restore-safety regression tests alongside the new surface tests |
|
||||
|
||||
## Test Strategy
|
||||
|
||||
- Extend existing backup-set, backup-items, policy-version, restore-selection, and RBAC Pest coverage before introducing any new harness.
|
||||
- Add unit tests for the narrow backup-quality helper so metadata-only detection, assignment issue mapping, orphaned-assignment mapping, and aggregate counts remain deterministic.
|
||||
- Add feature tests that prove `completed` and `good backup` are no longer visually conflated on backup-set list and detail surfaces.
|
||||
- Add feature tests that prove metadata-only and assignment-capture issues are visible on backup items and policy versions without relying on disabled actions or late restore checks.
|
||||
- Add feature tests that prove restore wizard step 1 and step 2 expose degraded input before risk checks or preview generation.
|
||||
- Add RBAC tests that prove `TENANT_VIEW` users still see backup-quality truth while restore actions remain unavailable, and non-members still receive 404 semantics.
|
||||
- Re-run existing restore-safety and restore-selection tests so earlier input-quality visibility does not change existing risk-check or execution behavior.
|
||||
- Keep all tests Livewire v4 compatible and run the smallest affected subset through Sail before asking for a full-suite pass.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
No constitution violations or exception-driven complexity were identified. The only added structure is a narrow derived backup-quality helper layer justified by cross-surface reuse and the need to keep current metadata interpretation consistent across list, detail, and wizard selection surfaces.
|
||||
|
||||
## Proportionality Review
|
||||
|
||||
- **Current operator problem**: Operators can currently tell that a backup set, backup item, or policy version exists, but they cannot quickly tell whether it is strong, degraded, or metadata-only as recovery input before they reach deep diagnostics or restore-safety surfaces.
|
||||
- **Existing structure is insufficient because**: The relevant truth is fragmented across backup metadata, version metadata, assignment fetch flags, orphaned-assignment markers, and disabled restore actions. Presence is visible earlier than usefulness, which creates false trust.
|
||||
- **Narrowest correct implementation**: Add one narrow derived backup-quality helper path and integrate it directly into existing backup-set, backup-item, policy-version, and restore-selection surfaces without adding new persistence or a broad taxonomy framework.
|
||||
- **Ownership cost created**: A small amount of derivation logic, additional list or detail wiring, and focused unit and feature tests to keep the mapping stable.
|
||||
- **Alternative intentionally rejected**: A persisted backup-health table, a recovery-confidence score, or a dashboard-wide backup-health program. Each would create broader truth and ownership cost than the current operator problem requires.
|
||||
- **Release truth**: Current-release truth. This slice corrects the truth on already-shipped backup and version surfaces before later backup-health or recovery-confidence work builds on them.
|
||||
@ -1,132 +0,0 @@
|
||||
# Quickstart: Backup Quality Truth Surfaces
|
||||
|
||||
## Goal
|
||||
|
||||
Validate that backup-set, backup-item, policy-version, and restore-selection surfaces now communicate backup quality truth early and explicitly without overstating restore safety, restore readiness, or tenant recoverability.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Start Sail if it is not already running.
|
||||
2. Ensure the workspace has representative fixtures for:
|
||||
- a backup set with only full-payload items
|
||||
- a backup set with at least one metadata-only item
|
||||
- a backup set with assignment fetch failure metadata
|
||||
- a backup set with orphaned-assignment metadata
|
||||
- one policy version captured as full payload
|
||||
- one policy version captured as metadata-only
|
||||
- one user with `TENANT_VIEW` but without restore capability
|
||||
- one user with restore capability for the same tenant
|
||||
3. Ensure the acting users are valid workspace and tenant members.
|
||||
4. Ensure archived backup-set and policy-version fixtures exist if lifecycle plus quality combinations need validation.
|
||||
|
||||
## Focused Automated Verification
|
||||
|
||||
Run the smallest existing backup, version, and restore-selection pack first:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupSetUiEnforcementTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/PolicyVersionTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/PolicyVersionRestoreViaWizardTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/RestoreItemSelectionTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Rbac/PolicyVersionsRestoreToIntuneUiEnforcementTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Rbac/CreateRestoreRunAuthorizationTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/RestoreRiskChecksWizardTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Unit/AssignmentBackupServiceTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Unit/BackupItemTest.php
|
||||
```
|
||||
|
||||
Expected new or expanded spec-scoped tests:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupQualityTruthSurfaceTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/PolicyVersionQualityTruthSurfaceTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/RestoreSelectionQualityTruthTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Rbac/BackupQualityVisibilityTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Unit/Support/BackupQuality/
|
||||
```
|
||||
|
||||
Use `--filter` for a smaller pass while iterating.
|
||||
|
||||
## Manual Validation Pass
|
||||
|
||||
### 1. Verify backup-set list truth
|
||||
|
||||
Open `/admin/t/{tenant}/backup-sets` and confirm:
|
||||
|
||||
- lifecycle status remains visible and separate from backup-quality summary
|
||||
- a full-quality set reads as `no degradations detected` or equivalent without implying safe restore
|
||||
- a degraded set shows metadata-only, assignment issues, orphaned assignments, or degraded-item count within one scan
|
||||
|
||||
### 2. Verify backup-set detail summary-first layout
|
||||
|
||||
Open a degraded backup set and confirm:
|
||||
|
||||
- the first visible summary answers whether the set is strong or weak as recovery input
|
||||
- metadata-only count, assignment issue count, and orphaned-assignment count appear before raw metadata
|
||||
- one primary next action is visible when degraded truth exists
|
||||
|
||||
### 3. Verify backup-items relation truth
|
||||
|
||||
Within the same backup-set detail page, confirm the relation table shows:
|
||||
|
||||
- snapshot mode per item
|
||||
- assignment capture issue truth per item
|
||||
- orphaned-assignment truth per item
|
||||
- current inspect model and action placement remain unchanged
|
||||
|
||||
### 4. Verify policy-version list and detail truth
|
||||
|
||||
Open `/admin/t/{tenant}/policy-versions` and confirm:
|
||||
|
||||
- metadata-only versions are visible at scan speed in the list itself
|
||||
- full-payload and degraded versions are distinguishable without hovering disabled actions
|
||||
|
||||
Open a degraded policy version and confirm:
|
||||
|
||||
- an explicit backup-quality section appears on the detail surface
|
||||
- the page explains degraded input quality without claiming safe restore or meaningful rollback certainty
|
||||
|
||||
### 5. Verify restore-selection truth before risk checks
|
||||
|
||||
Open `/admin/t/{tenant}/restore-runs/create` and confirm:
|
||||
|
||||
- step 1 backup-set choices expose degraded input before the wizard reaches checks or preview
|
||||
- step 2 item descriptions expose metadata-only and assignment-quality truth before risk checks run
|
||||
- the page still treats backup quality as input truth, not restore safety approval
|
||||
|
||||
### 6. Verify RBAC-safe truth visibility
|
||||
|
||||
Repeat the list and detail checks as a user with `TENANT_VIEW` but without restore permission and confirm:
|
||||
|
||||
- backup-quality truth remains visible
|
||||
- restore entry points remain unavailable or disabled with the current RBAC behavior
|
||||
- non-members still receive deny-as-not-found behavior rather than resource hints
|
||||
|
||||
## Non-Regression Checks
|
||||
|
||||
Confirm the feature did not change:
|
||||
|
||||
- tenant route identity for backup, version, or restore pages
|
||||
- current archive, restore, force-delete, or remove confirmation behavior
|
||||
- existing restore-safety blocking behavior for metadata-only input
|
||||
- existing assignment capture semantics and orphaned-assignment detection
|
||||
- current global asset registration and deployment requirements
|
||||
|
||||
## Formatting And Final Verification
|
||||
|
||||
Before finalizing implementation work:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail bin pint --dirty --format agent
|
||||
```
|
||||
|
||||
Then rerun the smallest affected test set and offer the full suite only after the focused backup-quality pack passes.
|
||||
|
||||
Close the feature only after manual validation confirms:
|
||||
|
||||
- an operator can identify degraded versus full-looking backup input within 10 seconds on backup-set list and detail surfaces
|
||||
- the first restore selection step exposes weak inputs before risk-check work begins
|
||||
- reduced-permission users still see truthful quality signals without gaining restore capability
|
||||
@ -1,65 +0,0 @@
|
||||
# Research: Backup Quality Truth Surfaces
|
||||
|
||||
## Decision 1: Derive backup quality from existing backup and version metadata instead of creating a persisted backup-health model
|
||||
|
||||
- Decision: Build backup quality from the metadata already present on `BackupItem` and `PolicyVersion`, then aggregate backup-set truth from those per-item facts. Do not add a new table, column, or stored backup-health projection.
|
||||
- Rationale: The current data model already records the core quality signals this feature needs: metadata-only source markers, assignment fetch failures, orphaned assignments, warnings, scope-tag context, and integrity notes. The product problem is weak surfacing, not missing persistence.
|
||||
- Alternatives considered:
|
||||
- Persist a `backup_quality` or `backup_health` table. Rejected because it would create a second source of truth for information that is already derivable.
|
||||
- Add materialized quality fields to `backup_sets` or `policy_versions`. Rejected because the feature does not need independent lifecycle state.
|
||||
|
||||
## Decision 2: Keep capture lifecycle and backup quality as separate truths on every affected surface
|
||||
|
||||
- Decision: Render capture lifecycle (`completed`, `partial`, `failed`, `archived`) independently from backup quality (`metadata-only present`, `assignment issues present`, degraded-count summary, or no degradations detected).
|
||||
- Rationale: Operators currently overread `completed` as `good backup`. The feature must stop that conflation without erasing the lifecycle truth that the system already tracks.
|
||||
- Alternatives considered:
|
||||
- Blend quality into one stronger status badge. Rejected because that would collapse two different truths into one ambiguous state.
|
||||
- Treat `completed` plus degraded counts as a new status family. Rejected because it would introduce new state where derived summary is sufficient.
|
||||
|
||||
## Decision 3: Reuse the central snapshot-mode badge and shared badge infrastructure instead of page-local mapping
|
||||
|
||||
- Decision: Use the existing `BadgeDomain::PolicySnapshotMode` and `PolicySnapshotModeBadge` semantics for `full` versus `metadata only`. Any new quality chips or labels should stay inside shared badge or copy seams rather than page-local `match` statements.
|
||||
- Rationale: The codebase already centralizes status-like badge semantics, and Filament v5 tables or schema text badges can render those shared specs directly. This keeps backup quality aligned with BADGE-001 and avoids a second vocabulary for snapshot completeness.
|
||||
- Alternatives considered:
|
||||
- Add local badge mapping per surface. Rejected because it would drift from the central badge catalog.
|
||||
- Introduce a generic trust score badge. Rejected because the spec explicitly avoids a new scoring engine.
|
||||
|
||||
## Decision 4: Use existing Filament tables, infolists, enterprise-detail sections, and checkbox-list descriptions instead of a new UI shell
|
||||
|
||||
- Decision: Implement the feature inside `BackupSetResource`, `BackupItemsRelationManager`, `PolicyVersionResource`, and `RestoreRunResource` using the current Filament table columns, infolist sections, enterprise-detail builder, and wizard descriptions.
|
||||
- Rationale: Filament v5 already supports badge columns, summary-first view content, relation-manager tables, and descriptive checkbox list options. The repository also already uses `enterpriseDetailPage()` for backup-set detail and schema-driven wizard steps for restore selection.
|
||||
- Alternatives considered:
|
||||
- Build a dedicated backup-health dashboard. Rejected because it is explicitly out of scope.
|
||||
- Add a custom client-side wizard overlay. Rejected because the needed truth is server-driven and fits existing Filament seams.
|
||||
|
||||
## Decision 5: Surface backup-set and item quality in restore selection before risk checks, but keep restore safety as a separate authority
|
||||
|
||||
- Decision: Enrich restore wizard step 1 backup-set labels or helper copy and step 2 item descriptions with input-quality truth before preview or risk checks run. Do not block degraded selections at this stage unless existing restore safety already blocks them later.
|
||||
- Rationale: Operators need early warning before the risk-check stage, but this spec is about backup quality, not execution safety. The restore-safety layer already owns blocker and preview-only semantics.
|
||||
- Alternatives considered:
|
||||
- Leave degraded truth exclusively to restore risk checks. Rejected because it preserves the current late-discovery trust failure.
|
||||
- Prevent selecting degraded inputs in step 1 or step 2. Rejected because the spec requires truthful surfacing, not a new restore policy.
|
||||
|
||||
## Decision 6: Preserve truth visibility for `TENANT_VIEW` users even when restore actions remain unavailable
|
||||
|
||||
- Decision: Quality truth remains visible on backup-set and policy-version surfaces for users who can view tenant backup or version records, even if they cannot create restore runs or use maintenance actions.
|
||||
- Rationale: Missing restore permission must not make degraded inputs appear calmer or cleaner. Authorization can suppress mutation, but it must not suppress source-of-truth visibility.
|
||||
- Alternatives considered:
|
||||
- Couple quality sections to restore permissions. Rejected because it would falsify the operator surface.
|
||||
- Rely on disabled restore actions as the quality indicator for lower-privilege users. Rejected because disabled actions are not an adequate explanation of input quality.
|
||||
|
||||
## Decision 7: Use `unknown quality` only when existing metadata cannot justify a stronger claim
|
||||
|
||||
- Decision: Emit `unknown quality` only when the record lacks authoritative metadata for snapshot completeness or assignment-quality interpretation. Absence of an error is not enough to call an item or version `full` if the record never captured the relevant quality signal.
|
||||
- Rationale: Defaulting to `unknown` too often would hide real degradations, while defaulting to `full` from silence would overstate confidence. This feature needs a narrow, evidence-based fallback.
|
||||
- Alternatives considered:
|
||||
- Default all older records to `unknown`. Rejected because many records already carry usable source metadata.
|
||||
- Infer `full` whenever `metadata_only` is absent. Rejected because silence is not always proof of completeness.
|
||||
|
||||
## Decision 8: Extend the existing Pest and Livewire test surface rather than introducing a browser-first harness
|
||||
|
||||
- Decision: Add focused unit coverage for backup-quality derivation and extend existing backup, version, restore-selection, and RBAC feature tests for UI truth. Keep the current Pest and Livewire patterns as the main verification path.
|
||||
- Rationale: The affected behavior is server-driven list, detail, and wizard state, which the current test suite already covers well. The repo also already has restore and RBAC tests that should remain authoritative.
|
||||
- Alternatives considered:
|
||||
- Rely only on manual validation. Rejected because the feature is specifically about preventing subtle trust regressions.
|
||||
- Introduce a large browser-only test pack. Rejected because the most important assertions are deterministic server-side state and rendered truth.
|
||||
@ -1,193 +0,0 @@
|
||||
# Feature Specification: Backup Quality Truth Surfaces
|
||||
|
||||
**Feature Branch**: `[176-backup-quality-truth]`
|
||||
**Created**: 2026-04-07
|
||||
**Status**: Draft
|
||||
**Input**: User description: "Spec 176 - Backup Quality Truth Surfaces"
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: tenant
|
||||
- **Primary Routes**: `/admin/t/{tenant}/backup-sets`, `/admin/t/{tenant}/backup-sets/{record}`, `/admin/t/{tenant}/policy-versions`, `/admin/t/{tenant}/policy-versions/{record}`, `/admin/t/{tenant}/restore-runs/create`
|
||||
- **Data Ownership**: Tenant-owned `BackupSet`, `BackupItem`, `PolicyVersion`, and `RestoreRun` draft-selection state within the active workspace and tenant scope.
|
||||
- **RBAC**: Workspace plus tenant membership is required on every affected surface. Members with `TENANT_VIEW` must see backup-quality truth on backup and version surfaces. Restore creation remains gated by `TENANT_MANAGE`. Backup-set mutation actions remain gated by existing `TENANT_SYNC`, `TENANT_MANAGE`, and `TENANT_DELETE` capabilities.
|
||||
|
||||
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Surface Type | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Backup sets page | CRUD / list-first resource | Full-row click to backup-set detail | required | One inline safe shortcut plus More | More menu and bulk More | `/admin/t/{tenant}/backup-sets` | `/admin/t/{tenant}/backup-sets/{record}` | Workspace context plus tenant context | Backup sets / Backup set | Capture lifecycle and backup quality summary | none |
|
||||
| Backup set detail | Detail plus relation manager | Direct detail page | forbidden | Contextual summary links plus relation header actions | Resource More and relation-manager More | `/admin/t/{tenant}/backup-sets` | `/admin/t/{tenant}/backup-sets/{record}` | Tenant context plus related policy context | Backup set | Quality summary before per-item diagnostics | none |
|
||||
| Backup items table | Relation-manager table | Full-row click within backup-set detail | required | Relation header actions plus More | More menu and bulk More | `/admin/t/{tenant}/backup-sets/{record}` | `/admin/t/{tenant}/backup-sets/{record}` | Parent backup set plus tenant context | Backup items / Backup item | Snapshot mode and assignment-quality truth per item | existing relation-manager pattern |
|
||||
| Policy versions page | CRUD / list-first resource | Full-row click to policy-version detail | required | More menu | More menu and bulk More | `/admin/t/{tenant}/policy-versions` | `/admin/t/{tenant}/policy-versions/{record}` | Workspace context plus tenant context | Policy versions / Policy version | Snapshot mode and version input quality | Empty-state CTA routes to backup sets |
|
||||
| Policy version detail | Detail / infolist page | Direct detail page | forbidden | Minimal related navigation only | No new destructive detail action placement | `/admin/t/{tenant}/policy-versions` | `/admin/t/{tenant}/policy-versions/{record}` | Tenant context plus related policy context | Policy version | Explicit backup-quality truth separate from restore availability | existing minimal header pattern |
|
||||
| Restore run create wizard | Wizard / selection workflow | Step-driven selection inside restore-run creation | forbidden | Inline descriptions and next-action guidance | None at selection stage | `/admin/t/{tenant}/restore-runs` | `/admin/t/{tenant}/restore-runs/create` | Tenant context plus selected backup set | Restore run / Backup selection | Backup-set and item quality before safety checks | none |
|
||||
|
||||
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| Backup sets page | Tenant operator | List | Which backup sets look strong or weak as recovery input? | Name, item count, capture timing, lifecycle status, compact backup-quality summary | Raw item metadata, per-item details, restore safety analysis | Capture lifecycle, input quality | TenantPilot only for existing archive and restore maintenance | Open backup set, Create backup set | Archive, Restore archived set, Force delete |
|
||||
| Backup set detail | Tenant operator | Detail | Is this backup set a strong or weak recovery input, and why? | Quality summary, degraded counts, next actions, related context | Raw payloads, raw assignment JSON, integrity detail | Input quality, assignment completeness, lifecycle status | TenantPilot only for existing maintenance actions | Inspect backup items, open related context from contextual links | Archive, Restore archived set, Force delete |
|
||||
| Backup items table | Tenant operator | Table inside detail | Which items are degraded inside this backup set? | Display name, type, snapshot mode, assignment issue signal, orphaned-assignment signal | Full metadata, raw assignments, low-level IDs | Snapshot completeness, assignment completeness | TenantPilot only for add and remove maintenance; none for visibility | Refresh, Add Policies, inspect row | Remove, Remove selected |
|
||||
| Policy versions page | Tenant operator | List | Which versions are full-payload versus metadata-only or otherwise degraded? | Policy identity, version number, capture time, snapshot mode, quality signal | Raw JSON, diff payload, redaction detail | Version lifecycle, input quality | TenantPilot only for existing archive and maintenance actions | Open version, open related policy, open backup sets from empty state | Restore via Wizard, Archive, Restore archived version, Force delete, bulk prune |
|
||||
| Policy version detail | Tenant operator | Detail | Is this version worth using as restore input? | Version identity, explicit backup-quality section, related context | Normalized settings, raw JSON, diff, redaction detail | Input quality, version lineage | None for visibility; existing restore entry remains separately gated | Open related policy | No new destructive detail action |
|
||||
| Restore run create wizard | Tenant operator with restore rights | Wizard | Which backup set or items should I avoid or inspect before running safety checks? | Backup-set quality summary, per-item quality descriptions, stronger or weaker input hints | Risk-check output, preview diff, unresolved mapping detail | Input quality first, restore safety later | Simulation only until later confirmation and execution steps | Select backup set, select items, continue through wizard | Final restore execution remains later in the flow |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: no
|
||||
- **New persisted entity/table/artifact?**: no
|
||||
- **New abstraction?**: yes
|
||||
- **New enum/state/reason family?**: no
|
||||
- **New cross-domain UI framework/taxonomy?**: no
|
||||
- **Current operator problem**: Operators can currently tell that a backup, item, or version exists, but they cannot quickly tell whether it is strong, degraded, or metadata-only as recovery input before they reach deep detail or restore-safety surfaces.
|
||||
- **Existing structure is insufficient because**: The relevant truth is split across backup metadata, assignment metadata, disabled restore actions, and later restore-safety checks. That fragmentation causes false confidence and late discovery.
|
||||
- **Narrowest correct implementation**: Introduce at most one narrow derived backup-quality helper that reads existing `BackupSet`, `BackupItem`, and `PolicyVersion` metadata and exposes a compact summary for existing list, detail, and wizard surfaces.
|
||||
- **Ownership cost**: A small amount of shared derivation logic plus unit, feature, and RBAC regression tests that keep quality labels aligned with the underlying metadata keys.
|
||||
- **Alternative intentionally rejected**: A persisted backup-health table, a tenant-wide scoring model, or a new recovery-confidence engine were rejected because they would create new truth, new state, and new ownership cost before the current surfaces tell the existing truth well.
|
||||
- **Release truth**: current-release truth hardening
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - Judge Backup Sets Early (Priority: P1)
|
||||
|
||||
A tenant operator opens the backup-set list or detail page and needs to tell within seconds whether a backup set is merely stored or also looks strong enough to inspect further as recovery input.
|
||||
|
||||
**Why this priority**: This is the earliest point where false confidence must be prevented. If the operator misreads `completed` as `good backup`, every later restore decision inherits that error.
|
||||
|
||||
**Independent Test**: Can be fully tested by loading backup-set list and detail pages with full-quality and degraded fixtures and verifying that lifecycle status and backup quality are shown separately.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a tenant has one full-quality backup set and one degraded backup set, **When** the operator opens the backup-set list, **Then** each row shows capture status separately from a compact backup-quality summary.
|
||||
2. **Given** a backup set contains degraded items, **When** the operator opens backup-set detail, **Then** the page shows a quality summary with degradation counts before per-item diagnostics or raw metadata.
|
||||
3. **Given** a completed backup set contains only metadata-only items, **When** the operator scans the list or detail surface, **Then** the surface does not imply that the set is safe to restore or broadly recoverable.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Inspect Item and Version Strength (Priority: P2)
|
||||
|
||||
A tenant operator reviewing backup items or policy versions needs to distinguish full payloads from metadata-only or assignment-degraded inputs without inferring that truth from disabled actions or hidden metadata.
|
||||
|
||||
**Why this priority**: Item-level and version-level truth determines whether a backup set is actually useful. If this information stays implicit, operators cannot compare restore inputs confidently.
|
||||
|
||||
**Independent Test**: Can be fully tested by loading the backup-items table, policy-version list, and policy-version detail page with mixed-quality records and verifying explicit per-record quality signals.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** backup items include full payload, metadata-only, assignment-fetch-failed, and orphaned-assignment examples, **When** the operator reviews the backup-items table, **Then** each item shows explicit snapshot mode and assignment-quality signals.
|
||||
2. **Given** policy versions include both full payload and metadata-only snapshots, **When** the operator reviews the policy-version list, **Then** snapshot mode is visible without needing to hover disabled actions.
|
||||
3. **Given** a policy-version detail page represents a degraded version, **When** the operator opens the page, **Then** the page shows an explicit backup-quality section that explains the weakness without using restore availability as the only signal.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Select Restore Inputs With Early Warning (Priority: P3)
|
||||
|
||||
A tenant operator starting a restore run needs to see weak backup sets and weak items before risk checks or preview steps so that poor input quality is visible at the first selection point.
|
||||
|
||||
**Why this priority**: Restore-safety hardening already exists later in the flow. This story closes the trust gap before the operator commits to a candidate backup set or item selection.
|
||||
|
||||
**Independent Test**: Can be fully tested by opening the restore-run creation wizard with degraded backup-set and backup-item fixtures and verifying that selection step labels or descriptions expose quality truth before safety checks run.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a degraded backup set is available for restore, **When** the operator opens restore wizard step 1, **Then** the backup-set selection surface shows that the set contains degraded input before the operator reaches safety checks.
|
||||
2. **Given** selected restore items include metadata-only and assignment-degraded inputs, **When** the operator reviews restore wizard step 2, **Then** each affected item is clearly marked as degraded before any risk-check action occurs.
|
||||
3. **Given** a backup set is full-quality, **When** the operator reviews steps 1 and 2, **Then** the wizard can communicate that no degradations are currently detected without claiming that restore is safe.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Preserve Truth Under RBAC Boundaries (Priority: P4)
|
||||
|
||||
A tenant member with backup or version viewing rights but without restore or maintenance rights still needs to see the same backup-quality truth so that authorization boundaries do not make weak inputs look calmer than they are.
|
||||
|
||||
**Why this priority**: Security boundaries must not distort source-of-truth visibility. Otherwise the UI becomes less truthful for read-only operators than for managers.
|
||||
|
||||
**Independent Test**: Can be fully tested by signing in as a tenant member with `TENANT_VIEW` but without restore capabilities and verifying that list and detail surfaces still expose quality truth while restore actions remain unavailable.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a tenant member has backup and version viewing rights but lacks restore permission, **When** they open backup-set or policy-version surfaces, **Then** backup-quality signals remain visible while restore actions stay unavailable.
|
||||
2. **Given** a non-member requests the same tenant-scoped surfaces, **When** the request is made, **Then** the system responds with deny-as-not-found semantics instead of exposing resource existence.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- A backup set is `completed` and has zero degradations; the surface must explicitly show that no degradations are detected rather than leaving quality unstated.
|
||||
- A backup set mixes full payload items with metadata-only and assignment-degraded items; the summary must show mixed quality without collapsing to a single misleading label.
|
||||
- Assignment capture is marked not applicable for a policy type; the surface must not mislabel that condition as a failure.
|
||||
- Older items or versions lack enough metadata to derive quality; the surface may show `unknown` only when no existing authoritative signal is available.
|
||||
- Archived backup sets and archived policy versions must retain the same quality truth on list and detail surfaces as active records.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
This feature introduces no new Microsoft Graph calls, no new background work, no new `OperationRun`, and no new persistence. It is a read-first truth-hardening feature that makes existing backup and version metadata visible earlier and more clearly.
|
||||
|
||||
Authorization remains in the tenant/admin plane under `/admin/t/{tenant}/...`. Non-members must continue to receive 404 responses. Established members missing mutation capabilities must continue to receive 403 on execution. Members with `TENANT_VIEW` must still see backup-quality truth on backup and version surfaces even when restore entry points remain unavailable.
|
||||
|
||||
Badge and UI semantics must stay centralized. Existing shared badge semantics, especially snapshot-mode badges, remain the canonical language for status-like signals. Any new quality labels or summaries must be derived from shared backup-quality rules rather than page-local color or wording decisions.
|
||||
|
||||
The affected Filament surfaces must keep exactly one primary inspect or open model, must not add redundant View actions, and must preserve destructive-action placement and confirmation behavior already defined by the action-surface contract. Quality truth is additive to existing surfaces, not a new local action framework.
|
||||
|
||||
If a shared backup-quality helper is introduced, it must replace duplicated page-local derivation instead of layering a second semantic system on top of existing restore-safety logic. Restore safety, preview eligibility, and execution outcome remain separate truths.
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-176-001**: The system MUST present backup existence truth separately from backup quality truth so that `completed`, `partial`, and `failed` remain capture-lifecycle states rather than quality claims.
|
||||
- **FR-176-002**: The backup-set list MUST show a compact backup-quality summary per row that indicates either no detected degradations or the presence of one or more degradation families.
|
||||
- **FR-176-003**: The backup-set detail surface MUST show a default-visible quality summary before deep diagnostics, including counts for metadata-only items, assignment-capture issues, orphaned-assignment signals, and any other degradation families that are already authoritatively derivable.
|
||||
- **FR-176-004**: The backup-items table MUST show per-item snapshot mode and per-item assignment-quality signals without requiring the operator to open raw JSON or later restore surfaces.
|
||||
- **FR-176-005**: The policy-version list MUST show snapshot mode for every visible version and MUST make degraded versions distinguishable from full-payload versions at scan speed.
|
||||
- **FR-176-006**: The policy-version detail page MUST show explicit backup-quality truth and MUST NOT rely on disabled restore actions or tooltips as the only signal that a version is weak.
|
||||
- **FR-176-007**: Restore wizard step 1 MUST expose backup-set quality before the operator reaches safety checks, preview generation, or execution confirmation.
|
||||
- **FR-176-008**: Restore wizard step 2 MUST expose item-level quality before safety checks, including metadata-only and assignment-quality degradations where the underlying data already exists.
|
||||
- **FR-176-009**: Metadata-only state MUST appear on backup and version surfaces as soon as the source metadata can establish it, and MUST NOT first surface as a restore-stage surprise.
|
||||
- **FR-176-010**: Assignment-capture failures and orphaned-assignment signals MUST be operator-visible on backup-quality surfaces whenever the metadata already records them.
|
||||
- **FR-176-011**: Backup-quality surfaces MUST NOT claim that a backup set, item, or version is safe to restore, restore-ready, or guaranteed to succeed.
|
||||
- **FR-176-012**: Backup-quality surfaces MUST NOT imply that a strong-looking backup set proves tenant-wide recoverability, a guaranteed rollback path, or a recovery certification outcome.
|
||||
- **FR-176-013**: Version history surfaces MUST separate three truths: version exists, version is selectable under current permissions and lifecycle state, and version has stronger or weaker payload quality.
|
||||
- **FR-176-014**: When a backup set, item, or version is weak, the surface MUST suggest meaningful next actions such as opening detail, inspecting degraded items, preferring a stronger version, or continuing into restore with caution.
|
||||
- **FR-176-015**: Quality signals MUST remain visible to users with backup or version viewing rights even when deeper restore or operations surfaces are inaccessible.
|
||||
- **FR-176-016**: The feature MUST derive backup-quality truth from existing tenant-owned records and metadata and MUST NOT require a new persistence model, new materialized state, or a new cross-tenant scoring engine.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Existing metadata keys such as `source`, `snapshot_source`, `assignments_fetch_failed`, `assignment_capture_reason`, `has_orphaned_assignments`, scope-tag metadata, and redaction or integrity notes are authoritative enough for first-pass backup-quality truth.
|
||||
- Existing restore-safety checks remain the sole owner of blocker, warning, preview-only, and execution-gating language.
|
||||
- Older records may lack some quality metadata; in those cases the product may show `unknown quality` only when the existing record truly does not contain enough information to derive a stronger statement.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Existing tenant-scoped backup, version, and restore resources remain the operator entry points.
|
||||
- Existing centralized badge semantics, especially snapshot-mode badges, remain the canonical language for visible status.
|
||||
- Existing restore-safety integrity behavior and metadata-only execution blocking remain unchanged and continue to run after the earlier backup-quality surfaces.
|
||||
|
||||
## Out of Scope and Follow-up
|
||||
|
||||
- No redesign of restore execution, restore-safety logic, backup capture, retention or pruning, tenant-wide recovery scoring, notification domains, or new persisted backup-health artifacts.
|
||||
- Reasonable follow-up work includes a backup-health dashboard, a broader recovery-confidence rollup, and version-rollback usefulness guidance after the current truth-hardening slice is complete.
|
||||
|
||||
## UI Action Matrix *(mandatory when Filament is changed)*
|
||||
|
||||
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| BackupSetResource | `app/Filament/Resources/BackupSetResource.php` | Create backup set | `recordUrl()` clickable row | Primary related action, More: Restore / Archive / Force delete | More: Archive Backup Sets / Restore Backup Sets / Force Delete Backup Sets | Create backup set | Grouped existing mutations remain; related navigation stays in contextual summary links, not the header | Create backup set submit plus cancel | Existing audit logging remains for restore, archive, and force delete; read-only quality truth adds no new audit event | Action surface contract stays satisfied. Quality summary is additive only. |
|
||||
| BackupItemsRelationManager | `app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php` | Refresh, Add Policies | Clickable row | More: Remove | More: Remove selected | Add Policies | n/a | n/a | Existing operation-run and audit behavior for remove flows remains; visibility changes are read-only | Existing relation-manager exception remains; no redundant View action is added. |
|
||||
| PolicyVersionResource | `app/Filament/Resources/PolicyVersionResource.php` | none | `recordUrl()` clickable row | Primary related action, More: Restore via Wizard / Archive / Force delete / Restore archived version | More: Prune Versions / Restore Versions / Force Delete Versions | Open backup sets | Existing detail header remains intentionally minimal | n/a | Existing audit logging remains for archive, force delete, and restore; restore-via-wizard keeps existing restore-run and backup creation behavior | Policy-version detail gains explicit quality truth so disabled actions stop being the only signal. |
|
||||
| Restore run create wizard | `app/Filament/Resources/RestoreRunResource.php`, `app/Filament/Resources/RestoreRunResource/Pages/CreateRestoreRun.php` | none | n/a | n/a | n/a | none | n/a | Wizard Previous / Next / Create restore run | Existing restore-run create and execute audit behavior remains unchanged; selection-stage quality visibility is read-only | Step 1 and step 2 gain quality descriptions only. No new destructive action is introduced. |
|
||||
|
||||
## Key Entities *(include if feature involves data)*
|
||||
|
||||
- **BackupSet**: A tenant-owned capture collection that already records lifecycle state, timestamps, item count, and metadata describing how the set was produced.
|
||||
- **BackupItem**: A tenant-owned captured recovery input for one policy or foundation item, including payload, assignments, and metadata that can expose snapshot completeness and assignment-quality issues.
|
||||
- **PolicyVersion**: An immutable tenant-owned version record that stores captured snapshot data, related metadata, assignments, redaction context, and capture timing.
|
||||
- **Restore selection context**: The tenant-scoped backup-set and optional item selection that an operator builds before restore-safety checks and preview generation.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: In validation sessions and acceptance tests, an operator can identify whether a backup set is full-quality or degraded from the list or detail surface in under 10 seconds without opening raw JSON or preview surfaces.
|
||||
- **SC-002**: In 100% of tested cases where existing records contain metadata-only, assignment-fetch-failed, or orphaned-assignment signals, at least one default-visible backup-quality signal appears on every affected list, detail, or wizard selection surface.
|
||||
- **SC-003**: In 100% of RBAC test cases, users with backup or version viewing rights but without restore rights can still see backup-quality truth on list and detail surfaces while restore actions remain unavailable.
|
||||
- **SC-004**: In 100% of degraded restore-input scenarios covered by acceptance tests, backup-set and item quality is visible before the operator reaches restore-safety checks or preview generation.
|
||||
@ -1,249 +0,0 @@
|
||||
# Tasks: Backup Quality Truth Surfaces
|
||||
|
||||
**Input**: Design documents from `/specs/176-backup-quality-truth/`
|
||||
**Prerequisites**: `plan.md` (required), `spec.md` (required for user stories), `research.md`, `data-model.md`, `contracts/`, `quickstart.md`
|
||||
|
||||
**Tests**: Tests are REQUIRED for this feature. Use focused Pest coverage in existing backup, version, restore-selection, and RBAC suites, plus new backup-quality tests under `tests/Feature/Filament/`, `tests/Feature/Rbac/`, and `tests/Unit/Support/BackupQuality/`.
|
||||
**Operations**: This feature introduces no new `OperationRun`, no queued or scheduled work, and no new audit event family. Work is limited to read-first quality truth on existing backup, version, and restore-selection surfaces.
|
||||
**RBAC**: Existing tenant membership, capability-registry usage, and `404` vs `403` behavior must remain unchanged across `/admin/t/{tenant}/backup-sets/...`, `/admin/t/{tenant}/policy-versions/...`, and `/admin/t/{tenant}/restore-runs/create`. Users with `TENANT_VIEW` must see backup-quality truth on read surfaces even when restore actions remain unavailable.
|
||||
**Operator Surfaces**: Backup-set list and detail, backup-items relation rows, policy-version list and detail, and restore wizard step 1 and step 2 must show backup-quality truth before diagnostics or later restore-safety conclusions. Quality copy must remain distinct from lifecycle, restore readiness, and tenant recoverability claims.
|
||||
**Filament UI Action Surfaces**: No new primary inspect model, redundant View action, or destructive-action placement is introduced. Existing archive, restore, force-delete, remove, and bulk actions remain confirmation-gated and server-authorized.
|
||||
**Filament UI UX-001**: This feature keeps the existing Filament list, relation-manager, infolist, enterprise-detail, and wizard layouts. New quality sections must be summary-first and diagnostics-second.
|
||||
**Badges**: Snapshot completeness must continue to use centralized badge semantics through `app/Support/Badges/Domains/PolicySnapshotModeBadge.php`. Any additional quality wording must come from the shared backup-quality layer rather than page-local mappings.
|
||||
|
||||
**Organization**: Tasks are grouped by user story so each story can be implemented and validated as an independent increment after the shared backup-quality scaffolding is in place.
|
||||
|
||||
## Phase 1: Setup (Shared Backup-Quality Scaffolding)
|
||||
|
||||
**Purpose**: Add the narrow derived backup-quality layer and base test scaffolding used by every story.
|
||||
|
||||
- [X] T001 Create the shared backup-quality resolver and summary types in `app/Support/BackupQuality/BackupQualityResolver.php` and `app/Support/BackupQuality/BackupQualitySummary.php`
|
||||
- [X] T002 [P] Add unit test scaffolding for resolver rules and aggregate summaries in `tests/Unit/Support/BackupQuality/BackupQualityResolverTest.php` and `tests/Unit/Support/BackupQuality/BackupSetQualitySummaryTest.php`
|
||||
- [X] T003 Add metadata convenience helpers for item evidence in `app/Models/BackupItem.php` and mirror them in `app/Models/PolicyVersion.php` only if resolver wiring still leaves justified duplication there
|
||||
- [X] T004 [P] Extend metadata semantics regression coverage in `tests/Unit/BackupItemTest.php` and `tests/Unit/AssignmentBackupServiceTest.php`
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational (Blocking Shared Wiring)
|
||||
|
||||
**Purpose**: Wire the shared backup-quality contract into the existing Filament seams before any story-specific surface work begins.
|
||||
|
||||
**⚠️ CRITICAL**: No user story work should begin until this phase is complete.
|
||||
|
||||
- [X] T005 Thread shared backup-quality loading and aggregation hooks through `app/Filament/Resources/BackupSetResource.php`, `app/Filament/Resources/PolicyVersionResource.php`, and `app/Filament/Resources/RestoreRunResource.php`
|
||||
- [X] T006 [P] Reuse centralized snapshot-mode and summary copy seams in `app/Support/Badges/Domains/PolicySnapshotModeBadge.php` and `app/Support/BackupQuality/BackupQualitySummary.php`
|
||||
- [X] T007 [P] Add shared mixed-signal, integrity-warning, and unknown-quality regression coverage in `tests/Unit/Support/BackupQuality/BackupQualityResolverTest.php` and `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`
|
||||
|
||||
**Checkpoint**: Backup, version, and restore-selection resources can now consume one shared backup-quality contract.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 - Judge Backup Sets Early (Priority: P1) 🎯 MVP
|
||||
|
||||
**Goal**: Let operators distinguish stored backup sets from degraded recovery input within one scan of the list or detail surface.
|
||||
|
||||
**Independent Test**: Load backup-set list and detail pages with full-quality, mixed-quality, and metadata-only fixtures and verify lifecycle truth stays separate from a default-visible quality summary.
|
||||
|
||||
### Tests for User Story 1
|
||||
|
||||
- [X] T008 [P] [US1] Add backup-set list truth coverage for full, mixed, metadata-only, and archived sets in `tests/Feature/Filament/BackupQualityTruthSurfaceTest.php`
|
||||
- [X] T009 [P] [US1] Extend summary-first backup-set detail assertions to cover archived parity and integrity-warning counts in `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [X] T010 [US1] Add compact backup-quality summary columns and row copy to `app/Filament/Resources/BackupSetResource.php`
|
||||
- [X] T011 [US1] Add a default-visible quality summary section with integrity-warning counts, next-action guidance, and contextual related links that stay out of the header in `app/Filament/Resources/BackupSetResource.php`
|
||||
- [X] T012 [US1] Ensure backup-set quality summaries use aggregated item facts without new N+1 queries in `app/Support/BackupQuality/BackupQualityResolver.php` and `app/Filament/Resources/BackupSetResource.php`
|
||||
- [X] T013 [US1] Run the focused backup-set truth pack in `tests/Feature/Filament/BackupQualityTruthSurfaceTest.php` and `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`
|
||||
|
||||
**Checkpoint**: Backup-set list and detail now expose input quality early without implying restore safety.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 - Inspect Item and Version Strength (Priority: P2)
|
||||
|
||||
**Goal**: Make item-level and version-level payload quality explicit instead of forcing operators to infer it from disabled actions or hidden metadata.
|
||||
|
||||
**Independent Test**: Load backup-items and policy-versions surfaces with full, metadata-only, assignment-fetch-failed, orphaned-assignment, and not-applicable fixtures and verify each surface renders explicit quality truth at scan speed.
|
||||
|
||||
### Tests for User Story 2
|
||||
|
||||
- [X] T014 [P] [US2] Extend backup-item relation truth coverage for snapshot mode, assignment failures, orphaned assignments, non-failure capture reasons, and inspect-next-step cues in `tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php`
|
||||
- [X] T015 [P] [US2] Add policy-version quality list and detail coverage for full, degraded, integrity-warning, and archived versions in `tests/Feature/Filament/PolicyVersionQualityTruthSurfaceTest.php` and `tests/Feature/Filament/PolicyVersionTest.php`
|
||||
- [X] T016 [P] [US2] Add regression coverage that quality truth remains visible independently from restore action gating in `tests/Feature/Filament/PolicyVersionRestoreViaWizardTest.php` and `tests/Unit/Support/BackupQuality/BackupQualityResolverTest.php`
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [X] T017 [US2] Add per-item snapshot mode, assignment-quality signals, and inspect-detail next-step cues to `app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php`
|
||||
- [X] T018 [US2] Add scan-speed snapshot mode, integrity-warning visibility, stronger-version or open-detail cues, and a single empty-state CTA to the table schema in `app/Filament/Resources/PolicyVersionResource.php`
|
||||
- [X] T019 [US2] Add an explicit backup-quality infolist section with integrity-warning truth and non-overclaiming guidance in `app/Filament/Resources/PolicyVersionResource.php`
|
||||
- [X] T020 [US2] Remove page-local quality derivation from item and version surfaces by routing them through `app/Support/BackupQuality/BackupQualityResolver.php`, `app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php`, and `app/Filament/Resources/PolicyVersionResource.php`
|
||||
- [X] T021 [US2] Run the focused item and version truth pack in `tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php`, `tests/Feature/Filament/PolicyVersionQualityTruthSurfaceTest.php`, `tests/Feature/Filament/PolicyVersionTest.php`, and `tests/Feature/Filament/PolicyVersionRestoreViaWizardTest.php`
|
||||
|
||||
**Checkpoint**: Backup items and policy versions now expose quality truth directly where operators inspect them.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 - Select Restore Inputs With Early Warning (Priority: P3)
|
||||
|
||||
**Goal**: Show weak backup sets and items at the first restore-selection step, before later restore-safety checks or preview work begins.
|
||||
|
||||
**Independent Test**: Open the restore wizard with degraded backup-set and backup-item fixtures and verify step 1 and step 2 expose input quality before any risk-check output is shown.
|
||||
|
||||
### Tests for User Story 3
|
||||
|
||||
- [X] T022 [P] [US3] Add step-1 degraded backup-set hint coverage in `tests/Feature/Filament/RestoreSelectionQualityTruthTest.php`
|
||||
- [X] T023 [P] [US3] Extend pre-risk-check item-quality assertions in `tests/Feature/Filament/RestoreItemSelectionTest.php` and `tests/Feature/RestoreRiskChecksWizardTest.php`
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [X] T024 [US3] Add backup-set quality summaries to step-1 option labels and helper text in `app/Filament/Resources/RestoreRunResource.php`
|
||||
- [X] T025 [US3] Add item-level snapshot mode and assignment-quality descriptions to restore item option data in `app/Filament/Resources/RestoreRunResource.php`
|
||||
- [X] T026 [US3] Preserve the backup-quality versus restore-safety claim boundary in `app/Filament/Resources/RestoreRunResource.php` and `app/Filament/Resources/RestoreRunResource/Pages/CreateRestoreRun.php`
|
||||
- [X] T027 [US3] Run the focused restore-selection truth pack in `tests/Feature/Filament/RestoreSelectionQualityTruthTest.php`, `tests/Feature/Filament/RestoreItemSelectionTest.php`, and `tests/Feature/RestoreRiskChecksWizardTest.php`
|
||||
|
||||
**Checkpoint**: Restore selection now exposes degraded input before later restore-safety logic runs.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: User Story 4 - Preserve Truth Under RBAC Boundaries (Priority: P4)
|
||||
|
||||
**Goal**: Keep backup-quality truth visible to read-only tenant viewers while preserving existing restore and mutation restrictions plus deny-as-not-found behavior.
|
||||
|
||||
**Independent Test**: Sign in as a tenant member with `TENANT_VIEW` but without restore capability and verify backup-set and policy-version surfaces still show quality truth, while non-members still receive `404` and in-scope users without mutation capability still receive `403` on execution.
|
||||
|
||||
### Tests for User Story 4
|
||||
|
||||
- [X] T028 [P] [US4] Add tenant-view visibility coverage for backup-set, backup-item relation rows, and policy-version quality truth in `tests/Feature/Rbac/BackupQualityVisibilityTest.php`
|
||||
- [X] T029 [P] [US4] Extend deny-as-not-found and missing-capability regressions for backup and restore entry points in `tests/Feature/Filament/BackupSetUiEnforcementTest.php`, `tests/Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php`, `tests/Feature/Rbac/CreateRestoreRunAuthorizationTest.php`, and `tests/Feature/Rbac/PolicyVersionsRestoreToIntuneUiEnforcementTest.php`
|
||||
|
||||
### Implementation for User Story 4
|
||||
|
||||
- [X] T030 [US4] Adjust quality-section visibility so read surfaces and backup-item relation rows remain available to `TENANT_VIEW` users in `app/Filament/Resources/BackupSetResource.php`, `app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php`, and `app/Filament/Resources/PolicyVersionResource.php`
|
||||
- [X] T031 [US4] Preserve `404` vs `403` semantics around restore-linked quality hints in `app/Filament/Resources/RestoreRunResource.php` and `app/Filament/Resources/RestoreRunResource/Pages/CreateRestoreRun.php`
|
||||
- [X] T032 [US4] Run the focused RBAC truth pack in `tests/Feature/Rbac/BackupQualityVisibilityTest.php`, `tests/Feature/Filament/BackupSetUiEnforcementTest.php`, `tests/Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php`, `tests/Feature/Rbac/CreateRestoreRunAuthorizationTest.php`, and `tests/Feature/Rbac/PolicyVersionsRestoreToIntuneUiEnforcementTest.php`
|
||||
|
||||
**Checkpoint**: Quality truth remains visible under read-only permissions without weakening authorization boundaries.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Final consistency, cleanup, formatting, and focused verification across all stories.
|
||||
|
||||
- [X] T033 [P] Review and align operator-facing backup-quality copy and next-action wording in `app/Support/BackupQuality/BackupQualitySummary.php`, `app/Filament/Resources/BackupSetResource.php`, `app/Filament/Resources/PolicyVersionResource.php`, and `app/Filament/Resources/RestoreRunResource.php`
|
||||
- [X] T034 Remove dead fallback derivation and duplicate helper logic left after story implementation in `app/Support/BackupQuality/BackupQualityResolver.php`, `app/Filament/Resources/BackupSetResource.php`, `app/Filament/Resources/PolicyVersionResource.php`, and `app/Filament/Resources/RestoreRunResource.php`
|
||||
- [X] T035 Run formatting with `vendor/bin/sail bin pint --dirty --format agent` for `app/Support/BackupQuality/BackupQualityResolver.php`, `app/Filament/Resources/BackupSetResource.php`, `app/Filament/Resources/PolicyVersionResource.php`, `app/Filament/Resources/RestoreRunResource.php`, and `tests/Feature/Filament/BackupQualityTruthSurfaceTest.php`
|
||||
- [X] T036 Run the focused verification pack from `specs/176-backup-quality-truth/quickstart.md` against `tests/Feature/Filament/BackupQualityTruthSurfaceTest.php`, `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`, `tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php`, `tests/Feature/Filament/BackupSetUiEnforcementTest.php`, `tests/Feature/Filament/PolicyVersionQualityTruthSurfaceTest.php`, `tests/Feature/Filament/PolicyVersionTest.php`, `tests/Feature/Filament/PolicyVersionRestoreViaWizardTest.php`, `tests/Feature/Filament/RestoreSelectionQualityTruthTest.php`, `tests/Feature/Filament/RestoreItemSelectionTest.php`, `tests/Feature/RestoreRiskChecksWizardTest.php`, `tests/Feature/Rbac/BackupQualityVisibilityTest.php`, `tests/Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php`, `tests/Feature/Rbac/CreateRestoreRunAuthorizationTest.php`, `tests/Feature/Rbac/PolicyVersionsRestoreToIntuneUiEnforcementTest.php`, `tests/Unit/Support/BackupQuality/BackupQualityResolverTest.php`, `tests/Unit/Support/BackupQuality/BackupSetQualitySummaryTest.php`, `tests/Unit/AssignmentBackupServiceTest.php`, and `tests/Unit/BackupItemTest.php`
|
||||
- [ ] T037 Run the manual validation pass in `specs/176-backup-quality-truth/quickstart.md` for backup-set, policy-version, restore-selection, and RBAC truth surfaces
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: Starts immediately and establishes the shared backup-quality namespace and test scaffolding.
|
||||
- **Foundational (Phase 2)**: Depends on Setup and blocks all story work until existing Filament resources consume the shared resolver and summary contract.
|
||||
- **User Story 1 (Phase 3)**: Starts after Foundational and delivers the MVP truth surface on backup-set list and detail pages.
|
||||
- **User Story 2 (Phase 4)**: Starts after Foundational and can proceed alongside User Story 1 once the shared resolver contract is stable.
|
||||
- **User Story 3 (Phase 5)**: Starts after User Story 1 and User Story 2 because restore selection reuses both aggregate backup-set truth and item-level quality facts.
|
||||
- **User Story 4 (Phase 6)**: Starts after User Story 1 and User Story 2 and should finish after User Story 3 if restore-selection RBAC visibility is included in the same pass.
|
||||
- **Polish (Phase 7)**: Starts after the desired user stories are complete.
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **US1**: Depends only on Setup and Foundational work.
|
||||
- **US2**: Depends only on Setup and Foundational work and shares the same resolver contract as US1.
|
||||
- **US3**: Depends on US1 and US2 because step 1 and step 2 reuse the backup-set and item-level quality models introduced there.
|
||||
- **US4**: Depends on US1 and US2 for truth surfaces and should include US3 when restore-wizard visibility checks are part of the same test pass.
|
||||
|
||||
### Within Each User Story
|
||||
|
||||
- Tests should be added or updated before the corresponding behavior change is considered complete.
|
||||
- Shared resolver and resource wiring should land before story-specific copy cleanup for the same surface.
|
||||
- Story-level focused test runs should pass before moving to the next priority slice.
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
- `T002` and `T004` can run in parallel once `T001` and `T003` establish the helper signatures and metadata rules.
|
||||
- `T006` and `T007` can run in parallel after `T005` lands the shared wiring points.
|
||||
- `T008` and `T009` can run in parallel for US1.
|
||||
- `T014`, `T015`, and `T016` can run in parallel for US2.
|
||||
- `T022` and `T023` can run in parallel for US3.
|
||||
- `T028` and `T029` can run in parallel for US4.
|
||||
- `T033` and story-specific cleanup reviews can run in parallel once feature behavior is stable.
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: User Story 1
|
||||
|
||||
```bash
|
||||
# Story 1 tests in parallel:
|
||||
Task: T008 tests/Feature/Filament/BackupQualityTruthSurfaceTest.php
|
||||
Task: T009 tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php
|
||||
|
||||
# Story 1 implementation after assertions are set:
|
||||
Task: T010 app/Filament/Resources/BackupSetResource.php
|
||||
Task: T012 app/Support/BackupQuality/BackupQualityResolver.php
|
||||
```
|
||||
|
||||
## Parallel Example: User Story 2
|
||||
|
||||
```bash
|
||||
# Story 2 tests in parallel:
|
||||
Task: T014 tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php
|
||||
Task: T015 tests/Feature/Filament/PolicyVersionQualityTruthSurfaceTest.php
|
||||
Task: T016 tests/Feature/Filament/PolicyVersionRestoreViaWizardTest.php
|
||||
|
||||
# Story 2 implementation split after the resolver contract is fixed:
|
||||
Task: T017 app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php
|
||||
Task: T018 app/Filament/Resources/PolicyVersionResource.php
|
||||
```
|
||||
|
||||
## Parallel Example: User Story 3
|
||||
|
||||
```bash
|
||||
# Story 3 tests in parallel:
|
||||
Task: T022 tests/Feature/Filament/RestoreSelectionQualityTruthTest.php
|
||||
Task: T023 tests/Feature/Filament/RestoreItemSelectionTest.php
|
||||
|
||||
# Story 3 implementation split after the selection copy is agreed:
|
||||
Task: T024 app/Filament/Resources/RestoreRunResource.php
|
||||
Task: T025 app/Filament/Resources/RestoreRunResource.php
|
||||
```
|
||||
|
||||
## Parallel Example: User Story 4
|
||||
|
||||
```bash
|
||||
# Story 4 tests in parallel:
|
||||
Task: T028 tests/Feature/Rbac/BackupQualityVisibilityTest.php
|
||||
Task: T029 tests/Feature/Rbac/CreateRestoreRunAuthorizationTest.php
|
||||
|
||||
# Story 4 implementation split after RBAC expectations are locked:
|
||||
Task: T030 app/Filament/Resources/BackupSetResource.php
|
||||
Task: T031 app/Filament/Resources/RestoreRunResource/Pages/CreateRestoreRun.php
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First
|
||||
|
||||
- Complete Phase 1 and Phase 2.
|
||||
- Deliver User Story 1 as the first usable increment so operators can judge backup-set quality early.
|
||||
- Validate that lifecycle truth and backup-quality truth are clearly separated on backup-set list and detail surfaces.
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
- Add User Story 2 next so item and version strength become explicit everywhere operators inspect backup inputs.
|
||||
- Add User Story 3 after that so restore selection inherits the same quality truth before risk checks.
|
||||
- Add User Story 4 last to verify RBAC-safe truth visibility across read and restore-linked surfaces.
|
||||
|
||||
### Verification Finish
|
||||
|
||||
- Run Pint on touched files.
|
||||
- Run the focused verification pack from `quickstart.md`.
|
||||
- Run the manual quickstart validation pass for backup-set, policy-version, restore-selection, and RBAC outcomes.
|
||||
- Offer the broader test suite only after the focused pack passes.
|
||||
@ -1,36 +0,0 @@
|
||||
# Specification Quality Checklist: Tenant Backup Health Signals
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-04-07
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- Validated on 2026-04-07 against the completed Spec 180 draft.
|
||||
- No clarification markers remain.
|
||||
- The spec stays bounded to tenant backup-health truth on dashboard and follow-up surfaces and does not expand into recovery-confidence or new persistence.
|
||||
@ -1,420 +0,0 @@
|
||||
openapi: 3.1.0
|
||||
info:
|
||||
title: Tenant Backup Health Surface Contracts
|
||||
version: 1.0.0
|
||||
description: >-
|
||||
Internal reference contract for tenant backup-health surfaces. The application
|
||||
continues to render HTML through Filament and Livewire. The vendor media types
|
||||
below document the structured dashboard, backup-set, and backup-schedule models
|
||||
that must be derivable before rendering. This is not a public API commitment.
|
||||
paths:
|
||||
/admin/t/{tenant}:
|
||||
get:
|
||||
summary: Tenant dashboard backup-health surface
|
||||
description: >-
|
||||
Returns the rendered tenant dashboard. The vendor media type documents the
|
||||
backup-health summary, backup-health attention item, and healthy-check model
|
||||
that the dashboard must expose.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered tenant dashboard
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.tenant-backup-health-dashboard+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/TenantBackupHealthDashboardSurface'
|
||||
'404':
|
||||
description: Tenant scope is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/backup-sets:
|
||||
get:
|
||||
summary: Backup-set list confirmation surface
|
||||
description: >-
|
||||
Returns the rendered backup-set list page. The vendor media type documents
|
||||
how the latest relevant backup basis and no-backup posture are confirmed.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered backup-set list page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.backup-health-backup-set-collection+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BackupSetCollectionSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks backup viewing capability
|
||||
'404':
|
||||
description: Tenant scope is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/backup-sets/{backupSet}:
|
||||
get:
|
||||
summary: Backup-set detail confirmation surface
|
||||
description: >-
|
||||
Returns the rendered backup-set detail page. The vendor media type documents
|
||||
the recency and quality facts that must confirm stale or degraded latest-backup posture.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: backupSet
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered backup-set detail page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.backup-health-backup-set-detail+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BackupSetDetailSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks backup viewing capability for the linked backup-set detail surface
|
||||
'404':
|
||||
description: Backup set is not visible because workspace or tenant membership is missing
|
||||
/admin/t/{tenant}/backup-schedules:
|
||||
get:
|
||||
summary: Backup-schedule follow-up confirmation surface
|
||||
description: >-
|
||||
Returns the rendered backup-schedule list page. The vendor media type documents
|
||||
the schedule-follow-up facts that must confirm overdue or missed schedule execution.
|
||||
parameters:
|
||||
- name: tenant
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered backup-schedule list page
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.backup-health-schedule-collection+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BackupScheduleCollectionSurface'
|
||||
'403':
|
||||
description: Viewer is in scope but lacks schedule viewing capability
|
||||
'404':
|
||||
description: Tenant scope is not visible because workspace or tenant membership is missing
|
||||
components:
|
||||
schemas:
|
||||
TenantBackupHealthDashboardSurface:
|
||||
type: object
|
||||
required:
|
||||
- summary
|
||||
properties:
|
||||
summary:
|
||||
$ref: '#/components/schemas/BackupHealthSummary'
|
||||
attentionItem:
|
||||
description: Present when a backup-health caution remains. `healthyCheck` must be null in that case.
|
||||
oneOf:
|
||||
- $ref: '#/components/schemas/BackupHealthAttentionItem'
|
||||
- type: 'null'
|
||||
healthyCheck:
|
||||
description: Present only when no backup-health attention item remains unresolved, including `schedule_follow_up`.
|
||||
oneOf:
|
||||
- $ref: '#/components/schemas/HealthyCheck'
|
||||
- type: 'null'
|
||||
BackupHealthSummary:
|
||||
type: object
|
||||
required:
|
||||
- posture
|
||||
- primaryReason
|
||||
- headline
|
||||
- tone
|
||||
- healthyClaimAllowed
|
||||
properties:
|
||||
posture:
|
||||
type: string
|
||||
enum: [absent, stale, degraded, healthy]
|
||||
description: Describes the state of the latest relevant backup basis itself.
|
||||
primaryReason:
|
||||
description: The active follow-up reason. This may be `schedule_follow_up` even when `posture` remains `healthy`.
|
||||
oneOf:
|
||||
- type: string
|
||||
enum: [no_backup_basis, latest_backup_stale, latest_backup_degraded, schedule_follow_up]
|
||||
- type: 'null'
|
||||
headline:
|
||||
type: string
|
||||
supportingMessage:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
tone:
|
||||
type: string
|
||||
enum: [danger, warning, success, gray]
|
||||
latestRelevantBackupSetId:
|
||||
type:
|
||||
- integer
|
||||
- 'null'
|
||||
latestRelevantCompletedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
freshness:
|
||||
$ref: '#/components/schemas/FreshnessEvaluation'
|
||||
scheduleFollowUp:
|
||||
$ref: '#/components/schemas/ScheduleFollowUpEvaluation'
|
||||
healthyClaimAllowed:
|
||||
type: boolean
|
||||
description: True only when the backup basis is healthy and no unresolved `schedule_follow_up` or stronger caution remains.
|
||||
actionTarget:
|
||||
oneOf:
|
||||
- $ref: '#/components/schemas/ActionTarget'
|
||||
- type: 'null'
|
||||
actionDisabled:
|
||||
type: boolean
|
||||
helperText:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
positiveClaimBoundary:
|
||||
type: string
|
||||
BackupHealthAttentionItem:
|
||||
type: object
|
||||
required:
|
||||
- title
|
||||
- body
|
||||
- badge
|
||||
- badgeColor
|
||||
properties:
|
||||
title:
|
||||
type: string
|
||||
body:
|
||||
type: string
|
||||
badge:
|
||||
type: string
|
||||
badgeColor:
|
||||
type: string
|
||||
actionTarget:
|
||||
oneOf:
|
||||
- $ref: '#/components/schemas/ActionTarget'
|
||||
- type: 'null'
|
||||
actionDisabled:
|
||||
type: boolean
|
||||
helperText:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
HealthyCheck:
|
||||
type: object
|
||||
required:
|
||||
- title
|
||||
- body
|
||||
properties:
|
||||
title:
|
||||
type: string
|
||||
body:
|
||||
type: string
|
||||
actionTarget:
|
||||
oneOf:
|
||||
- $ref: '#/components/schemas/ActionTarget'
|
||||
- type: 'null'
|
||||
FreshnessEvaluation:
|
||||
type: object
|
||||
required:
|
||||
- isFresh
|
||||
- policySource
|
||||
properties:
|
||||
latestCompletedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
cutoffAt:
|
||||
type: string
|
||||
format: date-time
|
||||
isFresh:
|
||||
type: boolean
|
||||
policySource:
|
||||
type: string
|
||||
enum: [configured_window]
|
||||
ScheduleFollowUpEvaluation:
|
||||
type: object
|
||||
required:
|
||||
- hasEnabledSchedules
|
||||
- needsFollowUp
|
||||
properties:
|
||||
hasEnabledSchedules:
|
||||
type: boolean
|
||||
enabledScheduleCount:
|
||||
type: integer
|
||||
overdueScheduleCount:
|
||||
type: integer
|
||||
failedRecentRunCount:
|
||||
type: integer
|
||||
neverSuccessfulCount:
|
||||
type: integer
|
||||
needsFollowUp:
|
||||
type: boolean
|
||||
summaryMessage:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
ActionTarget:
|
||||
type: object
|
||||
required:
|
||||
- surface
|
||||
- label
|
||||
- reason
|
||||
properties:
|
||||
surface:
|
||||
type: string
|
||||
enum: [backup_sets_index, backup_set_view, backup_schedules_index]
|
||||
recordId:
|
||||
type:
|
||||
- integer
|
||||
- 'null'
|
||||
label:
|
||||
type: string
|
||||
reason:
|
||||
type: string
|
||||
BackupSetCollectionSurface:
|
||||
type: object
|
||||
required:
|
||||
- postureConfirmation
|
||||
- rows
|
||||
properties:
|
||||
latestRelevantBackupSetId:
|
||||
type:
|
||||
- integer
|
||||
- 'null'
|
||||
postureConfirmation:
|
||||
type: string
|
||||
description: Explicit confirmation of the current collection meaning, including `no usable completed backup basis exists` when the dashboard drillthrough is resolving a `no_backup_basis` state.
|
||||
rows:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/BackupSetRow'
|
||||
BackupSetRow:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- name
|
||||
- lifecycleStatus
|
||||
- completedAt
|
||||
- qualitySummary
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
name:
|
||||
type: string
|
||||
lifecycleStatus:
|
||||
type: string
|
||||
completedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
isLatestRelevant:
|
||||
type: boolean
|
||||
qualitySummary:
|
||||
type: string
|
||||
BackupSetDetailSurface:
|
||||
type: object
|
||||
required:
|
||||
- header
|
||||
- freshness
|
||||
- qualitySummary
|
||||
- postureConfirmation
|
||||
properties:
|
||||
header:
|
||||
$ref: '#/components/schemas/BackupSetHeader'
|
||||
freshness:
|
||||
$ref: '#/components/schemas/FreshnessEvaluation'
|
||||
qualitySummary:
|
||||
type: string
|
||||
postureConfirmation:
|
||||
type: string
|
||||
positiveClaimBoundary:
|
||||
type: string
|
||||
BackupSetHeader:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- name
|
||||
- lifecycleStatus
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
name:
|
||||
type: string
|
||||
lifecycleStatus:
|
||||
type: string
|
||||
completedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
BackupScheduleCollectionSurface:
|
||||
type: object
|
||||
required:
|
||||
- rows
|
||||
- followUpPresent
|
||||
properties:
|
||||
followUpPresent:
|
||||
type: boolean
|
||||
summaryMessage:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
rows:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/BackupScheduleRow'
|
||||
BackupScheduleRow:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
- name
|
||||
- isEnabled
|
||||
- followUpState
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
name:
|
||||
type: string
|
||||
isEnabled:
|
||||
type: boolean
|
||||
lastRunStatus:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
lastRunAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
nextRunAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
followUpState:
|
||||
type: string
|
||||
enum: [none, overdue, failed_recently, never_successful, disabled]
|
||||
followUpMessage:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
@ -1,202 +0,0 @@
|
||||
# Data Model: Tenant Backup Health Signals
|
||||
|
||||
## Overview
|
||||
|
||||
This feature does not add or change a top-level persisted domain entity. It introduces a narrow derived tenant backup-health model over existing tenant-owned backup and schedule records and integrates that derived truth into dashboard and drillthrough surfaces.
|
||||
|
||||
The central design task is to make the tenant dashboard answer four operator-visible states without changing:
|
||||
|
||||
- `BackupSet`, `BackupItem`, or `BackupSchedule` ownership
|
||||
- existing backup-quality source-of-truth rules
|
||||
- existing backup or schedule route identity
|
||||
- existing mutation, audit, or `OperationRun` responsibilities
|
||||
- the no-new-table and no-recovery-score boundary of the feature
|
||||
|
||||
## Existing Persistent Entities
|
||||
|
||||
### 1. BackupSet
|
||||
|
||||
- Purpose: Tenant-owned backup collection that records capture lifecycle state and groups captured backup items.
|
||||
- Existing persistent fields used by this feature:
|
||||
- `id`
|
||||
- `tenant_id`
|
||||
- `workspace_id`
|
||||
- `name`
|
||||
- `status`
|
||||
- `item_count`
|
||||
- `metadata`
|
||||
- `completed_at`
|
||||
- `created_at`
|
||||
- Existing relationships used by this feature:
|
||||
- `tenant`
|
||||
- `items`
|
||||
- `restoreRuns`
|
||||
|
||||
#### Notes
|
||||
|
||||
- `completed_at` is the primary timestamp used to decide whether a completed backup basis exists and whether it is fresh enough.
|
||||
- No new `backup_health` or `freshness_state` column is introduced on `backup_sets`.
|
||||
|
||||
### 2. BackupItem
|
||||
|
||||
- Purpose: Tenant-owned captured recovery input for one backed-up policy or foundation record.
|
||||
- Existing persistent fields used by this feature:
|
||||
- `id`
|
||||
- `tenant_id`
|
||||
- `backup_set_id`
|
||||
- `payload`
|
||||
- `assignments`
|
||||
- `metadata`
|
||||
- `captured_at`
|
||||
- Existing relationships used by this feature:
|
||||
- `tenant`
|
||||
- `backupSet`
|
||||
- `policyVersion`
|
||||
|
||||
#### Existing metadata signals used by this feature
|
||||
|
||||
| Key | Type | Meaning |
|
||||
|---|---|---|
|
||||
| `source` | string or null | Direct source marker; may indicate metadata-only capture |
|
||||
| `snapshot_source` | string or null | Copied source marker from a linked policy version |
|
||||
| `warnings` | array<string> | Warning messages that may imply metadata-only fallback or other quality concerns |
|
||||
| `assignments_fetch_failed` | boolean | Assignment capture failed for the item |
|
||||
| `assignment_capture_reason` | string or null | Explanatory capture reason; not all values are degradations |
|
||||
| `has_orphaned_assignments` | boolean | One or more captured assignment targets were orphaned |
|
||||
| `integrity_warning` | string or null | Existing integrity or redaction warning carried into the backup item |
|
||||
|
||||
### 3. BackupSchedule
|
||||
|
||||
- Purpose: Tenant-owned schedule configuration for automated backup execution.
|
||||
- Existing persistent fields used by this feature:
|
||||
- `id`
|
||||
- `tenant_id`
|
||||
- `workspace_id`
|
||||
- `name`
|
||||
- `is_enabled`
|
||||
- `frequency`
|
||||
- `time_of_day`
|
||||
- `days_of_week`
|
||||
- `policy_types`
|
||||
- `last_run_status`
|
||||
- `last_run_at`
|
||||
- `next_run_at`
|
||||
- `timezone`
|
||||
- `created_at`
|
||||
- Existing relationships used by this feature:
|
||||
- `tenant`
|
||||
- `operationRuns`
|
||||
|
||||
#### Notes
|
||||
|
||||
- `last_run_at`, `last_run_status`, and `next_run_at` are sufficient to derive `schedule_follow_up`.
|
||||
- No new `schedule_health_state` or `backup_health_state` column is introduced.
|
||||
|
||||
## Derived Inputs
|
||||
|
||||
### 1. BackupHealthConfig
|
||||
|
||||
This is configuration, not persistence.
|
||||
|
||||
| Key | Type | Purpose |
|
||||
|---|---|---|
|
||||
| `tenantpilot.backup_health.freshness_hours` | integer | Defines the canonical age window for the latest relevant completed backup basis |
|
||||
| `tenantpilot.backup_health.schedule_overdue_grace_minutes` | integer | Defines how far past `next_run_at` an enabled schedule may drift before the feature raises `schedule_follow_up` |
|
||||
|
||||
## Derived Models
|
||||
|
||||
All derived models in this section are lightweight concrete value objects in `app/Support/BackupHealth/`. The concrete file set is `TenantBackupHealthAssessment.php`, `BackupFreshnessEvaluation.php`, `BackupScheduleFollowUpEvaluation.php`, `BackupHealthActionTarget.php`, and `BackupHealthDashboardSignal.php`, with `TenantBackupHealthResolver.php` orchestrating them.
|
||||
|
||||
### 1. TenantBackupHealthAssessment
|
||||
|
||||
Tenant-level backup-health truth used by dashboard and drillthrough logic.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `tenantId` | integer | tenant context | Identity |
|
||||
| `posture` | string | derived | One of `absent`, `stale`, `degraded`, `healthy` |
|
||||
| `primaryReason` | string or null | derived | One of `no_backup_basis`, `latest_backup_stale`, `latest_backup_degraded`, or `schedule_follow_up`; `null` only when posture is healthy and no remaining follow-up reason exists |
|
||||
| `headline` | string | derived | Primary operator-facing summary for dashboard surfaces |
|
||||
| `supportingMessage` | string or null | derived | Secondary operator-facing explanation |
|
||||
| `latestRelevantBackupSetId` | integer or null | derived | The backup set that currently governs posture |
|
||||
| `latestRelevantCompletedAt` | datetime or null | derived from `BackupSet.completed_at` | Null when no usable completed basis exists |
|
||||
| `qualitySummary` | `BackupQualitySummary` or null | reused `BackupQualityResolver` output | Reused quality truth for the latest relevant backup basis |
|
||||
| `freshnessEvaluation` | `BackupFreshnessEvaluation` | derived | Separates recency truth from degradation truth |
|
||||
| `scheduleFollowUp` | `BackupScheduleFollowUpEvaluation` | derived | Secondary caution about automation timing |
|
||||
| `healthyClaimAllowed` | boolean | derived | True only when the evidence supports a positive healthy statement and no unresolved `schedule_follow_up` remains |
|
||||
| `primaryActionTarget` | `BackupHealthActionTarget` | derived | Reason-driven drillthrough destination |
|
||||
| `positiveClaimBoundary` | string | derived | Explains that backup health does not imply recoverability or restore success |
|
||||
|
||||
### 2. BackupFreshnessEvaluation
|
||||
|
||||
Derived recency truth for the latest relevant completed backup basis.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `latestCompletedAt` | datetime or null | `BackupSet.completed_at` | Null when no usable completed basis exists |
|
||||
| `cutoffAt` | datetime | derived from config and `now()` | The point after which a backup basis becomes stale |
|
||||
| `isFresh` | boolean | derived | False when no basis exists or when `latestCompletedAt` is older than `cutoffAt` |
|
||||
| `policySource` | string | derived | Initially `configured_window` to make the canonical freshness rule explicit and testable |
|
||||
|
||||
#### Rules
|
||||
|
||||
- If there is no relevant completed backup basis, the feature does not produce `fresh`; it produces `absent`.
|
||||
- If a latest relevant completed backup basis exists but predates `cutoffAt`, the primary posture becomes `stale`.
|
||||
- `stale` outranks `degraded` as a primary posture when both conditions are true.
|
||||
|
||||
### 3. BackupScheduleFollowUpEvaluation
|
||||
|
||||
Derived automation follow-up truth for enabled schedules.
|
||||
|
||||
| Field | Type | Source | Notes |
|
||||
|---|---|---|---|
|
||||
| `hasEnabledSchedules` | boolean | derived from `BackupSchedule.is_enabled` | False when no enabled schedules exist |
|
||||
| `enabledScheduleCount` | integer | derived | Informational count |
|
||||
| `overdueScheduleCount` | integer | derived from `next_run_at` and grace window | Counts enabled schedules that appear overdue |
|
||||
| `failedRecentRunCount` | integer | derived from `last_run_status` | Counts enabled schedules whose recent status indicates failure or warning |
|
||||
| `neverSuccessfulCount` | integer | derived from `last_run_at` and schedule timing | Counts enabled schedules with no success evidence even though they should already have produced it |
|
||||
| `needsFollowUp` | boolean | derived | True when schedule timing or status indicates operator review |
|
||||
| `primaryScheduleId` | integer or null | derived | Optional single record for direct continuity if the result is unambiguous |
|
||||
| `summaryMessage` | string or null | derived | Operator-facing explanation of the schedule caution |
|
||||
|
||||
#### Rules
|
||||
|
||||
- Schedule follow-up is secondary. It adds attention but does not upgrade a tenant into `healthy`.
|
||||
- Enabled schedules with `next_run_at` past the grace window or with missing success evidence after the schedule should already have produced its first successful run count toward `schedule_follow_up`.
|
||||
|
||||
### 4. BackupHealthActionTarget
|
||||
|
||||
Reason-driven drillthrough target chosen by the resolver.
|
||||
|
||||
| Field | Type | Notes |
|
||||
|---|---|---|
|
||||
| `surface` | string | `backup_sets_index`, `backup_set_view`, or `backup_schedules_index` |
|
||||
| `recordId` | integer or null | Used only when the target is a specific backup set |
|
||||
| `label` | string | Operator-facing action label such as `Open backup sets` or `Open latest backup` |
|
||||
| `reason` | string | The problem class the destination is expected to confirm |
|
||||
|
||||
### 5. BackupHealthDashboardSignal
|
||||
|
||||
Shared dashboard-facing model for KPI, attention, and healthy-check rendering.
|
||||
|
||||
| Field | Type | Source |
|
||||
|---|---|---|
|
||||
| `title` | string | derived |
|
||||
| `body` | string | derived |
|
||||
| `tone` | string | derived |
|
||||
| `badge` | string or null | derived via shared badge primitives when the signal is rendered as an attention item |
|
||||
| `badgeColor` | string or null | derived via shared badge primitives when the signal is rendered as an attention item |
|
||||
| `actionTarget` | `BackupHealthActionTarget` or null | derived |
|
||||
| `actionDisabled` | boolean | derived from authorization and target availability |
|
||||
| `helperText` | string or null | derived |
|
||||
|
||||
## Validation Rules
|
||||
|
||||
- `absent` applies when no usable completed backup basis exists for the tenant.
|
||||
- `stale` applies when the latest relevant completed backup basis exists but fails the freshness rule, regardless of whether it is also degraded.
|
||||
- `degraded` applies when the latest relevant completed backup basis is fresh enough but existing `BackupQualitySummary` shows material degradation.
|
||||
- `healthy` applies when a latest relevant completed backup basis exists, passes freshness, and shows no material degradation.
|
||||
- `schedule_follow_up` is additive and must never be used as proof of health.
|
||||
- If `schedule_follow_up` is the only remaining caution, posture may remain `healthy`, but `primaryReason` must be `schedule_follow_up` and `healthyClaimAllowed` must be `false` until the follow-up resolves.
|
||||
- Existing `BackupQualitySummary` produced by `BackupQualityResolver` remains the authority for degradation families and degraded item counts.
|
||||
- Dashboard summary truth must remain visible to entitled tenant-dashboard viewers even when a downstream action target is suppressed or disabled.
|
||||
@ -1,273 +0,0 @@
|
||||
# Implementation Plan: Tenant Backup Health Signals
|
||||
|
||||
**Branch**: `180-tenant-backup-health` | **Date**: 2026-04-07 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/180-tenant-backup-health/spec.md`
|
||||
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/180-tenant-backup-health/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Harden the tenant dashboard so operators can tell within seconds whether a tenant has no usable backup basis, a stale latest backup basis, a degraded latest backup basis, or a healthy recent backup basis without opening deep backup surfaces first. The implementation keeps `BackupSet`, `BackupItem`, `BackupSchedule`, and the existing backup-quality layer as the only sources of truth, introduces one narrow derived tenant backup-health resolver over those records, adds a config-backed freshness policy with schedule follow-up semantics, integrates the result into `DashboardKpis` and `NeedsAttention`, and preserves reason-driven drillthrough into existing backup-set and backup-schedule surfaces without adding a new persistence model or recovery-confidence framework.
|
||||
|
||||
Key approach: work inside the existing `TenantDashboard`, `DashboardKpis`, `NeedsAttention`, `BackupSetResource`, `BackupScheduleResource`, and `BackupQualityResolver` seams; derive tenant posture from the latest relevant completed backup set plus existing backup-quality truth and enabled-schedule timing; keep the feature Filament v5 and Livewire v4 compliant; avoid new tables, Graph calls, jobs, or asset registration; validate the result with focused Pest, Livewire, truth-alignment, and RBAC coverage.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: PHP 8.4, Laravel 12, Blade, Filament v5, Livewire v4
|
||||
**Primary Dependencies**: Filament v5, Livewire v4, Pest v4, Laravel Sail, existing `DashboardKpis`, `NeedsAttention`, `BackupSetResource`, `BackupScheduleResource`, `BackupQualityResolver`, `BackupQualitySummary`, `ScheduleTimeService`, shared badge infrastructure, and existing RBAC helpers
|
||||
**Storage**: PostgreSQL with existing tenant-owned `backup_sets`, `backup_items`, and `backup_schedules` records plus existing JSON-backed backup metadata; no schema change planned
|
||||
**Testing**: Pest feature tests, Livewire widget and resource tests, and unit tests for the narrow backup-health derivation layer, all run through Sail
|
||||
**Target Platform**: Laravel web application in Sail locally and containerized Linux deployment in staging and production
|
||||
**Project Type**: Laravel monolith web application
|
||||
**Performance Goals**: Keep tenant-dashboard rendering DB-only and query-bounded, avoid new N+1 query hotspots while deriving the latest relevant backup basis, and preserve 5 to 10 second operator scanability on tenant dashboard and drillthrough destinations
|
||||
**Constraints**: No new backup-health table, no recovery-confidence score, no new Graph contract path, no new queue or `OperationRun`, no RBAC drift, no calmness leakage beyond evidence, no ad-hoc badge mappings, and no new global Filament assets
|
||||
**Scale/Scope**: One tenant-scoped dashboard composition, two existing dashboard widgets, one narrow derived backup-health layer, optional config additions in `config/tenantpilot.php`, and focused regression coverage across resolver, widget, drillthrough, and RBAC behavior
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Passed before Phase 0 research. Re-checked after Phase 1 design and still passing.*
|
||||
|
||||
| Principle | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| Inventory-first | Pass | Backups remain immutable snapshot truth; the feature only summarizes existing backup and schedule state on read |
|
||||
| Read/write separation | Pass | This is a read-first dashboard hardening slice; existing backup and schedule mutations remain unchanged and separately confirmed or audited |
|
||||
| Graph contract path | Pass | No new Microsoft Graph calls or contract-registry changes are introduced |
|
||||
| Deterministic capabilities | Pass | Existing capability registry and tenant-scoped authorization remain authoritative; no raw capability strings are introduced |
|
||||
| RBAC-UX planes and 404 vs 403 | Pass | The feature stays in the tenant/admin plane under `/admin/t/{tenant}/...`; non-members remain `404`, and existing in-scope authorization stays server-side |
|
||||
| Workspace isolation | Pass | No workspace-scope broadening or cross-workspace aggregation is added |
|
||||
| Tenant isolation | Pass | Backup sets, backup items, schedules, and dashboard summaries stay tenant-owned and tenant-scoped |
|
||||
| Dangerous and destructive confirmations | Pass | No new destructive action is introduced. Existing backup and schedule destructive actions remain `->requiresConfirmation()` and capability-gated |
|
||||
| Global search safety | Pass | No new globally searchable resource is introduced or changed. `BackupSetResource` already has a view page, `BackupScheduleResource` already has an edit page, and global search configuration remains unchanged |
|
||||
| Run observability | Pass | No new long-running work or `OperationRun` usage is introduced |
|
||||
| Ops-UX 3-surface feedback | Pass | No new queued action or run feedback surface is added |
|
||||
| Ops-UX lifecycle ownership | Pass | `OperationRun.status` and `OperationRun.outcome` are untouched |
|
||||
| Ops-UX summary counts | Pass | No new `summary_counts` keys are required |
|
||||
| Data minimization | Pass | The feature reuses existing metadata and timestamps only; no new secret or payload exposure is planned |
|
||||
| Proportionality (PROP-001) | Pass | Added logic is limited to one narrow tenant backup-health layer plus config-backed freshness semantics |
|
||||
| Persisted truth (PERSIST-001) | Pass | No new table, column, or stored backup-health mirror is introduced |
|
||||
| Behavioral state (STATE-001) | Pass | New posture and reason families are derived only because they change operator guidance and dashboard calmness behavior |
|
||||
| Badge semantics (BADGE-001) | Pass | Existing badge and tag infrastructure remains the semantic source; any new backup-health tone stays inside shared UI primitives rather than local mappings |
|
||||
| Filament-native UI (UI-FIL-001) | Pass | Existing Filament widgets, stats, tables, and shared primitives remain the implementation seams |
|
||||
| UI naming (UI-NAMING-001) | Pass | Operator-facing vocabulary stays bounded to backup health, last backup, stale, degraded, no backups, and schedule follow-up, without `recoverable` or `proven` claims |
|
||||
| Operator surfaces (OPSURF-001) | Pass | Default-visible tenant-dashboard content becomes more operator-first by exposing backup posture before deep diagnostics |
|
||||
| Filament Action Surface Contract | Pass | `BackupSetResource` and `BackupScheduleResource` keep existing inspect models and destructive placement; `TenantDashboard` remains under the current dashboard exemption |
|
||||
| Filament UX-001 | Pass with documented variance | No new create or edit screen is added. Existing backup-set and backup-schedule resources remain the canonical follow-up surfaces, with summary-first truth added where needed |
|
||||
| Filament v5 / Livewire v4 compliance | Pass | The implementation stays inside the current Filament v5 and Livewire v4 stack |
|
||||
| Provider registration location | Pass | No panel or provider changes are planned; Laravel 11+ provider registration remains in `bootstrap/providers.php` |
|
||||
| Asset strategy | Pass | No new panel assets are planned; deployment keeps the existing `php artisan filament:assets` step unchanged |
|
||||
|
||||
## Phase 0 Research
|
||||
|
||||
Research outcomes are captured in `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/180-tenant-backup-health/research.md`.
|
||||
|
||||
Key decisions:
|
||||
|
||||
- Derive tenant backup health from existing `BackupSet`, `BackupItem`, `BackupSchedule`, and `BackupQualityResolver` truth instead of introducing persisted backup-health state.
|
||||
- Let the latest relevant completed backup set govern tenant posture rather than allowing older healthier history to calm the dashboard.
|
||||
- Reuse existing backup-quality summaries for degradation truth and add no competing backup-quality taxonomy.
|
||||
- Define backup freshness through one config-backed fallback window on the latest relevant completed backup set, while treating schedule timing as a secondary follow-up signal rather than health proof.
|
||||
- Derive schedule follow-up from enabled schedules whose current `next_run_at` or `last_run_at` semantics indicate missed or overdue execution beyond a small grace window.
|
||||
- Integrate backup health into the existing `DashboardKpis` and `NeedsAttention` widgets and keep healthy wording suppressed unless the backing evidence is fully supportive.
|
||||
- Route dashboard drillthroughs by problem class: no usable backup basis opens the backup-set list, stale or degraded latest backup opens the latest relevant backup-set detail, and schedule follow-up opens the backup-schedules list.
|
||||
- Extend the current widget, truth-alignment, backup-set, schedule, and tenant-scope Pest coverage instead of creating a browser-first harness.
|
||||
|
||||
## Phase 1 Design
|
||||
|
||||
Design artifacts are created under `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/180-tenant-backup-health/`:
|
||||
|
||||
- `research.md`: implementation and domain decisions for tenant backup-health derivation
|
||||
- `data-model.md`: existing entities, config inputs, and derived backup-health models
|
||||
- `contracts/tenant-backup-health.openapi.yaml`: internal logical contract for dashboard summary, backup-set confirmation, and schedule follow-up surfaces
|
||||
- `quickstart.md`: focused automated and manual validation workflow for tenant backup-health signals
|
||||
|
||||
Design decisions:
|
||||
|
||||
- No schema migration is required. The design adds only a narrow derived resolver layer and a small config section in `config/tenantpilot.php` for backup-health freshness semantics.
|
||||
- Tenant backup health is derived at render time from the latest relevant completed backup set, existing `BackupQualitySummary`, and enabled-schedule timing. No new `Tenant` field, cache table, or materialized rollup is planned.
|
||||
- Stale versus degraded precedence is deterministic: `absent` outranks everything, `stale` outranks `degraded`, `degraded` outranks `healthy`, and `schedule_follow_up` remains a secondary reason family. When the latest backup basis is fresh and non-degraded, posture may remain `healthy`, but `schedule_follow_up` becomes the active reason and suppresses any positive healthy confirmation until resolved.
|
||||
- `DashboardKpis` owns the primary backup-health stat or card, while `NeedsAttention` owns reason-specific backup follow-up items and the positive healthy backup check.
|
||||
- Backup-set detail remains the confirmation surface for stale and degraded latest-backup posture by combining recency and existing backup-quality summary. Backup-schedules list remains the confirmation surface for schedule-follow-up posture and must foreground one derived follow-up indicator so the missed-run or overdue reason stays scan-fast.
|
||||
- The feature stays Filament v5 and Livewire v4 compliant, introduces no new panel provider, and requires no new asset registration.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/180-tenant-backup-health/
|
||||
├── spec.md
|
||||
├── plan.md
|
||||
├── research.md
|
||||
├── data-model.md
|
||||
├── quickstart.md
|
||||
├── contracts/
|
||||
│ └── tenant-backup-health.openapi.yaml
|
||||
├── checklists/
|
||||
│ └── requirements.md
|
||||
└── tasks.md
|
||||
```
|
||||
|
||||
### Source Code (repository root, including planned additions for this feature)
|
||||
|
||||
```text
|
||||
app/
|
||||
├── Filament/
|
||||
│ ├── Pages/
|
||||
│ │ └── TenantDashboard.php
|
||||
│ ├── Resources/
|
||||
│ │ ├── BackupScheduleResource.php
|
||||
│ │ └── BackupSetResource.php
|
||||
│ └── Widgets/
|
||||
│ └── Dashboard/
|
||||
│ ├── DashboardKpis.php
|
||||
│ └── NeedsAttention.php
|
||||
├── Models/
|
||||
│ ├── BackupItem.php
|
||||
│ ├── BackupSchedule.php
|
||||
│ ├── BackupSet.php
|
||||
│ └── Tenant.php
|
||||
├── Support/
|
||||
│ ├── BackupHealth/
|
||||
│ │ ├── TenantBackupHealthAssessment.php
|
||||
│ │ ├── BackupFreshnessEvaluation.php
|
||||
│ │ ├── BackupScheduleFollowUpEvaluation.php
|
||||
│ │ ├── BackupHealthActionTarget.php
|
||||
│ │ ├── BackupHealthDashboardSignal.php
|
||||
│ │ └── TenantBackupHealthResolver.php
|
||||
│ ├── BackupQuality/
|
||||
│ │ ├── BackupQualityResolver.php
|
||||
│ │ └── BackupQualitySummary.php
|
||||
│ └── Badges/
|
||||
│ └── [existing shared badge seams only if new backup-health tone mapping is needed]
|
||||
|
||||
config/
|
||||
└── tenantpilot.php
|
||||
|
||||
tests/
|
||||
├── Feature/
|
||||
│ ├── BackupScheduling/
|
||||
│ │ └── BackupScheduleLifecycleTest.php
|
||||
│ └── Filament/
|
||||
│ ├── BackupSetListContinuityTest.php
|
||||
│ ├── BackupSetEnterpriseDetailPageTest.php
|
||||
│ ├── DashboardKpisWidgetTest.php
|
||||
│ ├── NeedsAttentionWidgetTest.php
|
||||
│ ├── TenantDashboardDbOnlyTest.php
|
||||
│ ├── TenantDashboardTenantScopeTest.php
|
||||
│ └── TenantDashboardTruthAlignmentTest.php
|
||||
└── Unit/
|
||||
└── Support/
|
||||
└── BackupHealth/
|
||||
└── TenantBackupHealthResolverTest.php
|
||||
```
|
||||
|
||||
**Structure Decision**: Standard Laravel monolith. The implementation stays inside existing dashboard widgets, backup resources, shared support helpers, and current test structure. Any new helper types and lightweight dashboard-facing value objects live under `app/Support/BackupHealth/` as a narrow derived layer shared by the dashboard and drillthrough logic.
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### Phase A — Introduce Narrow Tenant Backup-Health Derivation
|
||||
|
||||
**Goal**: Create one derived path that can answer absent, stale, degraded, or healthy from existing backup and schedule truth without introducing new persistence.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| A.1 | New narrow helper(s) under `app/Support/BackupHealth/` | Introduce `TenantBackupHealthResolver` plus lightweight `TenantBackupHealthAssessment`, `BackupFreshnessEvaluation`, `BackupScheduleFollowUpEvaluation`, `BackupHealthActionTarget`, and `BackupHealthDashboardSignal` value objects that derive the latest relevant completed backup basis, posture, primary reason, supporting message, drillthrough target, and healthy-claim boundary with query-bounded latest-basis loading |
|
||||
| A.2 | `app/Support/BackupQuality/BackupQualityResolver.php` plus the new backup-health layer | Explicitly reuse `BackupQualityResolver` and `BackupQualitySummary` output to classify material degradation instead of creating a second backup-quality system |
|
||||
| A.3 | `config/tenantpilot.php` | Add a small `backup_health` config section for canonical freshness hours and schedule overdue grace so stale logic is explicit, testable, and not hard-coded in widgets |
|
||||
|
||||
### Phase B — Integrate Backup Health Into Primary Tenant Dashboard Surfaces
|
||||
|
||||
**Goal**: Make tenant backup posture visible on the dashboard before the operator has to open deep backup pages.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| B.1 | `app/Filament/Widgets/Dashboard/DashboardKpis.php` | Add a backup-health stat or card that reflects the derived posture, last relevant backup timing, current reason, color tone, and one reason-driven destination |
|
||||
| B.2 | `app/Filament/Widgets/Dashboard/NeedsAttention.php` | Add backup-health attention items for no usable backup basis, stale latest backup, degraded latest backup, and schedule follow-up |
|
||||
| B.3 | `app/Filament/Widgets/Dashboard/NeedsAttention.php` | Add `Backups are recent and healthy` to the healthy-check set only when the derived assessment positively supports it and no backup-health attention item, including `schedule_follow_up`, remains |
|
||||
|
||||
### Phase C — Preserve Drillthrough Continuity On Backup And Schedule Surfaces
|
||||
|
||||
**Goal**: Ensure the dashboard warning or healthy claim can be rediscovered on the destination surface without guesswork.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| C.1 | `app/Support/BackupHealth/TenantBackupHealthResolver.php` plus `app/Support/BackupHealth/BackupHealthActionTarget.php` | Centralize reason-driven URL selection in the existing backup-health layer so no-basis goes to backup-set index, stale or degraded latest backup goes to the relevant backup-set detail, and schedule follow-up goes to backup-schedules index |
|
||||
| C.2 | `app/Filament/Resources/BackupSetResource.php` | Reuse or slightly harden the backup-set list and detail presentation so the index confirms no usable backup basis and the latest relevant backup-set detail clearly confirms stale or degraded posture on arrival |
|
||||
| C.3 | `app/Filament/Resources/BackupScheduleResource.php` | Add one derived schedule-follow-up confirmation signal on the list surface so existing `last_run_at`, `last_run_status`, and `next_run_at` evidence remains scan-fast on arrival |
|
||||
|
||||
### Phase D — Lock Semantics With Focused Regression Coverage
|
||||
|
||||
**Goal**: Protect resolver truth, dashboard truth, continuity, and tenant safety from regression.
|
||||
|
||||
| Step | File | Change |
|
||||
|------|------|--------|
|
||||
| D.1 | New unit tests under `tests/Unit/Support/BackupHealth/` | Cover no-backup, stale, degraded, healthy, schedule-follow-up, and latest-history-governs derivation |
|
||||
| D.2 | `tests/Feature/Filament/DashboardKpisWidgetTest.php` | Extend KPI payload and URL assertions for backup-health posture and reason-driven drillthrough |
|
||||
| D.3 | `tests/Feature/Filament/NeedsAttentionWidgetTest.php` | Extend attention and healthy-check coverage for no-backup, stale-backup, degraded-latest-backup, schedule-follow-up, and healthy-backup scenarios |
|
||||
| D.4 | `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php` | Ensure backup-health calmness and caution align with the rest of the tenant dashboard and do not reintroduce calmness leakage |
|
||||
| D.5 | `tests/Feature/Filament/BackupSetListContinuityTest.php`, `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`, and `tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php` | Prove that no-basis, stale, degraded, and schedule-follow-up drillthrough destinations confirm the same problem class the dashboard named |
|
||||
| D.6 | `tests/Feature/Filament/TenantDashboardTenantScopeTest.php` or a new RBAC-safe visibility test | Preserve tenant-scope truth and non-member-safe behavior for dashboard summary and backup follow-up routes |
|
||||
| D.7 | `vendor/bin/sail bin pint --dirty --format agent` and focused Pest runs | Required formatting and targeted verification before implementation is considered complete |
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
### D-001 — Tenant backup health is derived, not stored
|
||||
|
||||
The product already stores the facts this slice needs: completed backup sets, backup-item quality metadata, and backup schedule timing. The missing piece is a tenant-level interpretation layer for overview truth, not a new persistence model.
|
||||
|
||||
### D-002 — The latest relevant completed backup set governs posture
|
||||
|
||||
Older healthy history cannot calm the dashboard if the latest relevant completed backup is stale or degraded. This keeps the overview aligned with the operator's current recovery starting point.
|
||||
|
||||
### D-003 — Stale and degraded remain distinct, with deterministic precedence
|
||||
|
||||
`absent`, `stale`, `degraded`, and `healthy` are mutually exclusive primary posture states. When the latest relevant backup is both old and degraded, `stale` becomes the primary posture while degradation remains visible as supporting detail rather than disappearing.
|
||||
|
||||
### D-004 — Schedule timing is follow-up truth, not health proof
|
||||
|
||||
An enabled schedule can support the operator's diagnosis, but it cannot prove healthy backup posture. Overdue or never-successful schedules add `schedule_follow_up`; they do not substitute for a recent healthy completed backup basis. If the backup basis is otherwise healthy, posture may stay `healthy`, but `schedule_follow_up` becomes the active reason and suppresses calm confirmation until the schedule concern clears.
|
||||
|
||||
### D-005 — Healthy wording is stricter than mere backup existence
|
||||
|
||||
`Backups are recent and healthy` is reserved for tenants whose latest relevant completed backup exists, meets the freshness window, and carries no material degradation under existing backup-quality truth. Lack of evidence must suppress calmness.
|
||||
|
||||
### D-006 — Existing Filament seams are sufficient
|
||||
|
||||
The current `DashboardKpis`, `NeedsAttention`, `BackupSetResource`, and `BackupScheduleResource` surfaces already provide the right seams. This slice does not need a new page shell, a new dashboard module, or a new front-end state layer.
|
||||
|
||||
### D-007 — Keep the claim boundary below recovery confidence
|
||||
|
||||
The feature can say that backups are absent, stale, degraded, or healthy as backup inputs. It cannot say that the tenant is recoverable, that restore will succeed, or that recovery posture is proven.
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
| Risk | Impact | Likelihood | Mitigation |
|
||||
|------|--------|------------|------------|
|
||||
| Latest-basis selection drifts from operator expectation and lets older history calm the dashboard | High | Medium | Make latest relevant completed backup selection explicit in the resolver and cover mixed-history precedence with unit tests |
|
||||
| Dashboard calmness returns because schedule presence is treated as a proxy for health | High | Medium | Keep schedule follow-up secondary in the resolver and test that schedules never make a tenant healthy on their own |
|
||||
| Backup health duplicates or contradicts existing backup-quality truth | High | Medium | Reuse `BackupQualityResolver` and existing degradation families rather than adding a second backup-quality mapping |
|
||||
| Schedule drillthrough lands on a surface that does not clearly confirm the warning | Medium | Medium | Use the schedule list as the primary follow-up destination and add one scan-fast confirmation signal if timestamps alone are insufficient |
|
||||
| Tight stale thresholds create noise or false calmness over time | Medium | Medium | Externalize fallback freshness and schedule grace in config and pin the semantics with unit and feature tests |
|
||||
|
||||
## Test Strategy
|
||||
|
||||
- Add unit tests for the narrow backup-health resolver so latest-basis selection, stale precedence, degraded detection reuse, healthy-gate logic, and schedule-follow-up derivation remain deterministic.
|
||||
- Extend `DashboardKpisWidgetTest` to assert the backup-health stat label, value, description, color, and destination across absent, stale, degraded, and healthy scenarios.
|
||||
- Extend `NeedsAttentionWidgetTest` to assert backup-health attention items, healthy-check inclusion or suppression, and safe degraded-link behavior when appropriate.
|
||||
- Extend `TenantDashboardTruthAlignmentTest` so backup-health calmness or caution cannot contradict the rest of the dashboard's operator truth.
|
||||
- Extend backup-set and schedule surface tests so dashboard drillthroughs recover the same problem class on the target page.
|
||||
- Extend tenant-scope or RBAC coverage so entitled users see truthful summary state and non-members receive deny-as-not-found semantics without cross-tenant hints.
|
||||
- Keep all tests Livewire v4 compatible and run the smallest affected subset through Sail before asking for a full-suite pass.
|
||||
- Run `vendor/bin/sail bin pint --dirty --format agent` before final verification.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
No constitution violations or exception-driven complexity were identified. The only added structure is a narrow derived backup-health layer and a small derived posture or reason family already justified by the proportionality review.
|
||||
|
||||
## Proportionality Review
|
||||
|
||||
- **Current operator problem**: The tenant dashboard can look healthy while backup posture is missing, stale, or degraded, which hides a recovery-relevant truth from the operator's primary overview surface.
|
||||
- **Existing structure is insufficient because**: Existing backup-quality truth lives in backup-set, item, version, and restore-adjacent surfaces, but there is no tenant-level rollup that answers the dashboard question directly.
|
||||
- **Narrowest correct implementation**: Add one narrow derived tenant backup-health layer, wire it into the existing dashboard widgets, and reuse current backup and schedule destinations for continuity without creating new persistence or a broader recovery-confidence system.
|
||||
- **Ownership cost created**: A small amount of resolver logic, a small config-backed freshness policy, limited widget wiring, and focused unit and feature tests.
|
||||
- **Alternative intentionally rejected**: A persisted backup-health table, a workspace-wide recovery rollup, or a recovery-confidence score. Each adds broader truth and maintenance cost than the current tenant-dashboard problem requires.
|
||||
- **Release truth**: Current-release truth. The feature corrects a trust gap on already-shipped tenant overview surfaces.
|
||||
|
||||
@ -1,123 +0,0 @@
|
||||
# Quickstart: Tenant Backup Health Signals
|
||||
|
||||
## Goal
|
||||
|
||||
Validate that the tenant dashboard now answers the operator's backup question within seconds, that backup-health warnings drill into confirming surfaces, and that positive backup-health wording only appears when the available evidence genuinely supports it.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Start Sail if it is not already running.
|
||||
2. Ensure the workspace has representative tenant fixtures for:
|
||||
- no usable completed backup basis
|
||||
- one latest completed backup basis that is older than the backup-health freshness window
|
||||
- one latest completed backup basis that is recent but degraded under existing backup-quality truth
|
||||
- one latest completed backup basis that is recent and not materially degraded
|
||||
- one enabled backup schedule whose `next_run_at` is overdue or whose `last_run_at` indicates missing or failed execution
|
||||
- for a deterministic local/testing fixture that reproduces the established-member dashboard-visible but backup-drillthrough-`403` case, run `vendor/bin/sail artisan tenantpilot:backup-health:seed-browser-fixture --no-interaction`, then open `/admin/local/backup-health-browser-fixture-login` when the integrated browser cannot complete Microsoft SSO for the seeded local user
|
||||
3. Ensure the acting users are valid workspace and tenant members.
|
||||
4. Ensure at least one tenant-scoped user exists for positive summary visibility and one non-member or wrong-tenant case exists for tenant-scope isolation checks.
|
||||
|
||||
## Focused Automated Verification
|
||||
|
||||
Run the smallest existing dashboard and backup pack first:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/DashboardKpisWidgetTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/NeedsAttentionWidgetTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantDashboardTenantScopeTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantDashboardDbOnlyTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php
|
||||
```
|
||||
|
||||
Expected new or expanded spec-scoped coverage:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail artisan test --compact tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php
|
||||
vendor/bin/sail artisan test --compact --filter=backup tests/Feature/Filament/DashboardKpisWidgetTest.php tests/Feature/Filament/NeedsAttentionWidgetTest.php tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php
|
||||
vendor/bin/sail artisan test --compact --filter=backup tests/Feature/Filament/BackupSetListContinuityTest.php tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php
|
||||
```
|
||||
|
||||
Use `--filter` for smaller iteration passes while implementing specific scenarios.
|
||||
|
||||
The tenant-scope pack must include one established-member scenario where the dashboard still renders truthful summary state with a disabled or downgraded backup-health action target while the protected downstream route returns `403`.
|
||||
|
||||
## Manual Validation Pass
|
||||
|
||||
### 1. Verify no-backup posture
|
||||
|
||||
Open `/admin/t/{tenant}` for a tenant without a usable completed backup basis and confirm:
|
||||
|
||||
- the tenant dashboard explicitly shows a backup-health warning rather than a calm omission
|
||||
- `NeedsAttention` includes a no-backup item or equivalent primary backup warning
|
||||
- the drillthrough opens the backup-set list, which confirms that no usable completed basis exists
|
||||
|
||||
### 2. Verify stale latest-backup posture
|
||||
|
||||
Open `/admin/t/{tenant}` for a tenant whose latest relevant completed backup basis is older than the configured freshness window and confirm:
|
||||
|
||||
- the dashboard does not show `Backups are recent and healthy`
|
||||
- the stale reason is visible on a primary summary surface
|
||||
- the drillthrough opens the latest relevant backup set and its recency confirms the stale posture immediately
|
||||
- if the latest relevant backup basis is both stale and degraded, the dashboard still leads with stale posture while the destination preserves degradation as supporting detail
|
||||
|
||||
### 3. Verify degraded latest-backup posture
|
||||
|
||||
Open `/admin/t/{tenant}` for a tenant whose latest relevant completed backup basis is recent but degraded and confirm:
|
||||
|
||||
- the dashboard shows degraded backup posture rather than a stale or healthy fallback
|
||||
- the drillthrough opens the latest relevant backup set
|
||||
- the destination confirms degradation through existing backup-quality summary without implying restore safety
|
||||
|
||||
### 4. Verify healthy backup posture
|
||||
|
||||
Open `/admin/t/{tenant}` for a tenant with a recent, non-degraded latest relevant completed backup basis and confirm:
|
||||
|
||||
- the dashboard may show a positive backup-health check
|
||||
- no backup-health attention item, including `schedule_follow_up`, is present
|
||||
- the healthy wording remains bounded to backup posture and does not imply recoverability or restore success
|
||||
|
||||
### 5. Verify schedule-follow-up posture
|
||||
|
||||
Open `/admin/t/{tenant}` for a tenant with an enabled schedule that looks overdue or never-successful and confirm:
|
||||
|
||||
- schedule follow-up appears as a backup-health attention reason when appropriate
|
||||
- a never-successful schedule triggers follow-up only when it is old enough that it should already have produced success evidence
|
||||
- if the latest backup basis is otherwise fresh and non-degraded, the basis posture may remain healthy, but `schedule_follow_up` stays the active reason and no positive healthy backup check appears
|
||||
- schedule presence alone does not make the dashboard healthy and suppresses any positive healthy backup check while the follow-up remains active
|
||||
- the drillthrough opens the backup-schedules list and the destination makes the overdue or missed-execution condition scan-fast
|
||||
|
||||
### 6. Verify tenant-scope and RBAC consistency
|
||||
|
||||
Repeat the dashboard checks as:
|
||||
|
||||
- an entitled tenant member, to confirm backup-health summary truth is visible
|
||||
- an entitled tenant member who can load the dashboard but cannot open one backup destination, to confirm the summary still renders, the affordance degrades safely, and the blocked downstream route fails with `403`; the deterministic local/testing fixture command above seeds exactly this case for `smoke-requester+180@tenantpilot.local`, and `/admin/local/backup-health-browser-fixture-login` starts the local/testing browser session for that user
|
||||
- a non-member or wrong-tenant actor, to confirm tenant dashboard and drillthrough routes remain deny-as-not-found
|
||||
|
||||
## Non-Regression Checks
|
||||
|
||||
Confirm the feature did not change:
|
||||
|
||||
- current backup-set and backup-schedule route identity
|
||||
- existing destructive action confirmation behavior on backup resources
|
||||
- existing backup-quality semantics owned by `BackupQualityResolver`
|
||||
- existing `OperationRun` behavior and operations widgets
|
||||
- current global asset registration and deployment requirements
|
||||
|
||||
## Formatting And Final Verification
|
||||
|
||||
Before finalizing implementation work:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail bin pint --dirty --format agent
|
||||
```
|
||||
|
||||
Then rerun the smallest affected test set and offer the full suite only after the focused backup-health pack passes.
|
||||
|
||||
Close the feature only after manual validation confirms:
|
||||
|
||||
- an operator can identify absent, stale, degraded, or healthy backup posture within 10 seconds on the tenant dashboard
|
||||
- warning drillthroughs land on surfaces that confirm the same problem class
|
||||
- positive backup-health wording appears only when the evidence truly supports it
|
||||
@ -1,73 +0,0 @@
|
||||
# Research: Tenant Backup Health Signals
|
||||
|
||||
## Decision 1: Derive tenant backup health from existing backup and schedule truth instead of creating a persisted health model
|
||||
|
||||
- Decision: Build tenant backup health from existing `BackupSet`, `BackupItem`, `BackupSchedule`, and `BackupQualityResolver` facts at render time. Do not add a `tenant_backup_health` table, a cached rollup row, or a recovery-confidence ledger.
|
||||
- Rationale: The repository already stores the facts this feature needs: completed backup timestamps, backup-quality degradations, and schedule timing. The product gap is missing tenant-level overview truth, not missing persistence.
|
||||
- Alternatives considered:
|
||||
- Persist a backup-health row per tenant. Rejected because it would create a second source of truth for data that is already derivable.
|
||||
- Piggyback on `Tenant` model columns. Rejected because this slice does not need a new lifecycle-bearing tenant field.
|
||||
|
||||
## Decision 2: Let the latest relevant completed backup set govern posture
|
||||
|
||||
- Decision: The latest relevant completed backup set is the primary tenant backup-health basis. Older healthier backup history cannot override a newer stale or degraded latest basis.
|
||||
- Rationale: The operator's first question is about the current recovery starting point, not whether an older good snapshot exists somewhere in history.
|
||||
- Alternatives considered:
|
||||
- Choose the healthiest recent backup in the tenant. Rejected because it would calm the dashboard while the most recent relevant backup is weak.
|
||||
- Aggregate all backup history into a composite score. Rejected because the feature explicitly avoids a scoring engine.
|
||||
|
||||
## Decision 3: Reuse existing backup-quality truth instead of introducing a second degradation system
|
||||
|
||||
- Decision: Material degradation for tenant backup health is derived from existing `BackupQualitySummary` output, especially degraded item counts and existing degradation families. No new competing backup-quality taxonomy is introduced.
|
||||
- Rationale: Backup-quality truth was already hardened in the dedicated backup-quality work. Re-deriving the same concepts differently at tenant level would create contradiction and extra maintenance.
|
||||
- Alternatives considered:
|
||||
- Add a tenant-specific degradation matrix. Rejected because it would drift from backup-set and item detail truth.
|
||||
- Use only raw backup-item metadata in the dashboard resolver. Rejected because the shared quality resolver already exists and should remain authoritative.
|
||||
|
||||
## Decision 4: Define one config-backed freshness window for backup posture and keep schedule timing secondary
|
||||
|
||||
- Decision: Backup posture freshness is evaluated against the latest relevant completed backup set using one config-backed canonical freshness window in `config/tenantpilot.php`, initially aligned with the repo's existing 24-hour freshness posture for other safety-critical truth. Enabled schedule timing can add follow-up pressure but cannot replace or override that single freshness rule.
|
||||
- Rationale: There is no current backup-health freshness rule in the codebase. Hard-coding a threshold inside widgets would be brittle, while a small config value keeps the semantics explicit and testable.
|
||||
- Alternatives considered:
|
||||
- Make freshness entirely schedule-driven. Rejected because schedule state is secondary in the spec and cannot replace actual backup existence.
|
||||
- Hard-code a stale threshold inside the dashboard widget. Rejected because it would hide an important product rule in presentation code.
|
||||
|
||||
## Decision 5: Detect schedule follow-up from enabled schedules that look overdue or never-successful beyond a grace window
|
||||
|
||||
- Decision: `schedule_follow_up` is derived from enabled schedules whose `next_run_at` is overdue beyond a small grace window, whose `last_run_at` is missing after they should have started producing evidence, or whose last schedule status indicates a failed or non-successful recent run. If the latest backup basis is otherwise fresh and non-degraded, posture may remain `healthy`, but `schedule_follow_up` becomes the active reason and suppresses any positive healthy confirmation.
|
||||
- Rationale: `BackupSchedule` already tracks `last_run_at`, `last_run_status`, and `next_run_at`. Those fields are enough to signal that automation needs attention without conflating it with actual backup health proof.
|
||||
- Alternatives considered:
|
||||
- Ignore schedule state entirely. Rejected because the spec explicitly wants schedule follow-up represented.
|
||||
- Treat any enabled schedule as positive backup evidence. Rejected because schedule existence is not backup proof.
|
||||
|
||||
## Decision 6: Surface backup health through the existing dashboard widgets, not a new page or module
|
||||
|
||||
- Decision: Add backup health to the current `DashboardKpis` and `NeedsAttention` widgets and extend the existing healthy-check pattern instead of building a dedicated dashboard module or alternate tenant overview page.
|
||||
- Rationale: The tenant dashboard is already the operator's primary overview surface, and the spec is explicitly a small hardening slice rather than a new product area.
|
||||
- Alternatives considered:
|
||||
- Build a standalone backup-health page. Rejected because it does not solve the tenant-dashboard truth gap.
|
||||
- Defer backup health until a full recovery-confidence initiative. Rejected because the current dashboard already needs a narrower truth fix.
|
||||
|
||||
## Decision 7: Keep drillthrough reason-driven and use the least surprising existing surface for each reason
|
||||
|
||||
- Decision: Use reason-driven drillthroughs. `no_backup_basis` opens the backup-set list, `latest_backup_stale` and `latest_backup_degraded` open the latest relevant backup-set detail, and `schedule_follow_up` opens the backup-schedules list as the primary confirmation surface.
|
||||
- Rationale: These destinations already exist and are tenant-scoped. The backup-set detail can confirm stale or degraded latest-basis truth through recency and backup-quality summary. The schedule list is safer than an edit screen as the first follow-up destination and already shows last-run and next-run timing.
|
||||
- Alternatives considered:
|
||||
- Send every backup-health state to the backup-set list. Rejected because it weakens reason continuity for degraded latest-backup scenarios.
|
||||
- Send schedule follow-up directly to edit pages. Rejected because the first operator need is confirmation, not mutation.
|
||||
|
||||
## Decision 8: Add only the minimum continuity hardening needed on target surfaces
|
||||
|
||||
- Decision: Reuse the current backup-set detail and list surfaces for stale or degraded continuity and add one minimal schedule-follow-up confirmation signal on the backup-schedules list so the current timestamp columns remain scan-fast enough by themselves.
|
||||
- Rationale: Spec 176 already moved backup quality into backup surfaces. This slice should not rebuild those surfaces again; it should only ensure the dashboard reason can be rediscovered quickly.
|
||||
- Alternatives considered:
|
||||
- Add a banner framework or page-level explanation system. Rejected because it would overgrow the slice.
|
||||
- Leave continuity entirely to raw timestamps. Rejected because schedule follow-up may be too implicit at scan speed.
|
||||
|
||||
## Decision 9: Extend existing widget and dashboard truth tests before introducing new test harnesses
|
||||
|
||||
- Decision: Extend `DashboardKpisWidgetTest`, `NeedsAttentionWidgetTest`, `TenantDashboardTruthAlignmentTest`, and existing backup or schedule feature tests, and add one narrow unit test file for the resolver.
|
||||
- Rationale: The affected behavior is server-driven widget and resource truth, which the current Pest and Livewire suite already covers well.
|
||||
- Alternatives considered:
|
||||
- Rely only on manual validation. Rejected because the feature is specifically about preventing subtle trust regressions.
|
||||
- Add a large browser-only pack. Rejected because the highest-value assertions are deterministic server-side state and rendered truth.
|
||||
@ -1,267 +0,0 @@
|
||||
# Feature Specification: Tenant Backup Health Signals
|
||||
|
||||
**Feature Branch**: `180-tenant-backup-health`
|
||||
**Created**: 2026-04-07
|
||||
**Status**: Proposed
|
||||
**Input**: User description: "Spec 180 — Tenant Backup Health Signals"
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: tenant
|
||||
- **Primary Routes**:
|
||||
- `/admin/t/{tenant}` as the tenant dashboard where `DashboardKpis` and `NeedsAttention` currently establish the first tenant-level posture impression
|
||||
- `/admin/t/{tenant}/backup-sets` and `/admin/t/{tenant}/backup-sets/{record}` as the primary backup truth surfaces for recentness, degradation, and latest-backup follow-up
|
||||
- `/admin/t/{tenant}/backup-schedules` as the primary schedule follow-up confirmation surface when automation exists but does not appear to be running successfully, with `/admin/t/{tenant}/backup-schedules/{record}/edit` remaining a secondary maintenance surface when configuration changes are needed
|
||||
- **Data Ownership**:
|
||||
- Tenant-owned `BackupSet`, `BackupItem`, and existing backup-quality metadata remain the source of truth for whether a usable recent backup basis exists and whether the latest relevant backup is degraded
|
||||
- Tenant-owned `BackupSchedule` remains the source of truth for schedule presence, last successful run timing, and next-run follow-up signals
|
||||
- Tenant dashboard backup health remains a derived tenant summary over those existing tenant-owned records; this feature introduces no new persisted tenant-health record, score table, or confidence ledger
|
||||
- **RBAC**:
|
||||
- Workspace membership plus tenant entitlement remain required to view the tenant dashboard and every backup follow-up destination
|
||||
- Existing backup and backup-schedule viewing permissions remain the enforcement source for drill-through destinations; this feature must not introduce raw capability checks or new role semantics
|
||||
- Tenant dashboard viewers must still receive truthful tenant-level backup-health signals even when a deeper backup destination is unavailable; in that case the signal may remain visible but the affordance must degrade safely rather than becoming a dead-end link
|
||||
|
||||
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Surface Type | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Tenant dashboard backup health summary | Embedded status summary / drill-in surface | One backup-health stat or card opens one matching backup follow-up destination for the strongest current reason | forbidden | none | none | `/admin/t/{tenant}/backup-sets` or `/admin/t/{tenant}/backup-schedules` depending on the reason | `/admin/t/{tenant}/backup-sets/{record}` when the latest relevant backup record is the clearest destination | Active tenant context remains visible on the dashboard and on every destination | Backup health / Backup | Whether the tenant has no usable backup basis, a stale basis, a degraded latest basis, or a healthy recent basis | Dashboard summary exemption |
|
||||
| Tenant dashboard `Needs Attention` backup item | Embedded attention summary | One attention item opens one matching backup or schedule follow-up destination | forbidden | none | none | `/admin/t/{tenant}/backup-sets` or `/admin/t/{tenant}/backup-schedules` depending on the reason | `/admin/t/{tenant}/backup-sets/{record}` when the attention reason is tied to the latest relevant backup set | Active tenant context plus reason-specific copy must stay visible before navigation | Backup health / Backup | The strongest backup problem class and the next place to inspect it | Multi-destination summary item |
|
||||
| Backup sets page | CRUD / list-first resource | Full-row click to the backup-set detail page | required | Existing inline safe shortcuts and More menu remain unchanged | Existing destructive actions remain grouped under existing More placement | `/admin/t/{tenant}/backup-sets` | `/admin/t/{tenant}/backup-sets/{record}` | Tenant context plus backup quality and recency context keep the list anchored to the current tenant | Backup sets / Backup set | Which backup set is the current basis and whether it is recent or degraded enough to explain dashboard posture | none |
|
||||
| Backup schedules page | CRUD / list-first resource | Record confirmation happens on the existing schedule list; edit remains secondary when maintenance is needed | required | Existing inline safe shortcuts and More menu remain unchanged | Existing destructive actions remain grouped under existing More placement | `/admin/t/{tenant}/backup-schedules` | `/admin/t/{tenant}/backup-schedules/{record}/edit` | Tenant context plus schedule timing and success context keep schedule follow-up anchored to the current tenant | Backup schedules / Backup schedule | Whether configured schedules are actually running often enough to support calm automation assumptions | none |
|
||||
|
||||
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| Tenant dashboard backup health summary | Tenant operator | Embedded status summary / drill-in surface | Are this tenant's backups recent and usable enough that I should feel calm, or do I need to follow up right now? | Backup-health class, last relevant backup timing, concise reason, and one matching next destination | Per-item degradation families, raw metadata, and restore detail remain secondary | backup existence, recency, backup quality, schedule follow-up | none | Open backup sets or backup schedules based on the current reason | none |
|
||||
| Tenant dashboard `Needs Attention` backup item | Tenant operator | Embedded attention summary | Why is backup posture weak right now, and where should I click next? | One reason-focused attention item such as no backups, stale backup, degraded latest backup, or schedule needs follow-up | Deep per-item diagnostics, full history, and raw schedule metadata remain secondary | backup absence, stale posture, degraded posture, schedule follow-up | none | Open the matching follow-up surface for the named reason | none |
|
||||
| Backup sets page | Tenant operator | List / detail | Which backup set is the relevant current basis, and does it confirm the dashboard warning or healthy claim? | Backup-set identity, recency, lifecycle, and quality summary that lets the operator recover the same problem class | Raw item metadata, deep assignment or payload diagnostics, and restore-specific detail remain secondary | capture lifecycle, recency, backup quality | TenantPilot-only existing backup maintenance remains unchanged and secondary to inspection | Open backup set, inspect latest relevant record | Existing archive, restore, or force-delete actions remain unchanged |
|
||||
| Backup schedules page | Tenant operator | List / edit | Is backup automation configured and actually running often enough, or does it need follow-up? | Schedule timing, last-success context, and overdue or missed-run context that confirms schedule follow-up | Low-level schedule configuration detail and related run history remain secondary | schedule presence, schedule freshness, schedule execution follow-up | TenantPilot-only existing schedule maintenance remains unchanged and secondary to inspection | Open the relevant backup schedule | Existing delete or maintenance actions remain unchanged |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: No. Existing `BackupSet`, `BackupItem`, existing backup-quality summaries, and existing `BackupSchedule` timing remain authoritative.
|
||||
- **New persisted entity/table/artifact?**: No. This slice explicitly forbids a new persisted backup-health table, score, or tenant-confidence ledger.
|
||||
- **New abstraction?**: Yes. A narrow derived tenant-level backup-health rollup is justified so the tenant dashboard can present one truthful tenant-level answer instead of forcing operators into multiple deep surfaces.
|
||||
- **New enum/state/reason family?**: Yes, but derived only. The feature needs a small tenant backup-health posture family such as `absent`, `stale`, `degraded`, and `healthy`, plus reason-level follow-up signals such as `no_backup_basis`, `latest_backup_stale`, `latest_backup_degraded`, and `schedule_follow_up`.
|
||||
- **New cross-domain UI framework/taxonomy?**: No. This is a tenant backup hardening slice only, not a new portfolio posture framework or recovery taxonomy.
|
||||
- **Current operator problem**: The tenant dashboard can currently look operationally healthy while the tenant's backup posture is weak, stale, degraded, or simply missing, which means the overview hides a recovery-relevant truth that operators need immediately.
|
||||
- **Existing structure is insufficient because**: Backup-quality truth already exists deeper in backup-set, version, and restore-adjacent surfaces, but there is no tenant-level rollup that answers the operator's first question on the tenant dashboard.
|
||||
- **Narrowest correct implementation**: Derive tenant backup health from the latest relevant completed backup basis, existing backup-quality truth, and existing backup-schedule timing, then inject that derived truth into the current tenant dashboard and attention surfaces without adding new persistence or a broader recovery-confidence system.
|
||||
- **Ownership cost**: The repo takes on one small rollup layer, one small derived posture family, dashboard and drill-through copy alignment, and regression coverage for absent, stale, degraded, healthy, and schedule-follow-up scenarios.
|
||||
- **Alternative intentionally rejected**: A full recovery-confidence framework, restore-proving system, workspace-level recovery score, or new persisted backup-health model was rejected because it solves a larger future problem than the one the current tenant dashboard actually has.
|
||||
- **Release truth**: Current-release truth. The false calmness already exists on the current tenant dashboard.
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - See Backup Posture Immediately (Priority: P1)
|
||||
|
||||
As a tenant operator, I want the tenant dashboard to tell me within seconds whether this tenant has no usable backups, stale backups, degraded latest backups, or healthy recent backups so that I do not have to open backup-set detail just to know whether backup posture needs attention.
|
||||
|
||||
**Why this priority**: This is the operator's first recovery-relevant question on the tenant dashboard. If the page stays quiet while backup posture is weak, the entire overview becomes less trustworthy.
|
||||
|
||||
**Independent Test**: Can be fully tested by seeding one tenant with no backups, stale backups, degraded latest backups, and fresh healthy backups, then verifying that the tenant dashboard surfaces the correct posture class on a primary summary surface.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a tenant has no usable completed backup basis, **When** an entitled operator opens the tenant dashboard, **Then** the dashboard explicitly shows that backup posture needs attention because no usable backup basis exists.
|
||||
2. **Given** a tenant has a latest relevant completed backup that is older than the accepted freshness window, **When** the tenant dashboard renders, **Then** the dashboard surfaces a stale-backup state instead of a calm or healthy backup message.
|
||||
3. **Given** a tenant has a latest relevant completed backup that is recent but materially degraded, **When** the tenant dashboard renders, **Then** the dashboard surfaces a degraded-backup state instead of a healthy backup message.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Click The Warning And Recover The Same Reason (Priority: P1)
|
||||
|
||||
As a tenant operator, I want every backup-health KPI, card, or attention item to send me to a surface that confirms the same problem family I clicked, so that the dashboard feels truthful instead of hand-wavy.
|
||||
|
||||
**Why this priority**: Dashboard trust breaks immediately if the operator clicks a backup warning and lands on a neutral or mismatched target page.
|
||||
|
||||
**Independent Test**: Can be fully tested by clicking backup-health summary and attention states in seeded scenarios and verifying that the destination clearly confirms the same problem family through recency, degradation, or schedule timing context.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the dashboard shows a stale-backup warning, **When** the operator opens the linked destination, **Then** the destination visibly confirms that the latest relevant backup basis is stale.
|
||||
2. **Given** the dashboard shows a degraded-latest-backup warning, **When** the operator opens the linked destination, **Then** the destination visibly confirms that the latest relevant backup basis carries the degradation.
|
||||
3. **Given** the dashboard shows a schedule-follow-up warning, **When** the operator opens the linked destination, **Then** the destination visibly confirms that schedule execution timing needs follow-up.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Trust Positive Backup Calmness Only When Earned (Priority: P2)
|
||||
|
||||
As a tenant operator, I want the tenant dashboard to show a positive backup-health message only when the available signals actually support it, so that a green or calm backup state does not overpromise recoverability.
|
||||
|
||||
**Why this priority**: Positive wording is more dangerous than negative wording here. A false healthy signal can make the operator skip backup follow-up entirely.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering the tenant dashboard for one fresh healthy scenario and several almost-healthy scenarios, then verifying that only the fully supported case emits a positive backup-health statement.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a tenant has a recent relevant completed backup with no material degradation and no stronger backup-health caution, **When** the tenant dashboard renders, **Then** a positive backup-health confirmation may appear.
|
||||
2. **Given** a tenant has a recent backup but the latest relevant backup is materially degraded, **When** the tenant dashboard renders, **Then** no positive backup-health confirmation appears.
|
||||
3. **Given** a tenant has a configured schedule but no recent successful backup basis, **When** the tenant dashboard renders, **Then** schedule presence does not produce a positive backup-health confirmation.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Preserve Truth Under Schedule And Permission Nuance (Priority: P3)
|
||||
|
||||
As a tenant operator, I want backup-health summary truth to remain accurate even when schedules exist, older good backups exist, or I cannot open every downstream surface, so that tenant-level truth does not become calmer under edge conditions or RBAC boundaries.
|
||||
|
||||
**Why this priority**: The feature only improves trust if the tenant-level rollup stays stronger than schedule optimism, older-history optimism, or permission gaps.
|
||||
|
||||
**Independent Test**: Can be fully tested by seeding tenants with mixed backup history, schedule-follow-up conditions, and reduced downstream visibility, then verifying that the tenant dashboard still reflects the strongest truthful backup-health state.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an older healthy backup exists but the latest relevant completed backup is degraded, **When** the dashboard renders, **Then** the tenant is still shown as degraded rather than healthy.
|
||||
2. **Given** a tenant dashboard viewer can see the dashboard but lacks one downstream destination capability, **When** the backup-health summary renders, **Then** the truth remains visible and the affordance degrades safely instead of becoming a dead-end link.
|
||||
3. **Given** a configured schedule exists but has not run successfully in an expected interval, **When** the dashboard renders, **Then** the tenant may receive schedule follow-up attention without the schedule being treated as proof of healthy backup posture.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- Backup history may exist without any completed backup set that can serve as a usable tenant backup basis; the dashboard must not treat mere backup records as healthy backup posture.
|
||||
- The latest relevant completed backup may be degraded even when an older backup looks healthier; the latest relevant completed backup must govern the tenant posture instead of allowing older history to calm the dashboard.
|
||||
- A backup schedule may exist and even have a future `next_run_at`, while the last successful backup basis is already stale; the tenant posture must still remain stale or otherwise attention-worthy.
|
||||
- Multiple schedules may exist for one tenant; schedule follow-up should remain additive and must not erase stronger absent, stale, or degraded backup-health reasons.
|
||||
- Legacy or incomplete backup metadata may be insufficient to positively prove that the latest relevant backup is healthy; in that case the dashboard must avoid a positive healthy claim.
|
||||
- A tenant dashboard viewer may be entitled to summary truth but not to every backup destination; summary truth must remain visible while navigation degrades safely.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
**Constitution alignment (required):** This feature introduces no new Microsoft Graph calls, no new write workflow, and no new queued or scheduled execution path. It hardens tenant overview truth by reusing already-existing tenant-owned backup and schedule records.
|
||||
|
||||
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** A narrow derived tenant backup-health rollup and a small derived posture family are justified because direct backup existence, direct schedule presence, or direct backup-quality detail alone do not answer the tenant dashboard question truthfully. The slice must remain derived-first, must not persist a second backup-health truth, and must avoid a broader recovery-confidence framework.
|
||||
|
||||
**Constitution alignment (OPS-UX):** No new `OperationRun` type, progress surface, or execution flow is introduced. Existing backup schedules and backup runs remain the only execution-truth surfaces for actual backup activity. This slice only summarizes and links to those existing truths.
|
||||
|
||||
**Constitution alignment (RBAC-UX):** The feature lives in the tenant/admin plane under `/admin/t/{tenant}/...`. Non-members remain `404`. In-scope members who can see the tenant dashboard but lack one deeper destination capability must still receive truthful backup-health summary state, while the drill-through affordance degrades safely or uses an allowed fallback. Authorization for downstream destinations remains server-side and must continue to use the canonical capability registry and existing scoped record resolution. No destructive action is added.
|
||||
|
||||
**Constitution alignment (OPS-EX-AUTH-001):** Not applicable. No authentication-handshake behavior changes.
|
||||
|
||||
**Constitution alignment (BADGE-001):** Existing centralized badge and status semantics for backup lifecycle, snapshot quality, and related status-like signals remain the semantic source. This feature may add backup-health wording or grouping, but it must not introduce page-local color or badge mappings that create a second backup status language.
|
||||
|
||||
**Constitution alignment (UI-FIL-001):** The feature reuses existing Filament dashboard widgets, stats, cards, alerts, resource tables, and shared UI primitives. Semantic emphasis must come from aligned wording and existing shared status primitives rather than custom local markup or ad-hoc color borders.
|
||||
|
||||
**Constitution alignment (UI-NAMING-001):** Operator-facing vocabulary must remain explicit and bounded to `Backup health`, `Last backup`, `No backups`, `Backup stale`, `Backup degraded`, `Schedule needs follow-up`, and `Backups are recent and healthy` or closely equivalent wording. The feature must not rename this slice into `recovery confidence`, `recoverable`, `proven`, or other stronger claims.
|
||||
|
||||
**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001):** The tenant dashboard backup-health summary is an embedded drill-in surface with one primary destination per current reason. `NeedsAttention` remains a multi-destination summary surface with one reason-focused destination per item. `BackupSetResource` remains the canonical backup inspection surface, and `BackupScheduleResource` remains the canonical schedule follow-up surface. No redundant `View` actions are added, and no destructive placement changes are introduced.
|
||||
|
||||
**Constitution alignment (OPSURF-001):** Default-visible content on the tenant dashboard must answer the operator's backup question within 5 to 10 seconds. Deep diagnostics such as per-item degradation causes, raw payload truth, and long schedule histories remain secondary to the default-visible backup-health class and the next destination.
|
||||
|
||||
**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** Direct mapping from `backup exists` or `schedule exists` to calm dashboard wording is insufficient. This feature may introduce one narrow derived tenant backup-health interpretation layer, but only to replace weaker widget-local calmness checks and to keep dashboard truth aligned with deeper backup-quality truth. Tests must focus on the business consequences: absent, stale, degraded, healthy, schedule-follow-up, and drill-through continuity.
|
||||
|
||||
**Constitution alignment (Filament Action Surfaces):** The Action Surface Contract remains satisfied for `BackupSetResource` and `BackupScheduleResource`; their existing inspect models, row-click behavior, and destructive placement remain unchanged. `TenantDashboard` and its widgets remain dashboard summary surfaces covered by the existing dashboard exemption, with no new destructive action, no empty action groups, and no redundant `View` affordances. UI-FIL-001 remains satisfied and no new exception is required.
|
||||
|
||||
**Constitution alignment (UX-001 — Layout & Information Architecture):** This feature does not add new create or edit flows. It refines the tenant dashboard summary area and existing backup follow-up surfaces. Backup health must appear in the primary tenant-summary zone rather than only in deep diagnostics. Existing backup-set and backup-schedule list screens must retain specific empty states and current table affordances while making the dashboard reason recoverable.
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-180-001**: The system MUST derive an explicit tenant-level backup-health assessment from existing tenant-owned backup and schedule records rather than leaving backup posture implicit in deep backup pages.
|
||||
- **FR-180-002**: The tenant-level backup-health assessment MUST determine whether a usable completed backup basis exists, which backup basis is currently relevant, when that basis last completed, whether it is fresh enough, whether it is materially degraded, and whether schedule timing adds follow-up pressure.
|
||||
- **FR-180-003**: The latest relevant completed backup basis MUST be the primary basis for tenant backup-health posture. Older healthier backups MUST NOT override a newer relevant stale or degraded backup basis.
|
||||
- **FR-180-004**: Tenant backup-health summary surfaces MUST distinguish at least `absent`, `stale`, `degraded`, and `healthy` as primary posture classes.
|
||||
- **FR-180-005**: `No backup` or `no usable completed backup basis` MUST remain a first-class attention state and MUST NOT disappear into neutral empty states.
|
||||
- **FR-180-006**: Backup freshness semantics MUST be defined once and used consistently across the tenant dashboard summary, `NeedsAttention`, and any positive healthy backup confirmation.
|
||||
- **FR-180-007**: Tenant backup-health degradation MUST be derived from existing authoritative backup-quality truth and MUST NOT invent a competing backup-quality system.
|
||||
- **FR-180-008**: Material degradation on the latest relevant completed backup basis MUST suppress healthy backup wording and MUST be sufficient to put tenant backup health into attention. If the latest relevant completed backup basis is both stale and materially degraded, `stale` MUST remain the primary posture while degradation remains visible as supporting detail.
|
||||
- **FR-180-009**: A configured backup schedule alone MUST NOT count as proof of healthy backup posture.
|
||||
- **FR-180-010**: Schedule state MAY add a `schedule_follow_up` reason when configured automation appears overdue or no longer successful, but it MUST complement rather than replace real backup-basis truth. When `schedule_follow_up` is the only remaining caution, the latest backup basis MAY keep `healthy` as its primary posture, but `schedule_follow_up` MUST become the active reason and any positive healthy confirmation MUST remain suppressed until the follow-up resolves.
|
||||
- **FR-180-011**: The tenant dashboard MUST expose backup health on a primary summary surface such as a KPI, stat, or summary card rather than only inside backup-set detail.
|
||||
- **FR-180-012**: `NeedsAttention` MUST be able to surface backup-health attention for at least no usable backup basis, stale latest backup basis, degraded latest backup basis, and schedule follow-up.
|
||||
- **FR-180-013**: A positive backup-health message may appear only when the latest relevant completed backup basis exists, satisfies the defined freshness rule, shows no material degradation under existing backup-quality truth, and no stronger backup-health caution remains unresolved.
|
||||
- **FR-180-014**: If existing signals cannot positively prove that the latest relevant backup basis is healthy, the system MUST avoid calm or healthy backup wording.
|
||||
- **FR-180-015**: Backup-health summary surfaces MUST make the current problem class visible to the operator, not just a generic `attention needed` state.
|
||||
- **FR-180-016**: Every backup-health KPI, summary, or attention item that implies follow-up MUST resolve to one semantically matching destination surface where the operator can recover the same problem class without guesswork.
|
||||
- **FR-180-017**: When the matching destination is backup-basis related, the destination MUST preserve or foreground the latest relevant backup basis so that the dashboard reason remains recognizable.
|
||||
- **FR-180-018**: When the matching destination is schedule related, the destination MUST foreground the schedule timing or missed-run reason rather than forcing the operator to infer it from generic schedule metadata.
|
||||
- **FR-180-019**: Summary surfaces on the tenant dashboard MUST NOT appear calmer than the underlying backup-set and backup-quality detail surfaces.
|
||||
- **FR-180-020**: The feature MUST NOT claim that the tenant is recoverable, that restore will succeed, or that backup posture proves recovery confidence.
|
||||
- **FR-180-021**: Tenant-scoped backup-health truth MUST remain visible and accurate for entitled tenant-dashboard users even when not every deeper backup surface is accessible; navigation must degrade safely instead of hiding the truth.
|
||||
- **FR-180-022**: The feature MUST ship without a new table, a persisted backup-health model, a tenant-wide recovery score, or a workspace-level recovery rollup.
|
||||
- **FR-180-023**: Regression coverage MUST prove no-backup, stale-backup, degraded-latest-backup, healthy-backup, schedule-follow-up, mixed-history latest-governs behavior, dashboard surfacing, attention surfacing, healthy-check suppression and allowance, drill-through continuity, and RBAC-safe degradation.
|
||||
|
||||
### Derived State Semantics
|
||||
|
||||
- **Relevant backup basis**: The latest tenant-scoped completed backup set that the product treats as the primary current backup-health basis for the tenant. Backup records that never reached a usable completed state do not qualify as healthy proof.
|
||||
- **Primary posture family**: `absent`, `stale`, `degraded`, `healthy`.
|
||||
- **Reason family**: `no_backup_basis`, `latest_backup_stale`, `latest_backup_degraded`, `schedule_follow_up`. The reason family explains why the posture is not calm or why follow-up still matters, and `schedule_follow_up` may remain the active reason even when the backup basis posture itself is `healthy`.
|
||||
- **Freshness policy**: One consistent freshness window over the latest relevant completed backup basis determines whether backup posture is recent enough. Schedule timing may add follow-up pressure but cannot turn a stale or missing backup basis into a healthy posture.
|
||||
- **Healthy evidence rule**: `healthy` describes the state of the latest relevant completed backup basis. A positive healthy confirmation is reserved for tenants whose latest relevant completed backup basis exists, is recent enough, is not materially degraded under existing backup-quality truth, and carries no unresolved `schedule_follow_up` or other stronger backup-health caution.
|
||||
|
||||
## UI Action Matrix *(mandatory when Filament is changed)*
|
||||
|
||||
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Tenant dashboard page composition | `app/Filament/Pages/TenantDashboard.php` | Existing tenant dashboard header actions remain unchanged | n/a | n/a | n/a | n/a | n/a | n/a | no new audit behavior | Composition-only dashboard surface. Backup health becomes a primary summary truth but the existing dashboard action-surface exemption remains in place. |
|
||||
| `DashboardKpis` | `app/Filament/Widgets/Dashboard/DashboardKpis.php` | none | One explicit stat or card click for actionable backup-health states | none | none | Any non-actionable healthy reassurance remains intentionally bounded and must not overpromise recoverability | n/a | n/a | no new audit behavior | One primary destination per backup-health reason. No local recovery-confidence wording. |
|
||||
| `NeedsAttention` | `app/Filament/Widgets/Dashboard/NeedsAttention.php` | none | One explicit destination or safe disabled state per backup-health attention item | none | none | Healthy fallback may include positive backup-health copy only when no covered backup-health attention state exists | n/a | n/a | no new audit behavior | Multi-destination summary widget. Backup-health item joins existing attention logic without adding destructive controls. |
|
||||
| `BackupSetResource` | `app/Filament/Resources/BackupSetResource.php` | Existing `Create backup set` header action remains unchanged | `recordUrl()` clickable row to backup-set detail | Existing row actions remain unchanged | Existing grouped bulk actions remain unchanged | Existing empty-state CTA remains unchanged | Existing detail header actions remain unchanged | Existing create flow remains unchanged | existing audit behavior remains authoritative for existing mutations | Target surface may gain reason-confirming framing for last-backup, stale, or degraded continuity only. The action-surface contract remains satisfied. |
|
||||
| `BackupScheduleResource` | `app/Filament/Resources/BackupScheduleResource.php` | Existing schedule-create header action remains unchanged | Existing schedule list inspect or edit affordance remains the primary open model | Existing row actions remain unchanged | Existing grouped bulk actions remain unchanged | Existing empty-state CTA remains unchanged | Existing edit header actions remain unchanged | Existing create and edit save or cancel remain unchanged | existing audit behavior remains authoritative for existing mutations | Target surface may foreground schedule follow-up timing only. Schedule presence itself must not be styled as health proof. |
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **Tenant backup-health assessment**: The derived tenant-level answer to whether the tenant currently has no usable backup basis, a stale basis, a degraded latest basis, or a healthy recent basis.
|
||||
- **Relevant backup basis**: The latest completed backup set that counts as the current tenant backup-health basis and whose recency and quality govern the dashboard posture.
|
||||
- **Backup schedule follow-up**: A tenant-level caution that configured backup automation appears overdue or no longer successfully running and therefore needs operator review.
|
||||
- **Backup-health drill-through contract**: The semantic promise that a dashboard warning or healthy statement can be rediscovered on its destination surface without changing problem class.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-180-001**: In seeded tenant review and acceptance coverage, an entitled operator can determine within 10 seconds whether a tenant is in a no-backup, stale-backup, degraded-latest-backup, or healthy-backup posture.
|
||||
- **SC-180-002**: In 100% of covered regression scenarios, no-backup, stale-backup, degraded-latest-backup, fresh-healthy-backup, and schedule-follow-up cases map to the correct tenant-dashboard summary and attention behavior without contradictory calm wording.
|
||||
- **SC-180-003**: In 100% of covered regression scenarios, positive backup-health wording appears only when the latest relevant completed backup basis is recent enough, not materially degraded, and not superseded by a stronger backup-health caution.
|
||||
- **SC-180-004**: In 100% of covered drill-through tests, backup-health KPI or attention links land on a surface whose default-visible framing confirms the originating problem class.
|
||||
- **SC-180-005**: In RBAC regression coverage, entitled tenant-dashboard users continue to see truthful backup-health summary state even when at least one deeper destination is unavailable, and the UI degrades safely without broken or misleading links.
|
||||
- **SC-180-006**: The feature ships without a required schema migration, a new persisted backup-health model, or a new tenant-wide or workspace-wide recovery-confidence score.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Existing `BackupSet`, `BackupItem`, backup-quality summary, and `BackupSchedule` timing fields are sufficient to derive a truthful tenant backup-health rollup without introducing new persistence.
|
||||
- Existing backup-set and backup-schedule surfaces remain the correct destinations for dashboard backup-health drill-through.
|
||||
- Older legacy records may not always contain enough metadata to prove a positive healthy posture; in those cases the product should stay non-calm rather than infer health.
|
||||
- The current tenant dashboard composition remains in place for this slice; the work changes truth visibility and continuity, not the broader dashboard layout.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Building a full recovery-confidence or proved-recoverability framework
|
||||
- Using restore history as the primary basis of tenant backup-health truth
|
||||
- Introducing workspace-level or portfolio-level recovery posture rollups
|
||||
- Creating a new persisted backup-health table, score, or ledger
|
||||
- Reworking backup-quality detail semantics that were already hardened in prior backup-quality work
|
||||
- Redesigning restore safety or restore result truth beyond the minimum truth-boundary wording needed here
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Existing `TenantDashboard`, `DashboardKpis`, and `NeedsAttention` tenant overview surfaces
|
||||
- Existing `BackupSet`, `BackupItem`, backup-quality summary, and related backup-quality truth work
|
||||
- Existing `BackupSchedule` resource, schedule timing fields, and schedule follow-up surfaces
|
||||
- Existing tenant-scoped RBAC and safe drill-through behavior for backup resources
|
||||
|
||||
## Risks
|
||||
|
||||
- If the tenant backup-health rollup is weaker than the underlying backup-quality truth, the dashboard will remain calmer than the detail surfaces.
|
||||
- If schedule-follow-up is treated as health proof instead of as a secondary caution, the dashboard can still overstate calmness.
|
||||
- If the latest relevant backup basis is not consistently used, older healthier history may hide a newer degraded or stale backup posture.
|
||||
- If healthy wording is allowed when evidence is incomplete, the feature will recreate the same trust problem with nicer copy.
|
||||
|
||||
## Follow-up Spec Candidates
|
||||
|
||||
- Recovery confidence or proved-recoverability work after stronger restore evidence exists
|
||||
- Workspace or portfolio backup-posture rollups after tenant backup health is stable and tenant-safe
|
||||
- Backup and restore continuity work that combines backup-health truth with later restore-evidence truth without overclaiming recovery
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Spec 180 is complete when:
|
||||
|
||||
- a tenant-level backup-health derivation exists over current backup and schedule truth,
|
||||
- the tenant dashboard shows backup health on a primary summary surface,
|
||||
- `NeedsAttention` can surface no-backup, stale-backup, degraded-latest-backup, and schedule-follow-up conditions,
|
||||
- positive backup-health wording appears only when supported by current evidence,
|
||||
- no-backup, stale, degraded, and healthy states are clearly distinguishable,
|
||||
- drill-through destinations confirm the same backup-health problem class,
|
||||
- RBAC-safe summary truth remains intact for entitled tenant-dashboard viewers,
|
||||
- and the semantics are protected by focused resolver, dashboard, attention, healthy-state, drill-through, and RBAC regression tests.
|
||||
|
||||
@ -1,250 +0,0 @@
|
||||
# Tasks: Tenant Backup Health Signals
|
||||
|
||||
**Input**: Design documents from `/specs/180-tenant-backup-health/`
|
||||
**Prerequisites**: `plan.md` (required), `spec.md` (required for user stories), `research.md`, `data-model.md`, `contracts/`, `quickstart.md`
|
||||
|
||||
**Tests**: Tests are REQUIRED for this feature. Use focused Pest coverage in `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`, `tests/Feature/Filament/DashboardKpisWidgetTest.php`, `tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`, `tests/Feature/Filament/TenantDashboardTenantScopeTest.php`, `tests/Feature/Filament/TenantDashboardDbOnlyTest.php`, `tests/Feature/Filament/BackupSetListContinuityTest.php`, `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`, and `tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php`.
|
||||
**Operations**: No new `OperationRun`, queue, or scheduled execution flow is introduced. Work stays limited to read-time tenant dashboard truth and existing backup or schedule follow-up surfaces.
|
||||
**RBAC**: Existing workspace membership, tenant entitlement, capability-registry usage, and `404` vs `403` semantics must remain unchanged across `/admin/t/{tenant}`, `/admin/t/{tenant}/backup-sets`, and `/admin/t/{tenant}/backup-schedules`. Tests must cover both positive and negative access paths plus safe degradation when an action target is unavailable.
|
||||
**Operator Surfaces**: The tenant dashboard must expose backup posture in the primary summary zone, `NeedsAttention` must show reason-specific backup follow-up, and backup-set or schedule destinations must make the clicked reason recognizable without forcing the operator into raw diagnostics first.
|
||||
**Filament UI Action Surfaces**: `DashboardKpis` and `NeedsAttention` remain summary-only surfaces with one primary reason-driven destination; `BackupSetResource` and `BackupScheduleResource` keep their current inspect models, row-click behavior, and destructive placement unchanged.
|
||||
**Filament UI UX-001**: No new create or edit flow is introduced. The work is limited to summary-first truth on the existing dashboard and list or detail surfaces.
|
||||
**Badges**: Reuse existing shared badge or tone primitives if backup-health tone mapping is needed; do not add page-local semantic mappings in widgets or resources.
|
||||
|
||||
**Organization**: Tasks are grouped by user story so each story can be implemented and validated as an independent increment after the shared backup-health scaffolding is in place.
|
||||
|
||||
## Phase 1: Setup (Shared Backup-Health Scaffolding)
|
||||
|
||||
**Purpose**: Add the narrow derived backup-health types and configuration used by every story.
|
||||
|
||||
- [X] T001 Create the shared backup-health value objects in `app/Support/BackupHealth/TenantBackupHealthAssessment.php`, `app/Support/BackupHealth/BackupFreshnessEvaluation.php`, `app/Support/BackupHealth/BackupScheduleFollowUpEvaluation.php`, `app/Support/BackupHealth/BackupHealthActionTarget.php`, and `app/Support/BackupHealth/BackupHealthDashboardSignal.php`
|
||||
- [X] T002 Create the central backup-health resolver skeleton in `app/Support/BackupHealth/TenantBackupHealthResolver.php`
|
||||
- [X] T003 [P] Add unit test scaffolding for the new backup-health namespace in `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`
|
||||
- [X] T004 [P] Add explicit backup-health freshness and schedule grace configuration in `config/tenantpilot.php`
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational (Blocking Shared Wiring)
|
||||
|
||||
**Purpose**: Wire the shared derivation contract before any story-specific dashboard or continuity behavior lands.
|
||||
|
||||
**⚠️ CRITICAL**: No user story work should begin until this phase is complete.
|
||||
|
||||
- [X] T005 Implement query-bounded latest-basis selection, `BackupQualityResolver`-backed degradation reuse, posture precedence, schedule-follow-up derivation, and reason target selection in `app/Support/BackupHealth/TenantBackupHealthResolver.php`
|
||||
- [X] T006 [P] Extend core resolver coverage for absent, stale, degraded, healthy, stale-over-degraded precedence, mixed-history latest-governs, `BackupQualityResolver`-backed degradation reuse, and schedule-follow-up behavior in `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`
|
||||
- [X] T007 Add shared backup-health loading helpers and dashboard-signal adapters for dashboard widgets in `app/Filament/Widgets/Dashboard/DashboardKpis.php` and `app/Filament/Widgets/Dashboard/NeedsAttention.php`
|
||||
- [X] T008 [P] Extend DB-only and query-bounded tenant dashboard guard coverage for backup-health rendering in `tests/Feature/Filament/TenantDashboardDbOnlyTest.php`
|
||||
|
||||
**Checkpoint**: The repository has one authoritative derived backup-health contract that dashboard and follow-up surfaces can consume without new persistence.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 - See Backup Posture Immediately (Priority: P1) 🎯 MVP
|
||||
|
||||
**Goal**: Show absent, stale, degraded, or healthy backup posture on the tenant dashboard's primary summary surface.
|
||||
|
||||
**Independent Test**: Seed one tenant each for no usable backup basis, stale latest backup, degraded latest backup, and fresh healthy backup, then verify the tenant dashboard renders the correct primary backup-health posture without opening deeper pages.
|
||||
|
||||
### Tests for User Story 1
|
||||
|
||||
- [X] T009 [P] [US1] Extend primary backup-health posture coverage in `tests/Feature/Filament/DashboardKpisWidgetTest.php`
|
||||
- [X] T010 [P] [US1] Extend tenant dashboard calmness-versus-caution coverage for backup-health summary states in `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [X] T011 [US1] Render the primary backup-health stat or card with posture, last relevant backup timing, and bounded summary copy in `app/Filament/Widgets/Dashboard/DashboardKpis.php`
|
||||
- [X] T012 [US1] Keep summary wording aligned to `absent`, `stale`, `degraded`, and `healthy` semantics in `app/Support/BackupHealth/TenantBackupHealthAssessment.php` and `app/Filament/Widgets/Dashboard/DashboardKpis.php`
|
||||
- [X] T013 [US1] Run the focused dashboard posture verification pack from `specs/180-tenant-backup-health/quickstart.md` against `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`, `tests/Feature/Filament/DashboardKpisWidgetTest.php`, `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`, and `tests/Feature/Filament/TenantDashboardDbOnlyTest.php`
|
||||
|
||||
**Checkpoint**: The tenant dashboard now answers the backup-health question within seconds on a primary summary surface.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 - Click The Warning And Recover The Same Reason (Priority: P1)
|
||||
|
||||
**Goal**: Make dashboard backup warnings and attention items open destination surfaces that confirm the same problem family.
|
||||
|
||||
**Independent Test**: Trigger stale, degraded, no-basis, and schedule-follow-up scenarios, click the dashboard KPI or attention destination, and verify the target surface immediately confirms the same reason.
|
||||
|
||||
### Tests for User Story 2
|
||||
|
||||
- [X] T014 [P] [US2] Extend reason-driven dashboard action coverage in `tests/Feature/Filament/DashboardKpisWidgetTest.php` and `tests/Feature/Filament/NeedsAttentionWidgetTest.php`
|
||||
- [X] T015 [P] [US2] Create or extend no-basis, stale, degraded, and schedule-follow-up continuity coverage in `tests/Feature/Filament/BackupSetListContinuityTest.php`, `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`, and `tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php`
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [X] T016 [US2] Add backup-health attention items with safe action-target rendering in `app/Filament/Widgets/Dashboard/NeedsAttention.php`
|
||||
- [X] T017 [US2] Route backup-health KPI and attention destinations by reason in `app/Support/BackupHealth/TenantBackupHealthResolver.php` and `app/Support/BackupHealth/BackupHealthActionTarget.php`
|
||||
- [X] T018 [US2] Make no-basis list continuity and stale or degraded latest-basis continuity scan-fast on the backup-set surfaces in `app/Filament/Resources/BackupSetResource.php`
|
||||
- [X] T019 [US2] Make schedule-follow-up continuity scan-fast on the backup-schedules surface in `app/Filament/Resources/BackupScheduleResource.php`
|
||||
- [X] T020 [US2] Run the focused drillthrough continuity pack from `specs/180-tenant-backup-health/quickstart.md` against `tests/Feature/Filament/DashboardKpisWidgetTest.php`, `tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `tests/Feature/Filament/BackupSetListContinuityTest.php`, `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`, and `tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php`
|
||||
|
||||
**Checkpoint**: Backup-health warnings on the tenant dashboard now lead to destinations that confirm the same problem class without guesswork.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 - Trust Positive Backup Calmness Only When Earned (Priority: P2)
|
||||
|
||||
**Goal**: Allow positive backup-health wording only when the latest relevant backup basis genuinely supports it.
|
||||
|
||||
**Independent Test**: Render the tenant dashboard for one clearly healthy case and several almost-healthy cases, then verify that only the fully supported case emits positive backup-health wording.
|
||||
|
||||
### Tests for User Story 3
|
||||
|
||||
- [X] T021 [P] [US3] Extend healthy-check inclusion and suppression coverage in `tests/Feature/Filament/NeedsAttentionWidgetTest.php`
|
||||
- [X] T022 [P] [US3] Extend healthy-claim gating coverage in `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php` and `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [X] T023 [US3] Enforce healthy-claim gating and supporting-message rules in `app/Support/BackupHealth/TenantBackupHealthResolver.php` and `app/Support/BackupHealth/TenantBackupHealthAssessment.php`
|
||||
- [X] T024 [US3] Render `Backups are recent and healthy` only when the assessment permits it in `app/Filament/Widgets/Dashboard/NeedsAttention.php`
|
||||
- [X] T025 [US3] Keep positive dashboard copy bounded to backup posture rather than recoverability in `app/Filament/Widgets/Dashboard/DashboardKpis.php` and `app/Filament/Widgets/Dashboard/NeedsAttention.php`
|
||||
- [X] T026 [US3] Run the focused healthy-wording pack from `specs/180-tenant-backup-health/quickstart.md` against `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`, `tests/Feature/Filament/NeedsAttentionWidgetTest.php`, and `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`
|
||||
|
||||
**Checkpoint**: Positive backup calmness now appears only when the current evidence earns it.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: User Story 4 - Preserve Truth Under Schedule And Permission Nuance (Priority: P3)
|
||||
|
||||
**Goal**: Keep tenant backup-health truth strong under mixed history, schedule nuance, and restricted downstream access.
|
||||
|
||||
**Independent Test**: Seed mixed-history, overdue-schedule, and reduced-destination-access scenarios, then verify the dashboard still surfaces the strongest truthful backup-health state and degrades navigation safely.
|
||||
|
||||
### Tests for User Story 4
|
||||
|
||||
- [X] T027 [P] [US4] Extend tenant-scope `404` coverage plus established-member blocked-destination `403` coverage in `tests/Feature/Filament/TenantDashboardTenantScopeTest.php`
|
||||
- [X] T028 [P] [US4] Extend mixed-history latest-governs and schedule-secondary coverage in `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php` and `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`
|
||||
- [X] T029 [P] [US4] Extend disabled-action, member-without-capability, and schedule-follow-up nuance coverage in `tests/Feature/Filament/NeedsAttentionWidgetTest.php`
|
||||
|
||||
### Implementation for User Story 4
|
||||
|
||||
- [X] T030 [US4] Finalize schedule-follow-up secondary semantics and latest-history precedence in `app/Support/BackupHealth/TenantBackupHealthResolver.php`
|
||||
- [X] T031 [US4] Degrade unavailable backup drillthroughs safely while preserving summary truth in `app/Filament/Widgets/Dashboard/DashboardKpis.php` and `app/Filament/Widgets/Dashboard/NeedsAttention.php`
|
||||
- [X] T032 [US4] Keep backup follow-up routes and record resolution tenant-scoped, capability-registry-backed, and `403`-after-membership authorization-safe in `app/Filament/Resources/BackupSetResource.php` and `app/Filament/Resources/BackupScheduleResource.php`
|
||||
- [X] T033 [US4] Run the focused nuance and RBAC pack from `specs/180-tenant-backup-health/quickstart.md` against `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`, `tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`, and `tests/Feature/Filament/TenantDashboardTenantScopeTest.php`
|
||||
|
||||
**Checkpoint**: Backup-health truth remains accurate even when schedules exist, history is mixed, or one downstream destination is unavailable.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Final consistency, formatting, and focused verification across all stories.
|
||||
|
||||
- [X] T034 [P] Review and align operator-facing backup-health copy in `app/Support/BackupHealth/TenantBackupHealthAssessment.php`, `app/Filament/Widgets/Dashboard/DashboardKpis.php`, `app/Filament/Widgets/Dashboard/NeedsAttention.php`, `app/Filament/Resources/BackupSetResource.php`, and `app/Filament/Resources/BackupScheduleResource.php`
|
||||
- [X] T035 [P] Run the focused verification pack from `specs/180-tenant-backup-health/quickstart.md` against `tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php`, `tests/Feature/Filament/DashboardKpisWidgetTest.php`, `tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php`, `tests/Feature/Filament/TenantDashboardTenantScopeTest.php`, `tests/Feature/Filament/TenantDashboardDbOnlyTest.php`, `tests/Feature/Filament/BackupSetListContinuityTest.php`, `tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php`, and `tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php`
|
||||
- [X] T036 Run formatting with `vendor/bin/sail bin pint --dirty --format agent` as required by `specs/180-tenant-backup-health/quickstart.md`
|
||||
- [ ] T037 Run the manual validation pass in `specs/180-tenant-backup-health/quickstart.md` for no-backup, stale, stale-over-degraded, degraded, healthy, schedule-follow-up, and tenant-scope scenarios
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: Starts immediately and establishes the new backup-health namespace and config.
|
||||
- **Foundational (Phase 2)**: Depends on Setup and blocks all story work until one authoritative backup-health derivation contract exists.
|
||||
- **User Story 1 (Phase 3)**: Starts after Foundational and delivers the first operator-visible backup-health truth.
|
||||
- **User Story 2 (Phase 4)**: Starts after Foundational and should follow User Story 1 closely because it adds reason continuity to the summary surfaces.
|
||||
- **User Story 3 (Phase 5)**: Starts after Foundational and can proceed once the primary posture contract from User Story 1 is in place.
|
||||
- **User Story 4 (Phase 6)**: Starts after Foundational and should follow User Stories 2 and 3 because it hardens action degradation and final nuance on top of those surfaces.
|
||||
- **Polish (Phase 7)**: Starts after the desired stories are complete.
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **US1**: Depends only on Setup and Foundational work.
|
||||
- **US2**: Depends on Setup and Foundational work and should reuse the posture contract delivered for US1.
|
||||
- **US3**: Depends on Setup and Foundational work and should reuse the posture contract delivered for US1.
|
||||
- **US4**: Depends on Setup and Foundational work plus the action-target and healthy-claim behavior hardened in US2 and US3.
|
||||
|
||||
### Within Each User Story
|
||||
|
||||
- Test updates should land before the corresponding behavior change is considered complete.
|
||||
- Resolver and value-object changes should land before widget or resource rendering tasks for the same story.
|
||||
- Story-level focused test runs should pass before moving to the next priority slice.
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
- `T003` and `T004` can run in parallel after the backup-health namespace from `T001` is agreed.
|
||||
- `T006` and `T008` can run in parallel once `T005` defines the derivation contract.
|
||||
- `T009` and `T010` can run in parallel for US1.
|
||||
- `T014` and `T015` can run in parallel for US2.
|
||||
- `T018` and `T019` can run in parallel for US2 once `T017` fixes the reason-target contract.
|
||||
- `T021` and `T022` can run in parallel for US3.
|
||||
- `T027`, `T028`, and `T029` can run in parallel for US4.
|
||||
- `T034` and `T035` can run in parallel once feature code is stable.
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: User Story 1
|
||||
|
||||
```bash
|
||||
# Story 1 tests in parallel:
|
||||
Task: T009 tests/Feature/Filament/DashboardKpisWidgetTest.php
|
||||
Task: T010 tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php
|
||||
|
||||
# Story 1 implementation split after the resolver contract is stable:
|
||||
Task: T011 app/Filament/Widgets/Dashboard/DashboardKpis.php
|
||||
Task: T012 app/Support/BackupHealth/TenantBackupHealthAssessment.php
|
||||
```
|
||||
|
||||
## Parallel Example: User Story 2
|
||||
|
||||
```bash
|
||||
# Story 2 tests in parallel:
|
||||
Task: T014 tests/Feature/Filament/DashboardKpisWidgetTest.php
|
||||
Task: T015 tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php
|
||||
|
||||
# Story 2 follow-up surfaces in parallel after reason-target mapping is fixed:
|
||||
Task: T018 app/Filament/Resources/BackupSetResource.php
|
||||
Task: T019 app/Filament/Resources/BackupScheduleResource.php
|
||||
```
|
||||
|
||||
## Parallel Example: User Story 3
|
||||
|
||||
```bash
|
||||
# Story 3 tests in parallel:
|
||||
Task: T021 tests/Feature/Filament/NeedsAttentionWidgetTest.php
|
||||
Task: T022 tests/Unit/Support/BackupHealth/TenantBackupHealthResolverTest.php
|
||||
|
||||
# Story 3 implementation split after gating rules are defined:
|
||||
Task: T023 app/Support/BackupHealth/TenantBackupHealthResolver.php
|
||||
Task: T024 app/Filament/Widgets/Dashboard/NeedsAttention.php
|
||||
```
|
||||
|
||||
## Parallel Example: User Story 4
|
||||
|
||||
```bash
|
||||
# Story 4 tests in parallel:
|
||||
Task: T027 tests/Feature/Filament/TenantDashboardTenantScopeTest.php
|
||||
Task: T028 tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php
|
||||
Task: T029 tests/Feature/Filament/NeedsAttentionWidgetTest.php
|
||||
|
||||
# Story 4 hardening split after expectations are locked:
|
||||
Task: T031 app/Filament/Widgets/Dashboard/DashboardKpis.php
|
||||
Task: T032 app/Filament/Resources/BackupSetResource.php
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First
|
||||
|
||||
- Complete Phase 1 and Phase 2.
|
||||
- Deliver User Story 1 first so the tenant dashboard stops hiding backup posture at the summary layer.
|
||||
- If the slice is intended to ship immediately after MVP, include User Story 2 before release so dashboard warnings also preserve drillthrough trust.
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
- Add User Story 2 next to make every warning recoverable on the correct destination surface.
|
||||
- Add User Story 3 after that to prevent positive calm wording from overclaiming health.
|
||||
- Add User Story 4 last to harden mixed-history, schedule nuance, and RBAC-safe degradation.
|
||||
|
||||
### Verification Finish
|
||||
|
||||
- Run Pint on touched files.
|
||||
- Run the focused backup-health pack from `quickstart.md`.
|
||||
- Run the manual quickstart validation pass for absent, stale, degraded, healthy, schedule-follow-up, and tenant-scope cases.
|
||||
- Offer the broader suite only after the focused pack passes.
|
||||
@ -1,40 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Pages\TenantDashboard;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Models\Tenant;
|
||||
use App\Models\User;
|
||||
use App\Models\Workspace;
|
||||
use App\Support\Workspaces\WorkspaceContext;
|
||||
|
||||
it('logs into the seeded backup-health browser fixture through the local helper', function (): void {
|
||||
$this->artisan('tenantpilot:backup-health:seed-browser-fixture', ['--no-interaction' => true])
|
||||
->assertSuccessful();
|
||||
|
||||
$workspaceConfig = config('tenantpilot.backup_health.browser_smoke_fixture.workspace');
|
||||
$userConfig = config('tenantpilot.backup_health.browser_smoke_fixture.user');
|
||||
$scenarioConfig = config('tenantpilot.backup_health.browser_smoke_fixture.blocked_drillthrough');
|
||||
$tenantRouteKey = $scenarioConfig['tenant_id'] ?? $scenarioConfig['tenant_external_id'];
|
||||
|
||||
$workspace = Workspace::query()->where('slug', $workspaceConfig['slug'])->first();
|
||||
$user = User::query()->where('email', $userConfig['email'])->first();
|
||||
$tenant = Tenant::query()->where('external_id', $tenantRouteKey)->first();
|
||||
|
||||
expect($workspace)->not->toBeNull();
|
||||
expect($user)->not->toBeNull();
|
||||
expect($tenant)->not->toBeNull();
|
||||
|
||||
$this->get(route('admin.local.backup-health-browser-fixture-login'))
|
||||
->assertRedirect(TenantDashboard::getUrl(tenant: $tenant));
|
||||
|
||||
$this->assertAuthenticatedAs($user);
|
||||
expect(session(WorkspaceContext::SESSION_KEY))->toBe((int) $workspace->getKey());
|
||||
|
||||
$this->get(TenantDashboard::getUrl(tenant: $tenant))
|
||||
->assertOk();
|
||||
|
||||
$this->get(BackupSetResource::getUrl('index', tenant: $tenant))
|
||||
->assertForbidden();
|
||||
});
|
||||
@ -1,6 +1,5 @@
|
||||
<?php
|
||||
|
||||
use App\Filament\Resources\BackupScheduleResource;
|
||||
use App\Filament\Resources\BackupScheduleResource\Pages\EditBackupSchedule;
|
||||
use App\Filament\Resources\BackupScheduleResource\Pages\ListBackupSchedules;
|
||||
use App\Jobs\ApplyBackupScheduleRetentionJob;
|
||||
@ -8,7 +7,6 @@
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\WorkspaceSetting;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use Filament\Facades\Filament;
|
||||
use Filament\Tables\Filters\TrashedFilter;
|
||||
use Illuminate\Auth\Access\AuthorizationException;
|
||||
@ -343,25 +341,3 @@ function makeBackupScheduleForLifecycle(\App\Models\Tenant $tenant, array $attri
|
||||
|
||||
expect($keptIds)->toHaveCount(3);
|
||||
});
|
||||
|
||||
it('confirms schedule follow-up continuity on the backup-schedules list surface', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
$this->actingAs($user);
|
||||
|
||||
$schedule = makeBackupScheduleForLifecycle($tenant, [
|
||||
'name' => 'Overdue continuity schedule',
|
||||
'last_run_at' => null,
|
||||
'last_run_status' => null,
|
||||
'next_run_at' => now()->subHours(2),
|
||||
]);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$this->get(BackupScheduleResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP,
|
||||
], panel: 'tenant', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('not produced a successful run yet')
|
||||
->assertSee($schedule->name)
|
||||
->assertSee('No successful run has been recorded yet.');
|
||||
});
|
||||
|
||||
@ -1,74 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Pages\TenantDashboard;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Widgets\Dashboard\DashboardKpis;
|
||||
use App\Filament\Widgets\Dashboard\NeedsAttention;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Tenant;
|
||||
use App\Models\User;
|
||||
use App\Models\Workspace;
|
||||
use App\Services\Auth\CapabilityResolver;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\Rbac\UiTooltips;
|
||||
use App\Support\Workspaces\WorkspaceContext;
|
||||
use Filament\Facades\Filament;
|
||||
use Livewire\Livewire;
|
||||
|
||||
it('seeds a deterministic blocked drill-through browser fixture for backup health', function (): void {
|
||||
$this->artisan('tenantpilot:backup-health:seed-browser-fixture', ['--no-interaction' => true])
|
||||
->assertSuccessful()
|
||||
->expectsOutputToContain('Fixture login URL')
|
||||
->expectsOutputToContain('Dashboard URL');
|
||||
|
||||
$workspaceConfig = config('tenantpilot.backup_health.browser_smoke_fixture.workspace');
|
||||
$userConfig = config('tenantpilot.backup_health.browser_smoke_fixture.user');
|
||||
$scenarioConfig = config('tenantpilot.backup_health.browser_smoke_fixture.blocked_drillthrough');
|
||||
$tenantRouteKey = $scenarioConfig['tenant_id'] ?? $scenarioConfig['tenant_external_id'];
|
||||
|
||||
$workspace = Workspace::query()->where('slug', $workspaceConfig['slug'])->first();
|
||||
$user = User::query()->where('email', $userConfig['email'])->first();
|
||||
$tenant = Tenant::query()->where('external_id', $tenantRouteKey)->first();
|
||||
|
||||
expect($workspace)->not->toBeNull();
|
||||
expect($user)->not->toBeNull();
|
||||
expect($tenant)->not->toBeNull();
|
||||
expect(BackupSet::query()->where('tenant_id', $tenant->getKey())->where('name', $scenarioConfig['backup_set_name'])->exists())->toBeTrue();
|
||||
expect(BackupItem::query()->where('tenant_id', $tenant->getKey())->where('policy_identifier', $scenarioConfig['policy_external_id'])->exists())->toBeTrue();
|
||||
|
||||
$resolver = app(CapabilityResolver::class);
|
||||
$resolver->clearCache();
|
||||
|
||||
expect($resolver->isMember($user, $tenant))->toBeTrue();
|
||||
expect($resolver->can($user, $tenant, Capabilities::TENANT_VIEW))->toBeFalse();
|
||||
|
||||
$this->actingAs($user)->withSession([
|
||||
WorkspaceContext::SESSION_KEY => (int) $workspace->getKey(),
|
||||
]);
|
||||
session()->put(WorkspaceContext::SESSION_KEY, (int) $workspace->getKey());
|
||||
|
||||
$this->get(route('filament.admin.pages.choose-tenant'))
|
||||
->assertOk()
|
||||
->assertSee((string) $tenant->name);
|
||||
|
||||
$this->get(TenantDashboard::getUrl(tenant: $tenant))
|
||||
->assertOk();
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(DashboardKpis::class)
|
||||
->assertSee('Backup posture')
|
||||
->assertSee('Stale');
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertSee('Open latest backup')
|
||||
->assertSee(UiTooltips::INSUFFICIENT_PERMISSION);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('index', tenant: $tenant))
|
||||
->assertForbidden();
|
||||
});
|
||||
@ -190,45 +190,3 @@ function backupItemsRelationManagerComponent(BackupSet $backupSet)
|
||||
->assertSet('tableSort', 'policy.display_name:desc')
|
||||
->assertSet('tableFilters.policy_type.value', 'intuneRoleDefinition');
|
||||
});
|
||||
|
||||
it('shows snapshot mode and backup quality hints for backup items', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
|
||||
$this->actingAs($user);
|
||||
$tenant->makeCurrent();
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
]);
|
||||
|
||||
$policy = Policy::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'external_id' => 'quality-policy',
|
||||
'policy_type' => 'settingsCatalogPolicy',
|
||||
'display_name' => 'Quality Policy',
|
||||
'platform' => 'windows',
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($backupSet)->for($tenant)->create([
|
||||
'policy_id' => (int) $policy->getKey(),
|
||||
'policy_identifier' => 'quality-policy',
|
||||
'policy_type' => 'settingsCatalogPolicy',
|
||||
'platform' => 'windows',
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'displayName' => 'Quality Policy',
|
||||
'source' => 'metadata_only',
|
||||
'assignment_capture_reason' => 'separate_role_assignments',
|
||||
'has_orphaned_assignments' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
backupItemsRelationManagerComponent($backupSet)
|
||||
->assertSee('Snapshot')
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Metadata only')
|
||||
->assertSee('Assignments captured separately')
|
||||
->assertSee('Orphaned assignments');
|
||||
});
|
||||
|
||||
@ -1,65 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
it('shows lifecycle status separately from backup quality on the backup-set list', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
|
||||
$this->actingAs($user);
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$fullSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Full quality set',
|
||||
'status' => 'completed',
|
||||
'item_count' => 1,
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($fullSet)->create([
|
||||
'payload' => ['id' => 'policy-full'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$degradedSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Degraded quality set',
|
||||
'status' => 'completed',
|
||||
'item_count' => 2,
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($degradedSet)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($degradedSet)->create([
|
||||
'payload' => ['id' => 'policy-warning'],
|
||||
'metadata' => [
|
||||
'has_orphaned_assignments' => true,
|
||||
'integrity_warning' => 'Protected values are intentionally hidden.',
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('index', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Full quality set')
|
||||
->assertSee('No degradations detected across 1 item')
|
||||
->assertSee('Degraded quality set')
|
||||
->assertSee('2 degraded items')
|
||||
->assertSee('1 metadata-only')
|
||||
->assertSee('1 assignment issue')
|
||||
->assertSee('Completed');
|
||||
});
|
||||
@ -3,17 +3,10 @@
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\OperationRun;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Filament\Facades\Filament;
|
||||
|
||||
afterEach(function (): void {
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
it('renders backup sets with lifecycle summary, related context, and secondary technical detail', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
$this->actingAs($user);
|
||||
@ -31,16 +24,6 @@
|
||||
],
|
||||
]);
|
||||
|
||||
\App\Models\BackupItem::factory()->for($backupSet)->for($tenant)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
'integrity_warning' => 'Protected values are intentionally hidden.',
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$run = OperationRun::factory()->for($tenant)->create([
|
||||
'workspace_id' => (int) $tenant->workspace_id,
|
||||
'type' => 'backup_set.add_policies',
|
||||
@ -51,18 +34,14 @@
|
||||
|
||||
$this->get(BackupSetResource::getUrl('view', ['record' => $backupSet], tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('1 degraded item')
|
||||
->assertSee('1 metadata-only')
|
||||
->assertSee('1 assignment issue')
|
||||
->assertSee('1 integrity warning')
|
||||
->assertSee('Recovery readiness')
|
||||
->assertSee('Timing')
|
||||
->assertSee('Archive')
|
||||
->assertSee('More')
|
||||
->assertSee('/admin/operations/'.$run->getKey(), false)
|
||||
->assertDontSee('Related record')
|
||||
->assertDontSee('>Completed</span>', false)
|
||||
->assertSeeInOrder(['Nightly backup', 'Backup quality', 'Lifecycle overview', 'Related context', 'Technical detail']);
|
||||
->assertSeeInOrder(['Nightly backup', 'Lifecycle overview', 'Related context', 'Technical detail']);
|
||||
});
|
||||
|
||||
it('keeps operations context and technical empty states readable for sparse backup sets', function (): void {
|
||||
@ -74,109 +53,13 @@
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Sparse backup',
|
||||
'item_count' => 0,
|
||||
'metadata' => [],
|
||||
]);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('view', ['record' => $backupSet], tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('No items captured')
|
||||
->assertSee('Operations')
|
||||
->assertSee('No backup metadata was recorded for this backup set.')
|
||||
->assertSee('Metadata keys')
|
||||
->assertDontSee('Related record');
|
||||
});
|
||||
|
||||
it('keeps backup quality counts visible for archived backup sets', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
$this->actingAs($user);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Archived backup',
|
||||
'item_count' => 1,
|
||||
]);
|
||||
|
||||
$item = \App\Models\BackupItem::factory()->for($backupSet)->for($tenant)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$item->delete();
|
||||
$backupSet->delete();
|
||||
|
||||
$this->get(BackupSetResource::getUrl('view', ['record' => $backupSet], tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Archived')
|
||||
->assertSee('1 degraded item')
|
||||
->assertSee('1 metadata-only');
|
||||
});
|
||||
|
||||
it('confirms stale latest-backup continuity on the enterprise detail page', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner', ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Stale dashboard backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($backupSet)->for($tenant)->create([
|
||||
'payload' => ['id' => 'policy-stale'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('view', [
|
||||
'record' => $backupSet,
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
], panel: 'tenant', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup posture')
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertSee('The latest completed backup was 2 days ago.');
|
||||
});
|
||||
|
||||
it('confirms degraded latest-backup continuity on the enterprise detail page', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner', ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Degraded dashboard backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(45),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($backupSet)->for($tenant)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('view', [
|
||||
'record' => $backupSet,
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED,
|
||||
], panel: 'tenant', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup posture')
|
||||
->assertSee('Latest backup is degraded')
|
||||
->assertSee('degraded input quality');
|
||||
});
|
||||
|
||||
@ -1,37 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
it('confirms no usable completed backup basis on the backup-set list surface', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner', ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS,
|
||||
], panel: 'tenant', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('No usable completed backup basis is currently available for this tenant.')
|
||||
->assertSee('No backup sets');
|
||||
});
|
||||
|
||||
it('keeps fallback continuity copy readable on the backup-set list when the latest backup detail is unavailable', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner', ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
], panel: 'tenant', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('The latest backup detail is no longer available, so this view stays on the backup-set list.');
|
||||
});
|
||||
@ -112,32 +112,3 @@ function getTableEmptyStateAction($component, string $name): ?\Filament\Actions\
|
||||
expect($action->isDisabled())->toBeTrue();
|
||||
expect($action->getTooltip())->toBe(UiTooltips::insufficientPermission());
|
||||
});
|
||||
|
||||
test('readonly members still see backup quality truth on the backup-set list', function () {
|
||||
$tenant = Tenant::factory()->create();
|
||||
[$user] = createUserWithTenant($tenant, role: 'readonly');
|
||||
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => $tenant->getKey(),
|
||||
'status' => 'completed',
|
||||
'item_count' => 1,
|
||||
]);
|
||||
|
||||
\App\Models\BackupItem::factory()->create([
|
||||
'tenant_id' => $tenant->getKey(),
|
||||
'backup_set_id' => $backupSet->getKey(),
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$this->actingAs($user)
|
||||
->get(BackupSetResource::getUrl('index', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('1 metadata-only');
|
||||
});
|
||||
|
||||
@ -2,23 +2,15 @@
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\BackupScheduleResource;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Resources\FindingResource;
|
||||
use App\Filament\Widgets\Dashboard\DashboardKpis;
|
||||
use App\Filament\Widgets\Dashboard\NeedsAttention;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSchedule;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Finding;
|
||||
use App\Models\OperationRun;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\OperationRunLinks;
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use App\Support\Rbac\UiTooltips;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Filament\Facades\Filament;
|
||||
use Filament\Widgets\StatsOverviewWidget\Stat;
|
||||
use Illuminate\Support\Facades\Gate;
|
||||
@ -43,38 +35,6 @@ function dashboardKpiStatPayloads($component): array
|
||||
->all();
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array{value:string,description:string|null,url:string|null}
|
||||
*/
|
||||
function backupPostureStatPayload(\App\Models\Tenant $tenant): array
|
||||
{
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
return dashboardKpiStatPayloads(Livewire::test(DashboardKpis::class))['Backup posture'];
|
||||
}
|
||||
|
||||
function makeBackupHealthScheduleForKpi(\App\Models\Tenant $tenant, array $attributes = []): BackupSchedule
|
||||
{
|
||||
return BackupSchedule::query()->create(array_merge([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'KPI schedule',
|
||||
'is_enabled' => true,
|
||||
'timezone' => 'UTC',
|
||||
'frequency' => 'daily',
|
||||
'time_of_day' => '01:00:00',
|
||||
'days_of_week' => null,
|
||||
'policy_types' => ['deviceConfiguration'],
|
||||
'include_foundations' => true,
|
||||
'retention_keep_last' => 30,
|
||||
'next_run_at' => now()->addHour(),
|
||||
], $attributes));
|
||||
}
|
||||
|
||||
afterEach(function (): void {
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
it('aligns dashboard KPI counts and drill-throughs to canonical findings and operations semantics', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
$this->actingAs($user);
|
||||
@ -220,188 +180,3 @@ function makeBackupHealthScheduleForKpi(\App\Models\Tenant $tenant, array $attri
|
||||
'url' => null,
|
||||
]);
|
||||
});
|
||||
|
||||
it('shows absent backup posture and routes the KPI to the backup-set list', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$stat = backupPostureStatPayload($tenant);
|
||||
|
||||
expect($stat)->toMatchArray([
|
||||
'value' => 'Absent',
|
||||
'url' => BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
]);
|
||||
|
||||
expect($stat['description'])->toContain('Create or finish a backup set');
|
||||
});
|
||||
|
||||
it('shows stale backup posture and routes the KPI to the latest backup detail', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Stale latest backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => ['id' => 'policy-stale'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$stat = backupPostureStatPayload($tenant);
|
||||
|
||||
expect($stat)->toMatchArray([
|
||||
'value' => 'Stale',
|
||||
'url' => BackupSetResource::getUrl('view', [
|
||||
'record' => (int) $backupSet->getKey(),
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
]);
|
||||
|
||||
expect($stat['description'])->toContain('2 days');
|
||||
});
|
||||
|
||||
it('shows degraded backup posture and routes the KPI to the latest backup detail', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Degraded latest backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(45),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$stat = backupPostureStatPayload($tenant);
|
||||
|
||||
expect($stat)->toMatchArray([
|
||||
'value' => 'Degraded',
|
||||
'url' => BackupSetResource::getUrl('view', [
|
||||
'record' => (int) $backupSet->getKey(),
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
]);
|
||||
|
||||
expect($stat['description'])->toContain('degraded input quality');
|
||||
});
|
||||
|
||||
it('shows healthy backup posture when the latest backup is recent and clean', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy latest backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(20),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$stat = backupPostureStatPayload($tenant);
|
||||
|
||||
expect($stat)->toMatchArray([
|
||||
'value' => 'Healthy',
|
||||
'url' => null,
|
||||
]);
|
||||
|
||||
expect($stat['description'])->toContain('20 minutes');
|
||||
});
|
||||
|
||||
it('keeps the posture healthy but routes the KPI to schedules when backup automation needs follow-up', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy latest backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(15),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
makeBackupHealthScheduleForKpi($tenant, [
|
||||
'name' => 'Overdue KPI schedule',
|
||||
'last_run_at' => null,
|
||||
'last_run_status' => null,
|
||||
'next_run_at' => now()->subHours(2),
|
||||
]);
|
||||
|
||||
$stat = backupPostureStatPayload($tenant);
|
||||
|
||||
expect($stat)->toMatchArray([
|
||||
'value' => 'Healthy',
|
||||
'url' => BackupScheduleResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP,
|
||||
], panel: 'tenant', tenant: $tenant),
|
||||
]);
|
||||
|
||||
expect($stat['description'])->toContain('not produced a successful run');
|
||||
});
|
||||
|
||||
it('keeps backup posture truth visible while disabling backup drill-throughs for members without backup view access', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Stale inaccessible backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => ['id' => 'policy-stale'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Gate::define(Capabilities::TENANT_VIEW, fn (): bool => false);
|
||||
|
||||
$stat = backupPostureStatPayload($tenant);
|
||||
|
||||
expect($stat)->toMatchArray([
|
||||
'value' => 'Stale',
|
||||
'url' => null,
|
||||
]);
|
||||
|
||||
expect($stat['description'])
|
||||
->toContain('2 days')
|
||||
->toContain(UiTooltips::INSUFFICIENT_PERMISSION);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertSee(UiTooltips::INSUFFICIENT_PERMISSION);
|
||||
});
|
||||
|
||||
@ -2,13 +2,8 @@
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\BackupScheduleResource;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Resources\FindingResource;
|
||||
use App\Filament\Widgets\Dashboard\NeedsAttention;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSchedule;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\BaselineProfile;
|
||||
use App\Models\BaselineSnapshot;
|
||||
use App\Models\BaselineTenantAssignment;
|
||||
@ -16,13 +11,11 @@
|
||||
use App\Models\FindingException;
|
||||
use App\Models\OperationRun;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\Baselines\BaselineCompareReasonCode;
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use App\Support\OperationRunType;
|
||||
use App\Support\Rbac\UiTooltips;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Support\Facades\Gate;
|
||||
use Livewire\Livewire;
|
||||
@ -51,27 +44,6 @@ function createNeedsAttentionTenant(): array
|
||||
return [$user, $tenant, $profile, $snapshot];
|
||||
}
|
||||
|
||||
function makeBackupHealthScheduleForNeedsAttention(\App\Models\Tenant $tenant, array $attributes = []): BackupSchedule
|
||||
{
|
||||
return BackupSchedule::query()->create(array_merge([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Needs Attention backup schedule',
|
||||
'is_enabled' => true,
|
||||
'timezone' => 'UTC',
|
||||
'frequency' => 'daily',
|
||||
'time_of_day' => '01:00:00',
|
||||
'days_of_week' => null,
|
||||
'policy_types' => ['deviceConfiguration'],
|
||||
'include_foundations' => true,
|
||||
'retention_keep_last' => 30,
|
||||
'next_run_at' => now()->addHour(),
|
||||
], $attributes));
|
||||
}
|
||||
|
||||
afterEach(function (): void {
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
it('shows a cautionary baseline posture in needs-attention when compare trust is limited', function (): void {
|
||||
[$user, $tenant, $profile, $snapshot] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
@ -121,18 +93,6 @@ function makeBackupHealthScheduleForNeedsAttention(\App\Models\Tenant $tenant, a
|
||||
[$user, $tenant, $profile, $snapshot] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy compare backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(20),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
OperationRun::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'workspace_id' => (int) $tenant->workspace_id,
|
||||
@ -356,211 +316,3 @@ function makeBackupHealthScheduleForNeedsAttention(\App\Models\Tenant $tenant, a
|
||||
->assertSee('Open terminal follow-up')
|
||||
->assertDontSee('Current governance and findings signals look trustworthy.');
|
||||
});
|
||||
|
||||
it('surfaces a no-backup attention item with a backup-sets destination', function (): void {
|
||||
[$user, $tenant] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$component = Livewire::test(NeedsAttention::class)
|
||||
->assertSee('No usable backup basis')
|
||||
->assertSee('Create or finish a backup set before relying on restore input.')
|
||||
->assertSee('Open backup sets')
|
||||
->assertDontSee('Backups are recent and healthy');
|
||||
|
||||
expect($component->html())->toContain(BackupSetResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS,
|
||||
], panel: 'tenant', tenant: $tenant));
|
||||
});
|
||||
|
||||
it('surfaces stale latest-backup attention with the matching latest-backup drill-through', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
$staleBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Stale backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($staleBackup)->create([
|
||||
'payload' => ['id' => 'policy-stale'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$staleComponent = Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertSee('Open latest backup')
|
||||
->assertDontSee('Backups are recent and healthy');
|
||||
|
||||
expect($staleComponent->html())->toContain(BackupSetResource::getUrl('view', [
|
||||
'record' => (int) $staleBackup->getKey(),
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
], panel: 'tenant', tenant: $tenant));
|
||||
});
|
||||
|
||||
it('surfaces degraded latest-backup attention with the matching latest-backup drill-through', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
$degradedBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Degraded backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(45),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($degradedBackup)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$degradedComponent = Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is degraded')
|
||||
->assertSee('Open latest backup')
|
||||
->assertDontSee('Backups are recent and healthy');
|
||||
|
||||
expect($degradedComponent->html())->toContain(BackupSetResource::getUrl('view', [
|
||||
'record' => (int) $degradedBackup->getKey(),
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED,
|
||||
], panel: 'tenant', tenant: $tenant));
|
||||
});
|
||||
|
||||
it('surfaces schedule follow-up instead of a healthy backup check when automation needs review', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(20),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
makeBackupHealthScheduleForNeedsAttention($tenant, [
|
||||
'name' => 'Overdue schedule',
|
||||
'last_run_at' => null,
|
||||
'last_run_status' => null,
|
||||
'next_run_at' => now()->subHours(2),
|
||||
]);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$component = Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Backup schedules need follow-up')
|
||||
->assertSee('not produced a successful run')
|
||||
->assertSee('Open backup schedules')
|
||||
->assertDontSee('Backups are recent and healthy');
|
||||
|
||||
expect($component->html())->toContain(BackupScheduleResource::getUrl('index', [
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP,
|
||||
], panel: 'tenant', tenant: $tenant));
|
||||
});
|
||||
|
||||
it('adds the healthy backup check only when the latest backup basis genuinely earns it', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant, $profile, $snapshot] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(10),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
OperationRun::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'workspace_id' => (int) $tenant->workspace_id,
|
||||
'type' => OperationRunType::BaselineCompare->value,
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Succeeded->value,
|
||||
'completed_at' => now()->subHour(),
|
||||
'context' => [
|
||||
'baseline_profile_id' => (int) $profile->getKey(),
|
||||
'baseline_snapshot_id' => (int) $snapshot->getKey(),
|
||||
'baseline_compare' => [
|
||||
'reason_code' => BaselineCompareReasonCode::NoDriftDetected->value,
|
||||
'coverage' => [
|
||||
'effective_types' => ['deviceConfiguration'],
|
||||
'covered_types' => ['deviceConfiguration'],
|
||||
'uncovered_types' => [],
|
||||
'proof' => true,
|
||||
],
|
||||
],
|
||||
],
|
||||
]);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Backups are recent and healthy')
|
||||
->assertSee('Baseline compare looks trustworthy')
|
||||
->assertDontSee('Backup schedules need follow-up')
|
||||
->assertDontSee('No usable backup basis');
|
||||
});
|
||||
|
||||
it('keeps backup-health attention visible but non-clickable when the member lacks backup view access', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
[$user, $tenant] = createNeedsAttentionTenant();
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Stale hidden backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => ['id' => 'policy-stale'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Gate::define(Capabilities::TENANT_VIEW, fn (): bool => false);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$component = Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertSee('Open latest backup')
|
||||
->assertSee(UiTooltips::INSUFFICIENT_PERMISSION);
|
||||
|
||||
expect($component->html())->not->toContain(BackupSetResource::getUrl('view', [
|
||||
'record' => (int) $backupSet->getKey(),
|
||||
'backup_health_reason' => TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE,
|
||||
], panel: 'tenant', tenant: $tenant));
|
||||
});
|
||||
|
||||
@ -1,88 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\PolicyVersionResource;
|
||||
use App\Models\Policy;
|
||||
use App\Models\PolicyVersion;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
it('shows snapshot mode and backup quality on the policy-version list', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
|
||||
$this->actingAs($user);
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$policy = Policy::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'display_name' => 'Windows Policy',
|
||||
'policy_type' => 'settingsCatalogPolicy',
|
||||
'platform' => 'windows',
|
||||
]);
|
||||
|
||||
PolicyVersion::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'policy_id' => (int) $policy->getKey(),
|
||||
'version_number' => 1,
|
||||
'snapshot' => ['id' => 'policy-1'],
|
||||
'metadata' => [],
|
||||
]);
|
||||
|
||||
PolicyVersion::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'policy_id' => (int) $policy->getKey(),
|
||||
'version_number' => 2,
|
||||
'snapshot' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
]);
|
||||
|
||||
$this->get(PolicyVersionResource::getUrl('index', tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Snapshot')
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Full payload')
|
||||
->assertSee('Metadata only')
|
||||
->assertSee('Assignment fetch failed');
|
||||
});
|
||||
|
||||
it('shows explicit backup quality on the policy-version detail page', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
|
||||
$this->actingAs($user);
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$policy = Policy::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'display_name' => 'Versioned policy',
|
||||
'policy_type' => 'settingsCatalogPolicy',
|
||||
'platform' => 'windows',
|
||||
]);
|
||||
|
||||
$version = PolicyVersion::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'policy_id' => (int) $policy->getKey(),
|
||||
'snapshot' => ['id' => 'policy-1'],
|
||||
'metadata' => [
|
||||
'has_orphaned_assignments' => true,
|
||||
],
|
||||
'secret_fingerprints' => [
|
||||
'snapshot' => ['/clientSecret' => 'abc123'],
|
||||
'assignments' => [],
|
||||
'scope_tags' => [],
|
||||
],
|
||||
]);
|
||||
|
||||
$this->get(PolicyVersionResource::getUrl('view', ['record' => $version], tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Orphaned assignments')
|
||||
->assertSee('Integrity note')
|
||||
->assertSee('Boundary')
|
||||
->assertSee('Input quality signals do not prove safe restore');
|
||||
});
|
||||
@ -124,55 +124,12 @@
|
||||
|
||||
Livewire::test(ListPolicyVersions::class)
|
||||
->assertTableActionDisabled('restore_via_wizard', $version)
|
||||
->assertSee('Full payload')
|
||||
->callTableAction('restore_via_wizard', $version);
|
||||
|
||||
expect(BackupSet::query()->where('metadata->source', 'policy_version')->exists())->toBeFalse();
|
||||
expect(BackupItem::query()->exists())->toBeFalse();
|
||||
});
|
||||
|
||||
test('metadata-only versions keep quality visible while restore-via-wizard stays disabled', function () {
|
||||
$tenant = Tenant::create([
|
||||
'tenant_id' => 'tenant-policy-version-wizard-quality',
|
||||
'name' => 'Tenant',
|
||||
'metadata' => [],
|
||||
]);
|
||||
|
||||
$tenant->makeCurrent();
|
||||
|
||||
$policy = Policy::create([
|
||||
'tenant_id' => $tenant->id,
|
||||
'external_id' => 'policy-quality',
|
||||
'policy_type' => 'settingsCatalogPolicy',
|
||||
'display_name' => 'Settings Catalog',
|
||||
'platform' => 'windows',
|
||||
]);
|
||||
|
||||
$version = PolicyVersion::create([
|
||||
'tenant_id' => $tenant->id,
|
||||
'policy_id' => $policy->id,
|
||||
'version_number' => 1,
|
||||
'policy_type' => $policy->policy_type,
|
||||
'platform' => $policy->platform,
|
||||
'captured_at' => now(),
|
||||
'snapshot' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
],
|
||||
]);
|
||||
|
||||
$user = User::factory()->create(['email' => 'owner@example.com']);
|
||||
$user->tenants()->syncWithoutDetaching([
|
||||
$tenant->getKey() => ['role' => 'owner'],
|
||||
]);
|
||||
$this->actingAs($user);
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(ListPolicyVersions::class)
|
||||
->assertSee('Metadata only')
|
||||
->assertTableActionDisabled('restore_via_wizard', $version);
|
||||
});
|
||||
|
||||
test('restore run wizard can be prefilled from query params for policy version backup set', function () {
|
||||
$tenant = Tenant::create([
|
||||
'tenant_id' => 'tenant-policy-version-prefill',
|
||||
|
||||
@ -32,8 +32,6 @@
|
||||
->get(route('filament.admin.resources.policy-versions.index', filamentTenantRouteParams($tenant)))
|
||||
->assertOk()
|
||||
->assertSee('Policy A')
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Full payload')
|
||||
->assertSee((string) PolicyVersion::max('version_number'));
|
||||
});
|
||||
|
||||
@ -80,7 +78,6 @@
|
||||
->get(\App\Filament\Resources\PolicyVersionResource::getUrl('view', ['record' => $version]).'?tab=normalized-settings&tenant='.(string) $tenant->external_id);
|
||||
|
||||
$response->assertOk();
|
||||
$response->assertSee('Backup quality');
|
||||
$response->assertSee('Helpdesk Assignment');
|
||||
$response->assertSee('Role assignment');
|
||||
$response->assertSee('Policy and Profile Manager (role-1)');
|
||||
|
||||
@ -129,15 +129,13 @@
|
||||
->reduce(fn (array $carry, array $options): array => $carry + $options, []);
|
||||
|
||||
expect($flattenedOptions)->toHaveKey($policyItem->id);
|
||||
expect($flattenedOptions[$policyItem->id])->toContain('Policy Display')
|
||||
->and($flattenedOptions[$policyItem->id])->toContain('Full payload');
|
||||
expect($flattenedOptions[$policyItem->id])->toBe('Policy Display');
|
||||
|
||||
expect($flattenedOptions)->not->toHaveKey($ignoredPolicyItem->id);
|
||||
|
||||
expect($flattenedOptions)->toHaveKey($scopeTagItem->id);
|
||||
expect($flattenedOptions[$scopeTagItem->id])->toContain('Scope Tag Alpha');
|
||||
expect($flattenedOptions[$scopeTagItem->id])->toBe('Scope Tag Alpha');
|
||||
|
||||
expect($flattenedOptions)->toHaveKey($previewOnlyItem->id);
|
||||
expect($flattenedOptions[$previewOnlyItem->id])->toContain('Conditional Access Policy')
|
||||
->and($flattenedOptions[$previewOnlyItem->id])->toContain('Full payload');
|
||||
expect($flattenedOptions[$previewOnlyItem->id])->toBe('Conditional Access Policy');
|
||||
});
|
||||
|
||||
@ -1,39 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\RestoreRunResource\Pages\CreateRestoreRun;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
use Livewire\Livewire;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
it('shows degraded backup-set hints before restore safety checks run', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
|
||||
$this->actingAs($user);
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Recovery candidate',
|
||||
'item_count' => 1,
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Livewire::test(CreateRestoreRun::class)
|
||||
->assertSee('Backup quality is visible here before safety checks run.')
|
||||
->assertSee('Recovery candidate')
|
||||
->assertSee('1 degraded item')
|
||||
->assertSee('Backup quality hints describe input strength only.');
|
||||
});
|
||||
@ -5,8 +5,6 @@
|
||||
use App\Filament\Pages\TenantDashboard;
|
||||
use App\Filament\Widgets\Dashboard\DashboardKpis;
|
||||
use App\Filament\Widgets\Dashboard\RecentOperations as DashboardRecentOperations;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Finding;
|
||||
use App\Models\OperationRun;
|
||||
use Filament\Facades\Filament;
|
||||
@ -31,21 +29,6 @@
|
||||
'initiator_name' => 'System',
|
||||
]);
|
||||
|
||||
$backupSet = BackupSet::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'DB-only healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(30),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'backup_set_id' => (int) $backupSet->getKey(),
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$this->actingAs($user);
|
||||
|
||||
Bus::fake();
|
||||
@ -60,8 +43,6 @@
|
||||
// server-rendered HTML.
|
||||
|
||||
Livewire::test(DashboardKpis::class)
|
||||
->assertSee('Backup posture')
|
||||
->assertSee('Healthy')
|
||||
->assertSee('Active operations')
|
||||
->assertSee('healthy queued or running tenant work');
|
||||
|
||||
|
||||
@ -3,23 +3,10 @@
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Pages\TenantDashboard;
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Widgets\Dashboard\DashboardKpis;
|
||||
use App\Filament\Widgets\Dashboard\NeedsAttention;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Finding;
|
||||
use App\Models\InventoryItem;
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\Tenant;
|
||||
use App\Services\Auth\CapabilityResolver;
|
||||
use App\Support\Auth\Capabilities;
|
||||
use App\Support\Rbac\UiTooltips;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Support\Facades\Gate;
|
||||
use Livewire\Livewire;
|
||||
|
||||
use function Pest\Laravel\mock;
|
||||
|
||||
it('does not leak data across tenants on the dashboard', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner');
|
||||
@ -51,55 +38,3 @@
|
||||
->assertOk()
|
||||
->assertDontSee('Other Tenant Policy');
|
||||
});
|
||||
|
||||
it('keeps backup summary truth visible on the dashboard while blocked backup drill-through routes still fail with 403', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'owner', ensureDefaultMicrosoftProviderConnection: false);
|
||||
$this->actingAs($user);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Stale scoped backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => ['id' => 'policy-stale'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Gate::define(Capabilities::TENANT_VIEW, fn (): bool => false);
|
||||
|
||||
mock(CapabilityResolver::class, function ($mock) use ($tenant): void {
|
||||
$mock->shouldReceive('isMember')
|
||||
->andReturnUsing(static fn ($user, Tenant $resolvedTenant): bool => (int) $resolvedTenant->getKey() === (int) $tenant->getKey());
|
||||
|
||||
$mock->shouldReceive('can')
|
||||
->andReturnUsing(static function ($user, Tenant $resolvedTenant, string $capability) use ($tenant): bool {
|
||||
expect((int) $resolvedTenant->getKey())->toBe((int) $tenant->getKey());
|
||||
|
||||
return match ($capability) {
|
||||
Capabilities::TENANT_VIEW => false,
|
||||
default => true,
|
||||
};
|
||||
});
|
||||
});
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertSee(UiTooltips::INSUFFICIENT_PERMISSION)
|
||||
->assertSee('Open latest backup');
|
||||
|
||||
Livewire::test(DashboardKpis::class)
|
||||
->assertSee('Backup posture')
|
||||
->assertSee('Stale');
|
||||
|
||||
$this->get(TenantDashboard::getUrl(tenant: $tenant))
|
||||
->assertOk();
|
||||
|
||||
$this->get(BackupSetResource::getUrl('index', tenant: $tenant))
|
||||
->assertForbidden();
|
||||
});
|
||||
|
||||
@ -4,9 +4,6 @@
|
||||
|
||||
use App\Filament\Widgets\Dashboard\BaselineCompareNow;
|
||||
use App\Filament\Widgets\Dashboard\NeedsAttention;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSchedule;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\BaselineProfile;
|
||||
use App\Models\BaselineSnapshot;
|
||||
use App\Models\BaselineTenantAssignment;
|
||||
@ -17,7 +14,6 @@
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use App\Support\OperationRunType;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Filament\Facades\Filament;
|
||||
use Livewire\Livewire;
|
||||
|
||||
@ -73,10 +69,6 @@ function seedTrustworthyCompare(array $tenantContext): void
|
||||
]);
|
||||
}
|
||||
|
||||
afterEach(function (): void {
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
it('suppresses calm dashboard wording when stale and terminal operations both need attention', function (): void {
|
||||
$tenantContext = createTruthAlignedDashboardTenant();
|
||||
[$user, $tenant] = $tenantContext;
|
||||
@ -153,18 +145,6 @@ function seedTrustworthyCompare(array $tenantContext): void
|
||||
|
||||
seedTrustworthyCompare($tenantContext);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy truth-aligned backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(30),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
OperationRun::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'workspace_id' => (int) $tenant->workspace_id,
|
||||
@ -239,94 +219,3 @@ function seedTrustworthyCompare(array $tenantContext): void
|
||||
->assertSee('Open findings')
|
||||
->assertDontSee('Aligned');
|
||||
});
|
||||
|
||||
it('suppresses calm dashboard wording when the latest backup basis is stale even if older history looked healthier', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
$tenantContext = createTruthAlignedDashboardTenant();
|
||||
[$user, $tenant] = $tenantContext;
|
||||
$this->actingAs($user);
|
||||
|
||||
seedTrustworthyCompare($tenantContext);
|
||||
|
||||
$olderHealthy = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Older healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(3),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($olderHealthy)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$latestStale = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Latest stale backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($latestStale)->create([
|
||||
'payload' => ['id' => 'stale-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Latest backup is stale')
|
||||
->assertDontSee('Backups are recent and healthy')
|
||||
->assertDontSee('Current governance and findings signals look trustworthy.');
|
||||
});
|
||||
|
||||
it('adds positive backup calmness only when the latest backup basis is recent, clean, and schedules do not need follow-up', function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
|
||||
$tenantContext = createTruthAlignedDashboardTenant();
|
||||
[$user, $tenant] = $tenantContext;
|
||||
$this->actingAs($user);
|
||||
|
||||
seedTrustworthyCompare($tenantContext);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(20),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
Filament::setCurrentPanel(Filament::getPanel('tenant'));
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Backups are recent and healthy')
|
||||
->assertDontSee('Backup schedules need follow-up');
|
||||
|
||||
BackupSchedule::query()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Overdue dashboard schedule',
|
||||
'is_enabled' => true,
|
||||
'timezone' => 'UTC',
|
||||
'frequency' => 'daily',
|
||||
'time_of_day' => '01:00:00',
|
||||
'days_of_week' => null,
|
||||
'policy_types' => ['deviceConfiguration'],
|
||||
'include_foundations' => true,
|
||||
'retention_keep_last' => 30,
|
||||
'last_run_at' => null,
|
||||
'last_run_status' => null,
|
||||
'next_run_at' => now()->subHours(2),
|
||||
]);
|
||||
|
||||
Livewire::test(NeedsAttention::class)
|
||||
->assertSee('Backup schedules need follow-up')
|
||||
->assertDontSee('Backups are recent and healthy');
|
||||
});
|
||||
|
||||
@ -1,60 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\Resources\BackupSetResource;
|
||||
use App\Filament\Resources\PolicyVersionResource;
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Policy;
|
||||
use App\Models\PolicyVersion;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
it('keeps backup quality visible to readonly tenant members on backup and version surfaces', function (): void {
|
||||
[$user, $tenant] = createUserWithTenant(role: 'readonly');
|
||||
|
||||
$this->actingAs($user);
|
||||
Filament::setTenant($tenant, true);
|
||||
|
||||
$backupSet = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Readonly backup',
|
||||
'item_count' => 1,
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($backupSet)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$policy = Policy::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'display_name' => 'Readonly policy',
|
||||
'policy_type' => 'settingsCatalogPolicy',
|
||||
'platform' => 'windows',
|
||||
]);
|
||||
|
||||
$version = PolicyVersion::factory()->create([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'policy_id' => (int) $policy->getKey(),
|
||||
'snapshot' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
],
|
||||
]);
|
||||
|
||||
$this->get(BackupSetResource::getUrl('view', ['record' => $backupSet], tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Metadata only');
|
||||
|
||||
$this->get(PolicyVersionResource::getUrl('view', ['record' => $version], tenant: $tenant))
|
||||
->assertOk()
|
||||
->assertSee('Backup quality')
|
||||
->assertSee('Metadata only');
|
||||
});
|
||||
@ -159,81 +159,3 @@
|
||||
->and(data_get($updated->metadata, 'assignments_fetch_failed'))->toBeFalse()
|
||||
->and(data_get($updated->metadata, 'assignments_fetch_error'))->toBeNull();
|
||||
});
|
||||
|
||||
it('records orphaned assignment metadata when resolved groups are missing in the tenant', function () {
|
||||
$tenant = Tenant::factory()->create([
|
||||
'tenant_id' => 'tenant-123',
|
||||
'external_id' => 'tenant-123',
|
||||
]);
|
||||
|
||||
ensureDefaultProviderConnection($tenant, 'microsoft');
|
||||
|
||||
$backupItem = BackupItem::factory()->create([
|
||||
'tenant_id' => $tenant->id,
|
||||
'metadata' => [],
|
||||
'assignments' => null,
|
||||
]);
|
||||
|
||||
$this->mock(AssignmentFetcher::class, function (MockInterface $mock) {
|
||||
$mock->shouldReceive('supportsStandardAssignments')
|
||||
->once()
|
||||
->with('settingsCatalogPolicy', null)
|
||||
->andReturnTrue();
|
||||
|
||||
$mock->shouldReceive('fetch')
|
||||
->once()
|
||||
->andReturn([
|
||||
[
|
||||
'id' => 'assignment-1',
|
||||
'intent' => 'apply',
|
||||
'target' => [
|
||||
'@odata.type' => '#microsoft.graph.groupAssignmentTarget',
|
||||
'groupId' => 'group-123',
|
||||
],
|
||||
],
|
||||
]);
|
||||
});
|
||||
|
||||
$this->mock(GroupResolver::class, function (MockInterface $mock) {
|
||||
$mock->shouldReceive('resolveGroupIds')
|
||||
->once()
|
||||
->andReturn([
|
||||
'group-123' => [
|
||||
'id' => 'group-123',
|
||||
'displayName' => 'Missing Group',
|
||||
'orphaned' => true,
|
||||
],
|
||||
]);
|
||||
});
|
||||
|
||||
$this->mock(AssignmentFilterResolver::class, function (MockInterface $mock) {
|
||||
$mock->shouldReceive('resolve')
|
||||
->once()
|
||||
->with([], \Mockery::type(Tenant::class))
|
||||
->andReturn([]);
|
||||
});
|
||||
|
||||
$this->mock(ScopeTagResolver::class, function (MockInterface $mock) use ($tenant) {
|
||||
$mock->shouldReceive('resolve')
|
||||
->once()
|
||||
->with(['0'], $tenant)
|
||||
->andReturn([
|
||||
['id' => '0', 'displayName' => 'Default'],
|
||||
]);
|
||||
});
|
||||
|
||||
$updated = app(AssignmentBackupService::class)->enrichWithAssignments(
|
||||
backupItem: $backupItem,
|
||||
tenant: $tenant,
|
||||
policyType: 'settingsCatalogPolicy',
|
||||
policyId: 'policy-123',
|
||||
policyPayload: [
|
||||
'roleScopeTagIds' => ['0'],
|
||||
],
|
||||
includeAssignments: true,
|
||||
);
|
||||
|
||||
expect($updated->assignments)->toHaveCount(1)
|
||||
->and(data_get($updated->metadata, 'assignments_fetch_failed'))->toBeFalse()
|
||||
->and(data_get($updated->metadata, 'has_orphaned_assignments'))->toBeTrue();
|
||||
});
|
||||
|
||||
@ -139,60 +139,6 @@
|
||||
expect($backupItem->assignmentsFetchFailed())->toBeFalse();
|
||||
});
|
||||
|
||||
test('snapshotSource prefers snapshot source metadata when present', function () {
|
||||
$backupItem = BackupItem::factory()->create([
|
||||
'metadata' => [
|
||||
'source' => 'policy_version',
|
||||
'snapshot_source' => 'metadata_only',
|
||||
],
|
||||
]);
|
||||
|
||||
expect($backupItem->snapshotSource())->toBe('metadata_only');
|
||||
});
|
||||
|
||||
test('assignmentCaptureReason returns trimmed capture reason metadata', function () {
|
||||
$backupItem = BackupItem::factory()->create([
|
||||
'metadata' => [
|
||||
'assignment_capture_reason' => ' separate_role_assignments ',
|
||||
],
|
||||
]);
|
||||
|
||||
expect($backupItem->assignmentCaptureReason())->toBe('separate_role_assignments');
|
||||
});
|
||||
|
||||
test('warningMessages filters non-string and empty warning entries', function () {
|
||||
$backupItem = BackupItem::factory()->create([
|
||||
'metadata' => [
|
||||
'warnings' => [' metadata fallback ', '', null, 123],
|
||||
],
|
||||
]);
|
||||
|
||||
expect($backupItem->warningMessages())->toBe(['metadata fallback']);
|
||||
});
|
||||
|
||||
test('integrityWarning returns trimmed integrity metadata', function () {
|
||||
$backupItem = BackupItem::factory()->create([
|
||||
'metadata' => [
|
||||
'integrity_warning' => ' Protected values are intentionally hidden. ',
|
||||
],
|
||||
]);
|
||||
|
||||
expect($backupItem->integrityWarning())->toBe('Protected values are intentionally hidden.');
|
||||
});
|
||||
|
||||
test('hasCapturedPayload reflects whether payload data exists', function () {
|
||||
$emptyPayload = BackupItem::factory()->create([
|
||||
'payload' => [],
|
||||
]);
|
||||
|
||||
$capturedPayload = BackupItem::factory()->create([
|
||||
'payload' => ['id' => 'policy-1'],
|
||||
]);
|
||||
|
||||
expect($emptyPayload->hasCapturedPayload())->toBeFalse()
|
||||
->and($capturedPayload->hasCapturedPayload())->toBeTrue();
|
||||
});
|
||||
|
||||
test('scopeWithAssignments filters items with assignments', function () {
|
||||
BackupItem::factory()->create(['assignments' => null]);
|
||||
BackupItem::factory()->create(['assignments' => []]);
|
||||
|
||||
@ -1,221 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSchedule;
|
||||
use App\Models\BackupSet;
|
||||
use App\Models\Tenant;
|
||||
use App\Support\BackupHealth\BackupHealthActionTarget;
|
||||
use App\Support\BackupHealth\TenantBackupHealthAssessment;
|
||||
use App\Support\BackupHealth\TenantBackupHealthResolver;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
beforeEach(function (): void {
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::create(2026, 4, 7, 12, 0, 0, 'UTC'));
|
||||
});
|
||||
|
||||
afterEach(function (): void {
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
function makeBackupHealthSchedule(Tenant $tenant, array $attributes = []): BackupSchedule
|
||||
{
|
||||
return BackupSchedule::query()->create(array_merge([
|
||||
'tenant_id' => (int) $tenant->getKey(),
|
||||
'name' => 'Backup health schedule',
|
||||
'is_enabled' => true,
|
||||
'timezone' => 'UTC',
|
||||
'frequency' => 'daily',
|
||||
'time_of_day' => '01:00:00',
|
||||
'days_of_week' => null,
|
||||
'policy_types' => ['deviceConfiguration'],
|
||||
'include_foundations' => true,
|
||||
'retention_keep_last' => 30,
|
||||
'next_run_at' => now()->addHour(),
|
||||
], $attributes));
|
||||
}
|
||||
|
||||
function resolveTenantBackupHealth(Tenant $tenant): TenantBackupHealthAssessment
|
||||
{
|
||||
return app(TenantBackupHealthResolver::class)->assess($tenant);
|
||||
}
|
||||
|
||||
it('marks the tenant absent when no usable completed backup basis exists', function (): void {
|
||||
[, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
|
||||
$assessment = resolveTenantBackupHealth($tenant);
|
||||
|
||||
expect($assessment->posture)->toBe(TenantBackupHealthAssessment::POSTURE_ABSENT)
|
||||
->and($assessment->primaryReason)->toBe(TenantBackupHealthAssessment::REASON_NO_BACKUP_BASIS)
|
||||
->and($assessment->latestRelevantBackupSetId)->toBeNull()
|
||||
->and($assessment->healthyClaimAllowed)->toBeFalse()
|
||||
->and($assessment->primaryActionTarget?->surface)->toBe(BackupHealthActionTarget::SURFACE_BACKUP_SETS_INDEX);
|
||||
});
|
||||
|
||||
it('lets the latest stale backup basis outrank older healthier history and preserves degradation as supporting detail', function (): void {
|
||||
[, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
|
||||
$olderHealthy = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Older healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(3),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($olderHealthy)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$latestStale = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Latest stale backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subDays(2),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($latestStale)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$assessment = resolveTenantBackupHealth($tenant);
|
||||
|
||||
expect($assessment->latestRelevantBackupSetId)->toBe((int) $latestStale->getKey())
|
||||
->and($assessment->posture)->toBe(TenantBackupHealthAssessment::POSTURE_STALE)
|
||||
->and($assessment->primaryReason)->toBe(TenantBackupHealthAssessment::REASON_LATEST_BACKUP_STALE)
|
||||
->and($assessment->qualitySummary?->hasDegradations())->toBeTrue()
|
||||
->and($assessment->supportingMessage)->toContain('The latest completed backup was 2 days ago.')
|
||||
->and($assessment->supportingMessage)->toContain('also degraded');
|
||||
});
|
||||
|
||||
it('reuses the backup quality resolver when the latest recent backup is degraded', function (): void {
|
||||
[, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
|
||||
$latestDegraded = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Latest degraded backup',
|
||||
'item_count' => 2,
|
||||
'completed_at' => now()->subHour(),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($latestDegraded)->create([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($latestDegraded)->create([
|
||||
'payload' => ['id' => 'warning-policy'],
|
||||
'metadata' => [
|
||||
'integrity_warning' => 'Protected values are intentionally hidden.',
|
||||
],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$assessment = resolveTenantBackupHealth($tenant);
|
||||
|
||||
expect($assessment->posture)->toBe(TenantBackupHealthAssessment::POSTURE_DEGRADED)
|
||||
->and($assessment->primaryReason)->toBe(TenantBackupHealthAssessment::REASON_LATEST_BACKUP_DEGRADED)
|
||||
->and($assessment->qualitySummary?->degradedItemCount)->toBe(2)
|
||||
->and($assessment->qualitySummary?->compactSummary)->toContain('2 degraded items')
|
||||
->and($assessment->supportingMessage)->toContain('The latest completed backup was 1 hour ago.')
|
||||
->and($assessment->primaryActionTarget?->surface)->toBe(BackupHealthActionTarget::SURFACE_BACKUP_SET_VIEW)
|
||||
->and($assessment->primaryActionTarget?->recordId)->toBe((int) $latestDegraded->getKey());
|
||||
});
|
||||
|
||||
it('allows a healthy claim only when the latest backup is recent and free of material degradation', function (): void {
|
||||
[, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy backup',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(30),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
$assessment = resolveTenantBackupHealth($tenant);
|
||||
|
||||
expect($assessment->posture)->toBe(TenantBackupHealthAssessment::POSTURE_HEALTHY)
|
||||
->and($assessment->primaryReason)->toBeNull()
|
||||
->and($assessment->healthyClaimAllowed)->toBeTrue()
|
||||
->and($assessment->headline)->toBe('Backups are recent and healthy.')
|
||||
->and($assessment->supportingMessage)->toBe('The latest completed backup was 30 minutes ago.')
|
||||
->and($assessment->primaryActionTarget)->toBeNull();
|
||||
});
|
||||
|
||||
it('keeps the posture healthy but suppresses the healthy claim when schedules need follow-up', function (): void {
|
||||
[, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy backup with overdue schedule',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(15),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
makeBackupHealthSchedule($tenant, [
|
||||
'name' => 'Overdue schedule',
|
||||
'next_run_at' => now()->subHours(2),
|
||||
'last_run_at' => null,
|
||||
'last_run_status' => null,
|
||||
]);
|
||||
|
||||
$assessment = resolveTenantBackupHealth($tenant);
|
||||
|
||||
expect($assessment->posture)->toBe(TenantBackupHealthAssessment::POSTURE_HEALTHY)
|
||||
->and($assessment->primaryReason)->toBe(TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP)
|
||||
->and($assessment->healthyClaimAllowed)->toBeFalse()
|
||||
->and($assessment->scheduleFollowUp->needsFollowUp)->toBeTrue()
|
||||
->and($assessment->scheduleFollowUp->neverSuccessfulCount)->toBe(1)
|
||||
->and($assessment->primaryActionTarget?->surface)->toBe(BackupHealthActionTarget::SURFACE_BACKUP_SCHEDULES_INDEX);
|
||||
});
|
||||
|
||||
it('treats failed recent schedule runs as backup follow-up even when the next run is not overdue yet', function (): void {
|
||||
[, $tenant] = createUserWithTenant(ensureDefaultMicrosoftProviderConnection: false);
|
||||
|
||||
$healthyBackup = BackupSet::factory()->for($tenant)->create([
|
||||
'name' => 'Healthy backup with failed schedule',
|
||||
'item_count' => 1,
|
||||
'completed_at' => now()->subMinutes(20),
|
||||
]);
|
||||
|
||||
BackupItem::factory()->for($tenant)->for($healthyBackup)->create([
|
||||
'payload' => ['id' => 'healthy-policy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]);
|
||||
|
||||
makeBackupHealthSchedule($tenant, [
|
||||
'name' => 'Failed schedule',
|
||||
'last_run_at' => now()->subHour(),
|
||||
'last_run_status' => 'failed',
|
||||
'next_run_at' => now()->addHour(),
|
||||
]);
|
||||
|
||||
$assessment = resolveTenantBackupHealth($tenant);
|
||||
|
||||
expect($assessment->posture)->toBe(TenantBackupHealthAssessment::POSTURE_HEALTHY)
|
||||
->and($assessment->primaryReason)->toBe(TenantBackupHealthAssessment::REASON_SCHEDULE_FOLLOW_UP)
|
||||
->and($assessment->scheduleFollowUp->failedRecentRunCount)->toBe(1)
|
||||
->and($assessment->scheduleFollowUp->summaryMessage)->toContain('needs follow-up after the last run');
|
||||
});
|
||||
@ -1,87 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\PolicyVersion;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use App\Support\RedactionIntegrity;
|
||||
|
||||
it('derives metadata-only and assignment degradations from backup item metadata', function (): void {
|
||||
$summary = app(BackupQualityResolver::class)->forBackupItem(new BackupItem([
|
||||
'payload' => [],
|
||||
'assignments' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
'has_orphaned_assignments' => true,
|
||||
'integrity_warning' => 'Protected values are intentionally hidden.',
|
||||
'assignment_capture_reason' => 'separate_role_assignments',
|
||||
],
|
||||
]));
|
||||
|
||||
expect($summary->snapshotMode)->toBe('metadata_only')
|
||||
->and($summary->hasAssignmentIssues)->toBeTrue()
|
||||
->and($summary->hasOrphanedAssignments)->toBeTrue()
|
||||
->and($summary->hasIntegrityWarning())->toBeTrue()
|
||||
->and($summary->degradationFamilies)->toBe([
|
||||
'metadata_only',
|
||||
'assignment_capture_issue',
|
||||
'orphaned_assignments',
|
||||
'integrity_warning',
|
||||
])
|
||||
->and($summary->qualityHighlights)->toContain(
|
||||
'Metadata only',
|
||||
'Assignment fetch failed',
|
||||
'Orphaned assignments',
|
||||
'Integrity warning',
|
||||
);
|
||||
});
|
||||
|
||||
it('uses unknown quality only when backup item metadata cannot justify a stronger claim', function (): void {
|
||||
$resolver = app(BackupQualityResolver::class);
|
||||
|
||||
$unknownSummary = $resolver->forBackupItem(new BackupItem([
|
||||
'payload' => [],
|
||||
'assignments' => [],
|
||||
'metadata' => [],
|
||||
]));
|
||||
|
||||
$assignmentIssueSummary = $resolver->forBackupItem(new BackupItem([
|
||||
'payload' => [],
|
||||
'assignments' => [],
|
||||
'metadata' => [
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
]));
|
||||
|
||||
expect($unknownSummary->degradationFamilies)->toBe(['unknown_quality'])
|
||||
->and($unknownSummary->compactSummary)->toBe('Unknown quality')
|
||||
->and($assignmentIssueSummary->degradationFamilies)->toBe(['assignment_capture_issue'])
|
||||
->and($assignmentIssueSummary->qualityHighlights)->not->toContain('Unknown quality');
|
||||
});
|
||||
|
||||
it('derives policy version integrity warnings from existing redaction context', function (): void {
|
||||
$summary = app(BackupQualityResolver::class)->forPolicyVersion(new PolicyVersion([
|
||||
'snapshot' => [
|
||||
'id' => 'policy-1',
|
||||
'displayName' => 'Policy One',
|
||||
],
|
||||
'metadata' => [
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'secret_fingerprints' => [
|
||||
'snapshot' => ['/clientSecret' => 'abc123'],
|
||||
'assignments' => [],
|
||||
'scope_tags' => [],
|
||||
],
|
||||
]));
|
||||
|
||||
expect($summary->snapshotMode)->toBe('full')
|
||||
->and($summary->hasAssignmentIssues)->toBeTrue()
|
||||
->and($summary->integrityWarning)->toBe(RedactionIntegrity::protectedValueNote())
|
||||
->and($summary->degradationFamilies)->toBe([
|
||||
'assignment_capture_issue',
|
||||
'integrity_warning',
|
||||
]);
|
||||
});
|
||||
@ -1,75 +0,0 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Models\BackupItem;
|
||||
use App\Models\BackupSet;
|
||||
use App\Support\BackupQuality\BackupQualityResolver;
|
||||
use Illuminate\Database\Eloquent\Collection as EloquentCollection;
|
||||
|
||||
it('renders a clear backup-set summary when no degradations are detected', function (): void {
|
||||
$backupSet = new BackupSet([
|
||||
'status' => 'completed',
|
||||
'item_count' => 2,
|
||||
]);
|
||||
|
||||
$backupSet->setRelation('items', new EloquentCollection([
|
||||
new BackupItem([
|
||||
'payload' => ['id' => 'one'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]),
|
||||
new BackupItem([
|
||||
'payload' => ['id' => 'two'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]),
|
||||
]));
|
||||
|
||||
$summary = app(BackupQualityResolver::class)->summarizeBackupSet($backupSet);
|
||||
|
||||
expect($summary->degradedItemCount)->toBe(0)
|
||||
->and($summary->compactSummary)->toBe('No degradations detected across 2 items')
|
||||
->and($summary->summaryMessage)->toBe('No degradations were detected across 2 captured items.');
|
||||
});
|
||||
|
||||
it('aggregates degraded backup-set counts from existing item metadata', function (): void {
|
||||
$backupSet = new BackupSet([
|
||||
'status' => 'completed',
|
||||
'item_count' => 3,
|
||||
]);
|
||||
|
||||
$backupSet->setRelation('items', new EloquentCollection([
|
||||
new BackupItem([
|
||||
'payload' => ['id' => 'healthy'],
|
||||
'metadata' => [],
|
||||
'assignments' => [],
|
||||
]),
|
||||
new BackupItem([
|
||||
'payload' => [],
|
||||
'metadata' => [
|
||||
'source' => 'metadata_only',
|
||||
'assignments_fetch_failed' => true,
|
||||
],
|
||||
'assignments' => [],
|
||||
]),
|
||||
new BackupItem([
|
||||
'payload' => ['id' => 'warning'],
|
||||
'metadata' => [
|
||||
'has_orphaned_assignments' => true,
|
||||
'integrity_warning' => 'Protected values are intentionally hidden.',
|
||||
],
|
||||
'assignments' => [],
|
||||
]),
|
||||
]));
|
||||
|
||||
$summary = app(BackupQualityResolver::class)->summarizeBackupSet($backupSet);
|
||||
|
||||
expect($summary->degradedItemCount)->toBe(2)
|
||||
->and($summary->metadataOnlyCount)->toBe(1)
|
||||
->and($summary->assignmentIssueCount)->toBe(1)
|
||||
->and($summary->orphanedAssignmentCount)->toBe(1)
|
||||
->and($summary->integrityWarningCount)->toBe(1)
|
||||
->and($summary->compactSummary)->toBe('2 degraded items • 1 metadata-only • 1 assignment issue • 1 orphaned assignment • 1 integrity warning')
|
||||
->and($summary->nextAction)->toBe('Open the backup set detail and inspect degraded items before continuing into restore.');
|
||||
});
|
||||
Loading…
Reference in New Issue
Block a user