Skip Headers
Oracle® Beehive Administrator's Guide
Release 2 (2.0.1.8)

Part Number E16648-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Managing Oracle Beehive Workspaces

Workspaces are the central focus of Oracle Beehive. The great majority of user interactions and collaboration processes take place within the context of the workspace. Every Oracle Beehive user is presented with a personal workspace, and most users will collaborate, share information, and access project resources using team workspaces. This module describes the properties of workspaces, how to create and manage workspaces, and how to manage content stored in workspaces.

This module contains the following topics:

About Workspaces

From an architectural standpoint, workspaces are containers. They fit into a hierarchy of containers in Oracle Beehive referred to as "scope", in which a single enterprise contains organizations and workspaces, with any organization containing organizations and workspaces.

From a user's perspective, however, the workspace is at the top of a different hierarchy. A workspace may contain any number of calendars, folders (containing files or messages), address books, and other entities. Each user has a private "personal workspace", and may also have access to any number of "team workspaces".

Other than users, resources, and groups, all Oracle Beehive objects are stored within either a personal workspace, or a team workspace.

About Personal Workspaces

Every Oracle Beehive user has a single personal workspace, which acts as the container for all exposed Oracle Beehive services. The user's e-mail messages arrive in an Inbox within the personal workspace, the user's personal time management features such as calendar and task list are exposed as objects within the personal workspace, and the user can create folders and upload files to the personal workspace.

The Personal Workspace is the place where end users can see all information that is pertinent to them. E-mails and notifications are delivered to an Inbox, invitations are delivered to a personal calendar, tasks that are assigned to them or that they own are exposed in a task list. In addition, users can create folders to upload files and manage their messages, as well as manage their personal tags.

About Team Workspaces

Team workspaces are workspaces that may be created, managed, and deleted by users, and are designed for multiple users to access them and perform collaborative actions within them. Team workspaces have participants with assigned roles, and may contain shared calendars, files, folders, forums, topics, announcements, tasks, and other objects.

Team Workspaces can be specified as having Public Access, and non-participants will be granted a specific role (by default, Read Only, Read, Comment and Post, and Read, Write, and Delete roles are provided). If Public Access is enabled, the workspace is accessible to non-participants by using a workspace URL.

Commonly Used Commands

The following are commonly-used beectl commands related to managing workspaces:

About Workspace Properties and Controls

Workspaces have a number of required and optional properties that, together, control how they are displayed to users, and what features are enabled within the workspace. They also have a variety of controls and options available for use by the workspace users.

The workspace properties and controls are:

  • Name: A plain text name for the team workspace. Display names of workspaces must be unique within the current scope, and must not duplicate the names of organizations within the enterprise.

  • Description: Optionally, a description of the workspace. By default it will be the same as the display name.

  • Default role for new members: For team workspaces, the default workspace-scoped role is assigned to new members whenever they join or are added to the workspace. A workspace-coordinator or workspace-participant-coordinator can optionally assign a different role when adding a new user.

  • Soft Quota: The soft quota defines a threshold at which a warning is given that quota is being exceeded. This value is set in MB, but may be left open (unbounded).

  • Hard Quota: The hard quota defines a maximum consumption of space by quota-consuming artifacts in the team workspace. In Oracle Beehive, documents and messages are the only quota-consuming artifacts. Once the hard quota is reached, no further quota-consuming artifacts may be added. A hard-quota-exceeded error message will be given whenever an attempt is made to exceed the hard quota. This value is set in MB, and if set, must be equal to or greater than the soft quota, or it may be left open (unbounded). If the hard quota is unbounded, the workspace may consume as much storage as has been allocated to its parent scope (its parent organization or enterprise).

  • Default Sensitivity: The sensitivity that will be applied to artifacts created in the workspace by default. Sensitivities are unassigned (template) Access Control Lists.

  • Members: Users and groups belonging to the workspace. Personal workspaces do not have the members attribute.

  • Trash folder: A default trash folder is always created, and cannot be removed. When items are deleted from the workspace, they go in the trash folder, and can be recovered from the trash folder. Purging the trash folder permanently removes the items from the workspace.

  • Inbox: A default inbox folder is always created. Messages addressed to a team workspace, or for personal workspaces, the user, will arrive in the inbox.

  • Default calendar: A default calendar is always created in personal workspaces (according to the default personal workspace template). In team workspaces, the first calendar that is created becomes the default calendar (but if there are several, a user with the workspace-coordinator role can select which is the default calendar). When the workspace, or for personal workspaces, the user, is invited to calendar events such as meetings, they will be held in the default calendar.

  • Default task list: A default task list is always created in personal workspaces (according to the default personal workspace template). In team workspaces, the first task list that is created becomes the default task list (but if there are several, a user with the workspace-coordinator role can select which is the default task list). Tasks assigned to the workspace, or for personal workspaces, the user, arrive in the default task list.

  • Default Address Book: A default address book (contacts list) is always created in personal workspaces (according to the default personal workspace template). In team workspaces, the first address book that is created becomes the default address book (but if there are several, a user with the workspace-coordinator role can select which is the default address book). Members added to a team workspace (users and groups) are added to the default address book, and members of the workspace can add additional contacts as well.

Address Books

Team workspaces may have one or more address books to manage contacts related to projects and activities within the workspace. The address book uses the workspace membership list as one of its data sources. Address books can contain Enterprise, Extended-enterprise, and External contacts. Addressable groups for workspace-scoped groups are managed by the address book functionality of the User Directory Service. Other contacts can also be created in the workspace contacts list.

See Also:

For more information about Enterprise and Extended-enterprise users, and External contacts, see "About User Accounts"

Messaging

Team workspaces are addressable entities. Messages sent to the workspace address are stored in the workspace inbox, while messages sent to the workspace members group will be sent to each member.

Announcements

Announcements are communications to the entire team, which usually have an expiration date. A user with appropriate privilege (workspace-coordinator) can perform the following operations on a team workspace:

  • Post an announcement.

  • Edit or delete an existing announcement.

All members can view announcements that are posted in the workspace. There is a default folder in team workspaces where all workspace announcements appear. Announcements are a special forum in the team workspace. Each announcement has an optional activation and an expiration date.

Trash

There is always a default trash folder within a workspace. A user with appropriate privileges can delete an item by moving it to the trash folder. Any deleted item will show up in the trash folder before it is explicitly purged.

When an item is moved to the trash folder, bonds between the item and other related items still exist. Traversing bonds will not work while an artifact is in the trash, but if the item is undeleted bonds will remain intact and become traversable. For example, a link or reference to a file in a different workspace stops working if that file is moved to the trash, but will work again if the file is removed from the trash.

The trash folder is read only. Items in the trash may only be read, purged or restored. Explicit access control on an item remains on a deleted item.

Items (documents and messages) in the trash folder count against the workspace quota until they are purged.

About Workspace Events

The workspaces service raises events for the purpose of notifications, triggering policies, and auditing. When you are creating policies or event subscriptions, use the Workspace events.

Table 6-1, "Workspace Related Business Events" shows a list of the business events related to workspaces.

See Also:

For more information about events, see "Managing Oracle Beehive Events and Policies".

Table 6-1 Workspace Related Business Events

Event Comments

ANNOUNCEMENT_CREATED

 

ANNOUNCEMENT_DELETED

 

ANNOUNCEMENT_READ

 

ANNOUNCEMENT_UPDATED

 

ATTACHMENT_CREATED

 

ATTACHMENT_DELETED

 

ATTACHMENT_UPDATED

 

BOND_CREATED

 

BOND_DELETED

 

CATEGORY_CLASS_CREATED

 

CATEGORY_CLASS_DELETED

 

CATEGORY_CLASS_UPDATED

 

CATEGORY_CONFIGURATION_ADDED

 

CATEGORY_CONFIGURATION_REMOVED

 

CATEGORY_CONFIGURATION_UPDATED 

 

CATEGORY_INSTANCE_APPLIED

 

CATEGORY_INSTANCE_REMOVED

 

CATEGORY_INSTANCE_UPDATED

 

DOCUMENT_ARCHIVE

 

DOCUMENT_CHECK_IN

 

DOCUMENT_CHECK_OUT

 

DOCUMENT_COPIED

 

DOCUMENT_COPIED_TO_LATEST_VERSION

 

DOCUMENT_CREATED

 

DOCUMENT_DELETED

 

DOCUMENT_LOAD

 

DOCUMENT_MOVED

 

DOCUMENT_NEW_VERSION_AUTO_CREATED

 

DOCUMENT_PURGE

 

DOCUMENT_SECURITY_CONFIGURATION_ADDED

 

DOCUMENT_SECURITY_CONFIGURATION_REMOVED

 

DOCUMENT_SECURITY_CONFIGURATION_UPDATED

 

DOCUMENT_UNDELETED

 

DOCUMENT_UPDATED

 

ENTERPRISE_CREATED

 

ENTERPRISE_DELETED

 

ENTERPRISE_SECURITY_CONFIGURATION_UPDATED

 

ENTERPRISE_UPDATED

 

ENTERPRISETRASH_PURGED

 

ENTITY_LOCKED

 

ENTITY_UNLOCKED

 

FOLDER_ARCHIVE

 

FOLDER_COPIED

 

FOLDER_CREATED

 

FOLDER_DELETED

 

FOLDER_MOVED

 

FOLDER_PURGE

 

FOLDER_SECURITY_CONFIGURATION_ADDED

 

FOLDER_SECURITY_CONFIGURATION_REMOVED

 

FOLDER_SECURITY_CONFIGURATION_UPDATED

 

FOLDER_UNDELETED

 

FOLDER_UPDATED

 

FOLDER_VERSIONING_CONFIGURATION_ADDED

 

FOLDER_VERSIONING_CONFIGURATION_REMOVED

 

FOLDER_VERSIONING_CONFIGURATION_UPDATED

 
 
 
 

LABEL_CLASS_CREATED

 

LABEL_CLASS_DELETED

 

LABEL_CLASS_UPDATED

 

LABEL_INSTANCE_APPLIED

 

LABEL_INSTANCE_REMOVED

 

LABEL_INSTANCE_UPDATED

 

LINK_CREATED

 

LINK_DELETED

 

LINK_UPDATED

 

ORGANIZATION_CREATED

 

ORGANIZATION_DELETED

 

ORGANIZATION_SECURITY_CONFIGURATION_ADDED

 

ORGANIZATION_SECURITY_CONFIGURATION_REMOVED

 

ORGANIZATION_SECURITY_CONFIGURATION_UPDATED

 

ORGANIZATION_UPDATED

 

WIKIPAGE_CREATED

 

WIKIPAGE_DELETED

 

WIKIPAGE_MOVED

 

WIKIPAGE_UNDELETED

 

WIKIPAGE_UPDATED

 

WORKSPACE_ARCHIVED

 

WORKSPACE_CREATED

 

WORKSPACE_HQUOTA_OVERFLOW

 

WORKSPACE_PURGED

 

WORKSPACE_SECURITY_CONFIGURATION_ADDED

 

WORKSPACE_SECURITY_CONFIGURATION_REMOVED

 

WORKSPACE_SECURITY_CONFIGURATION_UPDATED

 

WORKSPACE_SQUOTA_OVERFLOW

 

WORKSPACE_TRASHFOLDER_EMPTIED

 

WORKSPACE_UPDATED

 

Managing Personal Workspaces

Personal workspaces are created automatically during user account creation, according to a personal workspace template. Oracle Beehive provides a default personal workspace template, but you can modify it or create additional personal workspace templates. For instructions on working with workspace templates, see "Using Workspace Templates".

Personal workspaces are only deleted during user account deletion. Otherwise, they are undeletable.

A user may only have a single personal workspace.

If you create additional, custom personal workspace templates, the user provisioning policy determines which personal workspace template to use when creating a user account. For more information about managing policies, see Chapter 11, "Managing Oracle Beehive Events and Policies." For more information about managing and provisioning users, see Chapter 3, "Managing and Provisioning Oracle Beehive Users."

Personal workspaces can be modified using the Platform Web Services or using beectl. The following items may be modified using the beectl utility:

  • Workspace name

  • Workspace description

  • Hard quota

  • Soft quota

To modify a personal workspace, use the beectl modify_personal_workspace command:

beectl> modify_personal_workspace --workspace <Workspace identifier> --name <Workspace name> --description <Description> --hard_quota <quota> --soft_quota <quota>

Hard and soft quota values are in megabytes (MB). Use 'UNLIMITED' to set an unlimited quota size.

Using Workspace Templates

A Workspace Template is a creation blueprint with well-defined points of variability. A template can be used for capturing best practices and for domain-specific customizations. For example, a Project Workspace Template could specify the blueprint for creating workspaces that are suitable for collaboration among members of teams responsible for managing a project.

An Oracle Beehive template specifies the values of attributes that are common across template instantiations, as well as the attributes whose values can differ from one instantiation to another (called 'points of variability'). It also specifies the dependencies between attribute values.

This section contains the following topics:

About Workspace Templates

All workspaces are always created using a template. Personal workspaces are always created using a personal workspace template, and team workspaces are always created using a team workspace template.

Templates are stored in an XML format. To review the workspace template XML format, see Module 1, "Group, Policy, and Workspace Templates" in Oracle Beehive Administrator's Reference Guide.

Oracle Beehive comes with four pre-defined workspace templates. You can list them by using the beectl list_workspace_templates command:

beectl list_workspace_templates --scope <your enterprise identifier>

This produces output similar to the following:

----------------------------------------+---------------------------------------
Name                                    | Identifier                            
----------------------------------------+---------------------------------------
Basic Personal Workspace Template       | wstp=Basic Personal Workspace Template
                                        | ,enpr=yourcompany                     
----------------------------------------+---------------------------------------
Basic Team Workspace Template           | wstp=Basic Team Workspace Template,enp
                                        | r=yourcompany                         
----------------------------------------+---------------------------------------
Community of Practice Workspace Templat | wstp=Community of Practice Workspace T
e                                       | emplate,enpr=yourcompany              
----------------------------------------+---------------------------------------
Project Workspace Template              | wstp=Project Workspace Template,enpr=y
                                        | ourcompany                            
----------------------------------------+---------------------------------------
4 Record(s) displayed.

The four workspace templates are:

  • Basic Personal Workspace Template

    The personal workspace template is designed for personal workspaces, which are used solely by individual users to view and manage all of their content and collaborative activities in one primary location, including those that fall outside the scope of their team workspaces.

    By default, workspaces that are based on the Personal workspace are not listed in the system's public workspace directory. Also, although a user may not join another user's personal workspace, users can grant view-only access to each other's personal workspaces.

  • Basic Team Workspace Template

    The Basic Team Workspace Template contains a wiki home page that members can edit to add information about the workspace, and some tasks to guide workspace coordinators as they configure the workspace. It also contains a calendar, discussion forum, and folder for sharing documents.

  • Community of Practice Workspace Template

    The Community of Practice Template contains a FAQ template and wiki home page that members can edit to add information about this community, some tasks to guide workspace coordinators as they configure the workspace, and a wiki page, discussion forum, and folder to share best practices with other community members.

  • Project Workspace Template

    The Project Workspace Template contains a set of tasks that can be used to get started with a project, and some wiki pages that can be used to create a business case, project plan, project completion analysis, and meeting agenda. It also contains a calendar, discussion forum, and folder for sharing documents.

Workspace Template Contents

A workspace template contains specification for workspace attributes, workspace members and entities contained in the workspace. It contains the following main items:

  • Template Attributes

    In addition to the attributes that apply to all templates, a workspace template may also have the Domain attribute. The target domain of a workspace template is the line of business (such as life sciences, CRM, and so on) in which the template is intended to be used.

  • Workspace Attributes

    A workspace template can include the specification of values for one or more workspace attributes (such as name, description, and so on).

  • Membership Information

    A workspace template can specify members for the new workspace. For example, a workspace template can specify that the group PROJECT_MANAGERS should be a member of all workspaces created from the template.

  • Roles

    A team workspace template can specify roles that can be granted to workspace members in the scope of the workspace. These roles specify privileges and access types that are granted (or denied) to an actor in the scope of the workspace.

  • Labels

    A personal workspace template can specify one or more labels to be created for the owner of the personal workspace. For example, the default personal workspace template shipped with Oracle Beehive specifies the following two labels: Personal and Business.

  • Folder templates

    A workspace template can include templates for the following types of folders:

    • Heterogeneous real folder (a folder for documents and messages)

    • Specialized real folder (such as a Calendar, Task List or Address Book)

    A folder template, in turn, can include templates for sub-folders. A folder template can also include templates for entities to be created in the folder. For example, a folder template can include templates for labels, policies, documents, meetings, tasks, or messages.

  • Document templates

    A document template may optionally specify the body of the document. The body of a document is specified by reference:. a complete path name of an existing document is specified, and the content of this document is copied into the workspace at the time of template instantiation

  • Meeting (occurrence) templates

    A meeting template specifies values for one or more attributes of an occurrence. Values of temporal attributes (such as start time) can be specified either using template variables or as offsets from workspace creation time. Meeting attendees can also be specified in the template. A meeting attendee could be any user or group in the system. In addition to ordinary meetings, templates for repeating meetings (occurrence series) can also be included in a workspace template.

  • Task templates

    A task template specifies values for one or more attributes of a task. Values of temporal attributes (such as start time) can be specified either using user-defined template variables or as offsets from workspace creation time. Task assignees can also be specified in the template. A task assignee could be any user or group in the system.

  • Discussion forum templates

    A discussion forum template specifies values for one or more attributes of a discussion forum. It can also include specifications for sub-forums, discussion topics and announcements.

  • Address Book templates

    An address book template can include templates for one or more contacts

Using Expressions in Workspace Templates

Both Meeting and Task workspace templates allow you to specify multiple meetings or tasks. Oracle Beehive 1.3 and later includes a feature (the temporalExpression element) that allows you to use an expression to specify the time for an attribute (such as start time) for these meetings and tasks. Meetings or tasks can be specified relative to the set value, using a numerical expression.

For example, a consulting workgroup might routinely use a standardized set of tasks on each consulting engagement. A workspace administrator uses a custom consulting template to create a team workspace for the project. Within the template, an initial task is specified to kick-off the consulting project, and then additional, specific tasks follow on at various time intervals; a planning task that should be completed two days after the initial task, a milestone task that should be completed one week after the initial task, and so on.

You can set the start time variable for the first task. Then, using expressions, you can specify that the second task have an offset of 48 hours (two days), and the third task have an offset of 168 hours (seven days), and so on. Expressions can use the PLUS, MINUS, or PRODUCT arithmetic operators, and may use any template variable. You can establish a specific time value in a variable, and then specify offsets using the expressions. In this manner, expressions allow you to pre-set a complex arrangement of tasks and meetings in the workspace template, rather than having to re-create them by hand each time you create a new workspace.

For more details about using variables in workspace templates, see "Template Variables" in Oracle Beehive Administrator's Reference Guide.

For more details about using the expressions in workspace templates, see "Expressions" in Oracle Beehive Administrator's Reference Guide.

Modifying Workspace Templates

To modify a workspace template, first, download the workspace template to an XML file using the beectl list_workspace_templates command with the --file option:

beectl> list_workspace_templates --scope <Identifier of enterprise or organization>
--name <Workspace template name> --file <Full path of the output file>

Note:

For the --name option, you do not need to provide the workspace template's ID: just the name. Enclose names with spaces in double quotation marks.

The workspace template you specify will be downloaded to the file location and name you specify with the --file option.

Then, edit the file, and use the beectl modify_workspace_template command to upload your changes:

beectl> modify_workspace_template --template <Workspace template identifier> --file <Full path of the input file> --name <Workspace template name>

Creating a New Workspace Template

You can create a new workspace template, by writing an XML-formatted file defining the template. For complete documentation on workspace template formatting, see Module 1, "Policy and Workspace Templates Reference" in Oracle Beehive Administrator's Reference Guide.

Then, use the beectl add_workspace_template command to upload the file, creating the new workspace template:

beectl> add_workspace_template --scope <Identifier of enterprise or organization> --file <Full path of the input file> --name <Workspace template name>

If you create a workspace template at a scope other than Enterprise scope, it will only be available for creating workspaces at that scope. Using this technique, you could create different default workspace templates for members of different organizations.

Deleting a Workspace Template

You can delete a workspace template using the beectl delete_workspace_template command:

beectl> delete_workspace_template --template <Workspace template identifier>

Note:

You should not delete the default workspace templates. You should not delete a workspace template that is used by a policy, because it could render that policy invalid in some cases.

Creating and Managing Team Workspaces

Although Oracle Beehive users can create team workspaces, you can also create and manage team workspaces from the command line.

This section contains the following topics:

Creating Team Workspaces

There are four main ways to create new team workspaces:

  • Using the Team Collaboration Web client

  • Using developer tools exposed through the Beehive Development Kit

  • Using a client which supports workspace creation, such as Oracle Beehive Extensions for Outlook (OBEO) or Oracle Beehive Extensions for Explorer (OBEE)

  • Using the beectl command-line tool

If the Team Collaboration Web client is used, the user selects a scope to create the workspace in and which template to use. If OBEO or OBEE is used, the workspace is created in the same enterprise or organization scope as the creator's personal workspace, and the default template is used.

You can create a team workspace from the command-line. Optionally, you may create an XML-formatted file which defines one or more users as members of the workspace, and assigns those users with appropriate roles. You can then upload the XML file by designating it with the --file option during creation.

Create a new team workspace by using the beectl add_team_workspace command:

beectl> add_team_workspace --scope <Identifier of enterprise or organization> --template <Workspace template identifier> --name <Workspace name> --file <Full path of the input file>

A workspace always uses a template during creation. If you do not designate a template, the default workspace template for the given scope will be used.

Example 6-1, "Adding Members to a Team Workspace During Creation" shows the formatting of the XML file you may optionally upload when creating a workspace. In this example, two users are added to a workspace, and each user is given a role. In Oracle Beehive Release 1 version 1.2 or earlier, you must specify participants and roles using the <cen> element and full CollabIDs.

Example 6-1 Adding Members to a Team Workspace During Creation

<teamWorkspaceTemplate xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
    xmlns='http://xmlns.oracle.com/beehive/transportabletemplate'
    xsi:schemaLocation='http://xmlns.oracle.com/beehive/transportabletemplate http://xmlns.oracle.com/beehive/transportabletemplate.xsd'>
    
    <templateAttributes> 
    </templateAttributes> 
    <body> 
        <!-- Add users -->
        <participant>
            <identity type='USER'>
                <cen>0038:6B48:user:36C1F8C16EC34206A5021B92DDC97279000000000000</cen>
            </identity>
            <role>
               <cen>0038:6B48:acrd:8B1514BAD5FC427E9AE42FB3A88664D200000000001A</cen>
            </role>
        </participant>
         <participant>
            <identity type='USER'>
                <cen>0038:6B48:user:36C1F8C16EC34206A5021B92DDC9727900000000001B</cen>
            </identity>
            <role>
               <cen>0038:6B48:acrd:8B1514BAD5FC427E9AE42FB3A88664D200000000001A</cen>
            </role>
        </participant>
</body> 
</teamWorkspaceTemplate>

In Oracle Beehive Release 1 version 1.3 or later, and Release 2, you can alternatively specify participants and roles using the shorter BODN identifiers:

<participant>
      <identity type="USER">
         <bodn>user=example_user1</bodn>
      </identity>
      <role>
         <bodn>acrd=test_role1,orgn=example_organization1,enpr=example.com</bodn>
      </role>
</participant>

Once you have created a team workspace, you can use the command-line to modify it, as described in "Modifying Team Workspaces".

Viewing Team Workspaces

You can view the attributes and properties of a team workspace, by using the beectl list_workspaces command:

beectl list_workspaces --scope <Identifier of enterprise or organization> --type<p|t|a> --name <Workspace name>

Provide a value for the --name option to show details of a specific workspace. Example 6-2, "Example Team Workspace" is an example of the output from such a command.

Example 6-2 Example Team Workspace

Workspace name:                         my_team_workspace
Description:                            my_team_workspace
Workspace type:                         TEAM
Identifier:                             wksp=wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Hard quota in kilo-bytes (KB):          Unlimited quota
Soft quota in kilo-bytes (KB):          Unlimited quota
Workspace parent:                       orgn=human_resources,enpr=mycompany
Workspace path:                         /MYCOMPANY/HUMAN_RESOURCES/MY_TEAM_WORKSPACE
Default sensitivity:                    acsn=Normal,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      adbk=Contacts,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      fldr=Announcements,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      fldr=INBOX,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      fldr=Documents,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      fldr=Public Documents,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      clnd=Calendar,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      fldr=Workspace Trash,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Folder identifier:                      fldr=Tasks,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany
Workspace template identifier:          16C3:57F2:ttws:37D536448BC43F3DE040578C211A3EA80000000001D6
Is directory listed?:                   false
Default role definition:                acrd=workspace-member,enpr=mycompany
Participation mode:                     INVITE_ONLY
Workspace participant:                  user=jsmith    Assigned role:                      acar=workspace-coordinator,wksp=my_team_workspace,orgn=human_resources,enpr=mycompany

In this example, a workspace named "my_team_workspace" has been created using the default team workspace template. The workspace was created within the "human_resources" organization of the enterprise called "mycompany". No quota or hard quota has been set. A user has been added, with the login ID of "jsmith", and granted the role of workspace-coordinator.

You can also use Oracle Beekeeper to view a list of team workspaces in the system and launch to the Team Collaboration client to take actions on behalf in the workspace. You must have the 'read all' privilege in order to properly load the workspace.

See Also:

Oracle Beekeeper Online Help

Modifying Team Workspaces

Once a team workspace is created, you can modify it from the command-line to add or remove users, change its e-mail address, change its participation mode, and to modify the quota. You can make many other modifications to a workspace using the Team Collaboration Web client, OBEO, OBEE, and the Platform Web Services.

For information about adding and removing members, see "Managing Team Workspace Membership".

To change the e-mail address of a team workspace from the command line, use the beectl modify_team_workspace command with the --email_address option:

beectl> modify_team_workspace --workspace <Workspace identifier> --email_address <Team workspace email address>

To change the participation mode of a team workspace from the command line, use the beectl modify_team_workspace command with the --participation_mode option:

beectl> modify_team_workspace --workspace <Workspace identifier> --participation_mode <Team workspace participation mode>

You can use any of the following values: INVITE_ONLY, OPEN, or APPROVE_REQUIRED

To modify the quota of a team workspace from the command line, use the beectl modify_team_workspace command with the --soft_quota or --hard_quota options:

beectl> modify_team_workspace --workspace <Workspace identifier> --hard_quota <new quota in MB> --soft_quota <new quota in MB>

To modify whether a team workspace is directory-listed from the command line, use the beectl modify_team_workspace command with the --directory_listed option:

beectl> modify_team_workspace --workspace <Workspace identifier> --directory_listed <TRUE|FALSE>

Deleting Team Workspaces

You can delete a team workspace by using the beectl delete_workspace command:

beectl> delete_workspace --workspace <Workspace identifier> [--purge]

When you delete a team workspace, all artifacts stored in that workspace are also deleted. Use the --purge option to delete artifacts manually.

Beginning with Oracle Beehive 2.0, an asynchronous delete flow for team workspaces has been introduced. After a user chooses to delete a workspace, it is taken 'offline' and will asynchronously be purged in the background. Depending on your business and system resource requirements, you may need to manage deleted, offline (not yet purged) workspaces. The following beectl commands are now available to assist you with listing deleted workspaces and manually purging deleted workspaces:

  • list_deleted_workspaces: This command returns a list of deleted workspaces that are not yet purged in the system

  • delete_workspace --purge: This command manually purges a deleted workspace synchronously. This command can also purge a visible workspace.

Managing Categories

Note:

Categories are not exposed in the Oracle Beehive Team Collaboration Web client, OBEE, or OBEO. However, you can use categories with custom clients you build using the Oracle Beehive Development Kit (BDK). This section describes category capabilities you can use in your custom clients.

Categories are a hierarchical structure of designations that may be applied to entities, including all of the artifacts stored in a workspace. Categories always exist at the enterprise scope.

You can determine default categories available in a workspace during workspace creation: either from the workspace template, or, directly by specifying them in the XML file provided when you create the workspace.

In addition, you can create and delete categories, and you can apply and remove them from objects in workspaces. You create a category by uploading an XML formatted category definition file.

To create a new category, use the beectl add_category command:

beectl> add_category --file <path to the category XML file>

Example 6-3 shows an XML file for adding a simple category to an enterprise.

Example 6-3 Example Category XML File

<?xml version = '1.0' encoding = 'UTF-8'?>
<!-- Sample Template to add a Category -->
<CategoryDefinition xmlns="http://xmlns.oracle.com/beehive/category">
   <name>TTTesCat1->1179090518828</name>
</CategoryDefinition>

Example 6-4 shows an XML file for adding a category with attributes. An attribute has a default value, and can also have allowed alternate values.

Example 6-4 Example Category with Attributes XML File

<?xml version = '1.0' encoding = 'UTF-8'?>
<!-- Sample Template to Create a Category with Attributes -->
<CategoryDefinition xmlns="http://xmlns.oracle.com/beehive/category">
   <name>Test Category16</name>
   <description>Test Category-Desc</description>
   <abstract>T</abstract>
   <defaultTemplate>
      <copyOnVersion>T</copyOnVersion>
      <mandatory>F</mandatory>
      <finalInd>F</finalInd>
      <attributeTemplates>
         <attributeTemplate>
            <attributeDef>
               <name>AdefX1-1</name>
               <propertyType>STRING</propertyType>
            </attributeDef>
            <mandatory>F</mandatory>
            <prompted>T</prompted>
            <finalized>F</finalized>
            <forceDefault>F</forceDefault>
         </attributeTemplate>
         <attributeTemplate>
            <attributeDef>
               <name>AdefX2-1</name>
               <propertyType>STRING</propertyType>
            </attributeDef>
            <mandatory>T</mandatory>
            <finalized>F</finalized>
            <forceDefault>T</forceDefault>
            <allowedValues>
              <allowedVal>
                 <name>AL2</name>
                 <description>Desc-AL2</description>
                 <value>TestVal2</value>
              </allowedVal>
            </allowedValues>
            <defaultValue>
              <value>
                TestVal2
              </value>
            </defaultValue>
         </attributeTemplate>
      </attributeTemplates>
   </defaultTemplate>
  <attributes>
      <attribute>
         <name>AdefX1-1</name>
         <description>TestAdef1</description>
         <propertyType>STRING</propertyType>
         <searchable>T</searchable>
         <defaultValue>
           <value>
             TestVal1-Def
           </value>
         </defaultValue>
      </attribute>
      <attribute>
         <name>AdefX2-1</name>
         <description>TestAdef2</description>
         <propertyType>STRING</propertyType>
         <searchable>F</searchable>
         <defaultValue>
           <value>
             TestVal2
           </value>
         </defaultValue>
         <allowedValues>
              <allowedVal>
                 <name>AL1</name>
                 <description>Desc-AL1</description>
                 <value>11</value>
              </allowedVal>
              <allowedVal>
                 <name>AL2</name>
                 <description>Desc-AL2</description>
                 <value>TestVal2</value>
              </allowedVal>
            </allowedValues>
      </attribute>
   </attributes>
</CategoryDefinition>

To delete a category, use the beectl delete_category command:

beectl> delete_category --category <Identifier of the category to be deleted>

Note:

When you delete a category, all applications of that category are automatically removed.

To apply a category to an entity in a workspace, use the beectl add_category_application command:

beectl> add_category_application --category <Identifier of the category to be applied> -- entity <Identifier of the entity to which the category needs to be applied>

To remove a category from an entity in a workspace, use the beectl delete_category_application command:

beectl> delete_category_application --category <Identifier of the category to be removed> --entity <Identifier of the entity from which the category needs to be removed>

Managing Team Workspace Membership

You can add members to a team workspace during creation by formatting an XML file for upload. In the file, you specify any number of users (and groups) to be members of the team workspace. You can also specify roles for the users. At least one user of any team workspace should have the workspace-coordinator role.

To view a list of all of the available roles, use the beectl list_role_definitions command:

beectl> list_role_definitions

For a list of team workspace-related roles, see Table 6-2, "Summary of Default Team Workspace Roles".

Example 6-5, "Sample Team Workspace Adding Members XML File" is an example file, showing two members to be added to a workspace; each member is granted a role, by pasting in the CollabID of a role in the <cen> element.

Example 6-5 Sample Team Workspace Adding Members XML File

<teamWorkspaceTemplate xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
    xmlns='http://xmlns.oracle.com/beehive/transportabletemplate'
    xsi:schemaLocation='http://xmlns.oracle.com/beehive/transportabletemplate http://xmlns.oracle.com/beehive/transportabletemplate.xsd'>
    
    <templateAttributes> 
    </templateAttributes> 
    <body> 
        <participant>
            <identity type='USER'>
                <cen>0038:6B48:user:36C1F8C16EC34206A5021B92DDC97279000000000000</cen>
            </identity>
            <role>
               <cen>0038:6B48:acrd:8B1514BAD5FC427E9AE42FB3A88664D200000000001A</cen>
            </role>
        </participant>
         <participant>
            <identity type='USER'>
                <cen>0038:6B48:user:36C1F8C16EC34206A5021B92DDC9727900000000001B</cen>
            </identity>
            <role>
               <cen>0038:6B48:acrd:8B1514BAD5FC427E9AE42FB3A88664D200000000001A</cen>
            </role>
        </participant>
</body> 
</teamWorkspaceTemplate>

You can add, modify, and remove members from an existing workspace, by using the beectl modify_team_workspace command. You will need the unique workspace identifier as well as the unique IDs of any users you will add, modify or remove from the workspace. In this context, modifying the user only means modifying a user's role; you do not actually modify user accounts when managing team workspaces.

To add a user (or a group):

beectl> modify_team_workspace --workspace <workspace identifier> --add_participant <user or group identifier> --role <workspace role>

For example:

beectl> modify_team_workspace --workspace wksp=our_project,orgn=human_resources,enpr=mycompany --add_participant user=jsmith --role acrd=workspace-coordinator,enpr=mycompany

In this example, a user with the ID of "jsmith" is added to a team workspace called "our_project", which is in the organization called "human_resources", and granted the role of workspace-coordinator.

To remove a user (or a group):

beectl> modify_team_workspace --workspace <workspace identifier> --remove_participant <user ID>

Managing Team Workspace Access Control

In addition to explicit access control (using Access Control Entities to explicitly allow or disallow levels of access on objects), there are two methods for general control of access to entities in workspaces: roles, and sensitivities.

You can also manage the visibility of workspaces (and the content within them) to users in the enterprise who are not already members of the workspace.

This section contains the following topics:

See Also:

For complete instructions on managing access control, see Chapter 13, "Managing Oracle Beehive Access Control."

Enabling Public Access to Team Workspaces

You can specify a team workspaces as having 'Public Access'. Non-participants will then be granted a specific role (by default, the 'Read Only', 'Read, Comment and Post', and 'Read, Write, Delete' roles are available). If Public Access is enabled, the workspace will be accessible to non-participants through a workspace URL.

Non-participants will not see the workspace listed anywhere; they will require the URL to access the workspace.

Managing Team Workspace Roles

Within team workspaces, roles are used to define levels of control which workspace members may exercise over the workspace and its content.

Users with sufficient administrative privileges can perform the following administrative operations on a team workspace:

  • Make a user or a group member of the workspace. When a group is added as a member of a workspace, the group membership is honored dynamically. This means any new member of the group automatically becomes a member of the workspace (via the group).

  • Remove an existing member. When removing a member, option exists whether to revoke all the permissions that have been granted to the user for this workspace

  • Change the roles/permissions of a member

  • Invite the contacts, including enterprise users and extended-enterprise users, to become members

  • Remove himself or herself from the workspace

Users can perform the following read operations on a team workspace:

  • View the members of a workspace

  • Retrieve the workspace membership information of a specific user or group

Table 6-2, "Summary of Default Team Workspace Roles" shows the roles and granted privileges related to team workspaces.

Table 6-2 Summary of Default Team Workspace Roles

Role Granted Privileges Granted Access Types

workspace-coordinator

[ADDRESS_BOOK_MGR, CALENDAR_MGR, CONF_MGR, CONTENT_MGR, EMAIL_MGR, FORUM_MGR, IM_MGR, MARKER_MGR, MODIFY_ACL, NOTIFICATION_MGR, POLICY_MGR, PREFERENCE_MGR, READALL, ROLE_MGR, SECURITY, SUBSCRIPTION_MGR, USER_MGR, VERSION_MGR, WORKSPACE_MGR

discover, read, write, execute, delete

workspace-participant-coordinator

MODIFY_ACL, ROLE_MGR, USER_MGR

read, discover

workspace-document-coordinator

CONTENT_MGR, FORUM_MGR, MARKER_MGR, MODIFY_ACL, VERSION_MGR

discover, read, write, execute, delete

workspace-viewer

none

discover, read

workspace-member

none

discover, read, write, execute, delete

workspace-commenter

FORUM_WRITER

discover, read


The workspace-participant-coordinator role grants the ROLE_MGR privilege, which allows the creation and management of custom roles, within the scope of the workspace. In addition, ROLE_MGR allows the user to grant and revoke workspace-scoped custom roles to and from other users in the workspace.

In addition to the workspace roles, there are application-level roles which grant privileges over all workspaces. These roles are summarized in Table 6-3, "Summary of Default Application-Level Roles".

Table 6-3 Summary of Default Application-Level Roles

Role Granted Privileges Granted Access Types

enterprise-administrator

ARCHIVE_MGR, EXCEED_QUOTA, MARKER_MGR, ORGANIZATION_MGR, PREFERENCE_MGR, QUOTA_MGR, ROLE_MGR, USER_MGR, VERSION_MGR, WORKSPACE_MGR

discover, read, write, execute, delete

enterprise-system

BYPASS

discover, read, write, execute, delete


Creating Team Workspace Roles

When a participant is added to a workspace, they are assigned one or more roles. Roles are based on a Role Definition object. You can be create new role definitions at the enterprise, organization or workspace levels of scope. If you later change the name of a role definition, that change is reflected anywhere the custom role has been assigned.

Beginning with Oracle Beehive Release 2, a new role definition is provided: workspace-commenter (a user who has read, comment and post capabilities). In the following procedure, the creation of this role is used as a model to show how to create new roles using beectl.

To create a new role, perform the following steps:

  1. Add a new role definition using the beectl add_role_definition command. For example:

    beectl> add_role_definition --scope <enterprise identifier> --name workspace-commenter --privilege FORUM_WRITER --access_types OR --always_enabled true
    

    In this example, the FORUM_WRITER privilege allows the assignee to create posts in forums in the scope in which they are assigned the role (typically, a workspace). The assignee is also granted access types O (discover) and R (read) for all entities within the scope they are granted the role.

  2. Create an access control entity using the beectl add_local_ace command. For example:

    beectl> add_local_ace --entity <new role identifier> --accessor agrp=ALL_USERS --access_types R
    

    This step allows ALL_USERS access to Read the role, and therefore be able to the new role's existence.

  3. Get the category identifier of the WorkspaceParticipantRoleDefinitionCategory by using the beectl list_categories command:

    beectl> list_categories
    

    Make a note of the identifier for use in the next step.

  4. Apply the category to the new role using the beectl add_category_application command. For example:

    beectl> add_category_application --category <WorkspaceParticipantRoleDefinitionCategory Identifier> --entity <new role identifier>
    

    Once this category is assigned, clients like the Team Collaboration web client, OBEO, and OBEE will display it. (The clients know to ask the system only for all roles with this category assigned to it.) This step is required to avoid displaying inappropriate roles (such as enterprise-quota-administrator) at the Workspace scope.

Managing Team Workspace Sensitivities

Sensitivities are unassigned access control lists, packaged and given a name. Users with appropriate privileges may assign sensitivities to entities under their control. This allows users to manage access control over entities without needing to learn about or understand how access control works in detail.

The default personal workspace creates two sensitivities: public and private.

You can define sensitivities during workspace creation, by specifying them in the workspace template.

For detailed information about creating and managing sensitivities, see "Creating and Managing Sensitivities" in Chapter 13, "Managing Oracle Beehive Access Control."

Managing Files

Workspace users can create heterogeneous folders (entity real folders) and sub folders within any workspace to manage artifacts, including "library content" (documents, URLs, notes, and links), topics and messages (e-mails, discussions, voice mail messages, fax messages), IM chat logs, calendar events, tasks, and contacts.

Some of these folders can contain artifacts that may be stored in external file system directories, or accessed over FTP and WebDAV protocols.

This section contains the following topics:

Managing File System Directories

In Oracle Beehive, by default all user content is stored in the database. However, you may elect to store some content in file system directories. A file stored in a file system directory is treated as read-only by Oracle Beehive.

Whenever a user or process performs a read action on the file, the file is read from the file system directory.

At any time, if changes are made to the file in Oracle Beehive, such as if a user modifies the file content, the file is imported from the file system directory into the Oracle Beehive database. The unchanged, original file remains in the file system directory, but Oracle Beehive stores the new file in the database, and will continue to make use of only the database copy of the file.

Note:

This functionality allows you to expose your existing documents and files to Oracle Beehive users without having to perform a batch-import of all files to the Oracle Beehive database. Instead, map your files using the file system reference commands, and individual files will be automatically imported only as needed.

You can use the following beectl commands to manage file system directories and files:

  • add_filesystem_reference: Creates a reference in Oracle Beehive to a directory on the file system

  • delete_filesystem_reference: Removes a file system reference from Oracle Beehive

  • import_documents: Imports documents into Oracle Beehive from files on the server without copying the file content. Data on the server files will be treated as read-only; should an imported document be edited in Oracle Beehive, a copy of the content will be made at that time.

    Caution:

    Before importing documents to a workspace using the import_documents command, you should consider the effects of any existing policies on that workspace. A policy that is triggered on any new document created or added in a workspace could be triggered repeatedly as multiple files are imported.
  • list_filesystem_references: Lists the file system path, read-only status, and identifier (CollabID) of all available file system references.

Using File System Directories with Multiple Oracle Beehive Servers

For high availability deployments with a shared file system (or that leverage the filesystem_reference object within workspaces), all computers on which Oracle Beehive Application Tier instances and Oracle Database instances reside should have access to the file system reference paths at the same logical location. This shared access may be accomplished using a Network File System (NFS) server, symbolic links (symlinks), or another supported method. Typically, organizations will experience optimal performance if their file systems reside on computers other than those on which Oracle Beehive and Oracle Database reside.

The following two requirements detail the necessary access for file system references to function properly:

  • The BEECORE OC4J component executing the beectl import_documents command must have file system access to the specified server path.

  • The computer hosting the Oracle Beehive database must have local file-system access to the specified server path. SQL requires a local file-system path when creating a BFILE.

Creating and Using File System References

To map existing files to Oracle Beehive, perform the following steps:

  1. Use the beectl add_filesystem_reference command to map an existing server path for Oracle Beehive:

    beectl> add_filesystem_reference --name <Filesystem reference name> --filesystem_path <Server path> --read_only <true or false>
    

    Note:

    If you set the --read_only flag to true, Oracle Beehive will treat the file objects as read-only internally, meaning, users will not be allowed to modify them. If you set it to false, users will be allowed to modify the files, which will trigger the file importation into the Oracle Beehive database.

    Under no conditions will files on the file system be modified by Oracle Beehive.

  2. Use the beectl import_documents command to create individual references to all of the documents within Oracle Beehive:

    beectl> import_documents --filesystem_reference_id <CollabId of the filesystem reference> --folder_path <Folder path> [--name_filter <name filter>] [--conflict_res_mode <ABORT|OVERWRITE|CREATE_UNIQUE>]
    

    Caution:

    Before importing documents to a workspace using the import_documents command, you should consider the effects of any existing policies on that workspace. A policy that is triggered on any new document created or added in a workspace could be triggered repeatedly as multiple files are imported.

    The --folder_path specifies the folder path within Oracle Beehive to import the files. For example, you could specify a folder within a specific workspace.

    The --name_filter option allows you to specify only a subset of the files in the file system directory to be imported. For example, you could specify the filter %.doc to only import files with the .doc extension.

    the --conflict_res_mode determines how Oracle Beehive should treat files to be imported from the file system directory, when a file already exists in the target Oracle Beehive directory with the same name. You may choose to skip such files with the ABORT option, overwrite them, or create a new, unique file name for the file automatically.

You can also manage existing file system directories by listing them and deleting them.

To list all file system directories currently mapped in Oracle Beehive, use the beectl list_filesystem_references command:

beectl> list_filesystem_references

To delete a file system reference, use the beectl delete_filesystem_reference command:

beectl> delete_filesystem_reference --filesystem_reference_id <CollabID>

When you delete a file system reference, any files currently linked-to that have not been imported into the Oracle Beehive database become unavailable. Files already imported into the Oracle Beehive database remain available and are treated as normal files.

Managing FTP and WebDAV Access to Files

Content stored in workspaces may be made available to users over FTP and WebDAV protocols. FTP access is controlled by the FTP Service, and WebDAV access is controlled by the WebDAV service. When these protocols are enabled, users with supported clients can authenticate with Oracle Beehive, and then access files stored in any workspace with which they have sufficient privileges. In all respects, access via FTP and WebDAV is treated the same as access from any other user client; explicit and implicit access control is respected. User actions over these protocols are restricted to uploading, moving, and downloading files, and creating, moving, and deleting folders. Users cannot apply or change sensitivities or categories on files through these protocols.

For information about how to configure and enable FTP and WebDAV, see "Managing Oracle Beehive Services".

Managing Records Management

Records Management is an optional service, which is enabled by installing and configuring Oracle Beehive with Oracle Universal Record Manager (URM). URM provides lifecycle and disposition management of records managed Oracle Beehive artifacts. Once URM is installed and configured with Oracle Beehive, you can start the Records Management Service, and begin filing records for documents and e-mails.

Records Management documentation can now be found in Chapter 7, "Integrating Oracle Universal Records Management (Oracle URM) with Oracle Beehive" in the Oracle Beehive Integration Guide.

Example Workspace Template Contents

Example 6-6, "Example Workspace Template XML File" shows an example workspace template XML file (in this case, the Community of Practice Workspace template):

Example 6-6 Example Workspace Template XML File

<teamWorkspaceTemplate
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://xmlns.oracle.com/beehive/transportabletemplate"
 xsi:schemaLocation="http://xmlns.oracle.com/beehive/transportabletemplate http://xmlns.oracle.com/beehive/transportabletemplate.xsd">
<templateAttributes>
<author>Oracle</author>
<authorCreationTime>Oct, 2009</authorCreationTime>
<contactInfo>Oracle Corporation</contactInfo>
<copyrightInfo>Copyright (c) 2009, Oracle Corporation. All rights reserved.</copyrightInfo>
<description>This community of practice template contains an FAQ template and wiki home page that members can edit to add information about this community, some tasks to guide the coordinators as they configure the workspace, and a wiki page, forum and folder to share best practices with other community members.</description>
<name>Community of Practice Workspace Template</name>
<templateId>oracle.com.community-of-practice-workspace-template</templateId>
<domain>general</domain>
</templateAttributes>
<body>
   <publicSensitivityTemplateBodyId>public_sensitivity</publicSensitivityTemplateBodyId>
   <defaultSensitivityTemplateBodyId>default_sensitivity</defaultSensitivityTemplateBodyId>
  <attributes>
     <name prompt="true" promptMessage="enter workspace name">Community of Practice Workspace</name>
     <description>This workspace was created using the Community of Practice template.  It contains an FAQ template and wiki home page that members can edit to add information about this community, some tasks to guide the coordinators as they configure the workspace, and a wiki page, forum and folder to share best practices with other community members.</description>
     <publiclyListed>F</publiclyListed>
     <participationMode>INVITE_ONLY</participationMode>
  </attributes>
  <preferenceSet>
      <name>ForumPreferences</name>
      <description>forum preferences</description>
      <property>
        <name>DISC_UPDATE_WHO</name>
        <value type="STRING">AUTHOR_ONLY</value>
        <allowOverride>true</allowOverride>
      </property>
      <property>
        <name>DISC_DELETE_WHO</name>
        <value type="STRING">AUTHOR_ONLY</value>
        <allowOverride>true</allowOverride>
      </property>
      <property>
        <name>DISC_UPDATE_WHEN</name>
        <value type="STRING">NO_REPLIES</value>
        <allowOverride>true</allowOverride>
      </property>
      <property>
        <name>DISC_DELETE_WHEN</name>
        <value type="STRING">NO_REPLIES</value>
        <allowOverride>true</allowOverride>
      </property>
  </preferenceSet>
  <property>
      <name>forumDefaultDest</name>
      <description>forum default destination</description>
      <value type = "STRING">Forum List</value>
  </property>
  <property>
      <name>libDefaultDest</name>
      <description>library default destination</description>
      <value type = "STRING">Default Folder</value>
  </property>
  <property>
      <name>wikiDefaultDest</name>
      <description>wiki default destination</description>
      <value type = "STRING">All Pages</value>
  </property>
  <sensitivity id="default_sensitivity">
      <name>Normal</name>
      <description>normal sensitivity</description>
      <sensitivityOnly>false</sensitivityOnly>
      <delegatable>true</delegatable>
      <ace>
          <grantAccessType>DISCOVER</grantAccessType>
          <accessor type="GROUP"><systemDefinedGroupName>ALL_USERS</systemDefinedGroupName></accessor>
      </ace>
  </sensitivity>
  <sensitivity id="public_sensitivity">
      <name>Public</name>
      <description>public sensitivity</description>
      <sensitivityOnly>false</sensitivityOnly>
      <delegatable>true</delegatable>
      <ace>
          <grantAccessType>DISCOVER</grantAccessType>
          <grantAccessType>READ</grantAccessType>
          <accessor type="GROUP"><systemDefinedGroupName>ALL_USERS</systemDefinedGroupName></accessor>
      </ace>
  </sensitivity>
  <defaultAnnouncementsForum id="default_ann_forum">
     <name>Announcements</name>
     <description>Forum for workspace announcements</description>
        <announcement>
           <subject>Welcome to the ${sys.workspace.name} Workspace</subject>
           <messageBody>
              <mediaType>text/plain</mediaType>
              <body>This workspace was created using the Community of Practice template.  It contains an FAQ template and wiki home page that members can edit to add information about this community, some tasks to guide the coordinators as they configure the workspace, and a wiki page, forum and folder to share best practices with other community members.</body>
           </messageBody>
           <expiresOn prompt="false" offsetUnit="DAY"><offset>7</offset></expiresOn>
        </announcement>
  </defaultAnnouncementsForum>
  <defaultAddressBook id="default_address_book">
     <name>Contacts</name>
     <description>Workspace address book</description>
  </defaultAddressBook>
  <defaultCalendar id="default_calendar">
     <name>Calendar</name>
     <description>Workspace Calendar</description>
     <enrollmentType>PUBLIC</enrollmentType>
     <selfEnrollmentOpenToAll>false</selfEnrollmentOpenToAll>
     <enrollWorkspaceMembers>false</enrollWorkspaceMembers>
  </defaultCalendar>
  <defaultDiscussionsForum id="default_disc_forum">
     <name>Discussions</name>
     <description>Default forum for team discussions</description>
  </defaultDiscussionsForum>
  <defaultDocumentsFolder id="documents_folder">
     <name>Documents</name>
     <description>A folder for documents that you want to share with participants of this workspace.</description>
     <entities>
        <folder>
           <name>Best Practices</name>
           <description>A folder for sharing best practice documents with the participants of this workspace.</description>
        </folder>
     </entities>
  </defaultDocumentsFolder>
  <defaultEmailInbox id="inbox_folder">
     <name>INBOX</name>
     <description>Inbox for email messages</description>
  </defaultEmailInbox>
  <defaultTaskList id="default_task_list">
     <name>Tasks</name>
     <description>Team tasks</description>
     <todo>
       <name>Configure and customize the workspace</name>
       <description>
Modify the FAQ, Best Practices and Wiki Home pages.
Add additional content.
This task has been assigned from the ${sys.workspace.name} workspace.
</description>
       <startTime offsetUnit="SECOND"><offset>1</offset></startTime>
       <dueTime offsetUnit="DAY"><offset>1</offset></dueTime>
       <organizer type="USER"><cen>${sys.workspace.owner.collabid}</cen></organizer>
      </todo>
      <todo>
       <name>Identify and add workspace participants</name>
       <description>
Add participants to the community who can help contribute knowledge using the New Participants function.  If you are adding a user who is manager, you will have the option of including their  direct reports or their entire organization.  You can also choose to add a group to this workspace.  If you know you need a person with specific expertise but don't know who  that person is, you can try the Search Interests and Expertise function or New Connection Request to find the appropriate person.
Assign tasks to the newly added  participants.
This task has been assigned from the ${sys.workspace.name} workspace.
</description>
       <startTime offsetUnit="SECOND"><offset>1</offset></startTime>
       <dueTime offsetUnit="DAY"><offset>1</offset></dueTime>
       <organizer type="USER"><cen>${sys.workspace.owner.collabid}</cen></organizer>
      </todo>
  </defaultTaskList>
  <defaultWikiFolder>
      <name>Wiki</name>
      <description>default folder for wiki pages</description>
      <entities>
        <wikiPage>
          <name>Home</name>
          <description>Home page</description>
          <extractReferences>T</extractReferences>          <body>
            <inlineBody>
=Community Charter=
 
(insert the community charter and background information here)
 
=Shortcuts to Relevant Information=
 
|Wiki Pages|[[FAQ|FAQ]]\\[[Best Practices|Best Practices]]\\(insert other links here)|
|Documents|(insert links here)|
|Other Sites|(insert links here)|
 
=Help=
 
Here is some basic information about this workspace
 
|End-user Help|End-user help is always available through the Help icon in the upper-right corner.|
|Calendar Enrollment|Participants of this workspace are not automatically enrolled in its calendar. Events created in this workspace will not be added to participants personal calendars unless they enroll themselves. Participants can enroll themselves in the Overview page. Alternatively, workspace coordinators can access the Settings to change the default settings for new participants.|
|Library|By default, the Library contains a Documents folder and a Public Documents folder. The Documents folder is used for sharing documents with the team. The Public Documents folder is available to any authenticated user, provided you share the URL to the folder or the document.|
|Forums|This workspace contains two forums  a Best Practices forum and a Discussions forum. In the Best Practices forum,  participants can discusse and contribute best practices. The Discussions forum is can be used for generic discussions. By default, the Forum tool displays the list of forums in this workspaces. Workspace coordinators can modify this setting in the Defaults tab of the Settings page.|
|Tags|Tags allow workspace members to describe and organize various objects like wiki pages, topics, documents and tasks.  As a specific tag is applied by more users to an object, the strength of that tag as a descriptor for that object increases.  Tags enable easy discovery of related content and object-agnostic navigation.|
|Enable Public Access|Workspace coordinators can access the Settings to enable Public Access for this workspace and specify the type of access that non-participants will have.  Non-participants will be able to access this workspace if they are given the URL.  Additionally, non-participants will see search results with wiki pages and documents from this workspace.|
 
</inlineBody>
          </body>
          <isDefaultWikiPage>true</isDefaultWikiPage>
        </wikiPage>
       <wikiPage>
          <name>FAQ</name>
          <description>null</description>
          <extractReferences>T</extractReferences>          <body>
            <inlineBody>
&lt;&lt;toc>>
=(insert your first question here)=
 
(insert the answer to your first question here)
 
=(insert your second question here)=
 
(insert the answer to your second question here)
 
=(insert your third question here)=
 
(insert the answer to your third question here)
           </inlineBody>
          </body>
        </wikiPage>
      <wikiPage>
          <name>Best Practices</name>
          <description>null</description>
          <extractReferences>T</extractReferences>          <body>
            <inlineBody>
&lt;&lt;toc>>
The purpose of this page is to provide a framework to capture best practices in your community.
 
=(insert first best practice title)=
 
==Point of Contact==
 
(insert name, email address, phone number of contact person for this best practice)
 
==Description and Details==
 
(insert a description and details about this best practice)
 
==Benefits==
 
(briefly describe the benefits derived from implementing this best practice)
 
==Issues and Lessons Learned==
 
(briefly describe any problems or issues experienced with the best practice that, if avoided, would make the implementation of this best practice easier in the future)
 
 
=(insert second best practice title)=
 
==Point of Contact==
 
(insert name, email address, phone number of contact person for this best practice)
 
==Description and Details==
 
(insert a description and details about this best practice)
 
==Benefits==
 
(briefly describe the benefits derived from implementing this best practice)
 
==Issues and Lessons Learned==
 
(briefly describe any problems or issues experienced with the best practice that, if avoided, would make the implementation of this best practice easier in the future)
           </inlineBody>
          </body>
        </wikiPage>
      </entities>
    </defaultWikiFolder>
  <entities>
     <folder id="public_documents_folder">
        <name>Public Documents</name>
        <description>A folder for workspace documents that you want to share with people that are not members of this workspace. These users must be logged into the system to  view these documents, but they don&#39;t have to be members of this workspace.</description>
        <appliedSensitivity><entityTemplateBodyId>public_sensitivity</entityTemplateBodyId></appliedSensitivity>
     </folder>
     <forum>
        <name>Best Practices</name>
        <description>Forum for discussing best practices with the community.</description>
     </forum>
  </entities>
</body>
</teamWorkspaceTemplate>