Oracle eMail Server Administrator's Guide Release 5.2 A86653-01 |
|
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:
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.
This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.
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.
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.
You can add a shared folder to provide a common place to store messages that more than one person might need to access.
Before adding shared folders, you must configure the folder hierarchy and replication. Refer to "Configuring the Shared Folder Hierarchy" for instructions.
This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.
"Shared Folder Class Attributes" for a complete list of the Public Distribution List attributes and their descriptions
See Also:
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 |
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";
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.
This task can be performed through either the Administration Tool GUI, or the OOMGR command-line interface.
IOFCMGR>replicate to node=<node_name
> class=folder object=<object_name
>;
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;
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.
You can display a user's information to check if the user has administrative privileges for a shared folder.
This task can only be performed through the OOMGR command-line interface.
IOFCMGR>check user=<username
> item=<folder_name
>;
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:
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.
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 |
IOFCMGR>grant user=<username
> item="<folder_name
>" priv=<privilege
>;
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;
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.
admin
privileges to any eMail Server account. Any account with admin
privileges for a shared folder can delete any message from that shared folder.
admin
privileges, keep the following in mind:
admin
privileges to an account on another node.
person
object.
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.
You can revoke any privileges from a user for a specific folder.
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 |
"Shared Folder Access Privileges" for more information about the privileges in this dialog box
See Also:
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 |
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";
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.
The following Shared Folder class attributes are available:
You can grant the following privileges:
|
![]() Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|