We need to improve UX when there are multiple people working on the same part of the system at the same time. Currently we don't have much in place and having multiple people work on the system at the same time can be stressful.
Resource locking enables low-code app configurators to lock specific resources when they want to edit them such as a workflow and a series of related modules.
For now, locks should only occur on administration-like screens and potentially turned off all together in production.
For now, locks will only be for non-read operations (namely edit, delete, and undelete).
Considerations
Does this pose any complications as far as automation goes?
Someone should be able to hold multiple locks at the same time.
If we go with WS from V1 we can prepare a bunch for future improvements such as user indicators.
If there are complications we can opt in for pooling.
Should the ability to request and hold locks be unprotected as far as RBAC goes? Perhaps it's not a good idea because of end-users.
To implement
Back-end
On the back-end, we need
Some service to manage locks, potentially in the same manner as we have i18n.
Extension to WS to optimise how locks are maintained and optionally released (inactivity).
RBAC extension
manage locks (to overwrite held locks)
Front-end
On the front-end, we need
An interface to request a lock
Notifications/prompts to show lock-related information
An interface to show all held locks
An interface to forcefully release a lock (in case we need to kick someone off a resource)
Event handing to send heartbeats to the back-end
Additional nice to have
Active user indication
When viewing some page (TBD which exactly -- could be only admin pages or both public and admin) provide a list of users that are active (on the system and) on the resource.
We can utilise web sockets to figure out who is viewing what and who is actively interacting with the page/resource.
Web sockets to update resources
Currently, when someone updates a module (or similar) the changes are not reflected through other open instances (other employees, your other tabs).
This makes development a bit frustrating since you need to constantly refresh your page in order to see the most up-to-date state.
Goal
We need to improve UX when there are multiple people working on the same part of the system at the same time. Currently we don't have much in place and having multiple people work on the system at the same time can be stressful.
Resource locking enables low-code app configurators to lock specific resources when they want to edit them such as a workflow and a series of related modules.
For now, locks should only occur on administration-like screens and potentially turned off all together in production. For now, locks will only be for non-read operations (namely edit, delete, and undelete).
Considerations
To implement
Back-end
On the back-end, we need
Front-end
On the front-end, we need
Additional nice to have
Active user indication
When viewing some page (TBD which exactly -- could be only admin pages or both public and admin) provide a list of users that are active (on the system and) on the resource. We can utilise web sockets to figure out who is viewing what and who is actively interacting with the page/resource.
Web sockets to update resources
Currently, when someone updates a module (or similar) the changes are not reflected through other open instances (other employees, your other tabs). This makes development a bit frustrating since you need to constantly refresh your page in order to see the most up-to-date state.