...
- DB: Add facilityID column to
i_ben_flow_outreach, backfill old records, new tablem_userfacilitymapping - HWC-API: ~25 files (new login API, 16 worklist queries, visit save, entity change)
- HWC-UI: ~25 files (login flow, session, worklist calls, visit save)
- Inventory-API: ~3 files (hierarchy walk)
- Total: ~57 files
Benefit:
...
]
- No more fake Van, Zone, Parking Place for HWC
- Clean architecture - HWC uses facility directly
- Login: 2 API calls instead of 3
- Hierarchy built-in (DH→CHC→PHC→SC)
...
- DB: ZERO changes to
i_ben_flow_outreach(no new column, no backfill) - HWC-API: ZERO changes to login, worklist, visit save
- HWC-UI: ZERO changes to login, worklist, visit save
- Inventory-API: ~3 files (hierarchy walk using Van → FacilityID → ParentFacilityID) Total: ~3-5 files only
Benefit:
- Almost no code changes
- No risk to existing flow - everything stays as is
- No old data migration needed
- Hierarchy is available whenever needed through Van → FacilityID → m_facility
- Inventory hierarchy walk works (Van → FacilityID → walk up parents)
- Can be done very quickly
...
| Option A (Remove Van) | Option B (Keep Van + Hierarchy) | Files to change | ~57|||
|---|---|---|---|---|---|
| ~3-5 | DB migration | Yes (ALTER + backfill) | No | ||
| Login flow | Changed (facilityID) | No change | |||
| Worklist queries | Changed (16 queries) | No change | |||
| Visit save | Changed | No change | |||
| Admin setup for new HWC | 2 pages | 6 pages (same as now) | |||
| Fake Van/Zone needed | No | Yes (same as now) | |||
| Hierarchy available | Yes (direct) | Yes (through Van → FacilityID) | |||
| Inventory hierarchy walk | Yes | Yes | |||
| Risk | Medium (many changes) | Very low (minimal changes) | Testing effort | High (~57 files) | Low (~3-5 files) |
| Old data handling | Backfill needed | No change needed | |||
| Rollback | Redeploy old code | Almost nothing to rollback |
...