M
Max Myzer
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:
  1. 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
  1. 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.
  1. 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:
  1. To actually edit the resource
  2. To view the resource
  3. 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.