We experienced this issue as well a couple of days ago, Peter Baeza and us at the World Maritime University. Luckily Peter had the most substantial version of the form still opened in a tab allowing him to save over the change that I made and we avoided about 2 hours of work being lost. So far with Skuid being such a new component mainly adopted by administrators and interface designers at this point, we all appreciate as pointed out by ktyler, that other colleagues at a later stage can roll up there sleeves and make a big difference with the tools provided by Skuid. Being able to lock design when someone is performing edit actions is then needed.

This is a great idea. We’ve experimented with a few ways of solving this problem. 1. One way is storing the time that a user pulls up a page and then checking it against the last modified date right before a user saves. If the last modified date is greater than when the user opened the page, the page will not be saved and the user will be prompted with a message stating that. This solves the issue of overwriting someone else’s changes, but the second user who saved would have to reload the page and redo their changes. 2. Another option would be to actually have something like a “Locked By” field on each page. Whenever a user opened a page to start editing, they would be notified if the page was locked. If it was locked, they would only be put into a read-only mode for the page. If it was not locked, then the page would put their username into the locked field. The most difficult problem with this method is knowing when to “unlock” a page. Sometimes people will start editing a page and then just close their browser and we wouldn’t be able to tell that they were done editing. We could solve this by letting locks be overridden or have them time out, but it doesn’t seem like a terribly elegant solution. What do you think about these options? Any ideas we haven’t thought of?

Ben, I don’t think you can get around the problem of a page being locked when it should not be… Not only will users want to lock pages while they’re working on them… they may want to lock them over several work sessions. Letting locks be overridden solves the problem… the issue is not stopping users from deliberately overwriting other people’s work… but stopping them from doing it accidentially… if they had to go back to skuid admin page to “unlock” a form that would introduce an element of deliberation. Just popping up a dialog and asking “do you want to unlock this page” probably would not work… because its to easy to just click “yes”.