Readers fields are a bit dangerous, you can prevent people (even if they are database managers) from seeing the document.
If there are no readers fields on a document, everyone who has read access or higher in the database's ACL (Access Control List) can see the document.
If all of the readers fields are empty ie "" then again everyone who has read access or higher in the database's ACL can see the document. reference link
If one readers field contains something then that overrules the empty readers fields.
You can put "*" in readers fields so all users of Reader access or better can see the document. ie Not Depositor or No Access.
Authors fields only apply if the user has Author access to the database.
If a user has Editor access they can edit and save the document.
An Author can only edit a document if their name is in the list of an Authors field.
Having an authors field which is computed on compose to be "@username" allows an author to edit their own documents.
An authors field overrides a readers field, ie if PersonA is in the Authors field and PersonB is in the readers field, PersonA can read the document. reference link
Authors and readers fields can be multivalue.
You can use Groups and people directly in Readers and Authors Fields.
For best results use common names, or even better canonical names. Abbreviated names sometimes do not work. reference link
eg common name: "Adam Foster" Abbreviated: "Adam Foster/AdFos" Canonical: "CN=Adam Foster/O=AdFos"
Best practice for names of authors and readers fields.
Having Readers fields called "Readers" or "Readers_All" or "Readers_Admin" makes finding debugging etc much easier.
Having Authors fields called "Authors" or "Authors_All" or "Author_Admin" makes finding debugging etc much easier.
Readers fields should be prefixed "rd_" or "Readers"
Putting "*" in any readers field will allow all readers and above to see a document.
Best practice have 1 readers field with a computed value (or at worst have 2 readers fields , 1 that is "[ReadAll]" and the other has a computed value)
Best Practice for Readers fields
In the past I have had a computed readers field which checks to see if the other readers fields are not empty, and if they are not empty then the readers field is set to a role "[ReadAll]".
This role can then be used when required to see all documents in a database, very useful if someone leaves and they have otherwise hidden documents.
Splitting the [Admin] and [ReadAll] roles can also be useful when using a database or delegating [ReadAll] .
Servers in the ACL need this role if they are replicating to other servers. Another option is to put "LocalDomainServers" or "LocalServers" in the Readers fields of the documents.
NB Having documents with readers fields will slow down a database, so avoid if possible.
Alternatives to Readers Fields:
1) for non confidential data, use categorised by username views instead.
2) public documents user can have depositor access but still see or even write public documents, useful for reading About Pages, when not having access to a database
3) Use encrypted fields- messy as you have to share a key file around - but good for HR systems where confidentiality is crucia
3) use profile documents (advise against these as there are caching problems and documents cannot be seen in views.
If you get in a mess with Lotus Notes Readers fields
If nobody can see a document because someone has left or you've just made a developer mistake no one can see a document then enable "Full Access Admin" in the Notes Admin Client and then
open the database in the client as before, and you should be able to see everything.