How would you lock down an online form?

Question

We have a web application that is based around a form that gets passed around. Unfortunately when people look at it, it is editable. So two people can edit it at the same time and overwrite their changes. How would you go about locking the form (and any multiple parts of the same form because it is broken down into multiple pages) down so only one person can edit it at a time?

We only want them to be able to edit the form for a half hour in one shot (they can save and continue to add more time).

---

I have one solution, but I wanted to see what other people have thought of.

In my solution, when a user first looks at the form (or any parts of the form because there are multiple parts that all need to be locked down) none of the fields are editable until they hit the edit button. Once they hit the edit button a flag is entered with their user id and the start time. Then they are redirected to the same form that is editable. There will be a javascript timer at the bottom of the page to let them know how much time they have left. When they are finished they hit the "Save and Exit" button to save their changes, to unlock the form for other users, and to go back to the uneditable form. To avoid the use of the back button to return to the editable form I am thinking that an intermediary page that contains a javascript redirect will be used. So if they hit the back button they will be just redirected back to the current page.

If they want to edit one of the sub forms (there are buttons that redirect them to the sub forms from the main form) they can just click on one of those buttons in edit mode and it will save the big form, update the time to give them another half hour, and redirect them to an editable sub form.

When a user tries to look at a form that is currently being edited by another user, the edit button will be grayed out and the information of the current user will be shown along with the time it should be opened back up, but this time could be changed by the user upon saving and editing a sub form.

---

Does this sound like a viable solution? If had to do the same thing please let me know what your solution to the problem was?

Answer 1

It's a viable solution, a bit heavy on the visible management overhead but maybe the most suitable solution depending on your expected workflow.

Other approaches include:

a. Allow anyone to edit and submit a form, but if someone else has also submitted changes in between the time since the form was originally opened, respond with a 'conflict' error. To improve this if necessary, show the two different sets of changes and allow the user to choose which to apply, or attempt to merge the changes.

b. Have the form work as an instant-effect editor without a Save button. Keep all open views on the form up to date using an XMLHttpConnection to the server so that when one user makes a change to any field it is more-or-less-instantaneously updated on anyone else's copy of the form.

Answer 2

There are a number of ways to handle this situation. The one is by locking the form and allowing only one edit at a time. Another is to detect collisions when saving and warn the user.

Locking is most useful on resources with high contention. If many collisions are expected then making the user click an edit button works best. This should flag the record as locked in your datastore and should only allow the one user to edit it. The record needs to be unlocked when the user saves the record, or when the user cancels. In a disconnected situation like on a webpage there should also be an auto unlock after a period of time.

Collision detection is done by recording a revision number or last edited datetime and passing this to the client when they view the page. The client then passes this back to the server when they hit save and it is checked against the value in the database. If the value has changed then someone else has edited the record and the user can be warned of this. This system works much better for small edits, and when the resource is unlikely to be edited elsewhere (this is usally the case when there are many small records in comparison to the number of active users).

I find detecting the collisions works better and is less frustrating for the user in web applications. Provided that the text they are entering is sufficiently small. This is because locking resources can hold on to them far longer than is neccesary, which is very frustrating