How to avoid issue edit conflicts in JIRA?

[Sameera Shaakunthala [inactive]]

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.

[JamieA]

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

[Sameera Shaakunthala [inactive]]

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.

[Richard Bradley]

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

[TonyA]

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

https://plugins.atlassian.com/plugin/details/458476

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

[Sameera Shaakunthala [inactive]]

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.

[TonyA]

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.

[Sameera Shaakunthala [inactive]]

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.

[TonyA]

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.

[Jerome Bleichenbacher]

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.

[JonasC]

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: https://marketplace.atlassian.com/plugins/net.koncis.atlassian.jira-issue-edit-lock

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.

[Nic Brough -Adaptavist-]

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

[Richard Bradley]

This is a known bug, tracked at https://jira.atlassian.com/browse/JRA-6146

[Markus Lepper]

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

[Sameera Shaakunthala [inactive]]

This sounds good but.... :(

[Nic Brough -Adaptavist-]

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.

[Richard Bradley]

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

[Nic Brough -Adaptavist-]

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

[Richard Bradley]

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"

[Nic Brough -Adaptavist-]

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

[Radu Dumitriu]

well, in the meantime, we created lock/unlock for JIRA: http://confluence.kepler-rominfo.com/pages/viewpage.action?pageId=12190239

[francis]

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

[Nic Brough -Adaptavist-]

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

[francis]

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

[Nic Brough -Adaptavist-]

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.

[francis]

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

[Radu Dumitriu]

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

[Radu Dumitriu]

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: https://confluence.kepler-rominfo.com/display/TR/Locking+Issues https://confluence.kepler-rominfo.com/pages/viewpage.action?pageId=12190239

[Richard Bradley]

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.

[Radu Dumitriu]

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

[Richard Bradley]

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

[Radu Dumitriu]

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

[JamieA]

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

[Radu Dumitriu]

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