The NabFields profile could present a list box of the available fields derived from NotesForm.Fields. Then the administrator merely selects from the available fields. Or we could even do away with this profile document completely and use the NotesForm.Fields list on the Group form.

You might be tempted to add code that automatically ignores non-mail groups in the Directory, but I wouldn't do this because of the risk of creating duplicate groups. Remember mail groups include not only "Mail only" (GroupType 1) but also Multi-Purpose (GroupType 3) groups. What I might well do, though, is alter the CreateGroup sub at line 23 so that newly created groups are Type 1 rather than Type 0.

If the application had a wider audience than the administrators, I'd be tempted to handle the non-managed groups better. This is actually intended as a longstop against the administrator having a moment of aberration and creating a Group definition for something like LocalDomainServers. It was never intended as a complete lockdown mechanism.

As the application stands, when you enter a Group definition and hit the selection button, you get a list of all the Groups in the directory, because it uses the Groups view. This doesn't include Deny Access views, however. You select a Group, and then it's checked against the list of non-Managed views. This looks a bit clunky. One alternative, but not a complete solution, would be to use the hidden $MailGroups view for selection, and then you would only present Type 1 groups. The non-Managed groups list would then be much smaller, and you might not need any at all. Or, better, as the database is opened, a list of good groups could be created and stored temporarily in a profile. This list would include all Mail and Multi-Purpose groups--types 0 and 1--and exclude all non-managed groups. Then, when the Group list is requested, this list could be offered via @dbcolumn.

I'd also remove what is, to be honest, the rather questionable "security" provision of checking the expected list owner against the actual owner in the Directory. I don't, with hindsight, see that it adds anything to the application.

But after all this, you'll still be left with one thing, and that is that the groups will be as good as the source data that they're created from. So you'll still have to ensure that as people join and leave the company, move jobs, or get promoted, that the source data changes. Otherwise your groups still won't accurately reflect reality.

I hope you've enjoyed this in-depth look at programming a major Lotus project. Let me know if you do anything new with it by emailing me at mick_moignard@unipart.co.uk or by posting a message on the DominoPower Magazine PowerBoards.

Mick Moignard has been working with Notes and Domino for very nearly ten years. He is a Principal CLP with UALS (Unipart Advanced Learning Systems), a Lotus Premier Partner in the UK. If you want any more information or a preview of this application, contact Mick at mick_moignard@unipart.co.uk, or via http://www.uals.co.uk. UALS will also happily discuss commercial work on this application or any other Notes and Domino application development projects you need help with.