Restrict changes to issues via an adminstrator approval process

[Tristan Oldfield]

Can JIRA be set up in such a way that changes to issues (by normal users) are required to be approved by an adminstrator, before being committed (and visible) in the database?

That is, I'm looking for a way to restrict editing of issues so that there is some level of review on an issue change, before it is committed/written to the database.

[Tristan Oldfield · Accepted solution]

It's really just to centralise control - I don't necessarily want any old user to be able to change data within an issue without it first being passed through an administrator review.

I guess an ad-hoc way is to add more intermediate status types (e.g., Pending Test, Pending Closure), and then only allow administrators to transition out of those pending states, e.g., admin can only perform a "Pending Test" to "Test" transition. And at those pending points, and admin could tidy-up any undesired changes made to the issue (or even bounce back to a prior state).

[Nic Brough -Adaptavist-]

There's no way to do this, it really goes against the grain of what Jira is for - quick updates of shared information. If you look at the last major change to the UI, it was the complete opposite, because Jira moved from having to open an explicit "edit" screen to users being able to quickly a single field without leaving the "view" screen at all.

To do it, you'd need to implement a whole swathe of intermediate "waiting for approval" data storage places for every issue and field, and that's a nightmare for any system, let alone ones that are supposed to be for keeping people informed.

My instinct is to ask what you want this for - not because there may be some convoluted way to get Jira to do it, but because I can imagine some uses for it that I could recommend other tools for - ones that would be a lot more suitable!

[Peter T]

Not out-of-the-box but you can create a process that mimics that.

Lets say the issue have 4 fields - Name, Description, Size and Due Date.

1. First Edit is not e generic Transition so you don't have good control. Remove everyones Edit permission and create Global Transition with name Edit.
2. Then you need to have another set of invisible fields Name_c, Description_c, Size_c, Due Date_c
3. On create transition for the issue copy the original value of Name, Description, Size and Due date to the "cloned" fields - Name_c, Description_c, Size_c, Due Date_c, you can do that with a script or a post-function
4. On Edit (the new global transition) in the post-function which the values between Name and Name_c for example. So as a result after the post functional - the Name with have the old original value and Name_c will have the new changed value.
5. So now the issue is ready to review and approval. Create a new transition Approve that is restricted to the Administrator only. Create a transition screen that shows both Name and Name_c. On Approval you can do is overwrite Name with Name_c - i.e. the old value is changed to the new value.

I've done this before and it works. The only problem is the level of work you need to do on the Workflows to add all those logic.

[Nic Brough -Adaptavist-]

Hard work to set up, and very complex, but it will do the job.

There is one other minor point to consider - it's not really approval - changes will be commited to the database and will be visible to the users, irrespective of whether a change is approved or not. Not a show-stopper, but you do need to consider it before you go down this route.