Here's a general-purpose Author and Reader field troubleshooting guide. This document explains how these fields work and the causes of common perplexities.
There's a helpful tool that analyzes and explains your access to read or edit the document, but you should still read the information below so you'll understand what the tool does and what can go wrong.
To begin, look at one of the documents that has the readers fields in it. If the documents are hidden even from you, the database manager, then you will have to access the database from the server console, or use full access administration, which lets you see all documents regardless of Reader access. You may also have to temporarily disable the local security property ("Use consistent access control") in the database ACL.
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 of your reader fields in turn and look for differences from this ideal image. Note that:
- Field flags must say READ-ACCESS NAMES. If not, read in Domino Designer help about IsReaders property of NotesItem.
- 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 LotusScript, 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]"
doc.Readers = readerNames
' If field did not previously exist, tell Notes
' it's a Readers field.
doc.GetFirstItem("Readers").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).
- 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. In other words, always 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.
- An Authors field also allows read access (see below).
Author fields work like Readers fields for all the above tests, except that:
- the Field flags should read READ/WRITE-ACCESS NAMES instead of READ-ACCESS NAMES, and
- a blank Authors field does not enable everyone to edit the document. "*" does, though.
View - A view is one way of looking at all or some of the documents in the database. By selecting the View menu, you'll see a list of available views for the selected database.
Collection - Each view in a Notes database has a corresponding collection in the database. A collection contains a series of indexes related to the particular view. The collection indexes consist of:
1. An index sorted by note number.
2. The user-defined view collection (defined in the Design View Sort dialog)
3. An index of parent-child documents within the view.
Refresh - Refresh a view by pressing F9. Refreshing the view reads from the index and repaints the screen accordingly. It does not rebuild the index.
Rebuild - Rebuild a view by pressing Shift+F9. Rebuilding a view makes a call to NIF, and causes the current view's collection to be completely rebuilt.
Update - Pressing CTRL+SHIFT+F9 updates or builds all the views in the database. This includes both views which are hidden and views which are open. Pressing CTRL+SHIFT+F9 will work on server-based or local databases. If the views are not built, Notes will build them. If the views are already built, Notes will update them, not rebuild them.
The Notes 'Indexer' is actually a composite of three different subsystems. They are described below.
Discussion of NIF
The Notes Indexing Facility is comprised of a set of functions that the Notes server uses to manipulate indexes. Most of these calls are made by the server as users access databases (remember that Notes is client-server).
As a user makes changes to documents in a database, the current view for that user is updated immediately. This process is necessary so that the user sees their changes as they occur.
When a user changes documents within one view, and then switches to another view, NIF sees that the database has been modified since the last time the collection was rebuilt, so it forces an update to the collection. When the new view is open, it will reflect the updated documents. Note that this update may take some time if many documents are involved (other user's updates are included), or if the view is complex.
An indicator at the top left corner of the view (a reload arrow) signals that a view is out of date. That is, the database contains newer information than that reflected on the screen. Pressing F9 refreshes the view. Refreshing the view reads the index from the database, and paints it on your screen. Clicking the indicator with the mouse button also refreshes the view. (In Notes 3.x, the indicator that a view is out of date is a black question mark against a yellow background.)
The workstation normally stores the current chunk (called a page) of the index in memory. When you scroll back and forth within the view, you notice that scrolling down once or twice is quick, but the third times takes a few moments. This is because that third scroll has pushed you past the page of the index held in the workstations memory. A new page must be read from the database. This is when you may notice the refresh arrow. It will appear when you read a page of the index, and documents have been modified in the database since the view was last updated.
As you scroll up and down, you will see new documents in the view as they are updated by other users. The refresh arrow will display until you press F9. The view you have open may or may not change after pressing F9. This will depend on whether the modified document are supposed to appear in this view, or some other.
Discussion of Update
$Update.EXE is a process that runs continually, checking a work queue for databases to update. It checks the queue every 5 seconds. If it finds a queued request, it opens each collection within the specified database, forcing the update of the collections' indexes.
Update is normally specified on the ServerTasks= line of the NOTES.INI. For example:
ServerTasks=Replica, Router, Update
The Update process works off a queue, and updates database indexes as requested. Requests normally comes from the Replicator, Router, or a user.
Replicator When a database replicates, the Replicator adds an entry to the Update queue.
Router When the Router adds a document to a database, it also adds an entry to the Update queue.
User When a user closes a database, the workstation adds an entry to the Update queue if the database has been modified.
Update will wait to combine multiple request for the same job. About 15 minutes after the replication ends, the Update queue kicks in, updating all the indexes on the database. When Update has refreshed all the collections, it updates any databases that have Full Text indexes with the Index Update Frequency set to 'hourly'.
When a user closes a database, an entry is added to the Update queue. About 15 minutes later, the collections for that database will be updated to reflect the new documents that the user changed. If another user goes into the database before Update has updated the collections, the collection that the user opens is forced to update immediately. Note that this update may take some time if many documents are involved, or if the view is complex.
Discussion of Updall
$Updall.EXE is the single-instance version of $Update. It runs until it has processed each database, and terminates. It does not work from a queue. Like $Update, $Updall opens databases, forcing the update of the collection. When Update has rebuilt all the collections, it updates any databases that have Full Text indexes. Updall also purges delete stubs from databases.
Updall is normally specified on the ServerTasksat2= line of the Notes.INI. For example:
ServerTasksat2=Updall
Glossary of Notes Indexer Terms:
Posts
