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

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage
Highlighted

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

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

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you