How to avoid issue edit conflicts in JIRA?

In JIRA, consider the following hypothetical scenario in which two users edit the same issue at the same time.

There are two users called A & B, and there's an issue ticket. Here it goes,

  1. A views the issue.
  2. B Views the issue.
  3. A clicks the Edit button.
  4. B clicks the Edit button.
  5. A enters his estimation. (1d)
  6. B enters his estimation. (2d)
  7. A clicks the Update button.
  8. B clicks the Update button.

In last step of the above activity, B will actually be editing an old 'revision' of the issue. Once B click Update, the values entered by A will be overwritten without any confirmation.

(Even though all the edits are recorded in the History section, for issues that go through complex workflows it can be a headache to look at history all the time)

My question is, is there a way to trigger an 'edit lock' once A click the Update button (7th step). So when B clicks on the Update button, he should be given a warning.

14 answers

Locking is a little difficult because a user can just close the browser and walk away, the server does not receive an event for this.

But what could easily happen is that it could warn you when you commit that you are committing an out of date version.

Confluence has both features, it tells you that you are out of date, it also tells you that someone else is editing (by having the browser send a heartbeat message every minute or so).

Thanks for your reply! I understand that a perfect lock is not possible to implement. I also meant the warning message. Better if JIRA had the same.

"a user can just close the browser and walk away" -- this only affects explicit pessimistic locks. Optimistic locking (like that used by Confluence) don't care if you close the browser.

There is a new plugin that will at least make users aware that another person is viewing the issue:

It's still being released, but will be available at that link in a day or two.

Hi Tony,

Thanks for the reply. Is it going to be supported in JIRA 4.3.2 ? Since we are presently in the middle of a project started with version 4.3.x, I don't think we'll be feasible enough to move to 4.4 at this time.

We've been testing the plugin on JIRA 4.3.1, so I would assume so. The plugin compatibility will be included on the home page once the link goes live.

Whoslookin seems to be a great plugin; but I couldn't manage to get it work. I installed the plugin and restarted JIRA. Is there any other required configuration?

For testing, I'm using the multifox addon. I don't see such warning messages shown in the screenshots. I'm using v4.3.3#617-r149616


I'm encountering with problems writimg my review on the plugin's page. It says 'vote cannot be null' even though I have voted.

I believe you need to configure the plugin and let it know which groups are allowed to use the plugin (so that, for example, you can limit tracking to your developers and not your end users). There should be a configuration option in the administrative panel.

1 vote

No, there is no locking.

It's difficult to implement in a web-application because of the way the web works. A user's browser would need to be polling the server constantly to know if "someone else opens the item", or you need to design for user locks, which are nightmare and quickly annoy users. Locking works in systems where edits are likely to be large or there's few users, but issue trackers tend to need quick updates, and locking gets in the way of the humans trying to do it.

For what it's worth though, I've been a Jira admin for 6 years. I can only remember 4 cases where this happened and no-one complained once it had been explained to them.

"It's difficult to implement in a web-application because of the way the web works." -- That's not true. Most webapps use "optimistic locking" to deal with this case. There is no need for polling or anything of the sort.

That's not true - optimistic locking doesn't solve the problem here, as you have to discard someone's changes

It does solve the problem: you tell the user what happened, and show them both their changes and the conflicting changes and ask them to resolve the two. It's the only practical solution in a web app because, as you say, "[explicit pessimistic] user locks are nightmare and quickly annoy users"

But you still lose the changes, so it doesn't work.

I was asked this already 2 times...but I'm Jira admin only for 2 years ;-)

As all changes are recorded in history no big deal.

Of course I checked the plugin-exchange...but the only plugin providing functionality in this direction is the "Jira Visitor plugin" (only for ancient version 3.12.x).

... and if both Nic and Jamie don't know any solution then there's none. :)

BR, Markus

This sounds good but.... :(

Hi there,

here's my attempt at solving this problem.

I have developed a plugin called JIRA Issue Lock. You can find the Marketplace page here:

Users with edit-rights can lock down an issue for edit when viewing an issue, and while that happens, no other user can edit the issue. The user releases the edit-rights when he browses eg. to another issue/page (timeout is default 30 seconds but can be configurated. This means he has 30 seconds to jump back to the issue to avoid loosing the lock).

The plugin is configurated on a per-project basis, and configuration also includes "Admins-override lock" and "auto acquire lock when viewing issue".

JIRA versions supported are 6.2.X-6.4.X and 7.0.0-7.0.3, and it should work all over in the Service-desk and Agile parts.

If you have any ideas for improving the product or use an earlier version of JIRA, just let me know, and I'll see what I can do.

That's a nice idea, a short timeout lock. I'll have to try this when I get a chance.

However, you can simulate it by using security levels (but this may prove impractical). The idea: create a security level for each user (impractical, but can be scripted); add a "locked" state for each existing state in which you assign to the issue the personal security level.

Crazy as it sounds, it may work :) but benefits are not so great vs the work needed to employ it ...

Ah, ah. The only answer that has a solution attached to it is voted negatively. Like in the Greek vote of OXI, this shows the limits of democracy:

The solution to concurrent editing conflicts is not to ban working collaboratively. Also, this is not the correct forum for you to opine on what the Greeks should do about their financial problems.

I'm not talking about Greeks financial problems, I'm talking about limits of democracy. I'm sure you can understand the difference.

Very well; this is not the correct forum for you to explain why democracy needs to be "limited".

I give up. English may not be my native language, so I don't understand the twists here. Anyway, Matthew 6-7. You won.

6-7? Don't tell me Matthew lost on the tie-break again.

:) Or it was 7-6? A cultured atheist like me is allowed to mix these things up from time-to-time. Too lazy to google it. However, I should refrain speaking, it's not the correct forum.

Bumped into this one today - customer was very concerned about data loss.

0 votes

The only data loss is when a user puts some data in and another user has put the issue into a state where the new update is not valid, in which case the user is given a "cannot update issue" type error message immediately.

Nope, Assume issue has following values * Summary = The quick brown fox * Description = lorem ipsum User A clicks on edit and changes description in XYZ User B clicks on edit and changes summary in ABC User A saves entry User B saves entry The outcome is * Summary = ABC * Description = Lorem Ipsum The history contains * User A @ time 1: Description Lorem Ipsum -> XYZ * User B @ time 1: Summary: The quick brown fox -> ABC Description: XYZ -> Lorem Ipsum This is what I encountered today using JIRA 6.1.7 Francis

0 votes

Yes, there's no data loss in that case.

I know - but for the customer there is as the history indicates that the description has not the expected value.

We face this problem the frist time after only 1 month in a live-environment. 


We dont have the need for an extra lock-addin (its a shame when you have to pay for every little extra-feature-addin), but it would be nice if Jira informs you, that the issue you're updating has changed since you opened it. Like this:

- User A opens an issue (Jira-session remembers the loading timestamp and user)

- User B opens an issue (Jira-session remembers the loading timestamp and user)

- User A updates the description and saves the changes

- Jira updates the last-change-timestamp on the issue

- User B updates the description and tries to save the changes

- Jira compares the loading-timestamp versus the last-change-timestamp

--> oups, User A had made a change after you opened the issue, you'll probabely lose some information --> Check History


With this approach you'll inform the user at least that he is not saving the latest version of the issue.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 13, 2019 in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

600 views 0 12
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you