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?
Not sure whether Jira supports this, I guess no. But I have a workaround.
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.
Sounds like checkin/checkout for JIRA issues - cool :-)
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).
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.
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
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?
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)
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.
Ah, good, that covers the licencing I reckon. I'll not ask if you're in an auditable industry ;-)
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
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
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.
It looks like you're new here. Sign in or register to get started.
![Photo of Jobin Kuruvilla [Adaptavist]](https://us.v-cdn.net/6038660/uploads/avatars/17/c4/n17c4b8c7de7da6cee02bd69e8a3b017b.png)
