FCDirectory

This document will provide an overview of the FirstClass Directory, including how to restrict access to certain groups of users by using a variety of techniques including unlisting users or conferences, unpublishing conferences and in particular, using Directory Filtering.

The Directory is a database containing the names of all global objects defined on your FirstClass system (users, published conferences, Communities, public mail lists, groups, calendars, remote names). The FirstClass server consults the Directory when a user performs the following tasks:

Users can consult the Directory to find the name of a user or conference to which they want to address mail. You can display the Directory by choosing Collaborate > Directory.

If you can't see a name in the directory, you cannot address an email to that person, conference or mail list.

Note: If you set no restrictions on the directory, all users have access to all of the directory items.

A user can be made Unlisted by checking the Unlisted checkbox on the User Information Form for that user.

Note: Normally, best practice dictates that when you want to enable a privilege for a user, you would add them to a group that has that privilege enabled. You can then, as the Admin, do a directory search by group to locate all users with that privilege. This privilege cannot be set at the Group Level however.

This can be somewhat problematic as it will not be easy to discover the users for which you have enabled this privilege. The only way to discover this would be to open each individual User Information form and check to see which users have the privilege checked, OR, send a message to Batch Admin with the line GET USER "UserID" 1201 1227 for each user on your system

If a User is unlisted, then only users with the View Unlisted privilege will be able to see the user in the directory. As noted above, you should not set this privilege on an individual User Information form, but rather assign users to a group that has that privilege enabled.

In this case, however, you can also determine who has been assigned this privilege by either direct modification of the User Information Form, or by group membership by looking at the disuse.txt file found in the Reports >Statistics folder.

Like unlisted users, only those who have the View unlisted privilege will be able to view the conferences in their directory, or be able to address a message to the conference directly from outside of the conference.

Note: Normally, the default with any conference, whether it is published, unpublished, or unlisted, if the conference is open, choosing Message > New Message will create a new message with the conference name automatically entered in the To: field.

Also, like unlisted users, once set, the only way to discover unlisted conferences is to open this form for every conference, or to send a similar Batch Admin Command as we do to discover unlisted users.

Send a message to Batch Admin with the line GET CLIENT ClientID 1204 1227 for each conference on your system.

A public mail list is one that is created within the Mail List folder on the Admin desktop. You make your mail list unlisted, or local only in the same way that you did for conferences.

If the mail list is unlisted, only users with the View Unlisted privilege can see the mail list in the Directory.

If the public mail list is local only, users on your server can view the mail list in the Directory, but users connecting to your server through a gateway cannot.

You cannot create two published conferences with the same name as directory names must be unique unless you have disabled

on the System Profile. If you do this, you will be able to create users and conferences with the same name. For users, you can add them to a top level group that has and Organizational Unit set and also Requires unique names within this organizational unit checkbox set

This will not allow you to create two users within the same organizational unit. However, although you can assign conferences to organizational units, this checkbox will not apply to conferences so you will be in danger of creating two conferences with the same name within the same organizational unit.

In order for someone to be able to create a published conference (one that shows up in the directory) that person must have the Publish Directory names privilege

NOTE: There are no restrictions on duplicate names for unpublished conferences. Like unlisted conferences, the only way for a user to send a message to the conference is to have access to the conference and with the conference open, choose Message > New Message to create the message and have it auto-addressed to the conference.

Unlike unlisted conferences, even those with View Unlisted privilege cannot see these conferences in the directory.

If a user does have the Publish Directory names privilege, and they create a conference that they want to be unpublished, they must select the Permissions of the conference and check the Do Not Publish in Directory checkbox.

If you open the permissions on this conference again, and click on the

button on the form, you will be informed that there is no conference with that name.

Note: Once a conference is unpublished, it vanishes from the directory and even the Administrator will not be able to locate that conference using the Admin > List Directory option.

Directory filtering allows the administrator to control what people can see in your FirstClass Directory. When no Directory filtering is used, anyone added to any group can see all the entries in the Directory. If users can't see things, it makes it a lot harder for them to post to them. Filters let us make sure users only see names they are able to post to, or at least be aware of.

We have already seen that you can make conferences unpublished, but you may want to to have published conferences, users or mail lists who are visible to only certain groups of users, and not to others. This is done through directory filtering and group membership.

By default the Directory is unrestricted for all standard groups with the exception of the Unauthenticated Users group. This group cannot see any Directory entries as long as the "Allow unauthenticated Directory access" checkbox is cleared on the Advanced Web & File

You can filter the Directory at the user group level, or at the user level. We recommend setting Directory filters for user groups instead of individual users since this gives you more uniformity in your system and makes it easier to administer. Set Directory filters at the user level for special privileges only.

To set Directory filters at the group level, use the Directory tab on the Group Privileges form.

There are now three fields that allow you to control what parts of the directory users are able to see.

The best way to understand how these fields work is by way of example. On my test system I have created 3 User groups and have called them Alpha Users, Beta Users and Gamma Users.

The 5 accounts have been added to the corresponding groups and when a user chooses the directory, this is what is displayed. All of the users, conferences, calendars and mailing lists on the system are displayed.

This is the most restrictive field. If you enter any group name in this field, then only items that belong to this group will be viewable by this group.

The default for all groups is that this field is left blank, meaning that all Users (including Mailing lists), Conferences and Calendars are displayed which is what we see above with no directory restrictions.

NOTE: This would be the equivalent of entering the following in this field for any group as all directory objects belong to one of these three groups.

Since this field is restrictive, if we add only Alpha Users to to this field on the Alpha Users Group, we would then be allowing Alpha Users only to objects in the directory that belong to that group.

In our example, we have only added our users to the Alpha Users group so when logged in as an Alpha user, the directory only presents the following:

If we want to make the alpha mailing lists, conferences and calendars available in the directory to Alpha users, then we give those corresponding items membership in the Alpha Users group. This means that we can add non users to User Groups solely for directory filtering purposes.

To add a conference or a calendar to a User Group, you can select the permissions of the corresponding container and add the group name in the Belongs To: field.

With this now in place, the Alpha User's directory now looks like this and he can see all items in the Alpha Directory only.

Note: Since the Alpha Group has been set as an OU, if user who belongs to that group has the Publish Directory Names privilege all new conferences and calendars will be automatically added to that group as well and the directory listing will include these new containers for all Alpha Users.

In FirstClass 10, two new fields were added to the Directory Tab on groups. The addition of these fields has made directory filtering even more powerful. These fields allow you to add or remove filters to enhance the one that we have just discussed.

All Users Group is already using the Exclude these Groups: field to deny directory access to all Secret Communities for all users on the system.

What this means is that any container (Conference or Community) that is made a member of this group will never be seen in the directory by anyone including the Admin.

For example, let's assume that you would like to create a special set of conferences, calendars and/or mailing lists that are only available to users who belong to a particular group of users. These containers or mail lists can cross organizational units so in our case, if we have set up similar restrictions as above for the Beta and Gamma users, we would want to allow members of any one of these organizational units to be able to see these items if they belong to a new group.

For discussion purposes then, let's say that we would like to create a set of Training Conferences, calendars and perhaps a mail list that can only be viewed by those who are members of a group called Training Group.

Create a Conferences, Calendars and/or mailing lists that you want your Training group to be able to access in the directory and add these items to the Training Group Item group.

This now denies directory access to any item that is a member of that group and will not be visible in the directory.

Adding items to this field will add to the restrictions set in the Allow this group to view these groups: field

On the Training Group group Directory Tab, add the Training Group Item group to the Include these groups: field

Now, you can add any member of your system to the Training Group group and they should then be able to access any of those items in the directory.

I have added Alpha2 and Beta2 to the this group and have made sure that both the Alpha and Beta groups and their corresponding containers and mail lists have strict OU directory restrictions.

User	Directory View
Alpha 1
Alpha 2
Beta 1
Beta 2