Using the Lotus DBlookup to better Leverage the Name and Address book

Posted on by — 3 Comments ↓

Another , more code…. In last weeks adventure our narrator talked about (note: there was a mistake in the example, now fixed), and as promised I am going to talk about how to leverage that lookup into the Name and Address book (the Domino directory – a LDAP before there was a LDAP).

Most organization use – or should – the Name and Address book (or NAB for short), as a place to put basic employee contact information (work location, phone(s), manager).

The NAB also have a number – sometimes large – of groups (list of persons or other group) associated with roles and responsibilities. This group information is used in the ACL of Notes applications, and for mailing to groups of individuals.

Wouldn’t it be nice to use this information in the applications you build? So here are my 2 examples, to get the ball rolling

1) Selecting Pointy Hair Bosses () to email from a existing group:
Create an editable field, drop down dialog, may or may not allow multiple values. On the value definition (2nd tab) populate it with this formula:

1
2
3
4
5
6
7
8
class := "Notes";
server := @Subset(@DbName; 1);
database := "names.nsf";
view := "($VIMGroups)";
key :="Pointy_Hair_Bosses_with_Authority_in_this_Line_of_Business";
fieldName :="Members";
value := @DbLookup( class : "NoCache" ; server : database ; view ; key ; fieldName );
@If(@IsError(value);@Return("");@Name([HN];Value));

So, what’s it doing? Looking at the names.nsf (the NAB) for this server, going to a view showing groups (but not all groups), finding the group of PHB’s and getting the member list. When a new PBH gets added to the NAB, it auto-magically available to this application.

Also a note about Reader and Author fields. Suppose the field above was also being used to identify the manager in charge of this document, and you wanted Reader or Author security. It would be tempting to had the editable field as a Reader or Author field, but please don’t. If they leave the organization, AdminP will strip the value out and a) screw up any categorizations that used that field value, b) remove access to the document if that was the only Reader field. Instead use a hidden Reader or Author field with the value from the above field, plus a “[Admin]” or other roles

2) My second exampe is leveraging that extra information in the person document. In workflow applications to is nice to inculde information to contact the person assinged or who made the request, right on the form. So in a computed field :

1
2
3
4
5
6
7
8
9
class := "Notes";
Cache := "NoCache";
server := @Subset(@DbName; 1);
database := "names.nsf";
view := "($VIMPeople)";
key :=@Name( [Abbreviate]; @UserName );
fieldname := "OfficePhoneNumber";
value := @DbLookup( class : cache ; server : database ; view ; key ; fieldname );
@If(@IsError(value);@Return("");Value);

This gets the Office Phone Number for the current user (@UserName). I wonder if you grab the @DocNumber and build a Doclink on my document, link back to the person document? What other things are on the person document that I could make use of?

What other things to grab in the NAB? How about “Holidays”? (Could I use that to figure out how many business days between 2 dates? Humm..) Anything else? So will this keep your users quiet (and you happy?) Now I have to think of something for next week!

Update: small corrections…in my first example I used the ($Groups) view which is too restrictive, rather than ($VIMGroups). I also used a @Name([HN];Value) ,which was pure moondust, rather than @Name([Abbreviate];Value).