ge-aerospace/shopdb-flask

Fork 0

Files

History

cproudlock c4690da262

CI / backend (push) Successful in 1m38s

Details

CI / naming (push) Successful in 1s

Details

CI / frontend (push) Successful in 7s

Details

CI / migrations-mysql (push) Failing after 7s

Details

WJ import loader: resolve notification employee SSOs to names

Notifications imported with only employeesso, leaving employeename null - the
model displays "employeename or employeesso", so recognition/training cards
showed a bare SSO instead of a name. Build an SSO -> "First Last" map from the
employee source and populate employeename (comma-separated SSOs -> joined
names). SSOs not in the directory (former/non-WJF) stay null and fall back to
the SSO, as before.

Verified on the import DB: 261 notifications re-imported, names resolved
(Brandon Saltz, Jon Kolkmann, ...).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-13 13:25:12 -04:00

__init__.py

WJ legacy-import reference loader: harness + reference/employees stages

2026-07-13 11:20:58 -04:00

harness.py

WJ import loader: catalog + assets-hub stages (the machineid->assetid crosswalk)

2026-07-13 11:37:11 -04:00

README.md

Import docs: adoption playbook + superseded-mappers note + loader status

2026-07-13 12:18:56 -04:00

run.py

WJ import loader: resolve notification employee SSOs to names

2026-07-13 13:25:12 -04:00

README.md

WJ classic-ASP import loader (reference implementation)

This is site-specific reference glue, not product code. It maps West Jefferson's classic-ASP shopdb / cmmc_usb / wjf_employees schema onto the maintained, schema-agnostic import contract in docs/IMPORT-API.md.

Every adopting site has its own source database. Nobody else runs this loader. Instead, copy the pattern:

Point the harness at your source DB(s) (edit harness.Source).
Write per-entity stages that read your tables and POST to the same docs/IMPORT-API.md endpoints with Authorization: Bearer <admin PAT> and X-Import-Mode: true.
Persist legacy-id -> new-id crosswalks (see harness.IdMap) so later stages resolve foreign keys and a crashed run resumes.

The import API is the stable contract; loaders are per-site. The mapping itself can be produced with the agent-assisted workflow (point Fable/Opus agents at a source DB + this contract -> they emit the mapping + a loader skeleton).

Running (against a THROWAWAY import database)

DATABASE_URL='mysql+pymysql://root:PW@127.0.0.1:3306/shopdb_flask_import?charset=utf8mb4' \
  venv/bin/python -m scripts.site_imports.wjf.run --stages reference,employees

Prereqs: a fresh target DB built with flask db upgrade + flask plugin upgrade-all + flask seed permissions/settings/reference-data, and the three source dumps loaded into scratch DBs (shopdb_src, cmmc_usb_src, wjf_employees_src). See scratchpad/IMPORT-PLAN.md for the full mapping, resolved decisions, and remaining stages.

Status

Complete - all 15 stages built and verified end-to-end against a fresh scratch target (zero endpoint errors): reference, employees, catalog, assets (the hub + machineid->assetid crosswalk), locations, printers, communications, applications (+ installs), warranties, notifications, knowledgebase, relationships, subnets, usb, verify.

Last full run: 983 assets (computer 663, machine 76, network 58, measuring-tool 136, printer 50), 24 locations, 415 employees, 850 installs, 461 primary IPs, 464 warranties, 261 notifications, 341 KB, 93 relationships, 37 subnets, 18 USB devices + 232 events. UI spot-check passed (computer list + shop-floor map).

Known follow-ups: general asset locationid is null (no source column outside printers); the ~146 duplicate machinenumbers are first-wins-skipped by decision.