Jeff,
There are three approaches that can be taken to ensure two users are not making changes to the same record at the same time. One is to define an "edit" workflow that merely contains a manual activity with the Actor assigned to the Initiator role, which would be the same user who launches the work item. If the <repository> -> Edit -> Workflow Properties for the repository has the "Lock Record From Edit" checkbox checked, then the only user who has permission to edit the record would be the person who initiated the work item into the workflow. Once a work item is launched, then no other user will be able to launch a work item for the same record until the previous one has completed the workflow. Once the initiating user has made their desired edits and has sent the record to workflow, the work item reaches the end activity and the record is unlocked. One thing to keep in mind is that if the "Lock Record From Edit" option is checked, then repository records will be locked for any workflow on that repository (it's a global setting, not specific to one workflow).
The second approach is to leverage the Ownership security to lock the record, instead of launching the work item into workflow and relying on the "Lock Record From Edit" option, the user would select their name in an attribute with a code set with Ownership enabled. Their name would be associated with their login. An Attribute Security Filter would be configured to only allow editing of attributes if the record is "owned" by the user editing the record. Once the user was done making their changes, they'd update the owner attribute to have the "unlocked" value set. To ensure users cannot "unlock" the Attribute Security Filter can be configured such that the owner attribute is read-only and requires launching a work item to obtain the lock for the record. The workflow would ensure the record is not already locked before "granting" the lock (by setting the owner attribute to the user's login). Once the user is done with their changes, they would launch a work item to release the lock. The Brown Bag Session #21 on the eLearning Platform covers record locking using ownership security.
The above options limit access to the record to a single user. There may be some cases where different groups need to access different attributes in the same record concurrently. The Attribute Security Filters can be configured to only allow edit access to the attributes associated with a specific group. This allows users to edit and save the record concurrently without having the "last one wins" conflict. However, this still would allow more than one user from the same group to edit the same record at the same time and then the concurrency issue is present. This can be prevented by using Change Notification to implement "effective" record locking. The reason it's described as "effective" locking is because users will be allowed to make changes and save them, but if they don't have the lock associated with the attributes they can update assigned to them, their changes will be rolled back. This technique is described in detail in Brown Bag Session #74 on the eLearning Platform.
All of these options primarily focus on concurrency with users. If the API is involved, it can be used to lock the record, but the application would need to check the record for a "locked" status and then skip the attempt to update it if was locked. The third option would work with the API - if a user has a record locked and the API attempted to make changes, the Change Notification processing would roll back those changes. It would be the responsibility of the application to check if those changes were rolled back, but if it's going to do that, then it can easily check for a lock prior to doing an update.
-Brian
------------------------------
Brian Zupke | Senior Technical Support Engineer
Winshuttle North America | 9099009179
------------------------------
Original Message:
Sent: 07-27-2021 12:08
From: Jeff Wiedemann
Subject: Record Locking within UI
Curiosity is getting the best of me. Has there been any talk about managing shared records better through the UI? Specifically, if a user is editing a record while an API is also editing that record, the last saved appears to win. So the API applies the update and those updates are overlaid with the user via the UI. It would be nice if the first one in locks the record and prevents future updates to that record until the lock is released.
Please correct my understanding?
------------------------------
Jeff Wiedemann | Engineer, Apps
Steelcase, Inc | 616-460-0597
------------------------------