how to prevent concurrent update on same jira ticket?

[Eva]

At first I thought JIRA somehow soft lock teh ticket when someone's editing, but I just test this with another coworker of mine and it seems like we can overlap each other changes one way or another. Is there a way to prevent this fromp happening?

[Renjith Pillai]

Not sure whether Jira supports this, I guess no. But I have a workaround.

1. Create a custom field to store the username of the person who is currently editing (EditUser)
2. Have two additional transistions in each states 'Start Editing', 'End Editing' that you expect the users to edit the issue.
3. 'Start Editing' transition should have pre-condition EditUser is empty
4. 'Start Editing' transition should have post condition to update EditUser to the user who initiated the workflow (user %%CURRENT_USER%%, or assign to current user and copy value from field to field (assignee to EditUser)
5. In the permission scheme remove all the existing roles and add the Edit permission to use the EditUser custom field
6. The 'End Editing' should have pre-condition to check the current user same as EditUser custom field
7. The 'End Editing' should have a post-condition to clear the EditUser custom field.

With this, only when a user clicks 'Start Editing', the Edit button will be visible to the user. And once a user has done it, till he/she does 'End Editing' other users will not have 'Start Editing' or 'End Editing' or Edit buttons visible.

[NielsJ]

Sounds like checkin/checkout for JIRA issues - cool :-)

[JamieA]

Curious if you actually use this pattern? Sounds like massive annoyance for users, just to avoid an issue that happens only once in a blue moon. Also you need some kind of service to clear the "lock", because presumably people will forget to hit the "end editing" action. And what about the SOAP API, people need to manage this in their client code too? (Not to say your solution is not clever, just seems like overkill).

[Jobin Kuruvilla [Adaptavist]]

SOAP API is a good catch but that is even rarer ;) I think if someone forgets to click the "end editing" action, other users can see who it is by looking at the EditUser custom field. And maybe, make the action available to Admins as well!

It is more like an exclusive checkout and they will slowly learn to hit the "end editing".

This looks like a good solution that can be implemented without any coding. If you are open to plugins, there are a few better options for sure.

[JamieA]

Oh, and REST api ;-) Certain external plugins are going to be broken, eg jira client, mylyn, ecliptic, etc etc. I agree that it is good for a no-code solution... just seems like it could be better.

[Tim Baverstock]

Unfortunately, this fails if the user with the checkout happens to have the ticket open in multiple tabs - while researching it, getting distracted, etc.

It really needs proper support from Jira, to encode the original version number in the edit screen, and compare it with the current version number on submission. Failure would display a word-diff and allow the user to do a 3-way merge.

Or - gosh - maybe they allow multi-editing like their confluence wiki pages.

[MatthewC]

In a word, no. Renjith's example is clever but I don't think it's sustainable. It would cause more problems that it solves. It's not a big problem & you can always roll back using the data in the change history.

There is a feature request open for this so add your vote but don't hold your breath, it's been open since 2003.

https://jira.atlassian.com/browse/JRA-1917

[Dieter]

What about granting the Edit permission only to the current assignee? Since an issue can have only one assignee only thos one should be able to edit the issue at any time

[George Mihailoff]

A social and collaborative way to solve this -- with a plugin like this https://marketplace.atlassian.com/apps/1219999/quantify-realtime user can check who else is viewing the same page in real-time and decide what to do.

[Kristan Bullett]

Hi

Did anyone make furher progress with this? I can see that the whoslooking plugin does not work with 5.2 so we're left completely in the dark in understanding if someone else is editing a ticket.

Thanks

Kristan

[Jens Rapp]

hi,

in our company we consider to use group names instead of user names. (because our staff council wants this)

If we do so it could happen that two people work concurrently on same ticket. isn't there any way to prevent this?

[Nic Brough -Adaptavist-]

It's pretty much as above, there's no locking mechanism, but there's a couple of workarounds, like restricting edit to current assignee or moving all the edit rights down into the workflow.

As an aside, you say you're using group instead of user names? Does this mean shared accounts - people logging in using the same username/password? If so, then you might want to talk to your legal department because you might be breaching your license terms (if you've got a license for 10 users, and have 10 group names, but 50 actual users for example), and if you're working in certain types of organisations, you're breaking the law in a lot of countries (I've worked in financial corporations, defence, and a couple of government places, where I know it's illegal to share accounts for working with certain types of information, I'm not qualified to talk about it in other areas)

[Jens Rapp]

Yes we consider using shared accounts but that's no problem because we've got an enterprise license for unlimited users plus the product is only used inside our company.

[Nic Brough -Adaptavist-]

Ah, good, that covers the licencing I reckon. I'll not ask if you're in an auditable industry ;-)