Test Scenario: Verify data-driven fallback badge and badge eventing

Table of Contents

This page documents a test scenario verifying Badge palette swatch rendering + data-driven fallback badge in Badge colour scheme: visual polish and self-badging fixes. 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.

This scenario covers the two aspects of the task NOT already verified by the earlier swatch/colour-picker/shortcuts scenario: (1) the reserved __unmapped__ fallback badge_definition row now renders (dashed border, orange colours) whenever a badge_key/entity_code pair has no matching badge_mapping row, replacing the old hardcoded ColorConstants::badge_fallback constant; and (2) a badge_definition colour change made in one client instance propagates live, via the LISTEN/NOTIFY-to-NATS relay, to a second running instance without a manual reload – the eventing gap flagged as a note on the earlier scenario's "Open a badge for edit" step. Pass means both the fallback rendering and the live colour-change propagation are confirmed; fail means either one isn't.

Known, tracked limitation, not a bug to chase here: badge_mapping is a junction row with no generated entity handler, so editing it (even via a hypothetical future UI, not just the SQL used below) publishes no NATS change-event today – BadgeCache only reloads on badge_definition_changed or on next login/reconnect. The fallback part of this scenario therefore uses both running clients deliberately: red is left untouched after the mapping edit to demonstrate, on screen, that it keeps showing stale data with no live push (the expected behaviour given the gap), while blue relogs in to show that a reconnect does pick up the change. Closing this gap properly (so both instances would update live) is tracked in Junction eventing: extend codegen with notify-trigger, changed-event, and event-registrar facets for the junction model type – do not fail this scenario over red staying stale; that is the documented, expected result of the step it appears in.

Scenario Info

Field Value
Verifies task Badge palette swatch rendering + data-driven fallback badge
Parent story Badge colour scheme: visual polish and self-badging fixes
Target dialog PartyMdiWindow (fallback badge) / BadgeDefinitionDetailDialog (eventing) – Menu: Reference Data > Parties; Data Quality > Badges > Badge Definitions
Clients blue, red
State PASSED

Steps

Each step is its own heading — the title should be five to seven words so it fits on one line in the QA Validation Runner's step list without wrapping or truncating (e.g. "Edit and save the record", not a full sentence describing the whole operation). The body below the title is a bullet-point checklist, not a prose paragraph: give the tester every piece of context needed to execute that one step without looking anything up elsewhere — what UI state must already exist, exactly what to click or type, and exactly what confirms the step passed. The panel writes each step's PASS/FAIL/PENDING outcome and notes back as a *** Result child heading directly under it.

blue

Connect to tenant Barclays Plc

  • Log in as tenant_admin@barclays_plc / Secure-Password-123 and select BARCLAYS PLC.
  • Result
    Field Value
    Status PASS

Open Party list and confirm the real Active badge

  • Reference Data -> Parties.
  • Confirm active parties show the green Active status badge (solid pill, no dashed border).
  • Result
    Field Value
    Status PASS

red

Connect to tenant Barclays Plc

  • In a second, differently-coloured client instance, log in as tenant_admin@barclays_plc / Secure-Password-123 and select BARCLAYS PLC.
  • Reference Data -> Parties here too. Confirm it also shows the green Active badge – this window is the control: it is deliberately left untouched through the next few steps.
  • Result
    Field Value
    Status PASS

blue

Remove the Active badge mapping via SQL

  • In a terminal, run (the delete is rewritten by a table rule into a soft-close of the current row, not a literal row removal – DELETE 0 in the command output is expected). Scoped to Barclays' own tenant_id – badge data is duplicated per-tenant (see the restore step below), and the running client only ever reads its own tenant's copy: 

    ./compass.sh sql -- -c "delete from ores_dq_badge_mappings_tbl where tenant_id = ores_iam_tenant_by_code_fn('barclays') and code_domain_code='party_status' and entity_code='Active';"
  • Result
    Field Value
    Status PASS

red

Confirm no live update without reconnecting

  • Result
    Field Value
    Status PASS

blue

Reconnect and confirm the fallback badge

  • Log out and back in as tenant_admin@barclays_plc (this forces BadgeCache to reload from a cold start), then reopen the Party list.
  • Confirm active parties now render the reserved fallback badge instead: orange background, white text, dashed border, text "Unmapped" – visibly different from both the green Active badge and the grey Inactive badge (not just another solid colour).
  • Result
    Field Value
    Status PASS

red

Reconnect and confirm the fallback badge too

  • Now log out and back in on red as well, then reopen its Party list.
  • Confirm it now shows the same fallback badge as blue – proving the earlier "no live update" step was specifically about the missing mapping event, not a red-specific problem: a reconnect picks the change up on either instance, just not automatically.
  • Result
    Field Value
    Status PASS

blue

Restore the Active badge mapping via SQL

  • ores_dq_badge_mappings_upsert_fn defaults modified_by to current_user, which only passes validation before the tenant has any accounts (bootstrap); against an already-provisioned tenant it must be set explicitly, so restore via a direct insert instead. Badge data is duplicated per-tenant (the "provision tenant" bundle-publish step copies the system-tenant seed rows into Barclays' own tenant_id), and badge_service reads scoped to the caller's tenant – so the insert must target Barclays' tenant_id via ores_iam_tenant_by_code_fn('barclays'), not the system tenant, or the running client (logged in as Barclays) will keep seeing the fallback badge despite the row existing under the wrong tenant: 

    ./compass.sh sql -- -c "insert into ores_dq_badge_mappings_tbl (tenant_id, code_domain_code, entity_code, version, badge_code, modified_by, performed_by, change_reason_code, change_commentary, valid_from, valid_to) values (ores_iam_tenant_by_code_fn('barclays'), 'party_status', 'Active', 0, 'active', 'super_admin', 'super_admin', 'system.new_record', 'Restored after manual QA test', current_timestamp, ores_utility_infinity_timestamp_fn()) on conflict (tenant_id, code_domain_code, entity_code) where valid_to = ores_utility_infinity_timestamp_fn() do nothing;"
  • Log out and back in again, then reopen the Party list (same reason as the removal step – no live event for a mapping change).
  • Confirm active parties render the solid green Active badge again, not the fallback – the seed data is left as it was found.
  • Result
    Field Value
    Status PASS

red

Reconnect and confirm the badge is restored

  • Log out and back in on red too, reopen the Party list, and confirm it also shows the solid green Active badge again – both instances end this part of the scenario back in their original state.
  • Result
    Field Value
    Status PASS

blue

Open Badge Definitions and note the active colour

  • Data Quality -> Badges -> Badge Definitions.
  • Double-click the active row; note its current Background swatch colour (green, #22c55e) before changing it.
  • Result
    Field Value
    Status PASS

red

Open Badge Definitions here too

  • Data Quality -> Badges -> Badge Definitions in red as well, so its list is visible and idle, ready to observe a live update – unlike the mapping steps above, badge_definition itself does publish a real change-event, so this next part should update live with no reconnect needed.
  • Result
    Field Value
    Status PASS

blue

Change the active badge colour and save

  • Back in the blue instance's active detail dialog, click the Background swatch button and pick a clearly different colour (e.g. a blue).
  • Click Save; fill in the change-reason dialog and confirm.
  • Confirm the blue instance's own Badge Definitions list updates to the new colour immediately.
  • Result
    Field Value
    Status PASS

red

Confirm the colour change arrives live

  • Without touching or reloading anything in the red instance, confirm its Badge Definitions list's active row swatch updates to the same new colour within a few seconds – this is the LISTEN/NOTIFY-to-NATS relay actually firing, not just the repository layer ctest already covers.
  • Result
    Field Value
    Status PASS

blue

Revert the active badge colour

  • Re-open the active row, set the Background colour back to #22c55e, save with a change reason, so the seed data is left unmodified.
  • Confirm the red instance's list also reverts live, for the same reason as the previous step.
  • Result
    Field Value
    Status PASS

Results

Field Value
Status PASSED
Completed at 2026-07-26T10:55:10Z
Branch feature/badge-palette-swatch-and-fallback
Commit 0c002494c
Worktree eager_maxwell

Notes

Emacs 29.3 (Org mode 9.6.15)