JIRA Documenting Multiple Users - Overwritten

[Kyle Cabral]

Issue is when information is edited in JIRA and two people may be working on two separate sub tasks but both edit something on the main issue, there is no notification or lock.  Example scenario below.

Scenario

1) User A works on coding subtask 1 and edits a section that is only on the main issue (ie Developer Notes)

2) User B works on a testing subtask and while user A is editing the Developer Notes user B also edits the Developer Notes

3) User A files their edits

4) User B files their edits

5) Everything user A did is overwritten with what user B did and there is nothing to alert user B that user A was working on the issue

[rmaclennan]

Nic,

I appreciate what you are saying and subtasks are handled seperately but that is not the use case being referring to. This would be if multiple users edited the same section of something that is only on the main issue. Yes user A's edits are in history but text only. Any images are completely gone. User B wipes out user A edits as you mention so then user A (or B) must go back in and edit users B entry to merge the two together, again all images are not in history.

A workflow change could prob be implemented where you assign the main issue to yourself when you edit it and then assign it back when done but some kind of warning that you are editing it at the same time as someone else would be useful. I don't think a lock is even needed just something to notify the user it is being edited by someone else. Even changing the color of the text on the tab or something is sufficient.

[Nic Brough -Adaptavist-]

That was what you described in your question, you talked about sub-tasks, which are separate. I'm not sure what version you are using, but I don't lose the edits in 6.4, the history keeps them. Not displayed well, granted, but they're there. The problem with a form of visible notification rather than a lock is that it doesn't work. I open a JIRA issue, type something, then go and make coffee. I've started on a change, but it's stateless - you don't know what I'm doing, whether I'm going to commit it or not. My answer still stands - look at why A and B are making huge conflicting edits and fix that instead.

[Nic Brough -Adaptavist-]

Nope, that's not how it works.

First of all, the sub-tasks are separate issues.  They are linked to their parent, but don't affect it, so having two users work in two totally separate places means, well, that their edits are separate.

Second, points 3-5.  In point 3, User A files their edits, and that is saved on the issue.  In point 4, User B files their changes which update the issue.  Yes, they destroy User A's edits, but User A's changes were made, and they are in the issue history.  This only becomes a real problem when User B tries to do something User A's changes prevent.

There are a number of questions (and a feature request) for some form of issue locking, but Atlassian aren't going to implement it because the sort of usage that leads you into this state a lot is usually an indicator of a broken process, or a poor setup.  Look at why A and B are making huge conflicting edits and fix that instead.  Although, if you insist on locking, then you can do it in workflow - a user clicks a transition to edit and that stops anyone but them being able to edit until they unlock it again.  Pain to set up, and your other users will usually start screaming because they can't edit stuff (and you've made a rod for your own back when people move or leave)