One of the most annoying problem in ticket management is when you have to edit many issues at once, usually to finalize some release notes or other reports with correct data.

Once an issue has been marked as closed by QA/Clients Jira won’t let you change it anymore (As it has to be in an well-working scenario!), so usually even the smallest adjustment would go through an issue reopening, performing the adjustment and then close it again (or perform all proper step to close it).

For sure granting all user edit permission on closed issue is NOT a solution 🙂 but digging in discussions and documentation I sort out that jira provides a couple of workaround to grant just restricted group of users.

The quick-and-dirty solution is just to provide an additional Edit transition from the Closed status to itself, with a condition restricting it to the desired group.

Edit Self-Transition

I’ve used this self-transition solution successfully in many scenarios, since it let you choose which Screen you will show to the user, and therefore you can even filter which fields he will be allowed to edit.

Really nice, but not this time!

What this solution is missing, is the most useful feature when you are fixing release notes or similar: Bulk changes.
Being a single issue transition, it will force you to open one-by-one all the tickets you have to modify , click on the Edit button provided by the tranistion and then perform your change.
But from bulk edit perspective, the issue will always be Closed, with no change permission to anyone, preventing the massive change we would like to achieve.

Luckily, Jira provides also another way to filter user permission across workflow status: workflow properties.

Adding properties to workflow status will let you customize the user experience over issues in that state, you can hide/show resolutions, change status names, prevent adding commit and… prevent issue editing.

Non-editable issues in Closed state are enforced exactly by jira system, setting  jira.issue.editable property to false.

Finding an up-to-dated documentation of all properties and their correct usage, mainly with proper group filtering syntax, is not as easy as administrators would like, but their (well hidden) official page is a good starting point: https://confluence.atlassian.com/display/JIRA/Workflow+properties

One of the main point to keep in mind is that using properties you can just restrict user’s permission, not granting them additional ones.
If, as in our scenario, you want to grant edit permission to a single user group, you must FIRST grant edit to everybody, and THEN restrict to your group.

This means you will have to remove the jira.issue.editable=false property set by default on the Closed workflow status,
then grant edit globally re-adding it as   jira.issue.editable=true
and finally adding the additional filter which will restrict editing to own group jira.permission.edit.group=jira-administrators .

Et Voilà, now all users from jira-administrators group will be granted edit permission over all issues in closed state, while all users not belonging to such group will not be able to alter issue status as before.
Being this a global setting ( for all issues undergoing such workflow, obviously) and not a transition, also the bulk edit will work perfectly , as well as dragging issues from one version to the other from the Agile boards.

Now all your issues are secured and your administrator can perform quick (and happy)  fix over any singularity in release notes and reporting.
I hope you will enjoy this trick as much a I did 😉