Relevant only when ControlLockCanOnlyRemoveOwnLock is set to 1, thereby enabling the Lock Ownership feature of Control Locks. That property restricts which locks users with the Lock Add/Remove privilege can remove, such that they can only remove locks that they ‘own’.
The definition of ownership varies according to this property as follows:
Anyone with the Lock Administrator privilege can always remove any lock.
0. Session ID ownership (ControlLockOwnerMode=0)
Users only own locks that they create during a given session. Each time a user signs on, a new session ID is generated. Therefore, signing in and setting a lock, signing off, and then signing in again would result in the same user being in a different session and not be able to remove the locks they set in the first session. This extends to both thin and thick clients. Even if the same user is signed in on several clients, locks added on one will not be removable on other clients.
1. Account ID ownership (ControlLockOwnerMode=1)
This is the most straightforward ownership mode. As the name suggests, ownership is defined by the account ID that added the lock. If the same user is signed into several machines they would be able to remove locks set on other machines / clients.
2. Machine ID ownership (ControlLockOwnerMode=2)
In this mode, ownership is defined by the machine ID. This is useful way to segregate removal permissions based on physical workstations. When ownership is set to this mode, AutoUnlockUponLogout does not apply.
3. Custom Hook ownership (ControlLockOwnerMode=3)
Applies only to those who are developing their own code that involves Control Locks. When ownership is set to this mode, AutoUnlockUponLogout does not apply.
Ownership is defined by a custom hook provided by the customer within their code: ControlLockIsOwnerHook.SRC.
