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 · Accepted solution]

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?

[Gisela Lassahn]

Hi Radek,

many thanks! :-)

In fact, some options didn't appear correctly under the expand where the permissions are listed. After maximizing the browser window, I could see them all.

I added managewatcherlist, commenteditall, commenteditown, commentdeleteall, 
commentdeleteown, attachdeleteall and attachdeleteown to the earlier mentioned list. 

These options also do what they say.

Now users can still do:

• "Vote for this issue" / "Remove vote for this issue"
• "Start watching this issue" / "Stop watching this issue"
• Create Sub-tasks
• Rank issue

Of course I know that my way isn't recommandable, but I don't know an alternative way without using new AddOns.

[Nic Brough -Adaptavist-]

I know Atlassian don't recommend using properties, but I have never found any problem with them, beyond

• an admin not understanding how they work so using them wrong and getting the wrong behaviour (to be clear, I have to look it up every time as well, I really can't blame anyone who gets it wrong!)
• an admin not warning the rest of the admins that they have used them.  It's the first place I look when someone says "this issue isn't consistent with the permissions".   In a couple of places I even named the workflows like "Bug workflow by Nic - remember to check the properties"

It has been a long time since I tried to block sub-task creation, but you used to be able to do it by blocking the "create issue" permission with a property.  So when you are looking at an issue, the "create sub-task" vanishes from the tools menu, but in some versions, so does the "create" button in the menu (and the + button in the sub-task panel gave us an error).

Ranking can be partially disabled by removing the "schedule issues" permission, but all that does is stop you ranking that issue.  You can still rank the others around it - it just looks like the ranking process is failing if you pick the "wrong" issue.