Bug 1283214

Summary: [QE](6.2.z)After Force Unlock locked user can continue to work with Business Process but can't save it
Product: [Retired] JBoss BPMS Platform 6 Reporter: Kirill Gaevskii <kgaevski>
Component: jBPM DesignerAssignee: Tihomir Surdilovic <tsurdilo>
Status: CLOSED EOL QA Contact: Kirill Gaevskii <kgaevski>
Severity: high Docs Contact:
Priority: high    
Version: 6.2.0CC: alazarot, kverlaen, lpetrovi, tsurdilo
Target Milestone: CR1   
Target Release: 6.2.1   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1295547 (view as bug list) Environment:
Last Closed: 2020-03-27 19:43:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1288023, 1295547    
Attachments:
Description Flags
How it is looks like none

Description Kirill Gaevskii 2015-11-18 13:11:15 UTC
Created attachment 1096059 [details]
How it is looks like

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.

Comment 1 Kris Verlaenen 2015-11-18 14:22:53 UTC
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)?

Comment 2 Christian Sadilek 2015-11-18 15:39:29 UTC
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.
-------------------------

Comment 3 Kris Verlaenen 2015-11-18 16:02:18 UTC
Thanks Christian, just wanted to get confirmation there was consensus that User A might indeed lose his local changes.

Comment 4 Christian Sadilek 2015-11-18 16:16:35 UTC
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.

Comment 5 Tihomir Surdilovic 2015-11-18 23:39:17 UTC
master PR https://github.com/droolsjbpm/jbpm-designer/pull/87

Comment 6 Tihomir Surdilovic 2015-11-19 11:15:09 UTC
6.3.x PR https://github.com/droolsjbpm/jbpm-designer/pull/88

Comment 8 Christian Sadilek 2015-11-20 16:00:45 UTC
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