2. Create lifecycles and workflows for use with Web Publisher.
Refer to:
Chapter 5, Setting Up Lifecycles
Chapter 6, Creating and Installing Workflow Templates
3. Define Web Publisher’s system-wide default settings. For information on doing so, see the topic on defining system settings in the Web Publisher User Guide or Web Publisher online help.
4. Define integrations.
Refer toChapter 7, Defining Web Publisher Integrations 5. Set up your websites.
Refer toChapter 8, Creating Websites
6. Create the templates authors will use to create content for the web. Define the folder mapping rules that determine where content is located on a website.
Refer to:
Chapter 9, Creating Templates
Chapter 10, Creating Templates for Web Publisher Editor Chapter 12, Defining Folder Mapping
7. Design websites that publish in multiple languages.
Refer toChapter 13, Setting Up Multi-Language Websites
8. Set up alternate taxonomies for organizing content for your authors to access.
Refer toChapter 15, Using Taxonomies and Categories
9. Optionally, set up in-context editing, which allows your authors to find content by navigating websites as they appear on the web.
Refer toChapter 16, Setting Up In-Context Editing (ICE)
10. Create custom tags to enable authors to generate special information for websites.
Refer toChapter 17, Creating Custom Tags 11. Monitor Web Publisher operations and activities.
Refer toChapter 19, Monitoring Web Publisher
12. Address any errors that occur in Web Publisher using error messages and notifications.
Refer toChapter 20, Troubleshooting
13. Familiarize yourself with the repository object types that are used in Web Publisher.
Refer toAppendix A, The Web Publisher Object Model
Setting Up Users, Groups, and Roles
To use Web Publisher, you must set up Web Publisher-specific users, groups, and roles. To do so, you use Documentum Administrator, which you access through Web Publisher’s Administration node.
For documentation on how to use Documentum Administrator, see the Documentum Administrator User Guide.
This chapter gives overview information on setting up users, groups, and roles in Web Publisher:
• Users in Web Publisher, page 19
• Groups in Web Publisher, page 20
• Roles in Web Publisher, page 21
Users in Web Publisher
To access a repository, a person must be defined as a user in that repository. Adding someone as a user to a non-federated repository does not give that person access to every repository in the enterprise. The person must be explicitly added to each repository.
Before you create Web Publisher users in Documentum Administrator, determine what type of privileges each user must have in Web Publisher. User privileges authorize certain users to perform activities that are required to administer and maintain the system. The privilege levels are:
• None
• Create Type
• Create Cabinet
• Create Cabinet and Type
• Create Group
• Create Group and Type
• Create Group and Cabinet
• Create Group, Cabinet, and Type
• System Administrator
• Superuser
User client capabilities enable users to perform various operations in a repository such as create objects, view objects, manage lifecycles, and manage workflows. There are four types of users:
• Consumer
• Contributor
• Coordinator
• System Administrator
These four client capability levels available to users, can be set as client_capability attributes on the dm_user object in the repository.
Content Server does not recognize or enforce these client capability settings. Some capability actions check permissions in the launch or precondition class, or the component checks repository permissions, but the action or component does not specifically check the client capability level.
For more information on users, refer to the Documentum Administrator User Guide.
Groups in Web Publisher
A group represents multiple repository users and can contain groups, users, or roles.
(Roles are found in 5.x and later repositories only.) You can add users, groups, or roles to a group by following instructions in the Documentum Administrator User Guide. By default, a group is owned by the user who creates the group. Groups can be public or private. By default, groups created by a user with Create Group privileges are private, while groups created by a user with Sysadmin or Superuser privileges are public.
In a 5.x repository, a group can own sysobjects and permission sets.
In 5.3 and later repositories, you can create dynamic groups. A dynamic group is a group, of any group class, whose list of members is considered a list of potential members. A dynamic group is created and populated with members like any other group. Whether a group is dynamic is part of the groups definition. It is recorded in the is_dynamic attribute and may be changed after the group is created.
For more information on groups, refer to the Documentum Administrator User Guide. For more information on dynamic groups, refer to the Documentum Administrator User Guide and Content Server Administrator’s Guide.
Roles in Web Publisher
A role is a type of group that contains a set of users or other groups that are assigned a particular role within a client application domain. If you create a role as a domain, it is listed on the Groups list page, not the Roles list page. For information on roles and domains, refer to the section on security services in Content Server Fundamentals. Roles are found only in 5.1 and later repositories.
You can modify Web Publisher roles using XML files to change the functionality available to Web Publisher roles and to replace or add roles to your Web Publisher application.
Web Publisher can be configured to use any role that is defined in the repository. Web Publisher is already configured with the roles that are defined in the Web Publisher DocApp. If no roles are configured in the repository, or if the repository is pre-5.1, Web Publisher defaults to using the client capability model. For further details on configuring Web Publisher roles, refer to the Web Publisher Development Guide.
Note: If you create role groups in the repository, you can create roles named consumer, contributor, coordinator, and administrator. Your custom roles can contain these roles, so that Web Publisher components will not need to be reconfigured for your custom roles.
For more information on roles, refer to the Documentum Administrator User Guide.
Setting Up Security
Web Publisher enables you to control access to repository content using permission sets and folder security. A permission set defines the object-level permissions applied to objects to which the permission sets are assigned. Folder security is an additional level of security that supplements the existing repository security and may require you to have Write permission or greater for the folder in order to access an object.
This chapter describes the following:
• Permissions, page 23
• Access levels, page 25
• Extended permissions, page 25
• Additional access control entries, page 26
• Folder security, page 27
• Default alias sets, page 28
• Permission sets and the Web Publisher DocApp, page 28
• Editing permissions in the Permissions tab, page 29
Permissions
Permissions determine the access that each user has to each item in the repository.
Permissions are governed by permission sets. Each item in the repository is assigned a permission set by the item’s owner.
The permission set lists specific users and groups and assigns them specific access levels.
An access level determines which operations (such as read, edit, or delete) the user or group can perform on the item. Each entry in a permission set is called an access control entry.
There are seven possible access levels. Each higher access level includes the capabilities of the preceding access levels. The access levels are listed inAccess levels, page 25.
In addition to the seven levels of basic access, there are six levels of extended permissions.
For more information on extended permissions, refer toExtended permissions, page 25.
Each user is assigned a default permission set. When a user creates an item, the repository assigns the user’s default permission set to the item. For example, if your default permission set gives all members of your department Write access and all other users Read access, then those are the access levels assigned to the item.
You can change an item’s access levels by changing the item’s permission set. To do so you must be the item’s owner (typically the owner is the user who created the item) or you must have Superuser privileges in the item’s repository.
When you modify a permission set, the permission set is saved as a permission set assigned to you. You can then apply the permission set to other items in the repository.
Your ability to edit permission sets depends on your user privileges in the repository:
• If you have Superuser privileges, you can modify any permission set in the repository. You can designate any user as the owner of a permission set, and you can change the owner of a permission set. This permission is usually assigned to the repository administrator.
• If you have SysAdmin privileges, you can modify any permission set owned by you or by the repository owner. You can designate yourself or the repository owner as the owner of a permission set that you create and you can change whether you or the repository owner owns the permission set. This permission is usually assigned to the repository administrator.
• If you have any privileges less than the above, you are the owner only of the permission sets that you create. You can modify any permission set you own, but you cannot change the owner of the permission set.
If you designate the repository owner as the owner of a permission set, that permission set is a System (or Public) permission set. Only a Superuser, System Administrator, or the repository owner can edit the permission set. If a different user is the owner of the permission set, it is a Regular (or Private) permission set. It can be edited by the owner, a Superuser, System Administrator, or the repository owner.
A user with Write or Delete permission can change which permission set is assigned to an object.
Web Publisher users only: If the user does not assign the default permission set, the Content Server assigns a default permission set according to the setting in the default_acl attribute in the server config object.
Access levels
The following table lists the basic access levels that you can assign a user. You assign access levels in permission sets.
Table 4-1. Access levels
Access level What it allows
None No access is permitted to the item.
Browse Users can view the item’s properties but not the item’s content.
Read Users can view both the properties and content of the item.
Relate Users can do the above plus they can add annotations to the item.
Version Users can do the above plus they can modify the item’s content and they can check in a new version of the item (with a new version number). Users cannot overwrite an existing version or edit the item’s properties.
Write Users can do the above plus they can edit item properties and check in the item as the same version.
Delete Users can do all the above, and they can delete items.
Extended permissions
Extended permissions are used to give users or groups permission to perform additional actions, beyond what is allowed by their assigned access level. Only sysadmins and superusers may grant or modify extended permissions.
Table 4-2. Extended permissions
Extended permission What it allows
Execute Procedure Superusers can change the owner of an item and can use Execute Procedure to run external procedures on certain item types.
Change Location Users with Change Location permissions can move an item in the repository.
Extended permission What it allows
Change State Users with Change State permissions can change the state of an item that has a lifecycle applied to it.
Change Permission Users with Change Permissions can modify the basic permissions of an item.
Change Ownership Users with Change Ownership permissions can change the owner of the item.
Delete Object Users with the Delete Object extended permission have the right only to delete the object.
Additional access control entries
Under Content Server 5.3 and later, when Trusted Content Services is enabled in a repository, additional access control entries are available. The access control entries described in the table are independent of each other, not hierarchical.
Table 4-3. Additional access control entries
Access control entry Effect of the entry
Access Restriction An access restriction entry denies a user the right to the base object-level permission level specified in the entry.
For example, if a user would otherwise have delete permission as a member of a particular group, an access restriction might limit the user to, at most, version permission. The user would therefore lose write and delete permission.
Extended Restriction An extended restriction entry denies a user or the members of a specified group the specified extended object-level permission. For example, if a user would otherwise have Change Permission rights as a member of a particular group, an extended restriction would remove that right.
Access control entry Effect of the entry
Required Group A required group entry requires a user
requesting access to an object governed by the permission set to be a member of the group identified in the entry. If there are entries for multiple groups, the user must be a member of all of the groups before Content Server allows access to the object.
Required Group Sets A required group set entry requires a user requesting access to an object governed by the permission set to be a member of at least one group in the set of groups.
Folder security
Folder security is an additional level of security that supplements the existing repository security. Implementing this security option further restricts allowable operations in a repository. When folder security is in use, operations such as copying or moving documents may require you to have Write permission or greater for the folder in order to access an object. For information about assigning folder security to a repository, refer to the Content Server Administrator’s Guide.
If you use Documentum’s Web Publisher, and if folder security is used in a repository, any content files in the WIP state must have the same permission as the folder. To use the same folder permission, the administrator must ensure the lifecycle in WIP state does not apply any set ACL action. For example:
WIP - folder acl
Staging - WP "Default Staging ACL"
Approved - WP "Default Approved ACL"
The following table lists the actions affected by folder security.
Table 4-4. Permissions required under folder security
Action Requires at least write permission for:
Create an object Cabinet or folder in which you create the new object Import a file(s) or folder Cabinet or folder to which you import the file(s) or folder Move an object Both the cabinet or folder from which you remove the
object and the destination folder or cabinet
Action Requires at least write permission for:
Copy an object Destination cabinet or folder Link an object Destination cabinet or folder
Unlink an object Cabinet or folder from which you unlink the object Delete one version of a
document
The document’s primary folder
Delete all versions of a document
The document’s primary folder
Delete unused versions of a document
The document’s primary folder
Consult the repository administrator for information on whether folder security is enabled in the repository.
Default alias sets
The Content Server adds these default aliases to a permission set:
• dm_owner: Represents the owner of the permission set.
• dm_world: Represents all repository users.
Permission sets and the Web Publisher DocApp
Web Publisher’s default permission set (or ACL) is the Web Publisher User Default ACL.
If a user does not identify a permission set for an object or does not explicitly choose that the object should not have a default permission set, Content Server attempts to assign the new object a default permission set. To identify which permission set to assign as the default, the Content Server uses the value in the default_acl attribute of its server configuration object. This attribute contains an integer value that represents one of three candidate permission sets: 1, which is the folder permission set; 2, which is the type permission set; or 3, which is the user permission set. A value of 4 means that there is no default permission set.
When you install Content Server, the default_acl attribute is set to 3, for the user permission set. This means that whenever a user creates an object and does not explicitly assign it a permission set or grant it permissions, the server assigns the default permission set associated with the users dm_user object to the new object. The Web Publisher
If the Content Server’s default permission set (default_acl) mode is incorrect during your Web Publisher DocApp installation your cannot reinstall the Web Publisher DocApp. A DocApp installation cannot be rolled back and reinstalled. You must create a new repository. For details on installing the Web Publisher DocApp refer to the Web Development Kit and Applications Installation Guide.
Editing permissions in the Permissions tab
This procedure describes how to enter information in the Permissions tab. This procedure is used in numerous procedures. This procedure assumes you have already either opened a permission set or opened an object’s properties.
To edit permissions in the Permissions tab:
Note: This procedure includes steps for setting required groups, required group sets, and access restrictions. These are used in 5.3 or later repositories where Trusted Content Services is enabled.
1. If you have not already done so, click the Permissions tab.
This tab displays four different sections, each with a hyperlink at the top for a title.
Each hyperlink has either a [-] or [+] in front of it, indicating whether the section is expanded or collapsed. You expand or collapse a section by clicking the hyperlink.
When a section is expanded, the hyperlink has a [-] in front of it and the section’s items are displayed.
2. To add a required group, make sure the Required Groups section is expanded and do the following:
a. Click Add.
b. Select all groups of which a user must be a member.
c. Click the right arrow.
d. Click OK.
3. To remove a required group, make sure the Required Groups section is expanded.
Then select the group and click Remove.
4. To add a required group set, make sure the Required Group Set section is expanded and do the following:
a. Click Add.
b. Select the groups.
c. Click the right arrow.
d. Click OK.
5. To remove a required group set, make sure the Required Group Set section is expanded. Then select the group and click Remove.
6. To add a user or group to the permission set and assign the access level for the user or group, make sure the Permissions section is expanded.
Note: If you are creating a new permission set, the Permissions section displays the default access control entries:
• dm_owner
The owner of the permission set.
• dm_world
All repository users.
In the Permissions section, do the following:
a. Click Add.
b. To select from all users or groups, click the All tab. To select from recently used users and groups, click the Recently Used tab.
c. Check the checkboxes adjacent to the users or groups you want to add and click
c. Check the checkboxes adjacent to the users or groups you want to add and click