# Feature AGILE-181 - Multi-select cards within backlog and sprints

Project: Stream agile
Status: merged
URL: https://community.openproject.org/work_packages/AGILE-181

## Planning

| Attribute | Value |
| --- | --- |
| Date | 2026-08-03 – 2026-08-24 |
| Priority | Medium |
| Target versions | 18.0.0 |
| Sprint | Sprint 13 |
| Backlog bucket |  |
| Votes |  |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

| ID | Subject | Type | Status | Assignee | Target versions | Spent time |
| --- | --- | --- | --- | --- | --- | --- |
| AGILE-278 | Move selected work packages atomically | Implementation | closed |  | 18.0.0 |  |
| AGILE-348 | Show the card ActionMenu as a context menu | Implementation | closed |  | 17.8.0 |  |
| AGILE-361 | Add batch selection to Backlogs cards | Implementation | closed |  | 18.0.0 |  |
| AGILE-362 | Make Backlogs destination actions batch-aware | Implementation | closed |  | 18.0.0 |  |
| AGILE-363 | Add positional actions for batch selections | Implementation | closed |  | 18.0.0 |  |
| AGILE-364 | Apply batch selection to contextual ActionMenus | Implementation | closed |  | 18.0.0 |  |
| AGILE-392 | Constrain batch drags containing confined work packages | Implementation | closed |  | 18.0.0 |  |
| AGILE-396 | Add a stacked preview for multiple drag-and-dropped items in the backlog | Implementation | closed |  | 18.0.0 |  |
| AGILE-481 | Refresh deferred ActionMenu content via src | Implementation | closed |  | 18.0.0 |  |

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module | Modules and project features / Backlogs, Frontend components and Primer design system |
| Feature Flag |  |
| Requires doc change | Yes |
| Enterprise plan | Community (COM) |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups | https://www.figma.com/design/yRewu4Y5nuWCa8aMM3DFw3/Agile--Sprints-and-Backlogs?node-id=5986-20282&t=Hpb4KyP4hQldNesC-1 |
| Accessibility | Yes |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | OP Dev Polaris Team |
| Designer | Julia Racsko |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work | 12d 0h · Σ 12d 0h |
| Labor costs |  |

## Description

### Goal

**As** a user doing backlog refinement and sprint planning  
**I want to** select multiple cards  
**so that** I can move all selected cards to a sprint or backlog in one operation

### Acceptance Criteria (Refined)

#### Updated Card Interaction (<mention class="mention" data-id="AGILE-380" data-type="work_package" data-text="#AGILE-380">#AGILE-380</mention>)

  - Work Package Subject and Parent are no longer presented as links.

#### Scenario 1: Selecting a single card

  - **Given** a user with "manage backlog/sprint items" permissions

  - **When** they click a Work Package card without a modifier key

  - **Then** only that card is selected.

  - **And** its details are opened.

  - **And** it becomes the anchor for the next range selection.

#### Scenario 2: Toggling individual cards

  - **Given** a user with "manage backlog/sprint items" permissions

  - **When** they **Ctrl/Cmd-click** an unselected card

  - **Then** the card is added to the selection.

  - **When** they **Ctrl/Cmd-click** a selected card

  - **Then** the card is removed from the selection.

  - **And** the most recently toggled card becomes the anchor for the next range selection.

  - **And** the work package shown in the details pane does not change.

#### Scenario 3: Selecting a contiguous range

  - **Given** a selection anchor in a list

  - **When** the user **Shift-clicks** another card in the same list

  - **Then** the contiguous range between the anchor and the clicked card is selected.

  - **And** cards selected before this range began remain selected, including cards in other lists.

  - **And** repeated Shift gestures extend, shrink, or reverse the range from the same anchor. Cards added only by the previous range are removed when they fall outside the new range; independently selected cards remain selected even if they overlapped the previous range.

  - **And** the anchor stays unchanged.

  - **And** the work package shown in the details pane does not change.

  - **For example**, selecting A and C individually, then Shift-clicking D in C's list, selects A plus C–D. Shrinking the range back to C leaves A and C selected.

  - **And** a plain selection, an individual toggle, select-all, or clearing the selection ends the current range. The next range preserves the selection present when it begins, except after Select All: that selection can immediately be narrowed or reversed with Shift. Toggling a card still makes that card the anchor, including when it is deselected.

  - **Given** no anchor exists

  - **When** the user **Shift-clicks** a card

  - **Then** only that card is selected and it becomes the anchor.

#### Scenario 4: Range across a list boundary

  - **Given** an anchor in one list

  - **When** the user **Shift-clicks** a card in a different list

  - **Then** a new single-card selection starts in that list.

  - **And** the clicked card becomes the new anchor.

#### Scenario 5: Selection spanning several lists

  - **Given** a user with "manage backlog/sprint items" permissions

  - **When** they **Ctrl/Cmd-click** cards in different backlog and sprint lists

  - **Then** the sparse selection spans those lists.

  - **And** all selected cards are moved together by a later batch move (see Scenario 9).

#### Scenario 6: Range including unloaded cards (truncated list)

  - **Given** a truncated list with only part of its items rendered

  - **When** the user extends a range that would include unloaded cards

  - **Then** the range is rejected.

  - **And** the existing selection and anchor stay unchanged.

  - **And** the user is told to expand the list first.

#### Scenario 7: Cards the user may not move

  - **Given** a card the user is not permitted to move

  - **When** they attempt to select it by pointer or keyboard

  - **Then** the selection stays unchanged.

  - **And** the rejection is announced to screen readers.

  - **And** **Ctrl/Cmd+A** selects all loaded movable cards only.

#### ~~Scenario 8: Keyboard selection~~

*Screen-reader operability of keyboard selection is deferred to <mention class="mention" data-id="AGILE-423" data-type="work_package" data-text="#AGILE-423">#AGILE-423</mention> (under <mention class="mention" data-id="AGILE-448" data-type="work_package" data-text="#AGILE-448">#AGILE-448</mention>); the plain-keyboard behavior below is delivered.*

  - **Given** a keyboard user focused on a Work Package card

  - **When** they press the arrow keys

  - **Then** focus moves between cards without changing the selection.

  - **And** **Space** toggles selection of the focused card.

  - **And** **Shift+Space** or **Shift+Arrow** resizes a range from the anchor using the same preservation, shrinking, and reversal rules as Shift-click (Scenario 3).

  - **And** **Ctrl/Cmd+A** selects all loaded movable cards.

  - **And** **Escape** clears the selection.

  - **And** **Enter** opens the card's details.

#### Scenario 9: Dragging a selected card

  - **Given** several cards are selected

  - **When** the user drags one of the selected cards to a valid destination

  - **Then** the full selection moves as one ordered block.

  - **And** the cards retain their visible top-to-bottom order at the destination.

  - **And** the batch move succeeds or fails atomically as one operation.

#### Scenario 10: Dragging an unselected card

  - **Given** several cards are selected

  - **When** the user drags a card that is not part of the selection

  - **Then** the previous selection is cleared.

  - **And** only the dragged card moves.

#### Scenario 11: Successful batch move

  - **Given** a batch move has been submitted

  - **When** the server confirms it

  - **Then** the cards appear at their destination in the submitted order.

  - **And** the selection is cleared.

#### Scenario 12: Failed batch move

  - **Given** a batch move has been submitted

  - **When** the server rejects it

  - **Then** the whole batch is reverted, with no partial movement.

  - **And** the cards stay selected.

  - **And** the failure is announced to screen readers.

  - **When** a concurrent update has already changed the lists

  - **Then** the user is told to check the current card positions instead.

#### Scenario 13: Card menu on a selected card

  - **Given** several cards are selected

  - **When** the user opens the action menu on one of the selected cards

  - **Then** the batch selection is kept.

  - **And** applicable destination actions act on the whole batch.

  - **And** positional actions are offered only for a single contiguous selection within one list.

#### Scenario 14: Card menu on an unselected card

  - **Given** several cards are selected

  - **When** the user opens the action menu on a card that is not part of the selection

  - **Then** the selection is replaced with that card.

  - **And** the menu actions act on that card alone.

#### Scenario 15: Selection feedback

  - **Given** one or more cards are selected

  - **Then** ~~the selection state is communicated visually and exposed to assistive technology.~~ *(visual communication delivered; assistive-technology exposure is deferred to <mention class="mention" data-id="AGILE-424" data-type="work_package" data-text="#AGILE-424">#AGILE-424</mention>, under <mention class="mention" data-id="AGILE-448" data-type="work_package" data-text="#AGILE-448">#AGILE-448</mention>)*

  - **And** ~~while multiple cards are selected, a visible count is shown.~~ *(deliberately omitted in <mention class="mention" data-id="AGILE-361" data-type="work_package" data-text="#AGILE-361">#AGILE-361</mention>; presentation to be agreed per the Additional review decisions below — not part of <mention class="mention" data-id="AGILE-424" data-type="work_package" data-text="#AGILE-424">#AGILE-424</mention>)*

  - **And** keyboard users can perform the equivalent move through the card menu.

### Acceptance criteria (pre-refinement)

*Superseded by the scenarios above; kept for reference.*

  - Only cards the user is permitted to move can be selected. Attempting to select a non-movable card leaves the selection unchanged and is announced.

  - On desktop:
    
      - A plain click selects only that card and opens its details.
    
      - **Ctrl/Cmd-click** toggles individual cards. The most recently selected or toggled card becomes the anchor for the next range.
    
      - **Shift-click** selects a contiguous range from the anchor within the same list. Without an anchor, it selects only the clicked card and establishes it as the anchor.

  - Keyboard users have equivalent selection controls: arrow keys move focus, **Space** toggles selection, **Shift+Space** or **Shift+Arrow** extends a range, **Ctrl/Cmd+A** selects all loaded movable cards, and **Escape** clears the selection. **Enter** opens card details.

  - A sparse selection may span backlog and sprint lists, but a range cannot cross a list boundary or unloaded cards:
    
      - **Shift-click** in a different list starts a new single-card selection there and establishes a new anchor.
    
      - A range that would include unloaded cards is rejected: the existing selection and anchor stay unchanged, and the user is told to expand the list first.

  - Modifier-based selection does not change the work package currently shown in the details pane.

  - Dragging a selected card moves the full selection as one ordered block. Dragging an unselected card clears the previous selection and moves that card alone.

  - Cards retain their visible top-to-bottom order at the destination, and the batch move succeeds or fails atomically as one operation.

  - After a successful move, the selection is cleared. After a failed move, the cards remain selected and the move is reverted; if a concurrent update has already changed the lists, the user is told to check the current card positions instead.

  - Opening the card menu on a selected card keeps the batch selection; opening it on an unselected card replaces the selection with that card. Applicable destination actions act on the batch. Positional actions are available only for one contiguous selection within one list.

  - Pointer and keyboard selection behavior complies with the applicable WAI-ARIA APG multi-selection guidance.

  - Selection state is communicated visually and accessibly; while multiple cards are selected, a visible count is shown. Keyboard users can perform the equivalent move through the card menu.

### Technical notes

  - The interaction is informed by the [WAI-ARIA APG multi-select listbox pattern](https://www.w3.org/WAI/ARIA/apg/patterns/listbox/), but work package cards are not listbox options because they contain interactive descendants. Do not apply `role="listbox"`, `role="option"`, or `aria-selected`.

  - Pointer and keyboard selection behaviour complies with the applicable WAI-ARIA APG multi-selection guidance.

  - Builds on the drag-and-drop foundations delivered in <mention class="mention" data-id="AGILE-291" data-type="work_package" data-text="#AGILE-291">#AGILE-291</mention>; batch move mechanics are tracked in <mention class="mention" data-id="AGILE-278" data-type="work_package" data-text="#AGILE-278">#AGILE-278</mention>.

### Permissions and visibility considerations

  - Only cards the user is currently permitted to move are eligible for selection.

  - The server re-authorizes every submitted work package.

  - If any submitted work package is invalid or unauthorized, the entire batch is rejected without partial movement (atomic)

### Translation considerations

  - Selection and movement feedback must use translatable, plural-aware strings. This includes selected counts, selection rejection, successful movement, rollback or concurrent-update guidance, and work package counts shown in destination dialogs.

### Open decisions on behaviour

These are potential follow-up changes, not approved acceptance criteria. The current behavior remains unless a decision below is explicitly adopted.

  - **Shift into another list:** currently starts a new single-card selection and anchor. Consider preserving the existing batch and adding the endpoint instead. Any change must retain the single-item-type restriction; crossing into a different item type must not create a mixed batch.

  - **Anchor moved to another list by a live update:** currently ends the range session and retains the selected cards. The next Shift gesture uses that selection as its baseline. Consider whether cards added only by the old range should instead be removed. This would change selection during reconciliation and needs explicit agreement.

  - **Select-all scope and existing selections:** currently replaces the batch with loaded movable cards in the focused list. Consider whether retaining independent picks outside that list would be useful. Column-wide or progressive select-all would be separate decisions; neither is part of the current fix.

**Agreed correction in AGILE-361:** after Select All, Shift gestures can narrow or reverse the resulting range. Select All continues to replace the previous batch and stays list-scoped. Independently toggling a card afterwards starts a fresh range baseline in the usual way.

### Additional review decisions to discuss

These items from [the AGILE-361 review](https://github.com/opf/openproject/pull/24525#issuecomment-5602620070) are explicitly deferred for discussion. They do not change the accepted behavior or authorize implementation.

  - **Clearing by background click:** decide whether clicking empty Backlogs space should clear the batch, and which areas count as background. Preserve clicks in the details pane, menus, dialogs and drag interactions unless explicitly agreed otherwise. Escape remains the supported clear action. [Henriette’s usability review](https://github.com/opf/openproject/pull/24525#pullrequestreview-5030717957).

  - **Selection independent of movement permissions:** decide the first non-move batch use case and the separate capabilities for navigation, selection and movement. The move-only root gate and fixed-item selection restriction remain for now; the current work package highlight remains independent. Before introducing permission-independent actions, revisit both the root permission gate and item eligibility. [Jens’s coupling comment](https://github.com/opf/openproject/pull/24525#discussion_r3863821574), [Henriette’s permission comment](https://github.com/opf/openproject/pull/24525#discussion_r3870230676). Carry the destination-policy consequence in [AGILE-392 / <mention class="mention" data-id="24858" data-type="work_package" data-text="#24858">#24858</mention>](https://github.com/opf/openproject/pull/24858)'s merge checklist.

  - **Anchor after deselection and fixed-card clicks:** the most recently toggled card remains the anchor even when deselected; a plain click on a fixed card clears an existing batch while opening details. Discuss any alternative before changing these policies. Keep keyboard focus, the range anchor and the current work package distinct. [Henriette’s anchor report](https://github.com/opf/openproject/pull/24525#pullrequestreview-5030717957).

  - **Shared platform detection:** consolidate the Stimulus Apple-platform helper with Angular browser/device detection in a framework-independent home. The follow-up is agreed in principle; discuss scope and ownership before creating its Code maintenance work package. [Henriette’s comment and existing follow-up commitment](https://github.com/opf/openproject/pull/24525#discussion_r3869726177).

  - **Split-view activation and scroll loss:** confirm and minimise the reported reload/scroll-loss sequence, check for an existing issue, and agree a dedicated bug-fix work package if needed. Plain-click details activation remains unchanged. [Jens’s general review, click/scroll point](https://github.com/opf/openproject/pull/24525#pullrequestreview-5006033675).

  - **Modified double-click:** decide whether modified double-click should suppress full-page activation and how its two clicks affect membership. The existing full-view double-click handler remains; no cross-platform native-list equivalence is assumed. [Jens’s general review, double-click point](https://github.com/opf/openproject/pull/24525#pullrequestreview-5006033675).

  - **Persistent visible selection count:** reconcile Scenario 15 with AGILE-361's deliberate omission of a count that shifts cards under the pointer. Agree a stable presentation and delivery work package, or revise the feature criterion; AGILE-424 explicitly excludes a persistent visible count.

### Wayfinding

**Destination:** Scenarios 13–15 delivered on the shared batch-selection model, with the card menu's batch actions decided by the server rather than client-side projection, and a selection model that other lists (e.g. the type's Projects tab in <mention class="mention" data-id="AUTOWORK-324" data-type="work_package" data-text="#AUTOWORK-324">#AUTOWORK-324</mention>) can reuse.

**Notes**

  - Target: OpenProject 18.0. Feature freeze is 2026-11-11.

  - The stack PRs ([<mention class="mention" data-id="24779" data-type="work_package" data-text="#24779">#24779</mention>](https://github.com/opf/openproject/pull/24779), [<mention class="mention" data-id="24780" data-type="work_package" data-text="#24780">#24780</mention>](https://github.com/opf/openproject/pull/24780), [<mention class="mention" data-id="24781" data-type="work_package" data-text="#24781">#24781</mention>](https://github.com/opf/openproject/pull/24781)) implement the server-rendered menu design, target `release/18.0` and are in review; <mention class="mention" data-id="24779" data-type="work_package" data-text="#24779">#24779</mention> and <mention class="mention" data-id="24780" data-type="work_package" data-text="#24780">#24780</mention> are in "review failed" after two independent reviews on 2026-11-05. They still pin a Primer pre-release and wait for the rework of [opf/primer\_view\_components\#544](https://github.com/opf/primer_view_components/pull/544). [<mention class="mention" data-id="25359" data-type="work_package" data-text="#25359">#25359</mention>](https://github.com/opf/openproject/pull/25359) still documents the superseded client-projection design.

**Decisions so far**

  - [Move selected work packages atomically](https://community.openproject.org/wp/AGILE-278), [Add batch selection to Backlogs cards](https://community.openproject.org/wp/AGILE-361), [Constrain batch drags containing confined work packages](https://community.openproject.org/wp/AGILE-392), [stacked drag preview](https://community.openproject.org/wp/AGILE-396) and [the card ActionMenu as a context menu](https://community.openproject.org/wp/AGILE-348): delivered (Scenarios 1–12; context-menu presentation).

  - [Apply batch selection to contextual ActionMenus](https://community.openproject.org/wp/AGILE-364), 2026-10-30: the first implementation (<mention class="mention" data-id="24781" data-type="work_package" data-text="#24781">#24781</mention>) relies too much on client logic and is to be reworked ([comment on <mention class="mention" data-id="26467" data-type="work_package" data-text="#26467">#26467</mention>](https://github.com/opf/openproject/pull/26467#issuecomment-6512905685)). Its acceptance criteria stay: invalid batch actions are omitted, and an empty batch scope falls back to single actions. The server therefore renders the menu's contents for the settled selection on each open.

  - Card-menu wiring, 2026-10-30: one controller on the list container listens for `beforetoggle` in the capture phase and sets the menu's `src` from the settled selection. It borrows only the listener shape of `type-projects-selection.controller.ts` in <mention class="mention" data-id="26467" data-type="work_package" data-text="#26467">#26467</mention>; unlike that controller, the server decides the menu's contents. `ContextualActionMenuController` stays gesture- and positioning-only. The gesture-time selection policy stays in `beforeOpen`.

  - [Refresh deferred ActionMenu content via src](https://community.openproject.org/wp/AGILE-481), 2026-10-30: the Primer prerequisite. A deferred `ActionMenu` reloads when the `src` attribute on `<action-menu>` changes. An unchanged `src` does nothing, unless the last load failed. A newly inserted `<include-fragment>` is picked up, which may let us retire `action-menu-morph-remount.ts`. Implemented in [opf/primer\_view\_components\#544](https://github.com/opf/primer_view_components/pull/544), in review.

  - Delivery, 2026-11-01: rebuild the <mention class="mention" data-id="AGILE-362" data-type="work_package" data-text="#AGILE-362">#AGILE-362</mention>, <mention class="mention" data-id="AGILE-363" data-type="work_package" data-text="#AGILE-363">#AGILE-363</mention> and <mention class="mention" data-id="AGILE-364" data-type="work_package" data-text="#AGILE-364">#AGILE-364</mention> PRs from `dev`, cherry-picking only the server, dialog and transport work that survives, instead of reworking the existing branches. <mention class="mention" data-id="AGILE-362" data-type="work_package" data-text="#AGILE-362">#AGILE-362</mention>, <mention class="mention" data-id="AGILE-363" data-type="work_package" data-text="#AGILE-363">#AGILE-363</mention> and <mention class="mention" data-id="AGILE-364" data-type="work_package" data-text="#AGILE-364">#AGILE-364</mention> descriptions are revised before the rebuild.

  - Server-rendered menus via `src` supersede the LiveComponent experiment for card menus (September 2026), 2026-11-01. LiveComponent remains experimental.

  - Batch size, 2026-11-01: the provisional cap from <mention class="mention" data-id="AGILE-278" data-type="work_package" data-text="#AGILE-278">#AGILE-278</mention> (`MAX_BATCH_SIZE = 50`, refused as `batch_too_large`) stays for 18.0. Menus and dialogs add no further limit. Whether to raise or remove it is to be discussed with @ulferts.

  - More than 50 cards selected, 2026-11-01: the card menu shows the batch menu with its move actions disabled and explains why, reusing the drag refusal ("Cannot move %{count} work packages at once. Select no more than %{max}."). Selection itself stays uncapped.

  - Menu responsibilities, 2026-11-01: the server decides which actions that move cards out of their current list are offered, based on permissions. **Move to position** (Top, Up, Down, Bottom) stays on the client, because it uses optimistic reordering and will be reused by other lists.

  - Rebuild delivered, 2026-11-02: <mention class="mention" data-id="AGILE-362" data-type="work_package" data-text="#AGILE-362">#AGILE-362</mention>, <mention class="mention" data-id="AGILE-363" data-type="work_package" data-text="#AGILE-363">#AGILE-363</mention> and <mention class="mention" data-id="AGILE-364" data-type="work_package" data-text="#AGILE-364">#AGILE-364</mention> rebuilt from `dev` on server-rendered menus and retargeted to `release/18.0`; they merge together. The Turbo cache recovery and the per-entry-point invocation policy (More button, right-click, Context Menu key, **Shift+F10**) are part of <mention class="mention" data-id="AGILE-364" data-type="work_package" data-text="#AGILE-364">#AGILE-364</mention>. Remaining merge gates are on each PR's checklist.

  - Member-write race, 2026-11-02: [Coordinate member and batch moves into the inbox](https://community.openproject.org/wp/AGILE-426) does not block the stack. Destination moves go through the collection move; the remaining single-item callers and their consolidation are audited there.

  - [Refresh deferred ActionMenu content via src](https://community.openproject.org/wp/AGILE-481) rework, 2026-11-05: after Lars's review of [opf/primer\_view\_components\#544](https://github.com/opf/primer_view_components/pull/544) and two adversarial reviews, the element is reworked on top of [<mention class="mention" data-id="547" data-type="work_package" data-text="#547">#547</mention>](https://github.com/opf/primer_view_components/pull/547) (<mention class="mention" data-id="DREAM-980" data-type="work_package" data-text="#DREAM-980">#DREAM-980</mention>). A deferred menu renders its loader as a server-side `<template>`, so refreshability comes from markup and survives Turbo snapshots and morphs; OpenProject no longer restores lazy fragments on `turbo:before-cache`. `src` stays the trigger and `refresh()` forces a reload; no event (no use case yet). A closed menu applies a `src` change when it next opens, keeping its items, label and inputs until then; a failed load retries on the next open. Design: `agent-plans/superpowers/specs/2026-11-05-action-menu-src-refresh-rework-design.md`.

  - Morph gap root-caused, 2026-11-05: a morphed menu that did not fetch on reopen is Idiomorph inserting a new `<include-fragment>` **empty** when its content has an id (the spinner list does), then setting attributes; the fragment never registers its lazy observer. Primer now refetches any loader still in the body when the menu opens, with a regression test for that insertion order. `action-menu-morph-remount.ts` is retired once that test and `card_menu_turbo_cache_spec.rb` pass with it disabled.

  - Card-menu wiring, 2026-11-05: `menu-source.controller.ts` keeps the `beforetoggle` capture listener that sets `src` from the settled selection (legitimate consumer work, per both reviews) and drops `rememberLazyFragment`, `restoreLazyFragment`, `onBeforeCache`, `overlayOf`, `primaryBodyOf`. During a load it names the menu from the settled scope, not from the previous list. The accessible-name plumbing (`menuTargetConnected`, `rename`, `tooltipOf`) is a Primer gap: [ActionMenu: apply a consumer-supplied accessible name to the primary list and its IconButton](https://community.openproject.org/wp/DREAM-981), a follow-up outside this map's 18.0 scope.

**Open questions**

  - **OPEN POINT — fixed cards and the batch.** Selection is limited to cards the user may move, so a fixed card cannot join or replace the selection. Today a plain click on a fixed card clears the batch and opens its details, while opening its card menu keeps the batch and shows single work package actions only. The two disagree, and neither matches the work package table rule from <mention class="mention" data-id="OP-20333" data-type="work_package" data-text="#OP-20333">#OP-20333</mention> (an unselected row's menu replaces the selection with that row), because every table row is selectable. Behavior stays as is for 18.0. The conventional resolution is selection independent of movement permissions (see Not yet specified): fixed cards become selectable, permissions gate only the offered actions, and Backlogs and the table share one rule. Align with <mention class="mention" data-id="DREAM-874" data-type="work_package" data-text="#DREAM-874">#DREAM-874</mention>.

**Not yet specified**

  - Consuming <mention class="mention" data-id="AGILE-481" data-type="work_package" data-text="#AGILE-481">#AGILE-481</mention> in OpenProject: release of the Primer fork and the gem and npm bump that replace the pre-release pin in <mention class="mention" data-id="AGILE-362" data-type="work_package" data-text="#AGILE-362">#AGILE-362</mention>, then the `menu-source.controller.ts` simplification and the component-spec updates (assert the host `src` and the template, not a body fragment) in <mention class="mention" data-id="AGILE-364" data-type="work_package" data-text="#AGILE-364">#AGILE-364</mention>. Blocked on the rework of [opf/primer\_view\_components\#544](https://github.com/opf/primer_view_components/pull/544) landing on top of <mention class="mention" data-id="547" data-type="work_package" data-text="#547">#547</mention>.

  - Selection without drag: the `dragEnabled` flag on `sortable-lists` (<mention class="mention" data-id="26467" data-type="work_package" data-text="#26467">#26467</mention>) as an interim step, versus splitting the selection and drag controllers. To be agreed with <mention class="mention" data-id="AUTOWORK-324" data-type="work_package" data-text="#AUTOWORK-324">#AUTOWORK-324</mention>.

  - Selection independent of movement permissions (see Additional review decisions). Reuse by lists without movement, such as <mention class="mention" data-id="AUTOWORK-324" data-type="work_package" data-text="#AUTOWORK-324">#AUTOWORK-324</mention>, depends on it, and it resolves the fixed-card open point above.

  - When to retire `action-menu-morph-remount.ts`: after the <mention class="mention" data-id="AGILE-481" data-type="work_package" data-text="#AGILE-481">#AGILE-481</mention> rework lands, run `card_menu_turbo_cache_spec.rb` with the remount and the consumer restore disabled; retire it in <mention class="mention" data-id="AGILE-364" data-type="work_package" data-text="#AGILE-364">#AGILE-364</mention> when green (see Decisions, 2026-11-05).

  - Whether a selection change while a card menu is already open refreshes it immediately or waits until it closes.

  - [Document batch selection and movement in Lookbook](https://community.openproject.org/wp/AGILE-436) describes the client-projection APIs; rescope or descope.

**Out of scope for this map**

  - Screen-reader operability and accessible feedback ([AGILE-448](https://community.openproject.org/wp/AGILE-448): <mention class="mention" data-id="AGILE-423" data-type="work_package" data-text="#AGILE-423">#AGILE-423</mention>, <mention class="mention" data-id="AGILE-424" data-type="work_package" data-text="#AGILE-424">#AGILE-424</mention>).

  - The Open decisions on behaviour and the Additional review decisions above, except selection independent of movement permissions. They stay candidates for later work and do not block 18.0.

### Out of scope

  - Mobile and tablet long-press selection behavior, to be tracked in a deferred follow-up work package

  - Migration of `wp-fast-table` or the Angular card view to the framework-agnostic selection model

  - Direct keyboard grab and drop; equivalent movement remains available through the card menu

  - Adding a visible drag handle; the whole card remains the pointer drag source

  - Selecting work packages hidden behind truncation or filters

  - A separate **Ctrl/Cmd+Shift** range-selection mode. Ordinary Shift range selection already preserves independently selected cards as described in Scenario 3.