Making an issue read-only
Required apps
Level: INTERMEDIATE
Problem
Sometimes, it happens that more than one user edit one issue in the same time. To prevent this, you can make the issue read-only when someone is editing it.
 Let me show how to do this with Live Fields from our Power Scripts™ for Jira app and with Power Actions™ for Jira app.
Solution
 The idea is that when someone clicks the Edit button to edit an issue, a "lock" is put on the issue and nobody else can edit the issue until the user who locked the issue unlocks it.
Important
Before we start, please have a look at Live Fields Configuration.
Creating hidden custom field
First step is creating the custom field that keeps the user who locked the issue.
Go to Administration -> Custom Fields and add a new Custom Field of type User Picker.
You can make it hidden by not choosing any Screen for it, or using the lfHide function from Live Fields.
We choose to use lfHide function.
So, this is our custom field, userPicker with id = 13522.
Creating the unlock button
For the unlock button you have to create a Power Actionsâ„¢ Custom Field, we named it Unlock Issue, with one action: Unlock.
In the Edit Screen Script you only have to release the lock, that means that you have to set the custom field from the first step with an empty value.
customfield_13522 = ""; return;
This means that when the button is clicked, the user who had the lock on the issue, releases it.
Info
See more information about creating Power Actionsâ„¢.
Writing initial script
Initial script is executed when the issue page is loaded. Here we verify if someone is editing the issue. We know that when our custom field, created at first step, is not empty, that means that someone is editing the issue.
The fields are disabled from those users who haven't the lock for the issue and only the person who locked the issue can edit it.
Here we disabled the most important standard fields from Jira, but you can add a lot more fields or custom fields.
Info
For more information about how to disable fields, see Live Fields.
Also we have created hooks for the editable standard fields. When an user is editing an issue, the lock is put on the issue and nobody else can edit it, before that user explicitly releases the lock, by clicking the Unlock button. The issue will be locked until the user releases it.
The Unlock button will be visible only for the user who locked the issue.
lfHide("customfield_13522"); if (length(customfield_13522) != 0) { if (customfield_13522 != currentUser()) { lfDisable("issueType"); lfDisable("priority"); lfDisable("affectedVersions"); lfDisable("status"); lfDisable("resolution"); lfDisable("summary"); lfDisable("fixVersions"); lfDisable("assignee"); lfDisable("reporter"); lfDisable("created"); lfDisable("updated"); lfDisable("labels"); lfDisable("editSubmit"); lfDisable("transitionSubmit"); lfExecuteJS("ScriptHide.js"); } else { lfExecuteJS("ScriptShow.js"); } } else { lfExecuteJS("ScriptHide.js"); } lfWatch("edit-issue", {}, "disable.sil" , {"click"}); lfWatch("issueType", {}, "disable.sil",{"click"}); lfWatch("priority", {}, "disable.sil",{"click"}); lfWatch("affectedVersions", {}, "disable.sil",{"click"}); lfWatch("resolution", {}, "disable.sil", {"click"}); lfWatch("summary", {}, "disable.sil", {"click"}); lfWatch("fixVersions", {}, "disable.sil",{"click"}); lfWatch("assignee", {}, "disable.sil",{"click"}); lfWatch("reporter", {}, "disable.sil",{"click"}); lfWatch("labels", {}, "disable.sil",{"click"});
Info
For more information about hooks see How Live Fields work.
Writing script for disabling fields
Here we verify if someone has the lock, and if not, we give the current user the possibility to be the only one who is editing the issue.
If someone else tries to edit the issue, a dialog message will be displayed.
if (length(customfield_13522) == 0) { customfield_13522 = currentUser(); lfExecuteJS("ScriptShow.js"); } else if (customfield_13522 != currentUser()) { lfDialogMessage(customfield_13522 + " is editing this issue.", "WARNING"); lfDisable("issueType"); lfDisable("priority"); lfDisable("affectedVersions"); lfDisable("status"); lfDisable("resolution"); lfDisable("summary"); lfDisable("fixVersions"); lfDisable("assignee"); lfDisable("reporter"); lfDisable("created"); lfDisable("updated"); lfDisable("labels"); lfDisable("editSubmit"); lfDisable("transitionSubmit"); }
Manage Unlock button
To make Unlock button visible only for the user who locked the issue, you need to create two javascript fields, and execute them with lfExecuteJS as we can see in the previous scripts.
So, first create the ScriptShow.js file and write the following code:
AJS.$('#rowForcustomfield_14500').show();
Where 14500 is the ID for Power Actionsâ„¢ custom field.
Now, you have to create the ScriptHide.js file, with the following code.
AJS.$('#rowForcustomfield_14500').hide();
Testing it
First, we login with admin and try to edit an issue.
This means that we have the lock on the issue, and other users can't edit the issue. When we edit the issue, by clicking the Edit button or by inline editing, the Unlock button will be displayed on the screen.
So, let's see what user alina can do on that issue.
Well, not much. She can only view the issue, but can't edit it. When she tries to edit it (click on Edit button) the next message will be displayed.
Only after admin Unlocks the issue, other user can also update it.
Hope this is useful!
See also
- Disabling inline edits in Jira
- Forbidding users to create some issue types
- Hide fields from users not in a project role
- Limit Number of Characters in Text Field
- Lock an issue - a better variant (Live Fields)
- Locking Issues
- Require an issue to have attachments
- Require User to Log Work Before Transitioning Issue
- Restrict issue type availability by user
- Restrict workflow based on status of dependencies
- Validator for component lead