ux: resolve foreign ids to human names across backoffice read surfaces #56

New issue

Closed

opened 2026-07-04 12:11:52 +00:00 by momsse · 0 comments

momsse commented

2026-07-04 12:11:52 +00:00

Owner

Migré depuis viziertronic/octant#121 — ouvert le 2026-06-27 par @momsse.

The backoffice read surfaces render raw branded ids where a human name is available on the same page:

/banking accounts table — "Bank" column shows bankId, while the supported-banks list (id → name) is loaded on the same page.
/documents documents table — PartySource documents render Party · <partyId>, while the parties list (id → name) is loaded on the same page.

Do this uniformly across the read surfaces: derive a Map<id, name> from the already-loaded directory atom and render the name (falling back to the id when absent), keying sort/search on the name. Keeping it consistent across banking + documents avoids one surface showing names while the other shows ids.

Surfaced in the #41 banking (PR #119) and documents (PR for #41 docs slice) reviews.

> _Migré depuis [viziertronic/octant#121](https://github.com/viziertronic/octant/issues/121) — ouvert le 2026-06-27 par @momsse._ The backoffice read surfaces render raw branded ids where a human name is available on the same page: - `/banking` accounts table — "Bank" column shows `bankId`, while the supported-banks list (id → name) is loaded on the same page. - `/documents` documents table — `PartySource` documents render `Party · <partyId>`, while the parties list (id → name) is loaded on the same page. Do this uniformly across the read surfaces: derive a `Map<id, name>` from the already-loaded directory atom and render the name (falling back to the id when absent), keying sort/search on the name. Keeping it consistent across banking + documents avoids one surface showing names while the other shows ids. Surfaced in the #41 banking (PR #119) and documents (PR for #41 docs slice) reviews.

momsse closed this issue

2026-07-04 12:11:53 +00:00