Content
View differences
Updated by Alexander Coles 14 days ago
### 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)
#### Scenario 1: Selecting a single card
* - **Given** a user with "manage "manage backlog/sprint items" 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 "manage backlog/sprint items" 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 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. begins. 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 "manage backlog/sprint items" 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
* - **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 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.
*
- **And** while multiple cards are selected, a visible count is shown.
*
- **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 #AGILE-291; batch move mechanics are tracked in #AGILE-278.
### 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.
### 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.
**As** a user doing backlog refinement and sprint planning
### Acceptance Criteria (Refined)
#### Scenario 1: Selecting a single card
*
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
-
*
-
*
-
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
-
*
*
-
*
-
*
-
*
*
-
*
-
*
-
_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`.
* Only cards the user is currently permitted to move are eligible for selection.
* 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.
### Out of scope
* Mobile and tablet long-press selection behavior, to be tracked in a deferred follow-up work package