Domino Code Fragment

Code Name* Hierarchical ReaderNames Lookup Implementing control of hierarchical ReaderName relationships in Notes R3/4	Date* 04/29/2024	Source (or email address if you prefer)* Rlatulippe@romac.com IP address:.13.59.36.203
Description* Hierarchical ReaderNames Lookup Implementing control of hierarchical ReaderName relationships in Notes R3/4	Type* LotusScript	Categories* (Misc)

Implementation:	Required Client:	Server:
Limitations:	Comments:

Files/Graphics attachments (if applicable): Code:

---------------------------------------------------------------------------- FILE: Hierarchical ReaderNames Lookup UPDATED: August 1996 AUTHOR: Eric Koeler mailto:ekoeler@panix.com http://www.panix.com/~ekoeler NOTE: Copyright (C) 1997 by Eric Koeler, this file is protected by the GNU General Public License ---------------------------------------------------------------------------- parshuram@aol.com wrote:

> ...The real problem is that now they want readers based on hierachy. > For instance, AA is the CEO of the Organisation. Under AA, they have > two managers CC and DD. Under CC, they have EE and FF. Under DD they > have GG and HH. So now the document composed by HH should be read by > HH, DD and AA and not by GG and CC... ----------------------------------------------------------------------------

I would set up a separate database which contained user names and their relationships. In the main database, when each document is saved, an @DbLookup function will retrieve the names associated with HH's chain of command. The real trick is setting up and maintaining this external security database.

Let's call this external database the "Database Registry" and make sure that it resides in the same directory as the main database (it won't matter what directory that is, as long as it is the same for both).

This next step will be a serious pain in the ass, but maybe with some insight you can invent something that works a little easier. With that said, this registry database would contain a Person form. Each user of the main database (or rather, each manager) needs to have to have their own Person document in this registry. There will be two fields on this form: personName and personGroup.

The personName field will hold each manager's name (editable text, but you may want to make it a keyword lookup to the NAB so you are sure to get the proper spelling of the name, but since only the database manager or some other system administrator will be entering or changing these values, you should do whatever is easier for you). The personGroup would be a multi-value text list of all the names of the users for which the manager is authorized to read documents. For example, using the names you provided, the documents would look like this:

Document 1 personName: AA personGroup: CC, DD, EE, FF, GG, HH

Document 2 personName: CC personGroup: EE, FF

Document 3 personName: DD personGroup: GG, HH

In this registry database, besides the view(s) you will create and use to display and find these documents (which can be set up however you like), create a hidden view called "(Security Lookup)". This view should be set up like this: Column 1: personGroup, Sorted and Categorized Column 2: personName

Because you are categorizing a multi-valued field, the view would look like this:

CC AA DD AA EE AA CC FF AA CC GG AA DD HH AA DD

Now, back to the main database... The ReaderNames field is going to perform an @DbLookup on the (Security Lookup) view based on the author's name. The formula for the multi-valued ReaderNames field would look something like this:

nameKey:=@Name([CN]; @UserName); REM; regFileName:="REG.NSF"; REM; dbName:=@LeftBack(@Subset(@DbName; -1); "\\")+"\\"+regFileName; REM; serverName:=@Subset(@DbName; 1); REM; @DbLookup("":"NoCache"; serverName:dbName; "(Security Lookup)"; nameKey; 2) : "System Admin Group"

Of course, you have to be sure that you use the same name format (common, canonical, etc.) across the board, and in the formula above, you have to set regFileName to the actual filename of the Registry database.

That's the approach I've used in the past; let me know if it works for you. I would also use the Database Registry to hold any other keyword lookup lists, as well as any technical and/or user documentation.