Auto-unlock login from an env/CLI password
Table of Contents
This page is a capture in the inbox bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.
What
ores.qt should accept the login password via a CLI argument (and,
equivalently, an environment variable so it can be set once in
.env) and use it to automatically unlock/log in at startup instead
of requiring the tester to type it into the login dialog by hand every
time. If auto-unlock is attempted (the env var/CLI arg is present) and
fails – wrong password, account locked, server unreachable, whatever
– show a message box that clearly states login was attempted
automatically from the environment/CLI and failed, with the
underlying reason, so the failure is never silently swallowed or
mistaken for "just hasn't logged in yet". This should not become the
only way to log in – the manual dialog stays for cases where no
env/CLI password is supplied, or for logging in as a different
account.
Why
Dev/test workflows in this codebase constantly spin up one or more
ores.qt client instances (see compass client start, the
--open-scenario QA workflow, multi-client eventing scenarios) and
every one of them currently requires manually typing the same fixed
dev password (Secure-Password-123) into the login dialog before any
useful work can start. This is pure repeated friction with no security
value in a local dev environment where the password is already known
and shared. Auto-unlocking from =.env=/CLI removes that friction while
keeping the manual path available and making failures loud rather than
silent.
References
.envalready carries other environment-specific config (ports,ORES_CHECKOUT_LABEL, etc.) thatcompass client startreads and threads through toores.qt– the natural place to add a password var following the same convention.projects/ores.qt/application/src/LoginDialog.cpp– the manual login flow this would sit alongside.