ShowTable of Contents 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. Basic Principles- Your access to a document is controlled by the author/reader fields stored in that document at the time you try to access it. That's why, for instance, a "computed for display" Readers field will not work (because it stores nothing in the document when you save), and a "Computed" field will only grant access based on the value computed when the document was last saved -- not based on whatever value it would calculate now, if the current user executed the formula. To decide whether to let you access the document, Notes cannot refer to the form design.
- The above applies to Author fields also. Whether the user is allowed to edit a document depends on the value of the Authors field at the time the document was opened, not whether re-evaluating the formula now would give them access.
- Changing the form design does not affect access to pre-existing documents. Their access is controlled based on what values were written into the Reader/Author fields at the time they were last saved. You would have to write an agent or otherwise update the documents to correct the field values.
- A Readers or Authors field containing multiple values, only works if the values are properly stored as a multivalued item, not a single string with some delimiter character such as ";". Often this problem is caused by failure to check the "multivalued" field option when designing the form, or by an improperly coded agent.
- Usernames should generally not be used in Reader/Author fields, unless it's to indicate individual ownership of the document or as part of a workflow; use groups or roles wherever possible.
- If you do use a username, you must use the canonical form (beginning with "CN="). Abbreviated or common names will work in some situations but fail in others.
To start with, if you've been changing group memberships or editing the
database ACL while the database is open, exit the database entirely and reopen it. ACLs are cached during your session, so you might not see the effect of changes immediately. If you have the database open in Domino Designer, close it these also (if using the Eclipse-based Designer, you have to either close Designer, or remove the bookmark in Designer, to close the application).
Now, 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.
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 easily.
- 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).
Authors Fields
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. Tips
- 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.
- Form event code is not a security feature. To control access, use Reader and Author fields.
References
|