Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-6146

Implement issue locking

XMLWordPrintable

    • 22
    • 52
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      Atlassian Status as of 21 Dec 2015

      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.

        1. MidAirCollisionField.java
          3 kB
        2. edit.vm
          0.1 kB
        3. MidAirCollisionField.java
          3 kB
        4. edit.vm
          0.1 kB
        5. issue-edited-in-parallel-1.png
          issue-edited-in-parallel-1.png
          29 kB
        6. issue-edited-in-parallel-2.png
          issue-edited-in-parallel-2.png
          28 kB
        7. issue-edited-in-parallel-3.png
          issue-edited-in-parallel-3.png
          17 kB

              Unassigned Unassigned
              anton@atlassian.com AntonA
              Votes:
              495 Vote for this issue
              Watchers:
              320 Start watching this issue

                Created:
                Updated: