restricting who can lower priority and postpone fixversion

the goal is that a developer can change the priority to be higher than it is, or move the ticket to be worked on SOONER - but can't lower priority of ticket, or push the fixversion off.
So breaking that down into the 2 parts:
1)
I am trying to restrict who can lower the priority of a ticket.
a) Any good suggestions how to do that?
Right now it is not enforced from workflow, and I just have a subscribed query that runs to see if any of the forbidden people did a change:


--priority changed by (list of users) from (Medium) to (minor) after -1d OR priority changed by (list of users) from (High) to (Medium, minor) after -1d OR priority changed by (list of users) from (Major) to (High, Medium, minor) after -1d OR priority changed by (list of users) from (Blocker) to (Major, High, Medium, minor) after -1d
2)
second thing is changing fixversion to a later fixversion.
I wish to restrict that as well to a group of permitted people.

any way to do that in the workflow?
I have seen the horrible hack of making different transition screens of workflow based on permissions, but that looks HORRIBLE to set up.

the global permission of resolve (that includes fixversion) is too broad to restrict usage of it.

--


Thanks.

4 answers

1 accepted

This widget could not be displayed.

We've made some similar solution by using of the specific custom fields. The idea is - remove the fix version / priority from edit screen, add custom fix version and custom priority on the edit screen, implement the view that will show only items that user can set, on field update put a method that will change the target field (fix version / priority).

SOrry, but this doesn't anser my question as This doesn't allow developers to increase the priority or move up the fixversion, this solution just allows them not to be able to touch the field.

This widget could not be displayed.

Does anyone know a way to use a negative in "changed" ?

such as

fixversion changed not by (adminA, adminB);

or

fixversion changed to not (earliestUnreleasedVersion())

as the list of users who are NOT allowed to do something is dynamic vs the list of users who are allowed.

Thanks.

This widget could not be displayed.
Joe Pitt Community Champion Aug 24, 2014

You're probably going to have to modify the source to restrict the options when editing the fields. This sounds like a training issue that can be solved by giving one or two people a couple days off without pay for violating the rule.

This widget could not be displayed.
Joe Pitt Community Champion Aug 24, 2014

All JIRA permissions are based on allowing user to do something. By default users can't do anything. If you aren't on OnDemand, you may be able to code a listener.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Aug 06, 2018 in Jira Service Desk

A is for Activate: Share your top Jira Service Desk onboarding tips for new users!

Hi, everyone! Molly here from the Jira Service Desk Product Marketing Team :).  In the spirit of this month's  august-challenge, we're sourcing stories of Jira Service Desk activation fro...

553 views 25 15
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you