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

  • .env already carries other environment-specific config (ports, ORES_CHECKOUT_LABEL, etc.) that compass client start reads and threads through to ores.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.

See also

Emacs 29.3 (Org mode 9.6.15)