I really like to test the capability (or incapability) of the system to edit records simultaneously.It’s always fascinating to find the developers took a good care of users in this respect. Just picture the situation when from time to time your data get into a mess the moment somebody decides to edit it right away it occurs to you.
How is this issue handled in WorkXpress? Let’s check it through a standard test when one and the same record is opened in 2 browsers.
So, let’s open the record in IE and change Last and Hiredate Columns:
And open the record in Firefrox and change Last and First Columns:
And save the record in IE first:
Do the same in Firefox:
What we’ve got here? First thing: the system doesn’t really care about simultaneous editing. It means there is no warning you corrupt somebody’s data.
But the good news is the system tracks only fields the user modifies and doesn't overwrite them.. One can see on the screenshots hire date is not overwritten.
And one more thing: you can add audit for field modification.
It’s time to edit Last field in 2 different browsers and check out how the system acts.
This is the report about modifications in the Last column:
Conclusion:
WorkXpress doesn’t support simultaneous record editing so the user could know he overwrites somebody’s data. But field track history really helps here. At least you can always find the person who corrupted yours. Better than nothing.
Hi Jane,
ReplyDeleteJust as in a database tool where one commonly writes code to lock and unlock records according to the requirements of the application, WorkXpress allows you to use its 5 blocks to accomplish the same goal. However, we didn't make it as easy as having an "on/off" checkbox, and you've clearly highlighted that here.
For example, you can create an "in use" field on an item, and use actions to set and unset that field when the item is being edited on a particular page.
Then, on that page, you can use security to show the edit or view-only versions of the page depending on whether the flag is off or on.
However web apps all suffer from the same problem which is that its hard to know when the user "walks away" from the screen, when the internet connection goes down, etc, and therefore it's hard to always know when to unlock the record.
We encounter this need from time to time and do address it in a deep way. We posted "how-to's" here;
http://www.workxpress.com/training/check-if-another-user-has-edited-item and here
http://www.workxpress.com/training/lock-item-when-user-editing-it
to show how this is actually done by our professional services team when delivering applications to customers.
Having said that, the more sophisticated methods aren't simple. In practice though, the need for record locking doesn't really surface until you encounter higher volume operations, and those operations tend not to mind a few extra hours of "development".
Even with all of this, record locking in a deeper application is not simple because a given interface doesn't have to be restricted to 1 table, as in your example. What if the page is of a contact, the contacts accounts, the notes about that contact, and the projects that the contact is currently working on. Which "tables" do you lock?
In any case, it's a great test, we thank you as always for your fair review, and will continue to evaluate how we can better offer this feature - clearly the context you're providing needs consideration.
Regards,
Treff LaPlante
www.workxpress.com