## Summary - add Intune RBAC role definitions and role assignments as foundation-backed inventory, backup, and versioned snapshot types - add RBAC-specific normalization, coverage, permission-warning handling, and preview-only restore safety behavior across existing Filament and service surfaces - add spec 127 artifacts, contracts, audits, and focused regression coverage for inventory, backup, versioning, verification, and authorization behavior ## Testing - `vendor/bin/sail bin pint --dirty --format agent` - `vendor/bin/sail artisan test --compact tests/Feature/Inventory/InventorySyncServiceTest.php tests/Feature/Filament/InventoryCoverageTableTest.php tests/Feature/FoundationBackupTest.php tests/Feature/Filament/RestoreExecutionTest.php tests/Feature/RestoreUnknownPolicyTypeSafetyTest.php tests/Unit/GraphContractRegistryTest.php tests/Unit/FoundationSnapshotServiceTest.php tests/Feature/Verification/IntuneRbacPermissionCoverageTest.php tests/Unit/IntuneRoleDefinitionNormalizerTest.php tests/Unit/IntuneRoleAssignmentNormalizerTest.php` ## Notes - tasks in `specs/127-rbac-inventory-backup/tasks.md` are complete except `T041`, which is the documented manual QA validation step Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #155
14 KiB
Tasks: Intune RBAC Inventory & Backup v1 (127)
Input: Design documents from specs/127-rbac-inventory-backup/ (spec.md, plan.md, research.md, data-model.md, contracts/)
Prerequisites: specs/127-rbac-inventory-backup/plan.md (required), specs/127-rbac-inventory-backup/spec.md (required for user stories)
Tests: REQUIRED (Pest) for all runtime behavior changes in this repo.
Operations: Reuse existing OperationRun flows for inventory sync and backup capture; do not add ad-hoc operation feedback or notification patterns.
RBAC: Preserve tenant/admin plane enforcement, deny-as-not-found 404 for non-members, 403 for in-scope members missing capability, and canonical capability registry usage only.
Filament UI: No new Filament resource/page is added; existing coverage, backup/version, and provider verification surfaces are extended only.
Phase 1: Setup (Shared Infrastructure)
Purpose: Reconfirm the relevant existing architecture and validation surfaces before changing config-driven foundation behavior.
- T001 Review existing foundation type registration in
config/tenantpilot.php - T002 Review existing RBAC-related Graph contracts in
config/graph_contracts.php - T003 [P] Review foundation inventory sync flow in
app/Services/Inventory/InventorySyncService.php - T004 [P] Review foundation backup and version capture flow in
app/Services/Intune/FoundationSnapshotService.php,app/Services/Intune/BackupService.php, andapp/Services/Intune/VersionService.php - T005 [P] Review RBAC permission warning patterns in
app/Support/Verification/TenantPermissionCheckClusters.php,app/Support/Providers/ProviderReasonCodes.php, andapp/Services/Graph/ScopeTagResolver.php
Phase 2: Foundational (Blocking Prerequisites)
Purpose: Shared config and registry work that must exist before inventory, backup, or safety behavior can be implemented.
⚠️ CRITICAL: No user story work should begin until this phase is complete.
- T006 Add
intuneRoleDefinitionandintuneRoleAssignmentfoundation metadata inconfig/tenantpilot.php - T007 Add inventory-grade RBAC Graph contract entries in
config/graph_contracts.php - T008 Update RBAC contract helper coverage for the new inventory-grade keys in
app/Services/Graph/GraphContractRegistry.php - T009 [P] Extend foundation metadata resolution for RBAC category and preview-only semantics in
app/Support/Inventory/InventoryPolicyTypeMeta.php - T010 [P] Add or extend Graph contract sanitization coverage for RBAC foundation keys in
tests/Unit/GraphContractRegistryTest.php - T011 [P] Add config registration coverage for RBAC foundations in
tests/Feature/Filament/InventoryCoverageTableTest.phpandtests/Feature/RestoreUnknownPolicyTypeSafetyTest.php
Checkpoint: Foundation type config, contract registry, and metadata resolution are ready; user stories can now proceed.
Phase 3: User Story 1 - Capture Intune RBAC Inventory (Priority: P1) 🎯 MVP
Goal: Tenant inventory sync captures RBAC Role Definitions and Role Assignments as first-class foundation inventory items and reports them in coverage under RBAC.
Independent Test: Run tenant inventory sync with mocked RBAC responses and verify InventoryItem rows plus coverage.foundation_types entries for both RBAC types without needing backup capture.
Tests for User Story 1
- T012 [P] [US1] Add inventory sync coverage for RBAC foundation upserts in
tests/Feature/Inventory/InventorySyncServiceTest.php - T013 [P] [US1] Add coverage page assertions for RBAC foundation rows and category labeling in
tests/Feature/Filament/InventoryCoverageTableTest.php - T014 [P] [US1] Add foundation snapshot paging and payload-shape coverage for RBAC types in
tests/Unit/FoundationSnapshotServiceTest.php
Implementation for User Story 1
- T015 [US1] Extend foundation inventory sync persistence for
intuneRoleDefinitionandintuneRoleAssignmentinapp/Services/Inventory/InventorySyncService.php - T016 [US1] Add RBAC-specific sanitized metadata shaping for observed inventory rows in
app/Services/Inventory/InventorySyncService.php - T017 [US1] Extend foundation snapshot fetch behavior for full-fidelity RBAC capture in
app/Services/Intune/FoundationSnapshotService.php - T018 [US1] Surface RBAC foundation metadata in inventory coverage presentation using
app/Support/Inventory/InventoryPolicyTypeMeta.phpandapp/Filament/Pages/InventoryCoverage.php
Checkpoint: User Story 1 is complete when sync creates RBAC inventory rows and coverage shows both RBAC foundation types under the RBAC category.
Phase 4: User Story 2 - Review Immutable RBAC History (Priority: P1)
Goal: Backup set detail and policy version history/detail surfaces show immutable RBAC snapshots with readable normalized content for both role definitions and assignments.
Independent Test: Create a backup set with foundations enabled and verify RBAC backup items and policy version entries exist with full payloads and readable normalized content in backup set detail and policy version detail surfaces.
Tests for User Story 2
- T019 [P] [US2] Add backup foundation capture coverage for RBAC role definitions and assignments in
tests/Feature/FoundationBackupTest.php - T020 [P] [US2] Add Role Definition normalizer coverage for built-in and custom roles in
tests/Unit/IntuneRoleDefinitionNormalizerTest.php - T021 [P] [US2] Add Role Assignment normalizer coverage for role, principals, scopes, and fallback identifiers in
tests/Unit/IntuneRoleAssignmentNormalizerTest.php - T022 [P] [US2] Add version capture and reuse coverage for RBAC foundations in
tests/Feature/BackupServiceVersionReuseTest.phpandtests/Feature/VersionCaptureMetadataOnlyTest.php - T023 [P] [US2] Add backup set and policy version surface assertions for readable RBAC history in
tests/Feature/Rbac/BackupItemsRelationManagerSemanticsTest.phpandtests/Feature/Filament/PolicyVersionTest.php
Implementation for User Story 2
- T024 [US2] Capture RBAC foundation backup items and aligned version history entries through
app/Services/Intune/BackupService.phpandapp/Services/Intune/VersionService.php - T025 [P] [US2] Implement
IntuneRoleDefinitionNormalizerinapp/Services/Intune/IntuneRoleDefinitionNormalizer.php - T026 [P] [US2] Implement
IntuneRoleAssignmentNormalizerinapp/Services/Intune/IntuneRoleAssignmentNormalizer.php - T027 [US2] Register RBAC normalizers in
app/Providers/AppServiceProvider.php - T028 [US2] Extend normalized backup set and policy version rendering for RBAC foundation items in
app/Services/Intune/PolicyNormalizer.php,app/Filament/Resources/BackupSetResource.php,app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php, andapp/Filament/Resources/PolicyVersionResource.php
Checkpoint: User Story 2 is complete when RBAC backup items and policy version history entries are created and render readable, immutable snapshot content for audit review.
Phase 5: User Story 3 - Preserve Safe Read-Only Governance Posture (Priority: P2)
Goal: RBAC remains clearly preview-only for restore, permission gaps are surfaced gracefully, and tenant/workspace isolation remains enforced for RBAC coverage and history surfaces.
Independent Test: Verify restore-adjacent surfaces mark both RBAC types as preview-only, missing DeviceManagementRBAC.Read.All yields a clear warning or reason, and unauthorized access remains 404 or 403 as appropriate.
Tests for User Story 3
- T029 [P] [US3] Add preview-only restore guard coverage for RBAC foundation types in
tests/Feature/RestoreUnknownPolicyTypeSafetyTest.phpandtests/Feature/Filament/RestoreExecutionTest.php - T030 [P] [US3] Add verification or permission-warning coverage for missing
DeviceManagementRBAC.Read.Allintests/Feature/Verification/IntuneRbacPermissionCoverageTest.php - T031 [P] [US3] Add tenant/workspace isolation coverage for RBAC backup or coverage visibility in
tests/Feature/WorkspaceIsolation/TenantOwnedWorkspaceInvariantTest.php,tests/Feature/Filament/InventoryCoverageTableTest.php, andtests/Feature/Filament/PolicyVersionTest.php - T032 [P] [US3] Add badge or restore-mode mapping coverage for preview-only RBAC foundations in
tests/Unit/Badges/PolicyBadgesTest.php
Implementation for User Story 3
- T033 [US3] Preserve preview-only RBAC restore semantics in
app/Services/Intune/RestoreRiskChecker.phpandapp/Services/Intune/RestoreService.php - T034 [US3] Add graceful RBAC permission-warning clustering and next-step messaging in
app/Support/Verification/TenantPermissionCheckClusters.php - T035 [US3] Extend provider reason mapping for RBAC read gaps where needed in
app/Support/Providers/ProviderReasonCodes.phpand related verification helpers underapp/Support/Verification/ - T036 [US3] Ensure backup set, policy version, coverage, and verification surfaces present RBAC support state without bypassing existing tenant/admin authorization in
app/Filament/Pages/InventoryCoverage.php,app/Filament/Resources/BackupSetResource.php,app/Filament/Resources/PolicyVersionResource.php, and related policies or helpers already backing those surfaces
Checkpoint: User Story 3 is complete when RBAC is clearly read-only and safe, permission gaps are operator-readable, and no scope leakage is introduced.
Phase 6: Polish & Cross-Cutting Concerns
Purpose: Final verification, formatting, and cross-story regression protection.
- T037 [P] Add or update targeted contract documentation examples in
specs/127-rbac-inventory-backup/contracts/rbac-foundation.openapi.yamlandspecs/127-rbac-inventory-backup/contracts/foundation-rbac-snapshot.schema.jsonif implementation shape changed - T038 [P] Add reused
OperationRunnotification and summary-count regression coverage for RBAC inventory and backup/version flows intests/Feature/Notifications/OperationRunNotificationTest.phpandtests/Feature/OpsUx/OperationRunSummaryCountsIncrementTest.php - T039 Run formatting for changed files via
specs/127-rbac-inventory-backup/quickstart.md - T040 Run focused Pest verification from
specs/127-rbac-inventory-backup/quickstart.md - T041 Validate manual QA checklist from
specs/127-rbac-inventory-backup/quickstart.md
Dependencies & Execution Order
Phase Dependencies
- Setup (Phase 1): No dependencies; start immediately.
- Foundational (Phase 2): Depends on Setup; blocks all user stories.
- User Story 1 (Phase 3): Depends on Foundational completion.
- User Story 2 (Phase 4): Depends on Foundational completion and benefits from US1 because the same RBAC type metadata and contracts are already in place.
- User Story 3 (Phase 5): Depends on Foundational completion and should run after US1/US2 touch the relevant coverage and backup surfaces.
- Polish (Phase 6): Depends on all desired user stories being complete.
User Story Dependencies
- US1 (P1): First deliverable and MVP. No dependency on other user stories.
- US2 (P1): Depends on the same shared config/contract work as US1, but can proceed once foundational work is done.
- US3 (P2): Builds on the RBAC types being visible in coverage and backup flows, so it should follow US1 and US2.
Within Each User Story
- Tests should be added before or alongside implementation and must fail before the feature code is considered complete.
- Config/registry changes precede service changes.
- Service changes precede Filament presentation adjustments.
- Story-specific implementation is complete only when its focused tests pass.
Parallel Opportunities
- Setup review tasks marked
[P]can be done in parallel. - In Phase 2, metadata and test tasks
T009toT011can run in parallel after the core config/contract additions begin. - In US1,
T012toT014can run in parallel, andT017can proceed in parallel with metadata work once contracts are defined. - In US2, the two normalizer implementations
T025andT026can run in parallel with their test files, and version capture coverageT022can proceed in parallel with surface assertionsT023. - In US3, warning, isolation, and badge tests
T029toT032can run in parallel.
Parallel Example: User Story 1
# Launch US1 test work in parallel:
T012 tests/Feature/Inventory/InventorySyncServiceTest.php
T013 tests/Feature/Filament/InventoryCoverageTableTest.php
T014 tests/Unit/FoundationSnapshotServiceTest.php
# Launch US1 implementation work in parallel after config/contracts are ready:
T016 app/Services/Inventory/InventorySyncService.php
T017 app/Services/Intune/FoundationSnapshotService.php
Parallel Example: User Story 2
# Launch RBAC normalizer work in parallel:
T020 tests/Unit/IntuneRoleDefinitionNormalizerTest.php + T025 app/Services/Intune/IntuneRoleDefinitionNormalizer.php
T021 tests/Unit/IntuneRoleAssignmentNormalizerTest.php + T026 app/Services/Intune/IntuneRoleAssignmentNormalizer.php
# Launch version-history work in parallel:
T022 tests/Feature/BackupServiceVersionReuseTest.php
T023 tests/Feature/Filament/PolicyVersionTest.php
Parallel Example: User Story 3
# Launch safety and permission tasks in parallel:
T030 tests/Feature/Verification/IntuneRbacPermissionCoverageTest.php
T031 tests/Feature/WorkspaceIsolation/TenantOwnedWorkspaceInvariantTest.php
T032 tests/Unit/Badges/PolicyBadgesTest.php
Implementation Strategy
MVP First (User Story 1 Only)
- Complete Phase 1: Setup.
- Complete Phase 2: Foundational.
- Complete Phase 3: User Story 1.
- Validate focused inventory sync and coverage behavior.
Incremental Delivery
- Ship US1 to establish RBAC inventory visibility.
- Add US2 to make immutable RBAC history readable and auditable.
- Add US3 to harden preview-only messaging, permission warnings, and scope safety.
Suggested MVP Scope
- MVP = Phases 1 through 3, then run
vendor/bin/sail artisan test --compact tests/Feature/Inventory/InventorySyncServiceTest.phpandvendor/bin/sail artisan test --compact tests/Feature/Filament/InventoryCoverageTableTest.php.
Format Validation
- Every task follows the checklist format
- [ ] T### [P?] [US?] Description with file path. - Setup, Foundational, and Polish phases intentionally omit story labels.
- User story phases use
[US1],[US2], and[US3]labels. - Parallel markers are applied only where tasks can proceed independently on different files or clearly separable work.