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 Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published yesterday in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

203 views 4 8
Read article

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