-
Suggestion
-
Resolution: Unresolved
-
None
-
40
-
94
-
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
Hi everyone,
Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; however there are not currently any plans to implement this suggestion.
If issue locking is critical for your environment, there are alternatives;
- JIRA-Issue-Edit-Lock.
- There's also a non-supported plugin which may solve your immediate needs: whoslookin. This add-on is 6.x compatible and we're looking at the effort required to make this 7.x compatible. There is now also a cloud version of this plugin: whoslookin for cloud
Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.
I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.
Regards,
oruettinger@atlassian.com
Principal Product Manager, JIRA
Original description below:
This can be implemented in 2 stages:
1. A simpler approach that detects that an issue has been edited and displays an error message informing the user of this fact. For example, a user clicks edit issue and takes their time to update a few fields. Another user updates the issue in the mean time. When the first user presses "Update" they will be returned to the Edit Issue screen with all the fields populated with values that were submitted by the user. The screen will display an error message informing the user than an issue has changed. The error message will also contain a link that will open a new browser window displaying the issue as it appears currently.
The user will be able to compare the issue using the View Issue screen in the second browser window and the Edit Issue screen. The system will not provide an indication on what fields are "clashing". The Edit Issue screen will contain a confirm button, that when pressed will do the check again, to ensure the issue has not changed since, and if it has not, will update the issue.
Issues will also be checked for updates during Bulk Edit operation. The Bulk Edit operation will not update any issues that have been updated in the mean time and will inform the user about these issues. (The user will then be able to bulk edit those issues if required).
When an issue is being progressed through workflow (e.g Resolved, Closed) a check will also be performed. If the issue has been changed the user will be informed of this fact. If the Workflow Transition that the user is trying to perform is still available the user will be provided with a link that will open the View Issue screen in another browser window. The user will be able to confirm that they would like to proceed. If the workflow operation is no longer available, the user will be asked to return to the View Issue screen.
We estimate the effort required to implement the above functionality to be around 80 man hours (or 2 man weeks).
2. The second approach takes the "issue locking" functionality a bit further and when a clash is detected during the Edit Issue stage, the user is presented with a page that shows the conflicts. The page shows the fields that are "different" in value between the current issue and the values that are being submitted by the user. For each "clashing" field the issue's current field value is shown as well as the submitted value. For each field the user will be able to specify the value that they actually would like to go ahead with and then proceed with the update.
The Bulk Edit will still leave modified issues untouched and will simply report them, just like in the first approach.
Progressing issue through workflow will use the Edit Issue's approach and show a conflict resolution screen if the workflow transition is still available.
- blocks
-
- Closed
- is duplicated by
-
JRASERVER-18569 support collision detection
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- is related to
-
-
- Closed
-
-
- Closed
- relates to
-
- Closed
-
- Closed
-
- Gathering Interest
-
- Gathering Interest
- supersedes
-
-
- Closed
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
This problem still exists in 2025. I am using Jira Server/Data Center.
This issue is also affecting my organization and PS-170637 was entered for this where I was pointed to this Feature request.
However, locking the issues would not address our issue of being able to do concurrent writes to Jira issues by API calls.
If issue locking is an implemented feature, it would likely result in write failures by our pipelines.
What should happen in Jira, just like in most other web applications is users should be able to save the issue they are in and a follow up update (or ADD) should add values (Fix version in our case) rather than overwrite it.
We are interested in this feature also. Recently two people in the team lost significant time and effort as they were adding details to description on a Jira item. It also took a while to figure out what is going on and why the updates look different after submitting.
This is a must-have for instances with many users, resulting in a high probability of overwriting the data on one issue. It could also be done in a way that only fields that have been "touched" by the user are updated
we are very interested in this feature. need it desperately. this causes so many problems.
@Jason Sheneman, I'm curious to know if you're using the Data Center install? We're using on-prem Server and are essentially being forced to more to the cloud, which we're not particularly happy about.
For this reason alone I'll never be able to move to cloud. We use the issue lock app for our on-prem solution.
I know there is a paid plugin for this but I feel something like this should be fixed on your side. I always vote on these but rarely ever see them get fixed unless its their Cloud offering.