Re: Question on best practice for allowing edits of lists

One concern with the process of editing records is simultaneous
editing.

That is user A clicks on the link and begins editing..

Then user B, a quicker sort of person, does the same thing and SAVES
FIRST.

User A is still on the form page, plodding along and finally finishes
and hits the SAVE button, overwriting B's changes.

The classic rule is that you shouldn't be able to save over a record
that has been edited underfoot.

The easiest way to check this is to use a timestamp field (I'm using
mySQL vernacular) -- that is, a field whose date is set every time the
record is saved. (You can use a conventional date field and manually
set it to now() using SQL every time you save. I tend to call this
field "updated" by convention.

Load the old 'updated' field into a hidden field on the form.

The form will submit to a save_record.php page (or some such) and on
this page, BEFORE YOU SAVE, do a SELECT to determne the records'
current value for 'updated'. if it is different from the 'updated'
value that the record had when you loaded it, don't resave the data.
give the user an error message ("Your record has been edited by someone
else; your changes haven't been made. ) and return them to the list
view. If they want, they can click on the record and edit it again.

Also, in the event that someone else has deleted the record, you might
want to check that there is a record in the system with the current ID.


Ideally you'd have a "check out" system that prevented user B from
opening the record when user A was editing it, but in the web
environment it's very problematic to do this because its tough to
determine when the user has shifted gears (left the edit page without
saving the record) so "stale checkouts" are common.

These security measures are most necessary in data held in common by
several users. Private records like BLOG pages or user_ID records
probably don't need asynchronous edit protection.

.

Quantcast