ahmido 9c56a2349a feat/047-inventory-foundations-nodes (#51 )

Adds Inventory Sync toggle include_foundations (default true) + persistence tests
Adds Coverage “Dependencies” column (✅/—) derived deterministically from graph_contracts (no Graph calls)
Spec/tasks/checklists updated + tasks ticked off

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #51

2026-01-10 20:47:29 +00:00

2.2 KiB

Raw Permalink Blame History

Phase 0 Research: Foundations in Inventory (047)

Context

This feature makes specific Intune “foundation” objects first-class InventoryItem records so the Dependencies UI (Spec 042.2) can resolve names from the local DB (no UI-time Graph calls).

Foundation types in scope are already configured in config('tenantpilot.foundation_types'):

roleScopeTag
assignmentFilter
notificationMessageTemplate

Graph contract registry entries exist for all three types in config/graph_contracts.php under types.*.resource.

Decisions

Decision: Reuse existing Inventory sync flow (`InventorySyncService`) to sync foundation types

Rationale: Keeps inventory the “last observed” source of truth, preserves existing locking/idempotency/run observability, and avoids duplicating Graph pagination/retry behavior.
Alternatives considered:
- Separate “Foundations sync” job/service: rejected because it would duplicate run bookkeeping and selection hashing semantics.
- UI-time resolution via Graph: rejected (explicitly out of scope; violates Spec 042.2 / FR-006).

Decision: Treat foundation types as regular `policy_type` values with a stable `category=Foundations`

Rationale: No schema change; Inventory UI and filters already understand category and policy_type.
Alternatives considered:
- New table for foundations: rejected (adds joins and complexity; not needed for MVP).

Decision: Coverage UI presents two matrices (Policies + Foundations)

Rationale: Makes support surface explicit and avoids mixing foundational types into policy-type rows.
Alternatives considered:
- Single combined coverage table with category filter: rejected for MVP clarity.

Clarifications Resolved

Selection semantics: include_foundations=true means “always sync all configured foundation types in addition to selected policy types”. include_foundations=false means “never sync foundation types (even if explicitly present in policy_types)”.
Graph contracts: Foundation types must be represented in config/graph_contracts.php so they are handled via the single contract path.
Data minimization: Only safe, whitelisted meta_jsonb is stored (no raw payload dump).

2.2 KiB Raw Permalink Blame History