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
|Names||Displays names as they appear on IDs. Not useful for securing data.|
|Authors||Allows anyone listed in the field who also has Author access to edit the document.|
|Readers||Restricts read access to the document for users and groups with Reader access or greater.|
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.
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.
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.
Part I. Introduction to Release 6
Whats New in Release 6?
The Release 6 Object Store
The Integrated Development Environment
Part II. Foundations of Application Design
Advanced Form Design
Using Shared Resources in Domino Applications
Using the Page Designer
Adding Framesets to Domino Applications
Automating Your Application with Agents
Part III. Programming Domino Applications
Using the Formula Language
Real-World Examples Using the Formula Language
Writing LotusScript for Domino Applications
Real-World LotusScript Examples
Writing Java for Domino Applications
Real-World Java Examples
Enhancing Domino Applications for the Web
Part IV. Advanced Design Topics
Accessing Data with XML
Accessing Data with DECS and DCRs
Security and Domino Applications
Creating Workflow Applications
Analyzing Domino Applications
Part V. Appendices
Appendix A. HTML Reference
Appendix B. Domino URL Reference