Implementing Document-Level Security

Other techniques can secure the data in documents ”down to the field level, if necessary. Within the realm of documents, quite a few restrictions can be set. Three data types store names: Names, Authors, and Readers, all of which are described in Table 23.2. The field data types of Reader and Author Names fields can limit who can read or edit documents and provide a very powerful way to secure information. These fields can be manipulated programmatically or a designer can enable the user to edit the fields and determine the read and edit lists. Access-controlled sections were discussed in Chapter 5, "Advanced Form Design," but are not true security measures because the fields within the section can be accessed by other means such as views, other documents, and the field list in a document properties box. The tools available in Domino provide a sophisticated, highly refined system to secure information. The three types of names fields are listed in Table 23.2.

Table 23.2. Names Fields

Groups, users, servers, and roles can be added to Authors and Readers names fields. These fields can be single or multi-value , depending on the needs of the application.

Using Readers Fields

When you need to ensure that only certain users can read a document, the Readers field is just what the doctor ordered. If the document contains a Readers field and a user is not named in the field explicitly or implicitly through a group or role, it's as though the document doesn't even exist. It won't be replicated, not even server to server. This is very powerful!

Imagine creating an application for salespeople who are on the road so that they can access a database on their laptops. The database provides the main office with information about all the customers that the salesperson calls on, statistical information about that person's sales figures, and so on. Do you think each of the salespeople would want their information shared with other salespeople? Probably not! The good news is that you could create a Readers field on each of the forms that will allow the Management group and all servers to have Reader access to all the documents. At the same time, the salespeople would be listed only in the Authors field as the author of their individual documents. When a salesperson replicates with the server at the main office, all her information is sent to the server, but she can't replicate any of the documents that don't contain her name as the author or a reader.

NOTE

It's a good idea to always include at least two Readers fields ”one for users and one for administrators/developers ”so that you cannot be accidentally locked out of a document. For example, I usually create a field called rnReaders for end-user readers and another field called rnAdminReaders , which is computed when composed and contains a list of administrator and server groups that should always have access to every document. This approach can save you a lot of headaches in the long run.

CAUTION

Be sure to add all server names either explicitly or implicitly to a reader's field so that the documents can be replicated.

Using Authors Fields

As a developer, a field of Authors data type should appear on every form that you create! Without the existence of an Authors field, the person who creates a document cannot edit that document.

In a workflow application, it can be useful to manipulate the values of an Authors field programmatically based on the status of a document. To do this, set up a computed Authors field and use an @If() statement to change the value. The following formula for an Authors field called ECRDocAccess is an example:

@If(ECRStatus = "Accept"; "ECRAdmin"; ECRStatus = "New"; ECRDocOwner; ECRDocAccess)

In this formula, ECRAdmin is a group, and ECRDocOwner is a field that stores the name of a user. ECRStatus is a field that stores the status of the document.

If an Authors or Readers field is left editable, users can enter the values. Most often, the values of both Readers and Authors fields are handled programmatically.