[AGILE-361] Add batch selection to Backlogs cards

[myabc]

Ticket

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

What are you trying to accomplish?

Backlogs cards can only be acted on one at a time. This adds batch selection to the sprint planning page, so a user can build a selection of cards with the mouse or the keyboard, as a prerequisite for acting on several at once.

Mouse: a plain click selects just that card (and still opens its details pane, as before). Ctrl/Cmd+click toggles one card in or out without navigating. Shift+click selects a contiguous range from a fixed anchor, so repeated Shift+clicks resize one range rather than walking it.

Keyboard: Space toggles the focused card. Arrow keys move focus, and with Shift extend the range. Home/End jump to the first/last movable card in the list. Ctrl/Cmd+A selects every loaded movable card in the focused card's list. Escape clears the selection wherever focus sits — on a card, on a link inside one, or nowhere at all. Enter is left alone — it belongs to the card's own activation handler.

A range is confined to a single list, because a range that spanned the backlog and sprint columns has no meaningful order — and select-all is confined the same way, so "everything" means everything in the list the user is looking at. A selection spanning lists is still reachable: Ctrl/Cmd+click is not list-confined, and a keyboard user can Tab to a card in the other column and toggle it with Space. A one-gesture cross-list select-all is deliberately left to a separate, future mechanism.

Batch movement is not part of this PR. A drag still moves exactly one card, collapsing any wider selection onto the card being dragged rather than implying the rest came along. Acting on a batch is AGILE-278, which stacks on this branch.

Screen recording

Screen.Recording.2026-08-18.at.23.15.33.mov

Accessibility

Selection changes are announced through the shared Primer live region, in the consumer's own vocabulary ("work package", not "item"). Every selected card points at one shared, permanently hidden description element via aria-describedby, so batch membership reaches a screen reader per card without duplicating a string onto every card. Gestures that change nothing visible — a range refused because it crosses lists, or because it contains a card the user may not move — get their own message rather than silently doing nothing.

There is no visible on-screen count. An earlier revision had one; see below.

What approach did you choose and why?

The selection policy is framework-agnostic and lives outside Stimulus. frontend/src/common/batch-selection.ts knows nothing about the DOM, Stimulus, or work packages — it is anchor/range/toggle logic over opaque ids. wp-fast-table and the Angular card view are the intended next consumers, and keeping the model free of this page's concepts is what makes that possible without a rewrite. The DOM-facing half is a separate adapter, sortable-lists/selection.ts, so neither the model nor the root controller grows a second job.

Selection is opt-in per root. A root enables it with selectionEnabled; every other sortable-lists consumer is unchanged by being upgraded. The announcement scope and the shared description id are values too, so the shared controller speaks the consumer's vocabulary while staying free of Backlogs terminology itself.

The pointer listener runs in the capture phase at the root — but Escape listens at the document, in the bubble phase. Capture is what lets a modified click be consumed before the card's own navigation handler sees it, without depending on the order two independent controllers happen to connect in. An ordinary click is deliberately let through. Escape is the deliberate exception: clearing the selection must not depend on focus sitting on a card row, and bubbling lets a dialog's or menu's own Escape run first and be respected.

Movability became a property of the item rather than a reason to withhold the controller. Previously a card the user could not move rendered without the sortable item controller at all, which took it out of the list's addressable order: it could not anchor a neighbour's drop and was invisible to position counting. Every card row is now a sortable item, with mobility as a value on it.

Two things worth a reviewer's attention

No visible selection count. An earlier revision had one. It reserved a line of layout space above both planning columns, which shifted every card beneath it and broke positional drags against the unchanged drag_in_bucket_spec. Design had not settled on needing it, so it went rather than earning a layout workaround.

hidden on the shared description is deliberate. An element referenced directly by aria-describedby is still traversed for the accessible description (accname §4.1 step 2A). The feature spec asserts the computed accessible_description, so this is verified rather than assumed — please don't "fix" it to sr-only, which would put it back in the layout and reintroduce that drag regression.

Reviewing this

The first 7 commits are ordered to be read in sequence: the framework-free model first, then item mobility, the selection adapter and gestures, the root wiring, the Backlogs adoption, the end-to-end spec, and the docs. The 9 commits after them answer the 2026-08-26/27 review round, one topic each, so a thread's fix can be read as its own diff; each is green on its own.

Merge checklist

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

[github-actions]

Warning

Flaky specs

• rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]
• rspec ./modules/overviews/spec/features/project_description_widget_spec.rb[1:1:1:1:1]

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

- `rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]`
- `rspec ./modules/overviews/spec/features/project_description_widget_spec.rb[1:1:1:1:1]`

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

This PR introduces opt-in batch selection to Backlogs’ sortable lists, including keyboard/mouse interactions, persistent selection count UI, and consistent selection/current-work-package styling across Turbo morphs.

Changes:

• Add a framework-agnostic BatchSelection model plus a DOM adapter to drive selection behavior in the shared sortable-lists Stimulus controller.
• Render a persistent Backlogs selection count component (and shared “selected” description element) and wire Backlogs’ root to enable selection + consumer-specific announcements.
• Update Backlogs item/card DOM contract and styling: movable vs non-movable items, focus target, and selection/current markers preserved across morphs.

Reviewed changes

Copilot reviewed 38 out of 38 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
modules/backlogs/spec/support/pages/backlog.rb	Extends Backlogs page object with batch selection helpers and updated drag expectations.
modules/backlogs/spec/requests/backlogs/backlog_spec.rb	Adds request spec to ensure selection UI/description is rendered even when inbox is filtered out.
modules/backlogs/spec/features/work_packages/batch_selection_spec.rb	New Selenium feature spec covering mouse + keyboard batch selection behavior and accessibility wiring.
modules/backlogs/spec/components/backlogs/work_package_card_list_item_component_spec.rb	Updates component specs for movability flag, focus target, and row/card attributes.
modules/backlogs/spec/components/backlogs/work_package_card_list_component_spec.rb	Adjusts expectations for updated item target tokens.
modules/backlogs/spec/components/backlogs/sprint_component_spec.rb	Aligns sprint rendering expectations with “sortable item always, movable maybe” contract.
modules/backlogs/spec/components/backlogs/selection_count_component_spec.rb	New component spec for persistent selection count + shared description rendering.
modules/backlogs/spec/components/backlogs/bucket_component_spec.rb	Aligns bucket rendering expectations with updated item contract.
modules/backlogs/config/locales/js-en.yml	Adds Backlogs-specific selection announcement/count strings.
modules/backlogs/app/views/backlogs/backlog/show.html.erb	Enables selection on Backlogs root and configures announcement scope + description id.
modules/backlogs/app/views/backlogs/backlog/_backlog_list.html.erb	Renders selection count component above both planning columns.
modules/backlogs/app/components/backlogs/work_package_card_list_item_component.rb	Makes every row a sortable item, adds movable value, and adds a focus item target on the card.
modules/backlogs/app/components/backlogs/selection_count_component.sass	Styles persistent selection count and hides it via visibility when empty.
modules/backlogs/app/components/backlogs/selection_count_component.rb	Introduces SelectionCount component + shared description id constant.
modules/backlogs/app/components/backlogs/selection_count_component.html.erb	Renders persistent count region and shared description element.
modules/backlogs/app/components/_index.sass	Registers selection count styles in Backlogs components bundle.
frontend/src/turbo/pragmatic-dnd-morph-attributes.ts	Preserves batch selection marker across Turbo morphs to avoid visual flashing.
frontend/src/turbo/pragmatic-dnd-morph-attributes.spec.ts	Updates morph preservation test for new selection marker.
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection.ts	Adds selection DOM adapter: candidate resolution, range resolution, focus navigation helpers, and presentation wiring.
frontend/src/stimulus/controllers/dynamic/sortable-lists/selection.spec.ts	Unit tests for selection adapter behavior.
frontend/src/stimulus/controllers/dynamic/sortable-lists/scrollable.controller.spec.ts	Updates fake root interface in tests for new selection capabilities.
frontend/src/stimulus/controllers/dynamic/sortable-lists/preview.ts	Removes legacy split-view data-selected stripping; documents batch selection attribute placement.
frontend/src/stimulus/controllers/dynamic/sortable-lists/preview.spec.ts	Updates preview sanitization tests accordingly.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list.controller.spec.ts	Updates fake root interface in tests for new selection capabilities.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list-dom.ts	Adds movable attribute contract and isMovableItem helper.
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.ts	Adds movable value, focus target support, and collapses selection on drag start.
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.spec.ts	Adds coverage for movability gating + focus behavior + drag-start selection collapse.
frontend/src/stimulus/controllers/dynamic/sortable-lists/drag-and-drop.ts	Extends root interface with selectionEnabled and collapseSelectionForDrag.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.ts	Implements opt-in batch selection interactions, announcements, morph reconciliation, and selection count rendering.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.spec.ts	Extensive new test coverage for selection interactions, announcements, and morph reconciliation.
frontend/src/stimulus/controllers/dynamic/backlogs/work-package.controller.ts	Removes legacy data-selected handling; keeps only aria-current syncing to URL.
frontend/src/stimulus/controllers/dynamic/backlogs/work-package.controller.spec.ts	Updates tests for current-work-package behavior and ensures batch membership is unaffected by URL sync.
frontend/src/global_styles/content/modules/_backlogs.sass	Adjusts Backlogs layout to accommodate persistent selection count above scroll columns.
frontend/src/common/batch-selection.ts	Adds framework-agnostic batch selection model (ids + anchor + prune).
frontend/src/common/batch-selection.spec.ts	Unit tests for batch selection model semantics.
frontend/AGENTS.md	Documents sortable-lists batch selection opt-in, vocabulary, and marker placement.
config/locales/js-en.yml	Adds default sortable-lists selection announcement strings (generic “item” vocabulary).
app/components/open_project/common/border_box_list_component.sass	Updates styling selectors from legacy data-selected to new data-batch-selected + aria-current separation.

[Copilot]

Pull request overview

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

Suppressed comments (2)

modules/backlogs/app/components/backlogs/selection_count_component.html.erb:55

• hidden: true renders a literal HTML hidden attribute (i.e., display: none), which commonly removes the element from the accessibility tree. Because this span is referenced via aria-describedby, it should be visually hidden (e.g., sr-only) rather than hidden, otherwise some screen readers may ignore the referenced description.

<%= render(Primer::Box.new(tag: :span, id: DESCRIPTION_ID, hidden: true)) do %>
  <%= I18n.t("js.backlogs.selection.card_state") %>
<% end %>

modules/backlogs/spec/support/pages/backlog.rb:764

• This comment says the description is permanently hidden and still reachable via aria-describedby. With the HTML hidden attribute that isn’t reliably true; the description should be treated as visually hidden (e.g., sr-only) so assistive tech can still reference it. Updating this wording will prevent future changes from reintroducing hidden and breaking the a11y contract.

[Copilot]

Pull request overview

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

[github-actions]

Warning

Flaky specs

• rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:3:2:2:1:1]

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

- `rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:3:2:2:1:1]`

Treat this as a standalone task, unrelated to PR #24525. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24525 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/calendar/spec/features/calendar_user_interaction_spec.rb[1:1:4:1]

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

- `rspec ./modules/calendar/spec/features/calendar_user_interaction_spec.rb[1:1:4:1]`

Treat this as a standalone task, unrelated to PR #24525. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24525 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/wikis/spec/features/admin/internal_provider_spec.rb[1:1]
• rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]

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

- `rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]`
- `rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]`

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

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

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

Treat this as a standalone task, unrelated to PR #24525. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24525 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/share/multi_invite_spec.rb[1:5:1]

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

- `rspec ./spec/features/work_packages/share/multi_invite_spec.rb[1:5:1]`

Treat this as a standalone task, unrelated to PR #24525. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24525 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/wikis/spec/features/admin/internal_provider_spec.rb[1:1]

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

- `rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]`

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