Deleters
If a document contains a field of this type, the user must be listed in it to have the right to delete the document, whatever is his access level (of course, the user must have the Delete Documents right).
Subject: DIY: How to add “Deleters” field to documents
You could easily implement this feature in the Database Script event: QueryDocumentDelete
Here you’d catch any user attempts to delete a document in the database. Check each document in the source.documents collection for the presense of a “Deleters” field, and if this field exists, check if the user is a member (may get tricky if you allow Groups or wildcards like */MyCompany in the field).
But be aware that deletions made using lotusscript (notesDocument.remove) would not be prevented, and that there are ways to disable database script, too. But it may solve your current need.
Subject: RE: DIY: How to add “Deleters” field to documents
most of those ways of disabling script can be avoided by hiding the database design upon deployment.
Subject: RE: DIY: How to add “Deleters” field to documents
Sure, good point.
But if a malicious user really want to “break” a QueryDocumentDelete script, he could simply write a LotusScript agent in another (local) database that gets a handle on the database in question, and performs a notesDocument.remove() on any number of documents. As long as the user has “Delete documents” checked in the ACL, the documents would be deleted, regardless of any QueryDocumentDelete code.
Subject: RE: DIY: How to add “Deleters” field to documents
absolutely - probably a better idea to do this with authors fields then, you can’t delete a document you don’t have author access to do, if you’re listed as an author in the ACL - must have deletion access however!
Subject: RE: DIY: How to add “Deleters” field to documents
True. Authors fields provide “real” (native) security that is unbreakable.
But if you want to allow users to edit the documents, but not to delete, that is not an option.
Subject: RE: DIY: How to add “Deleters” field to documents
I prefer to not allow users to delete documents at all.Archiving will do it for them.
Subject: RE: DIY: How to add “Deleters” field to documents
I agree. Especially since I don’t trust soft deletion (in R5 it caused corruption). And I havn’t yet seen/heard of anyone stating thet they have fixed it, and you can rely on it to work (every time).
In my development framework, I use a global “mark for delete” facility that marks documents, and thereby “moves” them away from normal views into a “deleted documents” view. After 24 hours, a scheduled agent copies them to an archive and removes them. This way users don’t have to have deletion rights.
Subject: Soft Deletions work really well on my 6.0.2CF2 server. I trust my mail file with them.
Subject: corruption with soft deletions
The only corruption I could find (happend when replicating databases with soft deletions) in the Knowledge Base was fixed in R5.0.5.