--Introduction--
Here's a general-purpose Author and Reader field troubleshooting guide. This document explains how these fields work and the causes of common issues.
The references list a tool that analyzes and explains your access to read or edit the document, but begin with the information in this article.
--First Steps--
To begin, look at one of the documents you're having trouble with. Reader fields are effective for all users, even the database manager, so you might not be able to see the documents in question (this might be the problem you came here to solve!).
You can see all documents regardless of Readers items, if you access the database in "full access administration" mode. Only a server administrator can do this.
TIP: To prevent the database manager/administrator ever losing read access to documents, put a Computed when Composed Authors field (not a Readers field) on every form, with a formula such as "[Admin]". This will allow all members of [Admin] role to read the document, without preventing others from reading it, as a Readers field would.
From a view, open the Document Properties box. Here's an example of what it should look like:
Highlight each reader field in turn and look for differences from this ideal image. Note that:
- A reader field doesn't have to be named Readers -- it can have any name.
- Field flags must say READ-ACCESS NAMES (SUMMARY is optional). If not, it's not a real Readers field. Check whether the field is defined as Readers type on the form. Also note that the type of the field can be different from that on the form if the document was created with a different version of the form, or if the field was assigned by an agent. Read in Domino Designer help about IsReaders property of NotesItem, to learn how to write code to properly assign Readers items.
- If there are multiple values, they should appear as separate quoted strings on separate lines. In this case there are two values, "CN=Rex Rightway/O=Pings" and "[Admin]". If instead the value were listed as "CN=Rex Rightway/O=Pings, [Admin]" (or any other character instead of comma) then the problem is that you are storing multiple values as a string instead of a proper multivalue. If this is the problem:
- Make sure the multivalue checkbox is checked in the field properties.
- If you assign the field with agent code, assign it from an array with one value in each element, as opposed to a string with some character in it as the delimiter. Example:
Dim readerNames(0 to 1) As String
readerNames(0) = "CN=Rex Rightway/O=Pings"
readerNames(1) = "[Admin]"
Dim readerItem as NotesItem
Set readerItem = doc.ReplaceItemValue("Readers", readerNames)
' In case field is new, tell Notes it's a Readers field.
readerItem.IsReaders = True
- If assigning the field from macro language, say FIELD Readers := "CN=Rex Rightway/O=Pings" : "[Admin]" as opposed to "CN=Rex Rightway/O=Pings;[Admin]" (for instance). Note the use of the list concatenation operator : (colon)
NOTE: Formula language contains no equivalent to the LotusScript IsReaders property to set a new item to be the Readers type. A FIELD assignment should work to update the value of a field that's already of the Readers type, but to create a new field, you have to use LotusScript or Java (or manually edit the document). As noted in one of the references, it's possible to do using formulas, but not simply.
- If you use a username, you must use the full canonical username. If you store "Rex Rightway/Pings" the readers field will not work in all situations. You need that CN= garbage.
- Make sure there are not excess characters in the name, e.g. leading or trailing or multiple consecutive spaces. If in doubt, use @Trim.
- If the field is not visible in the document properties from the view, but only when the document is open, you've probably made the field Computed for Display, or created the document using an agent that neglected to set the field as shown above, so that it's not being stored in the document when it's saved. To take effect, a readers field must actually be saved in the document, before the user tries to access it. Notes looks at the document, not the form, when deciding whether to grant access.
- Should you have a problem with users being able to read the document whom you think should not have access:
- Check whether the READ-ACCESS flag is set on your Readers fields as shown above.
- If all Readers fields are blank, anyone can read the document. If there are multiple Readers fields and some are blank, the non-blank fields limit access.
- An Authors field, if not blank, also allows read access (see below).
Author fields work like Readers fields for all the above, except that:
- the Field flags should read READ/WRITE-ACCESS NAMES instead of READ-ACCESS NAMES, and
- a blank Authors field does not allow everyone to edit the document. "*" does, though.
--Other Things To Check--
Sometimes users have the right access to documents, but can't open or edit them because there's a Querymodechange or Queryopen event that prevents them by setting Continue= False. Check the design of the form and also any subforms it includes, or use the LotusScript debugger to see whether this is the case.
You should especially suspect Queryopen event code if the user can see the document in a view, but can't open it.
Note for developers: Form event code is not a security feature. To control access, use Reader and Author fields.
--References--