-
Suggestion
-
Resolution: Unresolved
-
None
-
22
-
52
-
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
-
JRASERVER-1917 Control Concurrency for Update Functions in JIRA
- Closed
- is duplicated by
-
JRASERVER-18569 support collision detection
- Closed
-
JRASERVER-44140 JIRA should not allow users to overwrite information added or changed after the Edit Screen was opened.
- Closed
-
JRASERVER-59122 Workflow Transition Missing after 2 Users Move the same Issue at same Time
- Closed
-
JRASERVER-1917 Control Concurrency for Update Functions in JIRA
- Closed
-
JRASERVER-15790 Jira should not allow more than one user to edit an issue report at any given time
- Closed
-
JRASERVER-16679 Multiple users updating issue warning (Race Condition)
- Closed
-
JSDSERVER-782 need for Issue locking, now more than ever
- Closed
- is related to
-
JRASERVER-15498 Move issue throws exception if issue was moved concurrently
- Closed
-
JRASERVER-37142 Notify user when editing a story will overwrite another user's changes
- Closed
- relates to
-
JRASERVER-1917 Control Concurrency for Update Functions in JIRA
- Closed
-
JRASERVER-44229 Lock Issue Types From Being Edited
- Closed
-
JRACLOUD-6146 Implement issue locking
- Gathering Interest
-
JSWSERVER-21234 Concurrent editing and merging changes in Jira
- Gathering Interest
- supersedes
-
JRASERVER-19218 Moving issues: WARN [web.action.issue.MoveIssueConfirm] Could not move the attachment <name> because it does not exist at the expected location
- Closed
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...