Test Scenario: Composite history dialog shows children as of a version
Table of Contents
- 1. Scenario Info
- 2. Context
- 3. Steps
- 3.1. Open BRCLYS's history dialog and check the version list
- 3.2. Select v1 and check the Composite tab shows no identifiers
- 3.3. Select v2 and check the Composite tab shows the LEI identifier
- 3.4. Select v3 (current) and check the Composite tab is unchanged
- 3.5. Add a second identifier via SQL and confirm the party bumps to v4
- 3.6. Select the new v4 and check the Composite tab shows both identifiers
- 3.7. Repeat the v1→v2 check for counterparty SNTRCH
- 4. Results
- 5. Notes
This page documents a test scenario verifying Qt composite history/version dialog in Implement temporal composite entity versioning. It is filled in with the target dialog and checklist of steps before testing starts; the QA Validation Runner panel rewrites * Results in place on save.
1. Scenario Info
| Field | Value |
|---|---|
| Verifies task | Qt composite history/version dialog |
| Parent story | Implement temporal composite entity versioning |
| Target dialog | PartyHistoryDialog and CounterpartyHistoryDialog (new "Composite (as of this version)" tab) |
| Clients | |
| State | PENDING |
2. Context
Background needed before running this — you don't need to re-derive any of this, it's already true in the current environment:
- The mechanism: child writes (party_identifier, party_contact_information,
and the counterparty equivalents) bump their parent's version in the
same transaction, with a
change_commentarylike "Bumped by child party_identifier: …". See Temporal composite entity versioning: target state. - The party BRCLYS (Barclays Plc, from the Barclays/GLEIF provisioning
script) currently has 3 versions:
- v1 — created by GLEIF import.
- v2 — bumped by its LEI identifier (
213800LBQA1Y9L22JB70) being created moments later, same provisioning run. - v3 — a direct edit ("Party provisioning completed via shell").
- The counterparty SNTRCH (Sonatrach) has an analogous v1→v2 history from its own LEI identifier.
- Both parties/counterparties currently have exactly one live identifier (LEI) and no contact information yet.
- Services and the Qt client should already be running (
compass services status,compass client startif not). If the DB was recreated since, re-runcompass shell -f projects/ores.shell/scripts/library/provisioning/barclays_system_provision.oresto restore this exact starting state.
3. Steps
3.1. Open BRCLYS's history dialog and check the version list
In the Qt client: Reference Data (or Party menu) → Parties → find
BRCLYS (Barclays Plc) → open its detail dialog → History. Confirm
the version list shows 3 rows (v1, v2, v3), with v2's commentary
reading "Bumped by child party_identifier: …".
3.1.1. Result
| Field | Value |
|---|---|
| Status | FAIL |
| Notes | so we can see composite as of this version but I wonder if this is the right thing. should we not just say "the component changed at this version" and then open the component history dialog? |
3.2. Select v1 and check the Composite tab shows no identifiers
Click the v1 row. Open the "Composite (as of this version)" tab. Expected: the Identifiers list shows "(none as of this version)" (the LEI identifier didn't exist yet at v1's instant) and Contacts shows "(none as of this version)".
3.2.1. Result
| Field | Value |
|---|---|
| Status | PASS |
3.3. Select v2 and check the Composite tab shows the LEI identifier
Click the v2 row, same tab. Expected: the Identifiers list shows one
entry — LEI: 213800LBQA1Y9L22JB70 (v1). Contacts still empty.
3.3.1. Result
| Field | Value |
|---|---|
| Status | PASS |
3.4. Select v3 (current) and check the Composite tab is unchanged
Click the v3 row (the latest). Expected: identical to v2's view — one LEI identifier, no contacts — since nothing has added/removed a child since v2.
3.4.1. Result
| Field | Value |
|---|---|
| Status | PASS |
3.5. Add a second identifier via SQL and confirm the party bumps to v4
Outside the Qt client, run:
./compass.sh sql -- -c "insert into ores_refdata_party_identifiers_tbl (tenant_id, id, version, party_id, id_scheme, id_value, modified_by, performed_by, change_reason_code, change_commentary) select tenant_id, gen_random_uuid(), 0, id, 'BIC', 'BARCGB22XXX', 'system', 'test', 'system.test', 'Manual test BIC' from ores_refdata_parties_tbl where short_code='BRCLYS' and valid_to='9999-12-31 23:59:59+00';"
Back in the Qt client, reopen (or refresh) BRCLYS's history dialog. Expected: a new v4 row appears, with commentary "Bumped by child party_identifier: Manual test BIC".
3.5.1. Result
| Field | Value |
|---|---|
| Status | PENDING |
3.6. Select the new v4 and check the Composite tab shows both identifiers
Click the v4 row. Expected: Identifiers list shows two entries — the
original LEI and the new BIC: BARCGB22XXX (v1). Re-select v3: it
should still show only the LEI (proving the as-of window is correctly
scoped to what existed at that version, not "everything that exists
now").
3.6.1. Result
| Field | Value |
|---|---|
| Status | PENDING |
3.7. Repeat the v1→v2 check for counterparty SNTRCH
Open Counterparties → SNTRCH (Sonatrach) → History. Confirm the same
pattern: v1 has no identifiers in the Composite tab, v2 has the LEI.
3.7.1. Result
| Field | Value |
|---|---|
| Status | PENDING |
4. Results
| Field | Value |
|---|---|
| Status | FAILED |
| Completed at | 2026-07-08T12:02:46Z |
| Branch | feature/write-composite-versioning-architecture-doc |
| Commit | de0fb9605 |
| Worktree | solid_dirac |