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_id field (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_request directly with the stored default party, skipping PartyPickerDialog entirely.
  • 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.ores and 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_id is 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 making provision party set it transparently — keeps "provision a party" and "make it my default" as two separately-visible, separately-testable steps.
  • Reused ClientManager::selectParty() (client) and mirrored select_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-service set_my_default_party_request path (shell/provisioning) stayed as originally designed — it's a different kind of action (immediate self-service, like select_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 PartyPickerDialog for 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 — issues select_party_request after 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.

Emacs 29.3 (Org mode 9.6.15)