Story: Implement the refdata journeys in ores.web
Table of Contents
This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
The written ores.refdata journeys run in ores.web against the real server: a reference data administrator can maintain the classification lists, currencies, currency pairs, desk groups and holiday calendars from the screens the journey documents describe, instead of the deleted per-entity screens.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-05 |
On 2026-10-05 this story closed DONE with all five journey screens built on the real server. The holiday calendar screen landed last (PR #2646): the sprint close had split it to a successor story, and when the screen shipped before the close record merged, its task returned here and the successor retired.
3. Acceptance
- Maintain a classification list, Add or correct a currency, Set up a currency pair, Group currencies for the desk and Keep a holiday calendar right each run in ores.web against the real server.
- Every screen uses the journey runtime and the generic history request; none adds a per-entity list, detail or history primitive.
- Every gap a journey document records is either closed or stated on the screen as the document says.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scaffold story: Implement the refdata journeys in ores.web | DONE | 2026-10-04 | 2026-10-04 | Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR. |
| Build the classification list screen | DONE | 2026-10-04 | 2026-10-05 | Build Maintain a classification list in ores.web: 28 code lists by topic, edit form and history. |
| Build the currency screen | DONE | 2026-10-05 | 2026-10-05 | Build Add or correct a currency in ores.web: the currency, its pickers, countries, calendars, desk groups and history. |
| Build the holiday calendar screen | DONE | 2026-10-05 | 2026-10-05 | Build Keep a holiday calendar right in ores.web: the calendar by shape, rules, exceptions, events, rebuild and business days. |
| Build the currency pair screen | DONE | 2026-10-05 | Build Set up a currency pair in ores.web: the pair and convention form, settlement calendars and history. | |
| Build the desk group screen | DONE | 2026-10-05 | Build Group currencies for the desk in ores.web: groups in order, members and history. |
5. Order
| # | Journey | Task | Why here |
|---|---|---|---|
| 1 | Maintain a classification list | Build the classification list screen | One generic screen covers 28 lists, needs no new server work, and settles the history panel and the change-reason form every later screen reuses |
| 2 | Add or correct a currency | Build the currency screen | Its pickers read lists the first screen maintains; it adds the junction panels |
| 3 | Keep a holiday calendar right | Build the holiday calendar screen | The currency and pair screens link to it |
| 4 | Set up a currency pair | Build the currency pair screen | Needs currencies and calendars in place |
| 5 | Group currencies for the desk | Build the desk group screen | Smallest; the currency screen already shows memberships |
6. Decisions
- The journey documents are the specification. The screens build from the five refdata journeys; where the build proves a document wrong, the correction goes to the document.
- No server work is planned. Every operation the five screens need exists, and the TypeScript wire package already carries all 139 refdata protocols and the history protocol. The work is ores.web routes, operations and screens. A gap the journeys record is stated on the screen, as each document says, unless a task chooses to close it.
- One history panel and one change-reason form, written once. The first
screen builds both over
refdata.v1.history.getand/api/change-reasons, and every later screen reuses them. - New routes and menu items only. The screens add routes and menu entries in
AppRoutes.tsxandshell/areas.ts, and touch no page another story owns, so they do not clash with the access and profile work in the same files. - One registry of record resources is the BFF's authority. Each screen
reads and writes through
/api/refdata/:resource, keyed by a name the registry allows; a write is checked against a schema that satisfies the generated write type. No screen names a subject. - A field table drives every record form. Text, numbers, dates, choices, classification and record pickers, with conditional fields, give the form, the details, the revert and the write from one list per entity.
- A screen states a server gap rather than hiding it. Where the server behaves differently from the journey, as with the calendar rebuild, the screen says so and the journey is corrected.
7. Out of scope
- Journeys 5 to 9 of the refdata catalogue (parties, books, conventions, tenors): they are not written yet.
- The server-side gaps the journeys record, such as delete-in-use checks and junction end checks; they are captured separately.
- The ORE XML export of currencies, which has no server operation.