admin_rb
6.1 KiB
The behaviors below are retained from2.1.0rc2. Current candidate2.1.0rc9 targets Core3.3.0rc8/schema5 and adds reports/journal described in REPORTS.md and JOURNAL.md. Credential, read-only inventory and OS-permission boundaries here remain unchanged; old version/no-migration statements describe the earlier slice.
Run comfort - AIM WebGUI 2.1.0rc2
Scope
Based on the working 2.1.0rc1 read-only release, targeting separately managed AIM Core3.3.0rc3/API1.0. This is a user-interface enhancement to the existing one-run credential path, not a password store, new authentication mode or execution engine. SQLite4, WebGUI HTTPv2, Core detail/outcome/hierarchy/staging contracts and release-managed permissions remain unchanged.
Open without leaving the job
When the worker is ready, the job owner selects Unlock this run on Job detail or Unlock run in Needs your attention. A native modal opens over the current page, with the reviewed playbook/customer, target count and Apply/Check mode visible. It does not open automatically, move the user into a new window, or focus a password field without a deliberate action. The title gets initial focus so opening on a phone does not immediately summon the keyboard.
The form is fetched lazily and is not part of the HTMX-polled job or attention region. Refreshing those regions does not erase typing. Tab/Shift+Tab stay inside the dialog; Escape or the explicit Close button dismisses it and returns focus, even when polling replaced the original trigger. A backdrop tap is ignored to avoid accidental loss of input. The viewport-bounded body scrolls internally and responds to visual-viewport resize. The full-page link still works without JS or dialog support, and also when deliberately opened in another tab.
Use only the fields Core requires
Vault-only jobs show one password field. Each input has a persistent label, Required/Optional text, Show/Hide button and Caps Lock hint. Paste is supported; the app neither stores values in browser storage nor disables a user's deliberate password-manager use. These are infrastructure passwords, not MFA/one-time-code inputs.
When the requirements contain both vault_password and ssh_key_passphrase_or_customer_vault_value, a native radio-button group styled as buttons offers Use customer Vault (default) and Enter separately. Choosing the latter reveals a required key-passphrase field; returning to Vault clears/disables it. When a key is explicitly required by Core, the field stays required and the alternate-source toggle is not offered. A requested connection password is labeled a default, since native inventory precedence still applies. No Vault/Custom credentials switch, forced account override, become field or private-key upload is added.
The user's Bootstrap4 grouped-radio example was used as visual inspiration. Implementation uses existing Bootstrap5 btn-check inputs with associated labels and native radio semantics, not Bootstrap4's button plugin or jQuery. Theme tokens and focus contrast remain in the established design system.
Submission and deadlines
The timer is synchronized to the server's existing reservation deadline and advances from a monotonic browser clock. Opening, polling and typing do not extend the five-minute window. An amber near-expiry notice is displayed once; the timer is not announced every second. POST validation, not the client timer, controls eligibility. Handoff/start keeps its existing 60-second bound.
Submit clears the live DOM values (including revealed text inputs), disables repeat interaction and sends only supported credential fields in the authenticated/CSRF-protected JSON POST. The confirmation says handoff accepted, not password verified. Core validates Vault/key/connection details later, and the user can close the dialog to follow the existing job output. Closing is not a job cancellation.
If the HTTP response is lost or uncertain, credentials are cleared and the form locks. It reads owner-only job status rather than resending the password automatically. Reopening that job on the same page preserves only the uncertainty marker/job ID, never secrets. The worker's existing atomic claim prevents reuse; refreshing a page is not a way to replay a claimed handoff. A 400 field-validation failure can allow another explicit corrected submission; throttles, revoked permission, expiry and ended jobs remove the input opportunity. No error echoes credential values or raw Core exceptions.
Clearing references is not physical memory erasure. The browser, network stack and operating system may have other transient copies. Infrastructure administrators must still manage TLS, proxy buffering/logging, dumps, swap and the trust of service identities.
Needs your attention
Overview shows up to eight actionable jobs; Jobs shows up to100 and discloses any remaining total. The query scans current actionable jobs rather than only the newest100 history entries. Your own live credential reservations come first. Administrators see other owners' jobs needing independent approval as review links, not automatically approved jobs and not another requester's credential form. Ended/expired/canceled jobs leave the action list. Ordinary failed jobs stay in history rather than masquerading as pending input.
Retained functionality
Inventory map/outline, Host Activity, Playbook Insights, mobile hamburger/theme controls, customer-scoped histories, one-run review, unique saved-plan names, partial-result presentation, manual fresh retry and terminal-only deletion remain. History continues to include only retained WebGUI jobs. No terminal Core history, inventory writes, secrets cache or live host probing is introduced.
Operator acceptance
Use a disposable authorized job and test both Vault-only and a customer-key requirement. Verify fields against Core, focus/keyboard/mobile viewport behavior, a live HTMX refresh while typing, close/expiry/revocation clearing and an accepted handoff followed by the actual run. Test an ambiguous response only on a safe disposable operation and confirm no automatic POST repetition. Verify fallback form and owner/admin policy. Source/browser fixture evidence and untested production boundaries are in VERIFICATION.md.