I would like to prevent users from changing the Rank for a specific issue type.
Is there a recommended way to effectively “lock” the Rank field for just one issue type, while keeping normal ranking for others? And not impacting other editing permissions?
Use case is creating a list for the entire business that's in prioritized order and locking it so no one but X group can update rank.
Hi @Sara Beyer ,
You can only do this if you have a separate space where you have the not-rankable-items. There you can only give X group the 'Schedule Issues' permission. This prevent others to change the rank of these items.
@Sebastian Krzewiński is right that there is no per-issue-type switch, and the reason is worth knowing because it tells you where the lock can go: Rank is not a field with its own permission, it rides on the Schedule Issues permission (together with Edit Issues) in the project's permission scheme. Atlassian's own KB for "unable to rank" points straight at that permission (unable to rank issues due to permission), and the request to split ranking out into its own permission is JSWCLOUD-6887, still open. Permission schemes are per project, not per work type, so the granularity you want does not exist inside one project.
Two designs that get you the outcome:
1. Give the prioritised list its own project. Put the business-wide prioritised items in a dedicated project with its own permission scheme where Schedule Issues is granted only to group X. Everyone else keeps Edit Issues (they can update fields and comment) but cannot drag or set Rank there, while ranking in every other project stays exactly as it is. If the items must appear on the same board as everyone else's work, a board filter across both projects still shows them together; the rank lock comes from the project the items live in, not from the board. This is the clean version and it is the one I would build.
2. Same project, lock Schedule Issues for everyone but X. If moving the work type out is not acceptable, the trade is that nobody outside X can rank any work type in that project, and, because Schedule Issues also governs the Due date field, they lose the ability to set due dates too. That is usually the deal-breaker, which is why design 1 exists.
One detail that bites in practice: on Scrum boards, Edit Issues alone has been reported as enough to reorder the backlog, while Kanban boards require Schedule Issues as well. If your list lives on a Scrum backlog, test design 1 on a Kanban board before promising the business it is locked. Vote on JSWCLOUD-6887 either way; a Champion's use case on that ticket is the kind that moves it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Sara Beyer
Unfortunately it is not possible to block rank for some specific conditions.
Regards,
Seba
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.