-
Suggestion
-
Resolution: Unresolved
-
74
-
99
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? 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.
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.
Notes
The unsupported Cloud app Who's Looking for Jira Cloud may be of interest to watchers of this issue.
- blocks
-
- Closed
- is duplicated by
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Gathering Interest
-
- Gathering Interest
-
- Gathering Interest
- relates to
-
- Closed
-
- Closed
-
- Closed
-
- Gathering Interest
-
PCS-16475 Loading...
- mentioned in
-
-
-
-
-
-
-
[JRACLOUD-6146] Implement issue locking
This problem still exists in 2025. I am using Jira Server/Data Center.
Just absurd. Priority 1 - blocker. Very simply adding a version to the records and checking it on save and denying overwrite is trivial and invaluable.
> We have reviewed this issue over the last few days; however there are not currently any plans to implement this suggestion. [2015]
Frankly I don't know how you can call this a collaborative enterprise cloud service while simply losing content, and I can't imagine how you can sleep at night after writing the above comment on a Jira [hopefully oruettinger has since been released] with so many linked items related so very clearly as the same fundamental, incontrovertible, ludicrous, concern.
Pitiful.
Our teams also run into this problem and overwrite each other's changes, which leads to confusion. It should be an absolutely fundamental feature.
From my point of view, it's a bug and not a suggestion for improvement.
I can't understand how an important issue like this can be unresolved since 2005.
I am so so disappointed that the basic concept of collaborative editing is an utter failure in Cloud Jira. We used to run into this in on-prem Jira and I really thought Cloud Jira was supposed to be 'smarter' with it. We have shared results grids (table) within our Regression Test Plans that results in multiple teams needing to edit the table at the same time, though they ARE working in different blocks within the table. Do we really need to go back to the Stone Ages where we post an update in Slack stating "I'm about to Edit the Test Plan, I'll post when I'm done. Please don't edit while I'm in there."
This functionality oversight has caused SO MUCH re-work by testers when results are overwritten time and time again. I'm so tired of seeing frustrated team members post that "someone overwrote their update again and they now have to mark their scenarios as passing again."
If you hadn't taken away the ability to input plain text into the ID Description we could at least get the old version that was overwritten from the History tab. If we had that ability still, that would help somewhat.
If this is being resolved in some other ID I haven't found yet please share it.
I understand that an implementation that addresses all possible issues of attempting to not lose data when two updates are made at the same time to the same issue is challenging. Would a simple improvement be to just have a notification when you attempt to edit any field that it shows any other users who are also currently attempting to edit that field (or have an unpublished change to the field)? This doesn't require adding full concurrent editing, just the ability to know that you run the risk of stomping on someone elses changes (or they might stomp your changes) if you continue?
Please include this in your next version. This is causing unnecessary rework on our side.
Allow collaborative editing on description of a defect. It helps both devs and QAs to type into same defect at a time, with some notification and indicators.
There should either be locking or at least a pop up saying someone else is editing already and the person editing should get a pop up that someone else is attempting to edit.
Added an upvote and a comment. Please make this a priority for one of the sprints. Data loss should be treated as an issue that needs urgent attention.