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

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.

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.

0 vote
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.

0 vote
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 Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,300 views 14 20
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot