How to avoid issue edit conflicts in JIRA?

Sameera Shaakunthala [inactive]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 3, 2011

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

3 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 3, 2011

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]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 4, 2011

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 July 9, 2015

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

2 votes
TonyA August 4, 2011

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]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 4, 2011

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 August 4, 2011

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]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 16, 2011

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 September 1, 2011

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
Jerome Bleichenbacher November 30, 2017

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.

1 vote
JonasC December 3, 2015

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 3, 2015

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

1 vote
Richard Bradley July 9, 2015

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

1 vote
Markus Lepper
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 4, 2011

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]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 4, 2011

This sounds good but.... :(

1 vote
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.
August 3, 2011

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 July 9, 2015

"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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 9, 2015

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

Richard Bradley July 9, 2015

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 3, 2015

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

0 votes
Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 11, 2014

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

0 votes
francis
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
November 10, 2014

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

0 votes
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.
November 10, 2014

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

0 votes
francis
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
November 10, 2014

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
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.
November 9, 2014

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.

0 votes
francis
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
November 9, 2014

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

0 votes
Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 3, 2011

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 9, 2015

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 July 9, 2015

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 9, 2015

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 July 9, 2015

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

Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 9, 2015

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 9, 2015

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

Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 9, 2015

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

Suggest an answer

Log in or Sign up to answer