12
Managing Shared Folders

You can create shared folders to provide a discussion medium and an archive for messages relating to a particular topic. Users with access privileges can browse through the history of messages on the topic and post messages into the shared folder. Shared folders have a subscribe property, which can be used to show or hide the folder (and its children) in the hierarchy.

This chapter includes the following topics:

• Configuring the Shared Folder Hierarchy

• Adding a Shared Folder

• Replicating Shared Folders Manually

• Displaying Shared Folder Access Privileges

• Granting Access Privileges

• Revoking Access Privileges

• Shared Folder Class Attributes

Configuring the Shared Folder Hierarchy

Before you can create shared folders, you must set up the folder hierarchy and specify the nodes to which the shared folders must be replicated. You must configure the shared folder hierarchy before creating any shared folders in the system. After this is done, you only need to reconfigure the shared folder hierarchy if you add or change nodes to which you want the shared folders replicated.

Steps for Configuring the Shared Folder Hierarchy

This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.

1. Establish a folder naming convention and determine your shared folder hierarchy.

2. On each node to which you want to replicate the shared folder hierarchy (not the actual content), create a user account to accept the replication information. Even though the shared folder is not an actual person, it must have a user account and a home node specified.

   For example, if you want to replicate shared folders to node A, node B, and node C, create a user account with the name NodeA on node A, and so on. Refer to "Creating an eMail Server User Account" for instructions.

3. Create a distribution list called Public_Folder_Nodes. Add the names of all the user accounts you just created on the nodes to which the shared folder hierarchy is being replicated. (You must use the name Public_Folder_Nodes for this distribution list.)

   For example, if you created accounts NodeA, NodeB, and NodeC, you would add these three names to the distribution list. Refer to "Creating a Public Distribution List" for instructions.

4. Add your shared folders. Refer to "Adding a Shared Folder" for instructions.

5. Grant user privileges to the folders, as needed. Refer to "Granting Access Privileges" for instructions.

Adding a Shared Folder

You can add a shared folder to provide a common place to store messages that more than one person might need to access.

Prerequisites to Adding a Shared Folder

Before adding shared folders, you must configure the folder hierarchy and replication. Refer to "Configuring the Shared Folder Hierarchy" for instructions.

Steps for Adding a Shared Folder

This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.

See Also: "Guidelines for Adding a Shared Folder" for more information about performing this task

In the Administration Tool GUI

1. Start the Administration Tool GUI.

2. In the navigation tree, select Messaging System > Domains > domain_name > Shared Folders.

3. In the toolbar, click (Create).

4. Complete the Add a New Shared Folder dialog box.

   See Also: "Shared Folder Class Attributes" for a complete list of the Public Distribution List attributes and their descriptions

5. Click OK.

In OOMGR

1. Start OOMGR.

2. Enter the following command at the OOMGR prompt:

   IOFCMGR>insert folder name=/<folder_name> daysKept=<days_kept>
   description='<description>' defaultAccess=[open | restricted]
   distList="<distribution_list_from_step2>";
   
   

   This command displays a portion of the available attributes.

   See Also: "Shared Folder Class Attributes" for a complete list of the Public Distribution List attributes and their descriptions

Example:

Assuming that the distribution lists have already been created, to add the folder #ProjectXInfo to a node, enter the following command:

IOFCMGR>insert folder name=/#ProjectXInfo daysKept=60
description='Shared Project X information'
distList="dl_#ProjectXInfo";

Guidelines for Adding a Shared Folder

• The Name and DefaultAccess attributes are required.

• The forward slash key (/) serves as a separator to specify subfolders. For example, /#X/#Y is a public folder named #Y that is a child of the public folder named #X. Make sure that you add the parent folder before adding any child folders.

• Before shared folders can be created from the messaging client, you must create a top or root-level shared folder. This folder defines the replication attributes of the shared folder and specifies, through folder grants, the users who can create subfolders.

• When bootstrapping a new node to the system, replicate the folder hierarchy required on the new node before updating Public_Folder_Nodes to include the new node. This avoids synchronization problems caused when folders are replicated to the new node before it receives its folder hierarchy.

• Before you create shared folders, you should establish a folder naming convention. Use the following suggestions as a guideline for naming your folders:

  Public Folder Account Names	Use "sf_" followed by the node name. For example, the Shared Folder account name for "nodeA" would be "sf_nodeA."
  Distribution List Names	Use "dl_" followed by the Public Folder name. For example, the distribution list for the Public Folder /Humor would be "dl_Humor."
  Folder Names	Shared folders and private folders should not have the same name. If a shared and a private folder with the same name exist, only the private folder can be viewed. To differentiate shared folders from private folders, either prefix the folder name with a special character or append an identifying string to the end of the folder name. For example, if your naming convention is to use the "#" symbol as the identifying public folder prefix, the public folder "East_Coast_Sales" would have the name "#East_Coast_Sales." If your naming convention is to append the string "(public)" as the identifying public folder string, the public folder "East_Coast_Sales" would have the name "East_Coast_Sales_(public)."

Replicating Shared Folders Manually

If you created a shared folder account on each node to which you replicated shared folders and created a public distribution list on the DCN containing the name of each shared folder account, then shared folder replication should happen automatically.

However, on occasion you may need to manually resynchronize folder hierarchies and folder contents.

Steps for Replicating Shared Folders Manually

This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.

In the Administration Tool GUI

1. Start the Administration Tool GUI.

2. In the navigation tree, select Messaging System > Domains > domain_name > Shared Folders > folder_name.

3. In the toolbar, click (Replicate).

4. Complete the Manually Replicate a Shared Folder dialog box.

5. Click OK.

In OOMGR

1. Start OOMGR.

2. Enter the following command at the OOMGR prompt:

   IOFCMGR>replicate to node=<node_name> class=folder object=<object_name>;
   

Example:

This syntax resynchronizes the contents of a folder to a node (dinner) participating in folder replication:

IOFCMGR>replicate to node=dinner class=folder object=/folder1/folder2;

Example:

The following resynchronizes the shared folder hierarchy to a new node participating in folder replication (lunch). In this example, folder replication starts at the root level. The optional object attribute can be used to resynchronize particular subtrees of a shared folder hierarchy.

IOFCMGR>replicate to node=lunch class=tree object=root;
IOFCMGR>replicate to node=lunch class=tree object=/folder1/folder2

Replicate-to-file does not support these classes or the object option.

Displaying Shared Folder Access Privileges

You can display a user's information to check if the user has administrative privileges for a shared folder.

Steps for Displaying Shared Folder Access Privileges

This task can only be performed through the OOMGR command-line interface.

In OOMGR

1. Start OOMGR.

2. Enter the following command at the OOMGR prompt:

   IOFCMGR>check user=<username> item=<folder_name>; 
   

Example:

To check the privileges that the user jdoe has for the /folder1/f2/f3 folder, enter the following command:

IOFCMGR>check user=jdoe item=/folder1/f2/f3

The following results appear:

Privileges   Grantee       Class       Item
----------   -------       ------      -----
----DVMC     jdoe          person      /folder1/f2/f3

l   may list objects in directory browser
s   may address message to object 
s   may save listing of object from directory browser 
a   has administrative privileges over domain 
d   may discover folder hierarchy from client
v   may view folder contents 
m   has moderator privileges on folder
c   may create child folders 

Lower case characters indicate inherited privileges. 
Upper case characters indicate explicit privileges. 

The first line of the results contains the following information:

Column	Description
Privileges	Letters representing each privilege that the user has been granted. These letters are displayed in the order of the privileges list that appears at the end of the results of the check command. This list displays all the possible privileges for both directory entries and shared folders. However, the only privileges that are used for shared folders are the last five: a represents the admin privilege. This gives the user or class permission to perform any administrative operation on the entries in a given domain. d represents the discover privilege. This gives the user permission to view the folder hierarchy. v represents the contents privilege. This gives the user permission to read and post messages in a folder. m represents the moderate privilege. This gives the user permission to create and delete messages in a folder. c represents the child privilege. This gives the user permission to create or delete child folders (subfolders). If the user does not have a particular privilege, there is a dash. Lowercase letters indicate privileges that have been inherited. For example, a user account could inherit privileges from the role to which it belongs. Uppercase letters indicate explicit privileges assigned to the particular user.
Grantee	Name of the user whose privileges are displayed.
Class	Name of the class to which the Grantee belongs. For example, if you are checking user privileges, this class would be person.
Item	Name of the folder for which the user or class has privileges. For example, if you are checking the privileges that the user jdoe has for the /folder1/f2/f3 folder, the item would be /folder1/f2/f3.

Granting Access Privileges

The individual user who sends, forwards, or replies to a message with a post to a shared folder can delete that post from the shared folder. Users can be granted additional access privileges to shared folders.

Steps for Granting Access Privileges

This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.

See Also: "Guidelines for Granting Access Privileges" for more information about performing this task

In the Administration Tool GUI

1. Start the Administration Tool GUI.

2. In the navigation tree, select Messaging System > Domains > domain_name > Shared Folders > folder_name.

3. In the toolbar, click (Grant).

4. Complete the Grant Access Privileges dialog box.

   See Also: "Shared Folder Access Privileges" for a list of the parameters in this dialog box

5. Click OK.

In OOMGR

1. Start OOMGR.

2. Enter the following command at the OOMGR prompt:

   IOFCMGR>grant user=<username> item="<folder_name>" priv=<privilege>;
   

   See Also: "Shared Folder Access Privileges" for a list of parameters available with this command

Example:

To grant admin privileges for the East_Coast_Sales folder to account Fran King with domain information us.corp.hq, enter the following command:

IOFCMGR> grant user=fking.us.corp.hq item="/#East_Coast_Sales" priv=admin;

See Also: "GRANT" for additional variations on the grant command

Guidelines for Granting Access Privileges

• When you grant a privilege, it is added to the other privileges that the user already has. Granting a privilege does not override the privileges that the user already has. For example, if a user has the child privilege, and you grant that user the discover privilege, the user still has the child privilege. If you want to restrict access to certain folders for a user, you should first revoke that user's current privileges and then grant the privileges that you want the user to have.

  See Also: "Revoking Access Privileges" for instructions on how to revoke privileges

• You can grant admin privileges to any eMail Server account. Any account with admin privileges for a shared folder can delete any message from that shared folder.

• When granting admin privileges, keep the following in mind:
  • If you do not fully qualify the eMail Server account name, the current domain information is automatically appended to the account.

  • You can grant admin privileges to an account on another node.

  • The user class is assumed to be a person object.

  • You must specify one user name at a time. You cannot specify a distribution list.

  • By default, everyone can access all public folders. Granting the admin privilege to a user causes the new privilege to mask out the default privileges so that the user no longer has access to the subfolders. To work around this issue, grant the user's admin privileges before creating the subfolders.

Revoking Access Privileges

You can revoke any privileges from a user for a specific folder.

Steps for Revoking Access Privileges

This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.

See Also: "Guidelines for Revoking Access Privileges" for more information about performing this task

In the Administration Tool GUI

1. Start the Administration Tool GUI.

2. In the navigation tree, select Messaging System > Domains > domain_name > Shared Folders > folder_name.

3. In the toolbar, click (Revoke).

4. Complete the Revoke Access Privileges dialog box.

   See Also: "Shared Folder Access Privileges" for more information about the privileges in this dialog box

5. Click OK.

In OOMGR

1. Start OOMGR.

2. Enter the following command at the OOMGR prompt:

   IOFCMGR>revoke priv=<privilege> user=<username> item="<folder_name>";
   

   See Also: "Shared Folder Access Privileges" for more information about the privileges available with this command

Example:

To revoke admin privileges for the Technical_Specifications folder from Ron Gomez, enter the following command:

IOFCMGR>revoke priv=admin user=rgomez item="/#technical specifications";

Guidelines for Revoking Access Privileges

When you grant a privilege, it is added to the other privileges that the user already has. Granting a privilege does not override the privileges that the user already has. For example, if a user has the child privilege, and you grant that user the discover privilege, the user still has the child privilege. If you want to restrict access to certain folders for a user, you should first revoke that user's current privileges and then grant the privileges that you want the user to have.

See Also: "Granting Access Privileges" for instructions on how to grant privileges

Shared Folder Class Attributes

The following Shared Folder class attributes are available:

Attribute	Type (Length Limit)	Description
created	date	Date the folder was created. Read only.
daysKept	number	Number of days a message is kept in the folder before it is automatically deleted.
defaultAccess	character (255)	The initial user access to the folder. Valid values are open or restricted. The default value is open which means that all users on nodes to which the folder is replicated have access to the folder. If this value is set to restricted, then only users assigned privileges by the system administrator can access the folder.
description	character (80)	A description of the folder contents. Although this is an optional attribute, it is a good idea to enter a description for each shared folder you create.
distList	character (80)	Name of the distribution list associated with the folder. This list contains the account names that receive folder messages.
modified	date	Date the folder was last modified. eMail Server changes this date each time a message is added to, or deleted from, the folder. Read only.
name (Required)	character (30)	Name of the folder. This is the key attribute for a folder, and the only required attribute.
numberOfMessages	number	Number of messages in the folder. Read only.
opened	date	Date the folder was last opened. Read only.
size	number	Size of the folder in bytes. Read only.

Shared Folder Access Privileges

You can grant the following privileges:

Privilege	Description
admin	The user has all administrative privileges, including all of those listed in this table, and can change the access list on the folder.
child	The user can create or delete a subfolder (child folder) in this folder.
contents	User can read and post to messages in the folder.
discover	The user may see and open the folder, but may not view the contents.
moderate	The user can create and delete messages in the folder.