ahmido
05a604cfb6
Implements Spec 076 enterprise remediation UX for tenant required permissions. Highlights - Above-the-fold overview (impact + counts) with missing-first experience - Feature-based grouping, filters/search, copy-to-clipboard for missing app/delegated permissions - Tenant-scoped deny-as-not-found semantics; DB-only viewing - Centralized badge semantics (no ad-hoc status mapping) Testing - Feature tests for default filters, grouping, copy output, and non-member 404 behavior. Integration - Adds deep links from verification checks to the Required permissions page. Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Reviewed-on: #92
60 lines
2.1 KiB
Markdown
60 lines
2.1 KiB
Markdown
# Verification Report — Clustered Checks (Spec 076)
|
||
|
||
This feature extends the existing verification report (`operation_runs.context.verification_report`) with additional *clustered* checks derived from required-permission coverage.
|
||
|
||
## Source of truth
|
||
- Schema: `app/Support/Verification/VerificationReportSchema.php` (v1.x)
|
||
- Writer: `app/Support/Verification/VerificationReportWriter.php`
|
||
|
||
## Proposed check keys (stable)
|
||
|
||
The report should contain 5–7 checks. Suggested keys:
|
||
|
||
1) `provider.connection.check` (existing)
|
||
2) `permissions.admin_consent`
|
||
3) `permissions.directory_groups`
|
||
4) `permissions.intune_configuration`
|
||
5) `permissions.intune_apps`
|
||
6) `permissions.intune_rbac_assignments`
|
||
7) `permissions.scripts_remediations` (optional / skip when irrelevant)
|
||
|
||
## Check computation rules
|
||
|
||
Each check must produce the fields required by the schema:
|
||
- `key`, `title`, `status` (`pass|fail|warn|skip|running`)
|
||
- `severity` (`info|warning|critical|...`)
|
||
- `blocking` (bool)
|
||
- `reason_code`, `message`
|
||
- `evidence[]` pointers
|
||
- `next_steps[]` links
|
||
|
||
### Permission-derived checks
|
||
- Input: permission comparison rows from `TenantPermissionService::compare(...persist: false, liveCheck: false)`.
|
||
- Status rules:
|
||
- `pass`: all mapped permissions are granted
|
||
- `fail`: at least one mapped permission is missing and the cluster is marked blocking
|
||
- `warn`: optional/non-blocking missing permissions (if introduced later)
|
||
- `skip`: no mapped permissions apply (or feature is irrelevant)
|
||
|
||
### Evidence pointers
|
||
Recommended evidence pointers:
|
||
- `{ kind: 'missing_permission', value: '<permission_key>' }`
|
||
- `{ kind: 'permission_type', value: 'application|delegated' }`
|
||
- `{ kind: 'feature', value: '<feature_key>' }`
|
||
|
||
### Next steps
|
||
For `fail`/blocking checks:
|
||
- Include a CTA: `Open required permissions` → links to the tenant-scoped Required Permissions page.
|
||
- Optionally include a pre-filtered URL by feature.
|
||
|
||
## Issues-first rendering
|
||
UI should sort checks:
|
||
1) blocking fails
|
||
2) non-blocking fails
|
||
3) warns
|
||
4) running
|
||
5) skips
|
||
6) passes
|
||
|
||
The onboarding wizard verify step should render the same check set, not only `failure_summary`.
|