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 5c61195..29aa9e7 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 @@ -430,16 +430,26 @@ the thing already in progress. drag-and-drop.** A checkable "Sort queue…" button puts the dialog into a focused reorder mode: other queue-mutating buttons (add/add command/delete/clear) disable, the table becomes single-select, and "▲ Move up" / "▼ Move down" swap the selected -row with its neighbour. A swap is only ever between two `pending`/`incomplete` rows — -a `running` or `done` neighbour blocks the swap outright, which gets the running-row -floor and the done-row pinning (§6.3) for free without separate index-range -bookkeeping. Reaching a position more than one row away takes multiple clicks, unlike -drag-and-drop, but sidesteps implementing "reject any drop above the running row" as -live drag-event math. Writes go straight to the `tomo_queue` global var, same pattern -as add/delete/clear (§6.1's two-write-paths rule doesn't apply here — reordering never -touches the live param global vars). The CLI got the equivalent +row with its neighbour. A swap is only ever between two `pending` rows — a `running`, +`incomplete`, or `done` neighbour blocks the swap outright, which gets the +running/incomplete floor and the done-row pinning (§6.3) for free without separate +index-range bookkeeping. Reaching a position more than one row away takes multiple +clicks, unlike drag-and-drop, but sidesteps implementing "reject any drop above the +running row" as live drag-event math. Writes go straight to the `tomo_queue` global +var, same pattern as add/delete/clear (§6.1's two-write-paths rule doesn't apply here +— reordering never touches the live param global vars). The CLI got the equivalent `tomo_queue_move(index, new_index)`, so both surfaces can reorder the pending tail. +**`incomplete` is a floor too, not just `running`.** The first cut treated +`incomplete` as movable alongside `pending`, reasoning that resume-before-fresh +already protects the real execution order regardless of list position. In practice +that let an operator drag a `pending` job visually ahead of an `incomplete` one — +functionally harmless (the `incomplete` job still resumes first), but confusing to +read, since list order looked like it meant run order and didn't. Fixed by narrowing +`_MOVABLE_STATUSES` to `("pending",)` in the GUI and the equivalent floor check in +`tomo_queue_move()` (blocks any `new_index` at or below the highest index among all +`running`/`incomplete` jobs, not just the running one). + ### 6.5 The command-job builder — a structured form, not a text box An **"Add command…"** control opens a sub-dialog: 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 c74dcfa..a27a78c 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 @@ -63,11 +63,15 @@ support on top of it: enters a focused reorder mode: add/add-command/delete/clear disable, the table becomes single-select, and "▲ Move up" / "▼ Move down" swap the selected row with its neighbour. A swap only ever happens between two - `pending`/`incomplete` rows — a `running` or `done` neighbour blocks it, - which is what keeps the running job as a floor and done jobs pinned. Not - drag-and-drop (see section 7's old note on why that was deferred) — this - is the up/down-button alternative. The CLI got the same capability via - `flomni.tomo_queue_move(index, new_index)`. + `pending` rows — a `running`, `incomplete`, or `done` neighbour blocks + it, which is what keeps the running/incomplete job as a floor and done + jobs pinned. (`incomplete` was movable in an earlier pass; narrowed to a + floor after testing showed a pending job could be dragged visually ahead + of an incomplete one — harmless to actual run order, since + resume-before-fresh always resumes it first regardless of position, but + confusing to read.) Not drag-and-drop (see section 7's old note on why + that was deferred) — this is the up/down-button alternative. The CLI got + the same capability via `flomni.tomo_queue_move(index, new_index)`. 6. **Full-detail row tooltips.** Every cell in a queue row now carries a tooltip with the complete job detail — label, status, added-at, and either the full params dump (tomo job) or the numbered step list + @@ -219,6 +223,14 @@ file is exactly how a regression sneaks in. 23. If any job in the queue is `done`, select a `pending` row adjacent to it and confirm the move button on that side is disabled — done rows are pinned, not swapped past. +23a. Get a job to `incomplete` (stop a running scan, or let one raise) and + leave it in the queue. In sort mode, select it and confirm both move + buttons are disabled (it can't be moved itself). Select the `pending` + row directly after it and confirm "Move up" is disabled too — a + pending job must never be draggable ahead of an `incomplete` one, even + though `tomo_queue_execute()` would still resume the incomplete job + first regardless (this was a real gap found during testing: the first + pass let `incomplete` swap freely with `pending`). 24. Click **"Sort queue…"** again to leave sort mode. Confirm the other buttons re-enable and multi-row selection (for delete) works again. 25. Cross-check from the CLI: with the queue back in a known order, run