Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

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
4,560,358
Community Members
 
Community Events
185
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.

2 comments

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 16, 2020

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
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 16, 2020

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..

Comment

Log in or Sign up to comment