Subject: Setup 2ndary NAB for web authentication, but not mail delivery?
I’m confused as to why the internet addresses need to be there at all; they obviously aren’t part of how these dealers get mail currently. But I’m sure you have your reasons. (Oh, and I don’t know the INI variable that Dave referred to; if he was thinking of the NAMES parameter, that doesn’t affect directory assistance, just the predecessor technology it obsolesces: cascading address books. But there may well be one; that would be simple.)
Anyway, one fairly sneaky option from the overkill department would be to enter the email address as the first entry in the Username field in all of these dealer person docs. Since address lookups return the first entry in that field, this is what your users would get when they enter any version of the dealer’s name, which would not only solve your problem, but add a feature, as your users could now browse the 2ndary NAB via the address dialog, pick the dealer’s name from the list, and have the internet addy automatically inserted into the address field of the email they’re composing. The dealer would still be able to authenticate using the same name they had been using, so they’d be unaware of any changes, and wouldn’t need to be told to do anything differently…
HOWEVER, while this would be ideal if this was merely an address book of external contacts who never authenticated against your web server, you have the additional wrinkle added by the fact that they do. Since this internet address would also become the name the dealers authenticate as, then in any place that a dealer’s name might show up (in groups, ACLs, or security fields), you would have to change the fully-distinguished name that’s there currently to be this internet address.
HOWEVER, it’s unlikely that the dealer names show up anywhere but in groups in your primary NAB, so it wouldn’t be too difficult to change them. (And the “Find User(s)” tool in the admin client will tell you every place that a username shows up in the primary NAB as well as in the ACLs of all dbs on all servers in your domain.) If you’re providing these dealers with a mail db, then their names will have to be changed (or just added) to these ACLs, but I’d assume that that’s pretty unlikely as well. (And as long as you don’t change the Owner of the mail db, but leave it set to the fully-distinguished Notes name, I’d assume that the name they see in their iNotes interface would be their Notes name and not their internet addy.)
ANOTHER GOTCHA would be if the dealers ever access a db which displays the results of @username, since that function will now return the internet address. Those display fields would have to be re-coded as well; maybe with something like this (untested):
@replacesubstring(@trim(@left(@username; “<”)); “"”; “”)
If, however, those drawbacks aren’t idea-killers, then a simple little agent run against all the person docs in that NAB using
SELECT Form = “Person”;
addy := “"” + Fullname[@elements(Fullname)] + “" <” + InternetAddress + “>”;
FIELD Fullname := @unique(addy : Fullname)
would take care of updating the person docs, and this one
SELECT Form = “Group”;
@For(i := 1; i <= @Elements(Members); i := i + 1;
addy := @NameLookup([Exhaustive]; Members[i]; "Fullname");
addy := @If(addy = ""; Members[i]; addy);
addies := @Trim(addies : addy)
);
FIELD Members := addies;
takes care of group docs.
DISCLAIMER: While I tested these agents and they work, I am recommending that you make changes to documents in your NABs which control authentication and security restrictions. You should, obviously, thoroughly test this with dummy users before blithely implementing some half-thought-out idea you got from some faceless person in an anonymous, unofficial, unsupported web forum.
(And lemme tell ya, becoming faceless was painful…)