SSProtect uses a single Administrator and zero or more Delegates (Privileged Users) to configure and manage an Organization and its' Users or Accounts. Delegates have nearly identical authorization, limited only from making changes to Enhanced 2FA configuration. Individual Accounts do not need to be concerned with the content in this article (until migrating to an Organization).
What happens when two individuals make changes to the same item at the same time? The system reflects the most recent change, which overwrites the first change. This can lead to confusion.
Before explaining how the software helps you manage these scenarios, it's first critical to understand that KODiAC Cloud Services have been designed to make certain that changes get committed as a single atomic transaction, in all cases. This means that changes to related configuration items get committed to the system at the same time, as a single operation, that cannot be interrupted.
If this were not the case, and two Privileged Users attempted to make changes to the same set of configuration items at the same time - for example Signup Policy - it would be possible for one part of the first User's changes to get saved, then another part of the second User's changes. The results wouldn't reflect the intent of either party, which in some situations could be catastrophic. KODiAC Cloud Services handle these situations at the most fundamental levels. All capabilities and features noted in this article are purposed to eliminate confusion, and are not required in any way to maintain system integrity.
Exclusive Edit Locks
To eliminate confusion, for Administer Users, :Collaborate Trusts, and other non-obvious (UI-based) tasks, the :Foundation Client uses Exclusive Edit Locking. This works by maintaining exclusive edit access for one Privileged User at a time - the first to display one of the managed dialogs - denying others the privilege of making changes until the Privileged User with the Exclusive Edit Lock dismisses the dialog.
The state of your edit session is reflected in the lower right-hand corner of each display. The ACCESS: EXCLUSIVE indicates that, when you displayed the dialog, the software requested, on your behalf, exclusive global edit privileges for the items managed by the UI (see below - some items are always available). Until you dismiss the dialog, other users that subsequently access the dialog are presented with ACCESS: READ ONLY, and most configuration controls are disabled. Note that Lock enforcement is implemented in the cloud, and as such, even if the controls weren't disabled, attempts to perform managed operations would fail. This can happen if you have a lock that another Privileged User chooses to break (FORCE LOCK, see below).
Exclusive Edit Locking allows you to make changes without concern for others making similar changes that overlap, insuring that you see the results of your changes without the confusion of other edits. When you dismiss the dialog, the Exclusive Edit Lock is released, and the next person to enter the dialog (or request the lock, see below) gains exclusive edit capabilities.
Managed dialogs contain two buttons that are active when you are denied Exclusive Edit Locking, i.e. display a dialog after another Privileged User has done the same, but before they dismiss it. REQ LOCK allows you to check to see if the other user has dismissed the dialog, allowing you to acquire the Exclusive Edit Lock just as if you dismissed the dialog and re-displayed it. In the future, this will be automated such that you will be granted access as soon as the other user dismisses his/ her dialog, automatically (and granted to Users in an orderly fashion, when more than one accesses the same manage entity at a time).
FORCE LOCK allows you to force acquisition of the lock, breaking it for the other User. This should only be used to recover from failure. For example, if you display the Administer Users dialog and your network connection is dropped, you have no way of telling the cloud that you are finished making edits. Your peers can use the FORCE LOCK to break the inactive connection and also acquire the lock for their use, in one operation. Use this sparingly, and only when coordinating with your peers, lest you anger them by purposely interrupting their work.
Losing the Lock
If someone performs a FORCE LOCK operation, you lose the lock - though this is not yet reflected to you in any way until you attempt to make a change. At that point, KODiAC Cloud Services will deny the request (since you no longer hold the lock) and you will see the appropriate error message. In the current release of the software, this change of state is not dynamically reflected for you - you must leave and re-enter the dialog for control state to reflect the lock change. This will be addressed in future releases.
Lock acquisition, release, and FORCE operations are audited and available in each Report that contains Administrative line items.
The Administer Users Exclusive Edit Lock manages operations that do not apply to a single Account, such as Change Pwd and Sync 2FA - these remain available at all times. The :Collaborate Trusts lock manages all capabilities for its' display except the Remove operation, which only affects local configuration data - it too is always available.
Note that :Collaborate Trusts and Administer Users are independently managed by different Exclusive Edit Locks, meaning two different Privileged Users can access each of the dialogs simultaneously, without conflict.
As noted above, if you acquire the Exclusive Edit Lock, and another Privileged User performs a FORCE operation to, "steal" the lock, you are not notified - though any operation managed by the lock will then fail (until you re-acquire the lock). Also note that the dialog buttons managing LOCK activities are not dynamically updated when encountering a changed lock state - exit and re-enter the dialog to see the new button state. Dynamic updates will be provided in a future release of the software.
This article was updated w/ v5.6.2 of the :Foundation Client