Thanks for the help. I worked on the suggestion of setting the postopen event to running an agent on a particular day, this agent sets all the readers fields to the “[Recover]” role text, so that if needed the documents could be retrieved. (but of course the role has not been created for the client to see and use)
The end result being this is not known by the end user, therefore effectively a good way protecting the database.
A bit sneaky, I know, but the weak link in my design is the fact that an agent needs to run on a set day, if the client knew this day then yes they could circumvent the triggering of the agent. The trick is them not knowing that an agent is set and even more so not knowing the day this set for.
just for your information this is no really secure way how to protect your database.
Just a few thoughts:
-You should keep in mind that in R6 it is possible to switch on “Full aministration rights” and then the user will see any documents and can modifie the ACL of the db. Then it will be for him very easy to look into the properties of the document and find the name of your role. Once he has this he just needs to create it and the application will be working on and on forever.
you dont need to worry that much about users who will “change” their computer time to be able to work with your application. If they do so (especially on a server)then they will get terrible problems with replications and properbly many,many other things.
if you want really to protect the database I would suggest to do this directly in the design. Pick a few most important function without which your application is “worthless” and put a time check-into it so they will inform the user and stop working. However now you will have to protect the design so that the user does not turn this off, which you can do through two options:
Distribute the database completely with a hidden design. (Easy to do and no way for the user to break)
If this is not possible because you want to allow the user to modifie some things in the database, do the following. Pick some of your most important code which should contain your “time-checker”(it HAS to be LotusScript)and export it into a *.lss - File. Then use a “%INCLUDE” for this file.
Now distribute your database without the lss-File and it will work, however nobody will be able to get to this “hidden” code.
If the .NSF is local, then the user will be able to see the documents, regardless of your Readers setting.
The only way to even come close to doing this would be to eradicate the data inside the documents on an open event. This would be very involved to get right, and it would be easily stopped if the site’s ECLs were set up a certainly way.
If the NSF is local, and “Enforce Consistent ACLs” is turned on, then it can be difficult, but not impossible, for the user to access the documents. I could, for instance, put the NSF on an R6 server to which I have Full Administrator rights, which would bypass the protection and allow me to see all documents.
Once there, even if you use some UI technique to block me from seeing the forms, I can use an agent or API to scan through the data and write it out to an unprotected location.
If you want to truly protect it, your only real shot is a “timebomb” approach which actually destroys the data at a given time. Even this can be bypassed, if I know what I’m doing, but it’s a heck of a lot harder than just throwing the NSF on a private server.
If it was only one time, I think it would be pretty easy to do either of the above options…I’ve never done this, so I can only guess it would work…
This example from the help seems right on track:
(Assuming the Default access was none)
This script finds Shelly McPhail’s entry in the access control list of the current database and removes it. Shelly is then no longer listed in the ACL, and she has the -Default- access.