restricting who can lower priority and postpone fixversion

[David Elman]

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.

[Alexey_Rjeutski__Polontech_ · Accepted solution]

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).

[David Elman]

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.

[Joe Pitt]

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.

[Joe Pitt]

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.

[David Elman]

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.