[AGILE-363] Add positional actions for contiguous selections

[myabc]

Note

This PR is part of a stack. Please review and merge in this order: #24525 → #24778 → #24779 → this PR.

Ticket

https://community.openproject.org/wp/AGILE-363

What are you trying to accomplish?

Make the existing Backlogs Move to position submenu move either one card or one contiguous selected block in the same list.

The change:

• resolves Top, Up, Down, and Bottom from one pure block-placement contract
• omits positional actions for sparse, cross-list, truncated, unaddressable, and effective no-op scopes
• preserves selected document order and excludes selected rows from predecessor resolution
• reuses the existing optimistic atomic collection move, rollback, announcement, busy, and selection lifecycle

What approach did you choose and why?

Menu availability and activation both call the same resolver. Activation settles the live action scope, resolves again against the current innermost owned list, and passes the ordered rows and IDs to the existing collection performMove path. Roots without the selection/collection capability retain their singular member-move behavior.

This supersedes the menu-collapse behaviour added in #24778. There, a menu move relocated exactly the card it named, so collapseForAction collapsed any wider selection onto that card rather than leaving a batch the move never touched. A positional move here carries the whole block, so collapsing would be wrong: the orchestrator method is removed on this branch, and the selection is committed with selectForAction only once the move is known to be executable.

The resolver validates row ownership so nested sortable lists cannot substitute an outer host row for an inner work package. Fixed rows remain addressable neighbours but cannot enter the selected block, and one-step moves never cross a truncation marker.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc)
• Tested major browsers (Chrome, Firefox, Edge, ...) — chromium only

[Copilot]

Pull request overview

Adds support for Move to position actions to operate on a contiguous selected block of backlog cards (while preserving existing single-card behavior), using a shared block-move resolver for both menu gating and execution.

Changes:

• Introduces resolveBlockMove / resolveBlockMoveAvailability to resolve predecessor placement for contiguous selections (and to reject sparse/cross-list/truncation-boundary/no-op scopes).
• Updates sortable-lists controller/menu plumbing to use action-scope-based availability and to execute batch menu moves through the existing optimistic collection-move path.
• Expands backend + frontend test coverage for contiguous selection moves, gating behavior, and rollback/selection lifecycle.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
modules/backlogs/spec/support/pages/backlog.rb	Adds page helpers for selecting contiguous cards and asserting Move-to-position availability.
modules/backlogs/spec/features/work_packages/batch_move_via_menu_spec.rb	New Selenium spec covering contiguous-block positional moves and rollback behavior.
modules/backlogs/spec/features/work_packages/batch_destination_menu_spec.rb	Updates destination menu spec to expect Move-to-position availability for contiguous multi-card scopes.
modules/backlogs/spec/components/backlogs/work_package_card_menu_component_spec.rb	Tightens expectations around Move-to-position menu rendering (client-driven availability, no legacy form fields).
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection-orchestrator.ts	Updates documentation/comments to distinguish singular-collapse vs batch menu moves.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list-dom.ts	Implements block-move resolution + availability helpers for contiguous selections.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list-dom.spec.ts	Adds unit tests for block-move resolution across many boundary cases.
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.ts	Switches Move-to-position gating to rely on root-provided availability (no longer hides submenu purely for multi-card scope).
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.spec.ts	Updates/extends menu tests for showing/hiding batch position directions and the submenu.
frontend/src/stimulus/controllers/dynamic/sortable-lists/drag-and-drop.ts	Clarifies move availability semantics in the interface comment.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.ts	Uses block-move availability/execution for selection-backed menu moves.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.spec.ts	Adds coverage for batch menu moves, rollback behavior, and batch availability reporting.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Warning

Flaky specs

• rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]
• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]
• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24780, linked for reference only):

- `rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]`
- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]`
- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]`

Treat this as a standalone task, unrelated to PR #24780. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24780 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]
• rspec ./spec/features/workflows/edit_spec.rb[1:4:4]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24780, linked for reference only):

- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]`
- `rspec ./spec/features/workflows/edit_spec.rb[1:4:4]`

Treat this as a standalone task, unrelated to PR #24780. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24780 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated no new comments.

Suppressed comments (1)

frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.ts:541

• selectForAction mutates the current selection before the owner-list, block-resolution, and identity checks below. If a menu opened on an unselected card becomes stale (for example, that direction becomes a no-op before activation), one of those checks returns without moving anything, but the previous batch has already been replaced by the invoker. Resolve and validate the prospective scope with actionScopeFor first, and only commit the selection change once the move is known to be executable.

      const scope = this.selectForAction(itemElement);