In 7.1.8, I need to unlock a work object of another users
In 7.1.8, I need to unlock a work object of other users. We have users closing a browser and not clicking logoff. I can detect when the popup closes, but cannot get any of the lock manager methods to work. They all seem to go against the database. I need the java logic to unlock a work object by handle and held by another.
Accepted Solution
NTT Data
US
Here is the answer I received from Pega Support. Basically, it can't be done in recent versions of Pega.
The ability to unlock the work of another user (that is, the Requestor that owns the lock is not a requestor for the same operator id that is attempting to release the lock) cannot be done from the 7 series onward. It was felt that this ability was counter-intuitive to how locking should behave, and so you can no longer do it.
The best that can be achieved is to perhaps shorten the lock timeout period in general for these case types. A lock becomes "soft" if it is held longer than the timeout period. Although the original requestor still holds this lock and can use it once it becomes soft, any other user in the system can then steal it (do what you are trying to do) while it is soft. So if your standard lock timeout is 2 hours, perhaps you want to reduce it to 15 minutes. The downside, of course, is that the user holding the lock might go out for a cup of coffee, come back, and be greeted with a "you have lost the ability to make this change" if someone else has taken the lock.
Here is the answer I received from Pega Support. Basically, it can't be done in recent versions of Pega.
The ability to unlock the work of another user (that is, the Requestor that owns the lock is not a requestor for the same operator id that is attempting to release the lock) cannot be done from the 7 series onward. It was felt that this ability was counter-intuitive to how locking should behave, and so you can no longer do it.
The best that can be achieved is to perhaps shorten the lock timeout period in general for these case types. A lock becomes "soft" if it is held longer than the timeout period. Although the original requestor still holds this lock and can use it once it becomes soft, any other user in the system can then steal it (do what you are trying to do) while it is soft. So if your standard lock timeout is 2 hours, perhaps you want to reduce it to 15 minutes. The downside, of course, is that the user holding the lock might go out for a cup of coffee, come back, and be greeted with a "you have lost the ability to make this change" if someone else has taken the lock.
You can, if user A was logged into node #1 and left something locked, and then user A logs in to node #2 and tries to get that same lock, achieve that. This case, however, is managed by the system Pulse agent, so there still can be some small delay as the unlock request is managed across the different nodes.
You are not the first customer to discover that we have tightened up the locking mechanism to disallow what you are trying to accomplish. Unfortunately, it is an unequivacal "no, you can't do that."
Ernst & Young LLP
MT
If you're NOT planning to do it programmatically:
1. Ask user to follow standard way of logging off from application.
2. If that doesn't work, wait for lock to become 'soft lock' (normally 30 mins, depending on lock setting of your case type).
3. If you don't want to wait for that long, login to SMA, go to Requestor Management > 'select that requestor session' > click on 'stop' button on top bar. It will end and also release all locks hold by that requestor.
Alternatively, depending on your Business requirement/expectation, you might switch to Optimistic lock type - https://community.pega.com/sites/default/files/help_v731/procomhelpmain.htm#case-management/case-designer/case-wide-properties/locking/cm-case-locking-con.htm
CGI
US
I do not believe at the current time, PEGA has a utility to capture 'browser close' which can trigger an event to release the lock. So it would be interesting to see what you come up with to capture the close of your PEGA browser.
In the alternative, ask your System Administrator if you can reduce the Soft Lock to 10 mins or 5 mins.
Accepted Solution
NTT Data
US
Here is the answer I received from Pega Support. Basically, it can't be done in recent versions of Pega.
The ability to unlock the work of another user (that is, the Requestor that owns the lock is not a requestor for the same operator id that is attempting to release the lock) cannot be done from the 7 series onward. It was felt that this ability was counter-intuitive to how locking should behave, and so you can no longer do it.
The best that can be achieved is to perhaps shorten the lock timeout period in general for these case types. A lock becomes "soft" if it is held longer than the timeout period. Although the original requestor still holds this lock and can use it once it becomes soft, any other user in the system can then steal it (do what you are trying to do) while it is soft. So if your standard lock timeout is 2 hours, perhaps you want to reduce it to 15 minutes. The downside, of course, is that the user holding the lock might go out for a cup of coffee, come back, and be greeted with a "you have lost the ability to make this change" if someone else has taken the lock.
Here is the answer I received from Pega Support. Basically, it can't be done in recent versions of Pega.
The ability to unlock the work of another user (that is, the Requestor that owns the lock is not a requestor for the same operator id that is attempting to release the lock) cannot be done from the 7 series onward. It was felt that this ability was counter-intuitive to how locking should behave, and so you can no longer do it.
The best that can be achieved is to perhaps shorten the lock timeout period in general for these case types. A lock becomes "soft" if it is held longer than the timeout period. Although the original requestor still holds this lock and can use it once it becomes soft, any other user in the system can then steal it (do what you are trying to do) while it is soft. So if your standard lock timeout is 2 hours, perhaps you want to reduce it to 15 minutes. The downside, of course, is that the user holding the lock might go out for a cup of coffee, come back, and be greeted with a "you have lost the ability to make this change" if someone else has taken the lock.
You can, if user A was logged into node #1 and left something locked, and then user A logs in to node #2 and tries to get that same lock, achieve that. This case, however, is managed by the system Pulse agent, so there still can be some small delay as the unlock request is managed across the different nodes.
You are not the first customer to discover that we have tightened up the locking mechanism to disallow what you are trying to accomplish. Unfortunately, it is an unequivacal "no, you can't do that."