[back to "Filtering data for Domino Web users"]
Technique #3: Readers Fields (sidebar)
Our third technique is another way to give users access to data that is specific to them. This technique is more appropriate when you need an extra layer of security -- you want to make sure that even if the user guesses on hidden view names or URLs, they cannot see other people's data -- or when you want to use a real view to list documents rather than building your own lists of links.
For our example, we will use Readers fields to create a "My Action Items" view. Users will be able to use this view to see only action items assigned by them or assigned by someone else to them. There are two fields that track assignment of action items on our Action Item form: From and AssignedTo (it seems like the From field should be called "AssignedBy" rather than "From," but the designer of this Action Items database used the common Notes technique of naming the field that tracks the creator of the document as "From").
If we define each of these fields with data type "Readers" rather than "Text," only the assignor and assignee can see the action item in any view. The My Action Items view will then contain all action items, but a given user will only see the ones assigned to him.
Note: The From and AssignedTo fields are not defined as Reader fields in the Action Item Filtering database, because they would not work correctly for the first two techniques.
We want to be careful, though, to include another Readers field on the form that specifies administrators and servers as Readers. If the administrators can't see all action items, it will be tough to administer the application, and if there are no servers listed in readers fields, action items will not replicate between servers. (You do not need to define an administrator's Reader field unless you have other Reader fields, like From and AssignedTo, and are trying to restrict the documents. Reader admin fields are not necessary unless there are other Reader fields in use.)
We'll define a field called ReaderAdmin on the form. The field should be computed and hidden at all times, with this formula:
"[Admin Readers]"
[Admin Readers] is a role, meaning a collection of people assigned in the database's ACL to a role called "Admin Readers." In the ACL, we add a role with this name, and then select the groups, individual users and servers we want to assign to that role for the purpose of this database:
Next, you simply define a "My Action Items" view that shows all action items. Users will only see those items assigned by or to them, but administrators will see all action items. Dan Marino would see this:
The limitation in the readers technique is that we cannot use categorized views to display documents that have Reader restrictions on them. This screen capture shows what happens if you do use a categorized view:
The user sees all the categories, even if a category doesn't contain any document he can see. So if he tries to expand the Finished view, nothing happens. There are Finished action items in the view, but none of them are assigned to or by Dan Marino.
If you need categorization, the drill-down approach is more effective. We could have a list of status codes links (Dan would see just Open and Approved). When he clicked on a status, it would drill down and show him the action items assigned to him in that status.
The other problem with the readers technique is that you can't show the users other people's data. We can't show Dan other people's action items, in any view. He simply doesn't have access to them. With the drill-down technique, you could give users both a "My Action Items" capability and an "All Action Items" view.
Return to "Filtering data for Domino Web users".
Copyright 1998 Iris Associates, Inc. All rights reserved.
|