Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Concurrent Updates to Jira Ticket clobber each other

We had a situation yesterday where two engineers picked up the same ticket within a minute of each other and assigned it to themselves. The second users changes clobbered the first without any type of warning, so they both worked on the ticket for the whole day, and as a result we had a full days loss of engineer productivity. Jira should either disallow stale updates (i.e. if the ticket state has changed since the user started editing it, do not accept the update), or provide some way for the user to manually merge the changes.


Not quite clobbered.  The first person to save changes would have saved what they had updated.  The second person's changes will indeed override anything different, but it will all be tracked in the history.

(I'd also question why people are "working on it for an entire day" - issue tracking is something you dip into, not use as a massive great documentation system)

I don't mean they were working on the ticket update the entire day; the field was the "assignee" field, so they were both working on the same story for the day.

So it is overridden, except that it is tracked in the history, is that right?

Like Nico Schlumprecht likes this

Yes, that's right.

Some people have tried to build "locking" into their flow (Atlassian have no plans to do anything about this, as when they've analysed large systems to see how often it happens, it's surprisingly rare), but there are a couple of easier tricks. 

One I've done is to disallow assignee changes directly, but put in a "I'll get this" transition into the workflow (from "to do" to "in development") which automatically assigns the issue to the user doing it, and then having a workflow property on the "in development" status that says "only assignee can edit or reassign the issue".  This means the second person to get to the issue can't clobber anything.

Gotcha, thanks. We were thinking of adding a rule that doesn't allow reassignment, only allows unassignment and assignment..


Log in or Sign up to comment