Current behavior: Any number of users can have a screen open. If another user has it open, it will warn the user. When saving, users must resolve merge conflicts. Suggested behavior: Retain this behavior, but add a feature for an additional level of "another user has this open" - Allow a user to click "request lock". When this happens: Existing users get a popup that another user has requested the lock. They can ignore it, (click save, which doesn't close the dialogue), decline, or acknowledge. - If any user declines the lock request, the requestor gets a popup with a message letting them know - If all users acknowledge the lock request, the requestor gets a message telling them they have the lock If a user attempts to open a resource that someone has a lock to: - They are warned that another user has the lock. They are offered the chance to request it, close, or edit anyway. - Maybe: the opened version is from when the lock was created, by default. If a user attempts to save their edit of a locked resource: - If the resource was unlocked since they opened it, they just resolve conflicts normally - If the resource is still locked, they can choose to: - Discard the edit: discard changes. Similar to "close and revert" option, useful for testing - Cancel the save: keep the changes to save later. - It would be nice if this could be saved to the gateway as a branch, but that is scope creep. - That feature could be similar to git, and allow for a request for the changes the lock user can merge/rebase onto - Insert before the lock point - any changes made on the lock will be applied on top of it, overwriting with priority to the lock holder. If this is done, the lock holder will get a conflict popup and chose what to keep Why:: There are a few reasons users may have a resource open: To actually edit the resource To view the resource To "inspect/test" the resource (ie, adjust params and observe the true internal changes, rather than the external ones on an embedded view) For users who are truly editing a resource, users who inadvertently save their test params, or keep the resource open, creates issues. By creating a lock system, users who are truly editing the resource take priority, and users who are only testing/viewing have the option to easily discard the edits.
