TEDY — deferred tasks

Work intentionally stubbed or skipped for now, to be implemented later. Each item notes where it’s currently faked and what “done” looks like.

Auth / UMA (EMR shell integration)

TEDY runs on the EMR shell, whose @helex/state calls the EMR UMA endpoints (/api/uma/*) on load. TEDY’s backend is terminology-server, which has no UMA service, so these are faked by the dev-only devGuestAuthStub middleware in modules/tedy/frontend/vite.config.ts (runs under vite only; never in a build).

• Real authentication — replace the dev guest stub (GET /api/uma/userinfo, GET /api/uma/auth/mock-users) with real tx Keycloak (OIDC). Until then every privilege gate is open (privileges: ['*']) and the user is a fixed guest/dev tenant. This is the gating item for a real deployment.
• User preferences — GET/PUT/DELETE /api/uma/preferences is currently answered with an empty set ({ data: [] }) by the dev stub so @helex/state’s on-load hydration doesn’t 404; nothing is persisted (menu favourites, pinned items, search prefs, UI prefs all reset per session). Implement a real store.
  • Contract to match (EMR UserPreferenceController, modules/uma/backend/.../UserPreferenceController.java):
    • GET /api/uma/preferences → { data: UserPreferenceEntry[] }, entry = { tenantAlias: string | null, key: string, value: string }.
    • PUT /api/uma/preferences body { key, value, scope } (scope = global | tenant) → 200.
    • DELETE /api/uma/preferences?key=&scope= → 200 (idempotent soft-delete).

Terminology data gaps (dev backend)

• Publisher $lookup 404 — the CS summary resolves the publisher display via GET /api/tx/$lookup?system=…/CodeSystem/publisher&code=HELEX, which 404s on the dev backend (no publisher CodeSystem / code HELEX). Cosmetic (falls back to the raw code); provide the publisher CodeSystem or make the widget tolerate a missing lookup.

Concept presentation

• Server-side paged concepts (+ field selection) — the concept list scales poorly because every concept is returned fully decorated (all entity versions, each with its designations + property values) and there is no way to page or trim it server-side. What’s already mitigated on the client and what’s still missing:
  • Done (client): hierarchy roots are paged (ROOT_PAGE = 100, Load more / Load all, in ConceptPresentationTable.tsx) instead of a silent limit: 200 cap; children lazy-expand one level; off-screen property markup is deferred (ConceptCell.tsx useInView); the cell reads only the current entity version.
  • Still missing (server): the payload per row stays huge. Measured on lt-lab-klt-nomenclature (part-of, 7,056 roots) against lmb-api: limit=100 = 1.22 s / 2.84 MB (~28 KB/root); limit=200 = 1.81 s / 5.71 MB; limit=7056 (Load all) = 44 s / 198 MB. rhk10 (is-a, ≈37k) is worse.
  • “Done” = a server that supports (a) real paging on roots/children/flat lists with a stable total, and (b) field selection — return only the fields the presentation needs (e.g. current-version designations of the requested types + the showInList properties), not the full version history. Then drop the client-side Load-all path for large systems. Needs a terminology-server change (the /ts/code-systems/{id}/concepts endpoint has no properties=/field-limiting and always decorates).