Story: Add a default party per account with a quick-login checkbox
Table of Contents
This page documents a story in Sprint 23. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Add a default_party_id to the account entity, and a "Log in to
default party" checkbox on the login dialog. When ticked (and the
account has a default party set), login skips the
PartyPickerDialog step entirely and calls select_party_request
directly with the stored default, rather than making the user pick
the same party from the list on every login. Also update the
tenant/party provisioning scripts (e.g.
projects/ores.shell/scripts/library/provisioning/barclays_system_provision.ores
and the Acme/synthetic equivalent) to set the newly-provisioned party
as the provisioning account's default, so freshly-provisioned
environments come up ready for one-click login out of the box.
Every manual verification or screenshot-capture session currently repeats "log in, then pick the same single party from the list" every single time a service restart or environment ready-up happens — pure friction for the common single-tenant-per-checkout case this whole dev fleet uses. A stored default plus a quick-login checkbox removes a manual step from that sequence without removing the ability to switch parties when an account genuinely has more than one.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 23 |
| Now | Nothing — all four tasks done. |
| Waiting on | Nothing. |
| Next | Nothing — ready to raise the PR. |
| Last touched | 2026-07-11 |
Acceptance
- Account entity gains a
default_party_idfield (nullable FK to party), across domain/SQL/repository/protocol layers. - Login dialog shows a "Log in to default party" checkbox, enabled only when the account has a default party set.
- When ticked, login calls
select_party_requestdirectly with the stored default party, skippingPartyPickerDialogentirely. - When unticked, or no default is set, login behaves exactly as today (party picker shown).
- The account can still switch parties after login (this only short-circuits the login-time picker step, not party-switching in general).
barclays_system_provision.oresand the Acme/synthetic provisioning equivalent set the newly-provisioned party as the provisioning account's default, so freshly-provisioned environments come up ready for one-click login.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Add default_party_id field to the account entity | DONE | 2026-07-11 | 2026-07-11 | Add a default_party_id FK field to the account entity across domain, SQL, repository, and protocol layers, so an account can designate one of its parties as the quick-login default. |
| Add quick-login checkbox to the login dialog | DONE | 2026-07-11 | Add a "Log in to default party" checkbox to the login dialog; when ticked, call select_party_request directly with the account's default_party_id, bypassing PartyPickerDialog. | |
| Update provisioning scripts to set the account's default party | DONE | 2026-07-11 | 2026-07-11 | Update barclays_system_provision.ores and the Acme/synthetic provisioning script so the provisioning account's default_party_id is set to the newly-provisioned party, so fresh environments come up ready for one-click login. |
| Fix default party dangling after a same-save party removal | DONE | 2026-07-12 | 2026-07-12 | AccountDetailDialog::onSaveClicked sends default_party_id from the combo's current selection before committing staged party removals, so removing the party currently selected as default (without also changing the combo) leaves default_party_id pointing at a party the account is no longer assigned to (soft FK, no DB error). Flagged as a non-blocking follow-up in PR #1514 review round 5. |
Decisions
default_party_idis a soft reference (no hard FK), matching the existing IAM/Refdata service-boundary separation — validated at the service layer (party membership check), not the database.- Provisioning sets the default via an explicit new shell subcommand
(
accounts set-default-party) called from the recipes, rather than makingprovision partyset it transparently — keeps "provision a party" and "make it my default" as two separately-visible, separately-testable steps. - Reused
ClientManager::selectParty()(client) and mirroredselect_party's membership-check pattern (server) rather than adding parallel logic — the quick-login path and the manual picker path converge on the same call. - Admin-side editing of the default party is a regular account field
edit (combo box in the Parties tab → Save → change-reason →
update_account_request→ version history), the same as every other account field — not a separate immediate-write action. An earlier attempt at a parallel admin-scoped NATS endpoint plus a right-click "set default" menu was reworked after manual QA flagged it as inconsistent with the rest of the dialog (see the Result section of the login-dialog-checkbox task for the detail). The self-serviceset_my_default_party_requestpath (shell/provisioning) stayed as originally designed — it's a different kind of action (immediate self-service, likeselect_party), correctly not routed through Save.
Out of scope
- Per-tenant default parties (this is a per-account default, one party regardless of which tenant/context the account is used in).
- Removing or hiding
PartyPickerDialogfor accounts with multiple parties — the picker remains available whenever the checkbox is off or no default is set.
References
projects/ores.qt/api/src/PartyPickerDialog.cpp— the dialog a default-party quick-login would bypass.projects/ores.qt/api/src/ClientManager.cpp— issuesselect_party_requestafter party selection; a default-party path would call this directly.projects/ores.shell/scripts/library/provisioning/barclays_system_provision.ores— the provisioning script to update to set the default party.