How to avoid accidental reverts due to simultaneous edits?

[Stig Brautaset]

I created an issue today that contained a list of simple actions that people needed to confirm they had performed. I asked them to just tick off their name in a list when they performed these, because I did not want to trawl the comments and manually update the ticket myself. (Partly because I expected a lot of tiny updates, and JIRA hides comments so you cannot quickly scan down---it becomes a multi-click job). Also, this was stuff that should be done in parallel, so assigning the issue to each person in turn would be desperately inefficient.

I was surprised and dismayed when it turns out that JIRA handled this scenario really, really poorly. Everyone kept overwriting eachothers' changes, because JIRA does not appear to have any form of optimistic locking or conflict detection.

Since JIRA lets people edit eachothers' comments (or maybe that's just me, since I'm an admin?) I thought about making each list item a separate comment, but it would both be laboreous, and annoying since some of the comments would be hidden. And it certainly is not an intuitive way to work with JIRA!

Can we hope for some form of conflict detection in the future, or do you have any suggestions for how to deal with this issue?

[Nicolas Bourdages]

You bring up a fair point. JIRA is definitely not well suited for simultaneous editing of the same issue. You need to be changing values that do not require entering an Edit mode.

Comments are one of them. But I can think of others:

• Votes
• ToDo Custom fields (comes from a free plugin of the same name)

Confluence is a bit better for that, as you "assign" quick tasks for users, for which they'll receive a notification and which they can tick off when they're done.

As to your other question, will they implement conflict handling natively in JIRA? The answer is: That's unlikely. https://jira.atlassian.com/browse/JRA-6146

They list alternatives. The whos looking plugin would help you I think, and it's free.

[Nic Brough -Adaptavist-]

Atlassian haven't done this because there's very few people asking for it.  It causes the odd problem now and then, but the answer to most of the times this gets raised as a "significant problem" usually comes down to the system being used for something it is not really for.  It is an issue tracker - with these, you expect updates to come as a stream of consecutive updates (mostly comments, hopefully status changes as it progresses and the odd edit when there's information to be added to fields).  It's not really intended for the purpose you've used it for here.

Now, that said, I'd like to see better concurrency, especially as Agile and DevOps methodologies are leading to faster smaller updates.  But I don't know if it's a priority for Atlassian - the last time I looked at the improvement request, it was pretty much languishing low on the list, with a relatively low number of votes.

I'm not actually sure you can really use JIRA for this type of thing - a quick check that someone has done something isn't really do-able if there's going to be edit locks.  The closest I can get would be some form of automatic creation and assignment of sub-tasks (one per person who needs to tick a box), but that feels like it is overkill in a lot of ways.

(Oh, and the "edit comments" thing - have a look at the project permissions - you'll find it lists who can edit all comments and their own comment)

[Ignacio Pulgar]

As a workaround, you can attach one lightweight icon image file per each task that needs to be done, with a descriptive filename and image for the task.

That way, users would typically have a local folder with the icons of the tasks they are supposed to do frequently, and they would just need to drag and drop the corresponding icon of the task that they have just done.

It's just an idea, and have not tested it myself, but I don't think this would be overwritten.