How do Reader and Author fields work ?

You need to have some documents available for users at one point, but not before/after. You need to design an application where some documents are restricted, but not all of them. You need to have documents which can be read by all, but only edited by a select few.

You need to use Reader/Author fields.

How do they work ?

First, a clarification. I will be using the term "Author field" and "Reader field", by which I mean a field of that type defined and existing in a document recorded in the database. Either of these fields need not particularly be defined in a form, since LotusScript can allow for their creation, but they usually are on a (sub)form somewhere because it is easier to set their functionality that way. Are we OK on that ? Fine.

Now on to the subject at hand. The textbook definition of a Reader field is a field which determines who can read the document. Fine, but how does that work in "real life" ?

Simple. Let's say we have a database which lists all documents in a view. If one of those documents has a Reader field with your name in it, you will see that document in the view. If the Reader field is filled in but not with your name, you won't see the document (more on this later). If there is a Reader field, but it is empty, then everyone can see the document.

The Author field works much in the same way, but with an added restriction - for it to be used, there must be people with Author access in the ACL.
Indeed, by definition an Editor (and above) can edit whatever he can see, and a Reader cannot edit anything at all. So Author fields concern mostly Authors.
If your name is listed in an Author field and you have at least Author access, you can edit that document. If your name is not listed in an Author field, you must be at least Editor to modify it. If an Author field exists but is empty, you must be at least Editor to modify the document.

Okay, so how does all this come together in a view ?

Lets go back to the view I was talking about above. In order to get a good idea of how all this works, lets imagine that there are four documents in this db, and you have Author access.
Document A has a Reader field that is filled in your name. It has an Author field that has someone else's name. You will be able to see that doc in the view, but you cannot edit it.
Document B has a Reader field with another name, and an Author field with your name in it. You will be able to see and edit that document.
Document C has Reader and Author fields filled with other names. You will not be able to see that document (nor edit it, obviously).
Document D has Author and Reader fields that are empty. You and everyone can see it, but you cannot edit it, nor can anyone with Author access.

To summarize, think of access-granting as a pyramid. At the bottom, Notes automatically displays all docs with no security restriction (ie. no Reader fields).
Then Notes checks if there is an Author field in which the user is recorded. If there is, the doc is displayed. If there is not, Notes checks the Reader fields. If they exist and the user's name is in one, then the doc is displayed.
All other docs are not displayed (they have no Reader or Author field in which the user is name, but they have Reader fields with other names).

I hope I have been clear enough on how Notes uses Reader and Author fields. Now the big question is how to program them ?

I have a word of warning here : Author fields you can play with to your heart's delight, but Reader fields are to be used with utmost caution.

Remember what I said about access ? A doc where you are not Reader nor Author is a doc you will not see. And do not imagine that the Notes Admin can get it back for you - he can't see it either. You can even make it disappear for the server (ie. the server cannot see it). Of course, the info in the doc would be totally lost at that point, so it's better not to.

So, when implementing Reader fields, I would strongly suggest complying with these simple rules :

1) Never let users modify the Reader field directly. Always use a button and force users to choose in a list YOU manage. That way, there will be no misspellings and no useless calls to the Helpdesk.
2) Always have a backup access when Reader fields are filled in. You do not want a user to transfer authority to a non-existant or absent user without being able to clean up the mess if something urgent comes up.
3) Make sure you can prove to your hierarchy that the backup access is controlled and can be locked down to essential maintenance operations only.
4) Don't forget to include a Reader field with LocalDomainServers, just to be sure the server will always find it.

A little more on backup access, and Reader/Author fields in general :
First off, you can have more than one Reader or Author field on the document. Take full advantage of that.
In scenarios where the original author must retain edit rights to the document and grant edit rights to others, make sure the OrigAuthor is a ComputedWhenComposed field, and make another field you can call AuthorGrant, with the button to manage the list. This is about the extent of the issues you can get with Author access - after all, an Editor can always go in and set things straight.
With Reader fields, it is a lot more tricky since you cannot accept the slightest chance of losing a document. Therefor, when implementing Reader fields I always include one hidden one with a set definition, something like a special group, role, or user name.
You can fill in that backdoor field only when needed, or directly upon creation, that depends on the workflow. It can also be made so that the workflow depends on it. For example, you can have an app where everyone needs to post docs, but every doc should be restricted in access to a list that is user-defined. Well, by setting the backdoor immediately, you ensure that no new doc can be viewed until the author adds additional access to the document, thereby respecting the specifications.

Just remember to always think twice before implementing Reader functionality. Make sure you have all bases covered, because a failure will, in the best case, mean you'll have to restore yesterday's backup.
You do have yesterday's backup available, right ?

;-)

Pascal.