It seems like Data Entry level group can also delete individual record. Definitely not good news. In Q&A, there was a setting that you can stop certain people from deleting Individual records. If capability is not there in Sesame at the present time, I would definitely likely to see that it is available. You can never have your data at risk with disgruntled employee!! If your whole file is deleted, you know immediately that it not there and you can replace by restoreing it but how about if someone keeps on erasing individual records on regular basis, you are not likely to detect until a big chunk is gone. Hopefully, there is such capability to block individual delete exists in Sesame and I am missing something.  

Mark,
The problem is, the person would be entering data, so he/she cannot have just read only access. Only thing we want to see that person is not able to delete the record, that we could do in Q&A. Please look into it to see if this could be accomplished somehow in Sesame.  

Its not just about malicious intentions, often it is simple stupidity. I have had users thinking they were doing the correct thing by purging records they thought were no longer valuable. Also unfortunately in an environment that has employee turnover  it seems that no matter how much training you give some people you used to get some one that used F3 instead of F7 and never read the warnings. The stories can go on forever but the reality at least in my little world has been the control of the deletion feature is a safer evil then bad data being entered. If Sesame does not end up with a simple feature to do this I am sure with a little creativity one of us will find a method to protect against this using the Sbasic tools we already have.

In our existing QAWIN file very few have del privileges, any user that has a record that needs deleting puts a specific code in a field (using a John Dow feature with DTFWIN it writes the user Id, patient id, date, and other pertinent data to a log file) upon exiting the field that updates a field with user id and asks for the reason. A manager reads these records daily determines the appropriateness of the deletion. Finally a report is generated before deleting that is saved and then the records are deleted.

The log file that was created is imported into another database that runs reports showing different data on the deleted records. Who deleted, why deleted, were deleted etc. When you look at historical data in this manner, very interesting patterns are found.

Well at least that is my opinion. 

Quote:


We're not generally debating intentions. Bharat specifically mentioned this in terms of a disgruntled employee. Our point was that preventing deletes while still allowing edits does not protect you from the type of subtle damage which can be inflicted by a disgruntled employee. If deleting a single record is difficult to detect, someone maliciously changing the content of notes on customer conversations or altering invoice dates is almost impossible.

We have a carefully designed security model based on the tried-and-true read/write/execute model used by operating systems for over three decades.  One of the core tenets of this is "If you don't want someone to do damage, don't let them write."

Our security model is capable of expanding well beyond Q&A's. We hear that this particular feature is important to some of you. If it is important to enough of you, we will look into how best to fit it into Sesame's overall design, whether through an SBasic event, an SBasic settable flag or an appropriate slot in the security model. This type of feature, however, is much more high impact than simply writing a new SBasic command. It needs to be considered carefully in terms of its effect on the whole. It's not something we can just drop in, nor does something count as "not a new feature" just because Q&A had it. Every feature we share with Q&A, we wrote from scratch. The security model is not something we followed directly. We went for something that, in the long run, is far more consistent and expandable.

Erika,
Consensus is very clear.  We have been using the system and working with people for several years and know the importance of such safeguard that developer might not foresee. The data-entry level people got to have write priviledges and especially when they are new, they are error-prone. Because of this reason, data validation is very important for data entry and edit and we are very happy to see that Sesame does pretty good job at that. But leaving the data-security hole in the form of someone maliciously, ignorantly, experimentally, foolishly, naively or whatever the reason may be, we cannot expose the data to such risks.  If you just know about the various data- validation codes we have to put into the system and what calibre data-entry people we have to work with, you will definitely see the need for such safeguard that we have been so vehemently looking for.  Thank you for looking from the user point of view and understanding our needs.

I have a particular need to allow specific people to delete, yet they can edit.

One of the requirements from a national accrediting agency is to have a designated person to be allowed to delete individual records, while all in that department can add and edit records.  Since the department is a closed one (we know who can access what),  malicious editing is caught quickly, because records are checked twice a month, as a minimum.

So, I believe a feature like undelete or allow delete somehow is very needed.

It is certainly in the plans for Sesame to have the ability in SBasic to on and off all of the available commands. As part of that, the ability to prevent deletion of records will naturally result. It will be part of a integrated and homogenous set of functions. But, it must be seen as an adjunct to application security, and should not be counted on to provide a level of data integrity or security.

Record deletion is not deletion of the container of data, but the data itself. Deleting the data itself cannot be prevented if the "deleter" is given full write access (in any system).