37 lines
2.2 KiB
Markdown
37 lines
2.2 KiB
Markdown
# 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).
|