The Vanishing Sprint Board After a Permission Scheme Swap
Your organization runs Jira Data Center with 41 projects. Project OPS-LEGACY was migrated last quarter into a shared permission scheme called "Standard-Agile" that grants Browse Projects to group jira-users and Manage Sprints to project role Administrators. After the swap, the scrum master (member of scrum-masters group, not in the Administrators role) reports the board renders but the Backlog and Sprint controls are missing, and dragging issues between sprints fails silently. Meanwhile 6 other projects on the same scheme are unaffected. The board is a Scrum board whose filter is project = OPS-LEGACY ORDER BY Rank. You confirm the user can view and edit issues. Two weeks later a second symptom appears: the same user can no longer see the board at all, though the filter still returns 120 issues when run in the issue navigator.
1. Diagnose why the sprint controls disappeared for this user while other projects on the same scheme are fine, and state the configuration change you would make.
Read the worked answer
The key is that a board's sprint controls are governed by Manage Sprints permission evaluated in the project(s) the board's filter returns, not by the scheme name or by issue edit rights. The user has Browse and Edit via jira-users, but Manage Sprints is only granted to the Administrators project role. Since the user is not in that role for OPS-LEGACY, the Backlog and Sprint actions are hidden and sprint assignment is rejected - consistent with the silent drag failure.
The reason 6 other projects look fine is that those users are probably in the Administrators role there, or those boards are owned by different people. Same scheme, different role membership per project - the scheme is shared, the role membership is not.
Fix options, in order of preference:
- Add the
scrum-mastersgroup to the Administrators project role for OPS-LEGACY only (Project settings → People). Narrow blast radius, no scheme edit. - If scrum masters should manage sprints everywhere on Standard-Agile, add
scrum-mastersto Manage Sprints in the scheme - but audit all 7 projects first, because this widens privileges broadly.
Do not grant Jira Administrators global permission; that is unrelated to Manage Sprints and over-privileges the user.
2. Explain the later symptom - filter returns 120 issues but the board is invisible - and give the most likely cause plus verification steps.
Read the worked answer
A board that vanishes while its filter still returns issues points to a board-level visibility or filter-ownership problem, not an issue-permission problem. The filter returning 120 issues proves Browse is intact.
Most likely causes, ranked:
- The saved filter was made private (or its owner changed/deactivated). A board inherits the filter's shared-with scope; if the filter is no longer shared with the user, the board cannot resolve and disappears from the board list. Common after an admin edits the filter owner or the owner leaves.
- The board's location/permission - boards can be restricted, and a board created from a filter only shows to users who can see the filter.
- Manage Sprints removal cascading is not a cause of invisibility; it hides controls, not the board.
Verification:
- Open the filter in issue navigator as the affected user and check Details → Shared with. If it says "Private" or excludes
jira-users/scrum-masters, that's it. - Check the filter owner's account is still active.
- As an admin, view the board configuration and confirm the saved filter ID matches the expected filter (not a duplicate).
Remediation: change the filter's shared-with to include the appropriate group or project role, or transfer ownership to an active service account, then re-share. Confirm the board reappears for the user and that sprint controls are still governed by Manage Sprints as fixed earlier - the two symptoms have different root causes and must be fixed separately.