From 7f7106c944dc8bf71fbebc5f06e5c5af6368ae61 Mon Sep 17 00:00:00 2001 From: x01dc Date: Mon, 13 Jul 2026 15:58:37 +0200 Subject: [PATCH] docs(flomni): document edit-mode queue-add, hard Submit block, and scilog fix Updates plan section 6.1 (marks the two-write-paths rule as actually implemented now) and the GUI test checklist (section 1 item 8, and flags section 3 item 4 as needing re-testing since its old passing result was against the since-replaced soft-warn Submit behaviour). Co-Authored-By: Claude Sonnet 5 --- .../AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md | 9 +++ .../flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md | 55 +++++++++++++------ 2 files changed, 48 insertions(+), 16 deletions(-) diff --git a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md index d988eb2..5c61195 100644 --- a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md +++ b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md @@ -391,6 +391,15 @@ doesn't expose, so the snapshot is still a complete `_TOMO_QUEUE_PARAM_NAMES` se Gate "Done" on the same busy signal `TomoParamsWidget` already computes (tomo heartbeat OR BEC scan-queue status). +**Implemented as designed, eventually.** The first GUI iteration shipped "Done" (named +`Submit` in the actual widget) as a soft warn — a Yes/Cancel confirmation dialog while +busy, not a block — because there was no "Add to queue" path yet for an in-progress +edit, and blocking Submit outright with nowhere else to put those edits would have been +a pure regression. A later pass added `TomoParamsWidget.add_edited_to_queue()` (a new +"Add to queue" button next to Submit, visible only in edit mode) that assembles the job +dict from the current form fields — exactly per this section's "must assemble the job +dict itself" rule — and only then did `submit_params()` become the intended hard block. + ### 6.2 No in-place row editing Editing a queued job = **delete it, add a new one, reorder into place**. One diff --git a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md index 3d97b9b..c74dcfa 100644 --- a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md +++ b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md @@ -9,11 +9,15 @@ session/chat. validated**. It compiles, imports cleanly, and its non-Qt-rendering logic (dynamic form building, step ordering, idempotent-default computation, job dict assembly) was exercised with a scripted fake-client smoke test. -Section 3 (baseline regression) items 1–4 have been clicked through against -a live session and passed; item 5 (opening the queue dialog) onward, and -everything in sections 4–6a — including the sort-mode reorder buttons and -row tooltips added after the first pass — have **not** been clicked through -yet. That's what this document is for. Companion docs: +Section 3 (baseline regression) items 1–3 have been clicked through against +a live session and passed. **Item 4 needs re-testing** — it passed against +the *old* Submit behaviour (a Yes/Cancel confirmation dialog while busy), +which has since been replaced with a hard block plus a new "Add to queue" +button (section 1 item 8); the step-4 instructions below already describe +the new behaviour. Item 5 onward, and everything in sections 4–6a — +including the sort-mode reorder buttons and row tooltips added after the +first pass — have **not** been clicked through yet. That's what this +document is for. Companion docs: `TOMO_QUEUE_COMMAND_JOBS_PLAN.md` section 6 (the design this implements), `TOMO_QUEUE_TESTING.md` (Steps 1 & 2, already sim-validated). @@ -74,6 +78,20 @@ support on top of it: columns like Type/Exp (s)/Step (µm), which now auto-fit their content instead. The "Added at" column was dropped — that value is still in the row tooltip (item 6). +8. **"Add to queue" while editing, and a real Submit block.** Edit mode now + shows an **"Add to queue"** button next to Submit. It packages the + current (possibly unsubmitted) form fields as a new `pending` tomo job + and writes only `tomo_queue` — never the live param vars — so it's + always allowed, scan running or not (plan section 6.1). `Submit` is now + a real hard block while the beamline is busy instead of a Yes/Cancel + confirmation dialog, since there's finally somewhere else to put an + in-progress edit. `flomni.py` also got a small, unrelated robustness fix + in the same pass: `tomo_scan()`/`scilog_last_ptycho_scans()`/the + alignment-scan scilog entry now go through a new `_scilog_write()` + helper that tolerates scilog being disabled instead of raising + `RuntimeError` and pausing the whole queue over a logging side effect + (mirrors the existing enabled-check already used for the PDF report + entry). --- @@ -106,8 +124,14 @@ file is exactly how a regression sneaks in. field reverts to the last-submitted value, not your edit. 4. Start a real (or fast/sim) tomo scan from the CLI (`flomni.tomo_scan()`), then open the widget while it's running. Confirm - the busy banner appears with a reason. Try **Submit** — confirm you get - the "scan appears to be running" confirmation dialog, not a silent write. + the busy banner appears with a reason and now says Submit is blocked. + Click **Edit**, change a value, click **Submit** — confirm it's refused + outright (a plain warning dialog, no Yes/Cancel choice) and nothing gets + written (`flomni.` in the CLI still shows the old value). Then + click **"Add to queue"** instead — confirm it prompts for a label, adds a + new `pending` tomo job with your edited values (check via + `flomni.tomo_queue_show()` or the queue dialog), and does **not** change + any live param (`flomni.` still shows the pre-edit value). 5. Click **☰ Queue control…**. Confirm the dialog opens and the table reflects the current `tomo_queue` (including anything you added earlier via CLI in prior testing sessions). @@ -242,15 +266,14 @@ Worth knowing before you file something as broken: `_queue_action_move()` is still the actual safety boundary regardless (two-layer validation, plan section 3.3), so this is a UX gap, not a safety gap. -- **`Done` is a soft warn, not a hard block, while a scan runs** (existing - pre-Step-3 behaviour, not something this iteration touched). The plan's - section 6.1 literally says "must be blocked"; the actual implementation - allows submitting with a confirmation dialog instead, on the reasoning - that some live params (e.g. counting time) safely take effect on the next - projection while others are already baked into the current run's - trajectory. Worth a deliberate decision (keep as documented nuance, or - tighten to match the plan literally) rather than silently "fixing" — flag - it if a real submit-while-running mistake actually happens during testing. +- **Resolved: `Submit` is now a hard block while the beamline is busy**, + matching plan section 6.1 literally instead of the earlier soft-warn + confirmation dialog. The gap that made the soft warn tempting in the first + place -- wanting to prepare a parameter set while a scan runs -- is now + covered by a new **"Add to queue"** button that appears next to Submit in + edit mode: it packages the current (possibly unsubmitted) form fields as + a new `pending` tomo-queue job and writes only to `tomo_queue`, never the + live param vars, so it's always allowed. See test step 4 in section 3. - **No automated widget tests.** `pytest-qt` isn't a dependency of this repo, so there's no `qtbot`-driven test suite here — the smoke test that validated the builder's logic (dynamic fields, step ordering, idempotent