Allow only a certain group to change issues in certain statuses

Gisela Lassahn

Hello all together,

we're on Jira Software Data Center 9.4.8 (and will shortly introduce Scriptrunner for Jira).

Our challenge is this:
In some projects we want to prevent changes on issues which have certain statuses.
Only one group shall be able to change these issues.

Now I've got a solution that doesn't please us because it is a little dangerous and very maintenance-intensive.

We use the following status properties to prevent the users outside our group to change the issues:

jira.permission.assign.group
jira.permission.attach.group
jira.permission.comment.group
jira.permission.delete.group
jira.permission.edit.group
jira.permission.link.group
jira.permission.move.group
jira.permission.resolve.group
jira.permission.setsecurity.group
jira.permission.transition.group
jira.permission.work.group

Atlassian explicitely doesn't recommend our method, see
https://confluence.atlassian.com/adminjiraserver0904/workflow-properties-1188768420.html#

And we've found out that users still can do some things with the issues:
* Vote / Remove vote => not really critial
* Change Watchers => may be critical because users might no longer get emails
* Delete Attachments => VERY CRITICAL! because the attachments are gone for good and not reproducable
* Edit existing comments or delete them => VERY CRITICAL! because the comments can contain relevant informations and after deletion/edit they (or their older versions) are also gone for good

In addition, we have many different workflows and statuses and must maintain the status properties for all these workflows and statuses.

So we would prefer another, recommandable way to prevent the issues from any changes (with the exception of those made by our group).

Do you have any idea how to do it better, without buying another AddOn again?

 

Radek Dostál

Kind of specific, can't say I would have used more than maybe 10 basic ones in workflows (it is generally pain in the neck to be around when there is a problem..)

 

The page you linked however also says:

"With permissions, the following values can be used:"

admin, use, sysadmin,
project, browse, create,
edit, scheduleissue, assign, assignable, attach, resolve,
close, comment, delete, work, worklogdeleteall, worklogdeleteown,
worklogeditall,
worklogeditown, link,
sharefilters,
groupsubscriptions, move, setsecurity, pickusers, 
viewversioncontrol,
modifyreporter, viewvotersandwatchers, managewatcherlist,
bulkchange, commenteditall, commenteditown,
commentdeleteall, 
commentdeleteown,
attachdeleteall, attachdeleteown, 
viewworkflowreadonly

 

Have you tried if they work? E.g. 'jira.permission.managewatcherlist.group'

On paper what you describe is all there.

 

Overall though, I don't know of anything else to do this based on the status, I only know of workflow properties, and yes they should be avoided whenever possible, it only complicates things and makes them harder to troubleshoot for those uninitiated. Not exactly the first thing you would learn when becoming a jira admin.

My thinking is this:

• Jira workflow properties are clearly baked into Jira
• Jira can use them before it spits out the page to you, it already filtered out what permissions you have before you get to use the page
• All of this happens inside Jira, you cannot really change that

If a plugin did attempt to change that, it would need to rely on javascript, after the issue was already loaded in the browser. It then would need to do some evaluations and finally modify the page by removing things from the page you don't have access to.

There might be some atlassian ajax functions and whatnot, but it sounds really difficult and unreliable to make work. So I just simply think there really isn't anything like this on issue level.

Field levels sure, that is much easier to do, but not the whole issue, not to say it's not possible, but it sounds like an absolute nightmare.

That said, I could also be entirely wrong and maybe Jira has some kind of a mechanism to tinker with, just that I have never come across it, and I really doubt it.

 

I'll wrap my rant around, try out those permissions, they have them listed, but maybe you haven't spotted them on the page as it's somewhat tucked under an expand?