ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
ab17e2695b
TenantAtlas/specs/126-filter-ux-standardization/quickstart.md
Ahmed Darrazi ab17e2695b feat: add Intune RBAC inventory and backup support
2026-03-09 11:39:36 +01:00

4.1 KiB
Raw Blame History

Quickstart: Filter UX Standardization

Goal

Bring Tier 1 and Tier 2 Filament resource lists onto a single filter UX standard using native Filament filters, native session persistence, and focused guard coverage.

Foundation Steps

  1. Review the current filter standard and comprehensive audit to confirm the Tier 1 and Tier 2 targets.
  2. Confirm the missing persistence trio on InventoryItemResource, PolicyVersionResource, RestoreRunResource, AlertDeliveryResource, and EntraGroupResource.
  3. Confirm the current central status vocabularies already available through enums, badge catalogs, or tag-badge catalogs.
  4. Confirm OperationRunResource as the reference implementation for the native date-range pattern.
  5. Identify any resource with query-risk filters before extending search or filtering behavior.

First-Wave Implementation Steps

  1. Add persistFiltersInSession(), persistSearchInSession(), and persistSortInSession() to all missing Tier 1 and Tier 2 filtered resource lists.
  2. Extend FilamentTableStandardsGuardTest so Tier 1 and Tier 2 persistence is enforced consistently.
  3. Add essential missing filters to RestoreRunResource, PolicyVersionResource, InventoryItemResource, FindingResource, AlertDeliveryResource, and BaselineProfileResource.
  4. Reuse the native OperationRunResource date-range shape for new date-range filters and ensure indicateUsing() is present.
  5. Normalize soft-delete behavior to the existing Archived/Active/All pattern on every in-scope soft-deletable resource list.
  6. Replace prioritized local status arrays with centralized option sources backed by the thin shared helper layer where needed.
  7. Keep domain-specific filter intent resource-local while using the thin shared helper layer only for repeated mechanical presets.

Approved Follow-up Surfaces

  1. Add the same persistence and filter treatment to BaselineSnapshotResource when governance review shows the missing filter gap in daily use.
  2. Add type/restore/platform filtering to BackupItemsRelationManager when backup reviewers need to isolate specific foundations or RBAC entries inside a backup set.
  3. Keep these follow-ups Filament-native and low-risk; they are extensions of the same standard, not a second filter framework.

Verification

Automated

vendor/bin/sail up -d
vendor/bin/sail artisan test --compact tests/Feature/Guards/FilamentTableStandardsGuardTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/TableStatePersistenceTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/BaselineSnapshotListFiltersTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/Findings
vendor/bin/sail artisan test --compact tests/Feature/Filament/Alerts
vendor/bin/sail bin pint --dirty --format agent

Manual

  1. Narrow an in-scope resource list with search, sort, and filters, refresh the page, and confirm the same state remains.
  2. Navigate away from the same list and return within the session to confirm list-state persistence holds.
  3. Apply each new date-range filter and confirm the indicator summary shows the active window clearly.
  4. Verify Archived, Active, and All semantics on each changed soft-deletable surface.
  5. Verify workspace-scoped monitoring lists and tenant-scoped inventory/governance lists do not reveal records outside the current entitlement boundary.
  6. On Baseline Snapshots, filter by baseline, state, and capture window, then clear the filters and confirm the full workspace-scoped list returns.
  7. Inside a backup set, filter Items by type, restore mode, and platform to isolate RBAC or foundation entries without losing the backup-set scope.

Rollback

  • Revert the affected resource table() filter definitions and any guard updates that enforce the new standard.
  • Keep the thin shared helper layer mechanically scoped and remove only pieces that stop serving repeated archived, date-range, or centralized-option use cases.
  • No database rollback is required because the feature introduces no schema changes.