-
Type:
Suggestion
-
Resolution: Unresolved
-
Component/s: Backlog (Company) - View
-
None
-
1
Issue Summary
Following the rollout of the "Enhanced Jira board and backlog" UI (as detailed in the recent Community Article: Enhanced Jira board and backlog{}), the right-click context menu and keyboard shortcuts became strictly container-aware. When an issue is located inside an Active or Planned Sprint, users can no longer move that issue directly to the top or bottom of the global Backlog. The options are now restricted only to "Move to top/bottom of sprint". This severely disrupts customers who rely on a dedicated "Triage" sprint, as they can no longer rapidly rank issues into the global backlog directly from their triage sprint container.
Steps to Reproduce
- Ensure the "Enhanced Jira board and backlog" UI is active on a Jira Cloud site.
- Navigate to the Backlog view of a Jira Software board.
- Locate or place an issue inside a planned or active Sprint.
- Right-click the issue to view the context menu, OR attempt to use the global keyboard shortcuts (s + t for top, s + b for bottom).
Expected Results
Users should have an option in the right-click menu, or a functioning keyboard shortcut, that allows them to send the selected issue directly to the top or bottom of the global "Backlog" section, regardless of what Sprint it is currently sitting in.
Actual Results
The contextual menu only displays "Move to top/bottom of sprint". Furthermore, the keyboard shortcuts (s + t and s + b) are also container-restricted and only move the item to the top/bottom of the current Sprint, failing to move the item to the global Backlog.
Workaround
The user must perform a two-step process: First, right-click the issue and select "Move to Backlog" (or drag and drop it into the backlog section). Second, once the issue is sitting in the backlog section, right-click it again (or use the shortcuts) to finally move it to the "Top/Bottom of backlog".
Required, if there is no workaround please state:
Currently there is no known workaround for this behavior. A workaround will be added here when available