+++ This bug was initially created as a clone of Bug #1283214 +++

Description of problem:
If user A start to work on Business Process but user B user Force Unlock button for unlock this process. User A can to continue his work but can't to use save button. It can cause waste of time by user A because no warnings was shown for user A after Force Unlock button was clicked by user B. See Attachment.

Version-Release number of selected component (if applicable):
6.2.CR1

How reproducible:
always

Steps to Reproduce:
1. Open BP with user A and start to edit
2. Open BP with user B and use Force Unlock button
3. Start to edit the Business Process by user B
4. Try to edit the Business Process by user A and try to save it.

Actual results:
User A can continue to edit the Business Process but can't to save it.

Expected results:
User A can't continue to edit the Business Process.

— Additional comment from Kris Verlaenen on 2015-11-18 09:22:53 EST —

Christian, Joe,

What's the recommended behavior here? It seems other editors do:

• show a message when you are editing the file and it detects the lock has been released and taken by someone else
• refresh the editor at that point, making you lose any changes

It seems we might need something in between, a notification to the user that the lock was released, but the ability to keep the changes open, so you can try save after the lock was released (or force unlock as well)?

— Additional comment from Christian Sadilek on 2015-11-18 10:39:29 EST —

The process designer is missing some functionality there. The desired behavior is as follows:

1. Open BP with user A and start to edit
2. Open BP with user B and use Force Unlock button
3. Start to edit the Business Process by user B
4. Try to edit the Business Process by user A.
5. User A gets a notification that the process is now locked by User B

That's how all other editors work. Unfortunately, the process designer is not a platform native editor and requires some custom logic (it doesn't automatically inherit that functionality from UberFire). However, there's existing API that can be used to add this functionality to the process designer.

– General discussion –
It was decided in many discussions (and I think it makes sense) that if User B steals a lock from User A, User A can potentially lose changes. The popup to confirm the force unlock specifically warns about that. The force unlock functionality should really only be used if it's clear that the other user doesn't need the lock which is why it was originally constraint to admin users.

If we allow edits and allow to keep local changes for locked assets, we essentially fall back to the functionality we had before introducing pessimistic locking, which then (again) questions the point of adding pessimistic locking to begin with. A User could then always keep local changes and run into the very same conflicts we tried to avoid. As a remedy, they could then only override another users changes or drop their own (because we have no 3-way merge support). So, imo, we'd be right were we started before adding this feature.
-------------------------

— Additional comment from Kris Verlaenen on 2015-11-18 11:02:18 EST —

Thanks Christian, just wanted to get confirmation there was consensus that User A might indeed lose his local changes.

— Additional comment from Christian Sadilek on 2015-11-18 11:16:35 EST —

You're welcome, Kris. I do have an idea for a relatively minimal change to the process designer to make it behave similar to all other native editors in this case. I will discuss with Tiho.

I think we all agree that pessimistic locking is a compromise, the "easiest" solution to avoid conflicts altogether and that we'll adjust functionality based on feedback.

— Additional comment from Tihomir Surdilovic on 2015-11-18 18:39:17 EST —

master PR https://github.com/droolsjbpm/jbpm-designer/pull/87

— Additional comment from Tihomir Surdilovic on 2015-11-19 06:15:09 EST —

6.3.x PR https://github.com/droolsjbpm/jbpm-designer/pull/88

— Additional comment from Tihomir Surdilovic on 2015-11-19 13:48:50 EST —

commits:
master:https://github.com/droolsjbpm/jbpm-designer/commit/b2e3187891a524bd8b827b8d96456a91640b68a7

6.3.x:https://github.com/droolsjbpm/jbpm-designer/commit/2dcd04cfca04df520b23a03a8c42792856a5f3d5

— Additional comment from Christian Sadilek on 2015-11-20 11:00:45 EST —

6.3.x commit was reverted as not identified as blocker. PR was recreated and is ready to merge when needed:

https://github.com/droolsjbpm/jbpm-designer/pull/94