[AGILE-362] Make Backlogs destination actions batch-aware

[myabc]

Note

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

Ticket

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

What are you trying to accomplish?

Make the Backlogs inbox, sprint, and backlog-bucket destination actions operate on the current ordered selection while preserving existing one-card behavior. Invoking an action from an unselected card replaces the previous selection with that card.

The change:

• loads and authorizes the complete selection's available destinations server-side
• submits ordered batches through the atomic collection move contract, appending after existing destination members
• coordinates batch placement with destination lifecycle operations and serializes concurrent collection appends
• names every affected work package in the move dialogs, so a selection assembled by rubber band or modifier-click plus Shift can be checked before submission
• announces successful moves, retains selection on rejection, and restores busy/progress state on every result
• keeps destination and positional menu groups consistent as selection changes, including hiding empty separators and positional children for multi-card scopes

The dialog listing delivers the "list affected elements" half of AGILE-374 for the two move dialogs.

Screenshots

Move to sprint

What approach did you choose and why?

The client projects the live ordered selection onto the existing menu, while the server remains authoritative. DestinationAvailability supplies the candidate universe for menu markup and filters the full batch for dialog choices. Candidates are not filtered solely by the invoking card: another selected card may validly enter the invoker's current list.

Dialog routes validate the ordered IDs before loading, preload the type and status associations, and render the affected work packages. Direct inbox and dialog moves share the atomic batch service. A permission/candidacy preflight rejects unavailable targets before movement locks; a separate, fresh availability check runs under those locks. Source and destination lifecycle locks use stable ordering, and project/destination locks serialize concurrent append placement.

The empty-append guard rejects a batch if an independent writer fills an initially empty target between placement resolution and revalidation. It does not close the remaining member-write race after revalidation; that remains AGILE-426. Existing member positional and add-existing callers remain supported.

Menu projection and destination acceptance are shared rather than duplicated. Refreshes are limited to the primary menu's opening toggle and coalesced when deferred targets connect; tooltip and submenu toggles do not trigger a full refresh. Destination requests use the shared progress wrapper with guaranteed cleanup. Malformed destination metadata fails closed with a dev-only diagnostic that omits the payload.

The dialogs reuse the inset WorkPackages::InfoLineComponent treatment behind Backlogs::SelectedWorkPackagesComponent. The affected-work-package list is a sibling of the form, and the dialog body scrolls for long selections. A hidden selected count remains associated with the destination select for assistive technology.

Follow-up work:

• AGILE-363 restores Move to position for supported selected blocks
• AGILE-364 extends batch action-menu handling beyond destination actions
• AGILE-374 covers the remaining dialog-clarity work: cancel and finish-sprint dialogs, and copy rewrites
• AGILE-393 owns application-wide unsuccessful Turbo Stream/non-stream response handling, including the inherited async-dialog rejection behavior
• AGILE-426 owns the remaining member-versus-batch placement race

Merge checklist

• Inherited range/anchor behavior from [AGILE-361] Add batch selection to Backlogs cards #24525 is verified through a destination dialog: modifier-click A/C, Shift to E then back to D, submit A/C/D in document order, append after X, leave B/E in the source, and clear selection on success. Range discussion.
• Destination dialog forms and direct destination moves omit prev_id to append; blank still means top. AGILE-426 remains separate. Review discussion.
• Non-optimistic collection moves announce the result: singleton moves delegate to the richer singular wording; multiple cards announce count, destination and contiguous range. Review discussion.
• dropRouteFor retains the collection-URL-only drop decision, including one-member drops; destination moves retain resolveCollectionMoveUrl(false). Review discussion.
• Complete manual tooltip/menu pointer QA in Chrome and Firefox.
• Complete the deferred batch-selection Lookbook documentation using the documentation home in DREAM-774 / #25137. Cover selection/current/focus distinctions, range preservation and Select All narrowing, consumer opt-in values, marker placement, and a selected/current preview. This carries the documentation request from AGILE-361 / #24525; the generic docs alone do not complete it.
• Agree the merge disposition for the remaining AGILE-426 member-write race.

[Copilot]

Pull request overview

This PR makes Backlogs destination actions (move to sprint/bucket/inbox) operate on the current ordered action scope (single card or batch selection), while keeping the server authoritative via destination intersection + revalidation under advisory locking.

Changes:

• Introduces server-side destination intersection (DestinationAvailability) and updates dialog + menu endpoints to use ordered ids[] batches.
• Extends the atomic batch move service with destination lifecycle + append serialization locks to keep placement and availability checks atomic under concurrency.
• Updates the sortable-lists Stimulus stack to project destination candidates, freeze/submit action scopes, handle direct destination moves, and clear selection on successful move events.

Reviewed changes

Copilot reviewed 38 out of 38 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 feature helper APIs for batch selection, dialogs, and announcements.
modules/backlogs/spec/services/backlogs/work_packages/destination_availability_spec.rb	Unit coverage for destination intersection/authorization semantics.
modules/backlogs/spec/services/backlogs/work_packages/batch_update_service_spec.rb	Extends batch move specs for new locking and revalidation behavior.
modules/backlogs/spec/services/backlogs/work_packages/batch_update_service_concurrency_spec.rb	Adds concurrency specs validating serialization/locking guarantees.
modules/backlogs/spec/routing/backlogs/work_packages_routing_spec.rb	Updates routing for dialog endpoints to collection POST routes.
modules/backlogs/spec/requests/work_packages/move_collection_spec.rb	Adds request coverage for plural announcements + dialog staleness rejection.
modules/backlogs/spec/features/work_packages/batch_destination_menu_spec.rb	End-to-end Selenium coverage for batch destination menus/dialogs.
modules/backlogs/spec/controllers/backlogs/work_packages_controller_spec.rb	Updates controller specs for new dialog contracts + candidate passing.
modules/backlogs/spec/components/backlogs/work_package_card_menu_component_spec.rb	Updates menu component spec for destination metadata + POST dialog loading.
modules/backlogs/spec/components/backlogs/move_to_sprint_dialog_component_spec.rb	Updates dialog component spec to submit ordered ids[] collection.
modules/backlogs/spec/components/backlogs/move_to_bucket_dialog_component_spec.rb	Updates dialog component spec to submit ordered ids[] collection.
modules/backlogs/config/routes.rb	Moves sprint/bucket dialog routes to collection post.
modules/backlogs/config/locales/en.yml	Adds no-destination messages and plural moved announcements.
modules/backlogs/app/views/backlogs/backlog/show.html.erb	Clears selection on successful move events at the root controller.
modules/backlogs/app/services/backlogs/work_packages/destination_availability.rb	New service intersecting destinations across a batch + permissions.
modules/backlogs/app/services/backlogs/work_packages/batch_update_service.rb	Adds destination lifecycle + append locks and revalidates via DestinationAvailability.
modules/backlogs/app/controllers/backlogs/work_packages_controller.rb	Dialog endpoints now load/authorize ordered collections and render plural announcements.
modules/backlogs/app/components/backlogs/work_package_card_menu_component.rb	Menu now receives destination candidate ids and emits destination metadata.
modules/backlogs/app/components/backlogs/work_package_card_menu_component.html.erb	Renders destination actions as projected items with dialog POST forms and metadata.
modules/backlogs/app/components/backlogs/move_to_sprint_dialog_component.rb	Refactors dialog component to accept work package collections + controller-provided sprints.
modules/backlogs/app/components/backlogs/move_to_sprint_dialog_component.html.erb	Submits ids[] and shows selected count in the sprint dialog.
modules/backlogs/app/components/backlogs/move_to_bucket_dialog_component.rb	Refactors dialog component to accept work package collections + controller-provided buckets.
modules/backlogs/app/components/backlogs/move_to_bucket_dialog_component.html.erb	Submits ids[] and shows selected count in the bucket dialog.
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection.ts	Adds ordered selected elements helper for action-scope projection.
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection.spec.ts	Unit coverage for ordered selected element resolution.
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection-orchestrator.ts	Adds action-scope APIs (prospective vs mutating) for menu/dialog invocation.
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection-orchestrator.spec.ts	Covers action-scope semantics and anchor preservation.
frontend/src/stimulus/controllers/dynamic/sortable-lists/scrollable.controller.spec.ts	Updates root mocks for new destination/action-scope interface.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list.controller.spec.ts	Updates root mocks for new destination/action-scope interface.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list-dom.ts	Adds destination identity + intersection helpers for client-side projection.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list-dom.spec.ts	Unit coverage for destination intersection and occupancy filtering.
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.ts	Projects destination items, freezes ids[] into dialog forms, and supports direct destination moves.
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.spec.ts	Extensive coverage for projection, dialog freezing, and destination activation.
frontend/src/stimulus/controllers/dynamic/sortable-lists/drag-and-drop.ts	Extends root interface with action-scope + destination move capabilities.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.ts	Implements destination availability, direct destination moves, and busy-state recovery.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.spec.ts	Covers action scopes, direct destination submission, and busy-state reconciliation.
frontend/src/stimulus/controllers/async-dialog.controller.ts	Reimplements async dialog loading using @rails/request.js + beforeLoad hook.
frontend/src/stimulus/controllers/async-dialog.controller.spec.ts	New unit coverage for beforeLoad behavior, loading state, and response handling.

Suppressed comments (2)

frontend/src/stimulus/controllers/async-dialog.controller.ts:49

• Same as the click path: key activation uses void this.triggerTurboStream() without a catch, which can lead to unhandled promise rejections on request failures or unexpected responses. Catch/log in the handler to fail gracefully.

  private readonly handleKeydown = (event:Event):void => {
    const keyboardEvent = event as KeyboardEvent;
    if (keyboardEvent.key === 'Enter' || keyboardEvent.key === ' ') {
      event.preventDefault();
      void this.triggerTurboStream();

frontend/src/stimulus/controllers/async-dialog.controller.ts:106

• handleOpenDialog also calls triggerTurboStream() via void ... without handling rejections. If the request fails, this can likewise create an unhandled promise rejection. Catch/log here as well (or handle errors centrally in triggerTurboStream).

  handleOpenDialog(event:CustomEvent<{ url:string }>):void {
    // Trigger the dialog with custom URL
    void this.triggerTurboStream(event.detail.url);
  }

---

💡 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: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 #24779, 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:2]`

Treat this as a standalone task, unrelated to PR #24779. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24779 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 ./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 #24779, 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 #24779. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24779 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 ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]
• rspec ./spec/features/projects/lists/filters_spec.rb[1:6: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 #24779, linked for reference only):

- `rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]`
- `rspec ./spec/features/projects/lists/filters_spec.rb[1:6: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 #24779. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24779 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 40 out of 40 changed files in this pull request and generated 1 comment.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]
• rspec ./spec/features/roles/report_spec.rb[1:1]
• rspec ./spec/features/roles/report_spec.rb[1:2]
• rspec ./spec/features/roles/report_spec.rb[1:3]

🤖 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 #24779, linked for reference only):

- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`
- `rspec ./spec/features/roles/report_spec.rb[1:1]`
- `rspec ./spec/features/roles/report_spec.rb[1:2]`
- `rspec ./spec/features/roles/report_spec.rb[1:3]`

Treat this as a standalone task, unrelated to PR #24779. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24779 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.