Task: Serve the history of the whole pricing engine document
Table of Contents
This page documents a task in the Make every configuration screen follow one standard story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
The History tab of a pricing engine configuration shows every version of the whole document: the configuration, its products and its parameters, in the shared timeline the other record pages use.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Make every configuration screen follow one standard |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-25 |
3. Acceptance
- The tab draws versions of the configuration, its products and its parameters.
- Each event names the entity it came from.
- The tab uses the shared timeline, not the legacy history panel.
- An event states who changed it, when and why, and the fields that moved.
- A change to a setting appears without a change to the configuration row.
4. Plan
- Read the document, so the entity ids are known.
- Read the generic history of the configuration, each product and each parameter. The reads travel in batches of 32, because a large configuration holds hundreds of parameters.
- Answer the versions as one list, each carrying its entity, its name and its changes.
- Draw the list with the shared timeline. The mapping lives in
model.ts, so it is a pure function with a test.
5. Measurements
Every number this task claims about a tree, with the command that produced it
and the commit it was measured at. A number without both is not a measurement,
because a clean-up record describes a tree and trunk moves under a branch: a
consumer count, a gate's component count and a suite's size all change with no
code changing, and the reader of a bare number cannot tell which tree it came
from. Where the raw output matters, put it in an evidence/ file beside the
task and name that file in the Command column.
| What | Value | Command | Commit |
|---|---|---|---|
| Entities per document | 1 + one per product + one per parameter (25 for XVA Overnight) | select count(*) from ores_analytics_pricing_model_products_tbl ... |
095d48438d |
| History reads in flight | 32 | grep HISTORY_BATCH projects/ores.web/packages/bff/src/pricing-engines.ts |
095d48438d |
| Web suite | 1986 tests | npm test -w @ores/web |
095d48438d |
| BFF suite | 945 tests | npm test -w @ores/bff |
095d48438d |
6. Notes
- The history read is the generic one, so a new entity type needs no new read.
- A configuration with hundreds of parameters reads one history per parameter. The batch keeps the requests bounded; a single read for the whole document is the server-side alternative if it ever gets slow.
7. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario)
that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
| #3767 | [web] Draw the whole document history on the timeline |
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
The tab reads as the other record pages do. A save writes the configuration, its products and its parameters, so one timeline shows the version of each thing that changed, who changed it and why. The legacy panel is no longer used on this page.