Web Publisher Administration Guide

Transcription

1 Web Publisher Administration Guide Version 5.3 SP4 December 2006

2 Copyright EMC Corporation. All rights reserved.

3 Table of Contents Preface Chapter 1 Introduction Chapter 2 Sequence for con guring Web Publisher and setting up websites Chapter 3 Setting Up Users, Groups, and Roles Users in Web Publisher Groups in Web Publisher Roles in Web Publisher Chapter 4 Setting Up Security Permissions Access levels Extended permissions Additional access control entries Folder security Default alias sets Permission sets and the Web Publisher DocApp Editing permissions in the Permissions tab Chapter 5 Setting Up Lifecycles Lifecycles overview Required lifecycle states Reconfiguring the default lifecycle Default lifecycle configuration Advancing files through their lifecycle states Lifecycles and permissions on active and expired objects Chapter 6 Creating and Installing Work ow Templates Workflow templates overview Demoting a change set Custom dynamic performer values Simple process workflows Translation workflows Workflow tasks Workflow methods Chapter 7 De ning Web Publisher Integrations Web Publisher Administration Guide 3

4 Table of Contents Activating the Web Publisher extended search option (ECI Services) Saved searches Defining imarkup Storing annotations Localizing imarkup Authoring in supported languages in ewebeditpro Setting up a link checker Configuring clients to open web files in authoring applications Editing XML files in Internet Explorer 5.5 or higher Setting up Web Publisher to send HTML mail Integrating Web Publisher with Business Process Services Configure listeners and message processors for Web Publisher Prepare and register inbound message handlers and add supporting files Create a Web Publisher alias Create a cabinet to store messages Copy Web Publisher SBO Defining integration with CI Server Integrating Web Publisher and CI Server Defining CI Server system settings Mapping CI Server properties with repository properties Defining automatic property population Setting property population Chapter 8 Creating Websites Overview of creating websites Site publishing configurations Default publishing configurations for exporting editions Synchronous and asynchronous publishing Site protection Mirror objects Determining what content is published Publishing to multiple sites Publishing a site in multiple languages Publishing with different effective dates on different sites Publishing change sets Storing multiple effective and expiration dates Setting effective date as a date in the past Resetting effective and expiration dates upon checkout Publishing externally created XML Web-safe characters Sequence for creating a new website Example of setting up a protected site Creating a site publishing configuration Viewing site publishing configurations Chapter 9 Creating Templates Overview of creating templates Web page creation Templates Supporting files Replication of templates and supporting files File locations Web Publisher Administration Guide

5 Table of Contents Updated XML and XSL Dynamic content using XDQL Automatically generated names Extended characters in XML files XSL includes Sequence for creating templates Creating templates for external applications Creating presentation files for external applications Presentation files for external applications Presentation files for ewebeditpro Defining folder structures for templates Testing a template Deleting a rendition Updating the structure of XML files Updating XML structure Creating an instruction file Examples of instruction files Updating multiple XML files Example of how an instruction file updates the structure of an XML file Chapter 10 Creating Templates for Web Publisher Editor Web Publisher Editor overview Transforming content through XDQL and Web Publisher Editor Sequence for creating Web Publisher Editor templates Creating content templates for Web Publisher Editor Creating a content template Creating an XML-based content template Creating an HTML-based content template Examples of Web Publisher Editor templates Using symbols in XML Web Publisher Editor attribute extraction Web Publisher Editor comments Link management Creating Editor rules files Overview of Editor rules files Absolute and relative paths Path rule matching Attribute name value matching Preview and web view Repeatdef Component types <calendar> element <checkbox> element Sample checkbox rules <choice> element Sample choice rules <content> element <content> element attributes Customizing the default toolbar Sample content rule <graphic> element Sample graphic rules <repeatdef> element Sample repeatdef rules Web Publisher Administration Guide 5

6 Table of Contents <repeatdef> nesting elements multiple nesting levels <tabledef> element Sample <tabledef> elements <tagcontent> element in non-xml templates <textarea> element <textline> element Sample textline rules <textselector> element Sample textselector rules <xselector> element Sample xselector rules Sample xselector filters Defining a format list The rules file on the sample website Creating Editor presentation files (XSL stylesheets) Validating Web Publisher Editor templates Chapter 11 Creating Templates for Page Builder Understanding Web Publisher Page Builder Understanding the content template Understanding the blueprint What a web page looks like Updating and rendering content for a web page Using views Layout view Content view Preview Site view Rendering content into HTML Creating a translated web site Channels Understanding the blueprint descriptor Creating a new Page Builder template Editing Page Builder templates Importing Page Builder templates Importing Page Builder Dreamweaver template Exporting Page Builder templates Globalization support in Page Builder How it works? Choosing an image of a specific locale Content migration Update template Enabling SSI support on the Web View server Chapter 12 De ning Folder Mapping Folder mapping overview Folder mapping elements <attr_list> <path_list> Example of a folder map file Repeating properties Repeating properties in <attr_list> Web Publisher Administration Guide

7 Table of Contents Repeating properties in <path_list> Rules-searching order How to debug or create a catch-all rule How folder mapping handles symbols How folder mapping handles special characters Specifying that an attribute has no value Dynamic folder mapping Dynamic folder mapping with full or partial paths How dynamic folder mapping handles special characters How folder mapping uses language_code Chapter 13 Setting Up Multi-Language Websites Sequence for setting up multi-language websites Enabling globalization Adding a new country and language to the locale creation page Specifying Web Publisher Editor s dictionary Chapter 14 Setting Up Portlets Portlets overview Sequence for creating a portal and its components Creating a new portal Creating a new target portal server Creating portlet templates Portlet Builder templates overview Creating a new portlet template by an extension of an existing template Customizing your portlet template components Examples of customizing portlet template components Deleting a portlet template Publishing a portal Manually publishing a portal Deploying a web archive (war) file on BEA WebLogic Workshop Configuring the connection to an LDAP server Resolving links repository content at runtime Chapter 15 Using Taxonomies and Categories How taxonomies work in Web Publisher Using taxonomies in Web Publisher Assigning taxonomies to web cabinets Publishing taxonomies to websites Storing taxonomy values in properties other than keywords Chapter 16 Setting Up In-Context Editing (ICE) How Web Publisher determines a page is editable through ICE ICE uses a mini-proxy to render frames Sequence for setting up ICE Removing dm_relation objects Enabling authors to edit content displayed through <include> Web Publisher Administration Guide 7

8 Table of Contents Enabling authors to create new content files from the web page Chapter 17 Creating Custom Tags Overview of custom tags Create custom tags in an element definition file Assign a custom tag set to a content rule Chapter 18 Understanding Discussions and Comments Discussion permissions Using discussions Searching discussions Chapter 19 Monitoring Web Publisher Content transfer Tracing Turning on the DFC tracing tool Accessing tracing Setting tracing Testing your API Testing your DQL Java Method Server Verifying the Method Server Tracing details Web Publisher application-level settings Log files Chapter 20 Troubleshooting Shared memory error Java Method Server errors Effective and expired content Problems sending HTML mail Web view Translation workflows Troubleshoot Business Process Services Site publishing configuration Setting the error_threshold key in Site Caching Services Translation workflow configuration In-context editing Java plug-in install Formatted text appears different when previewing Appendix A The Web Publisher Object Model Object model diagram dm_sysobject wcm_config wcm_user_pref dm_folder wcm_change_set dm_cabinet wcm_channel Web Publisher Administration Guide

9 Table of Contents wcm_edition wcm_channel_fld wcm_edition_fld wcm_supporting_doc_folder wcm_auto_naming wcm_locale dm_relation (relations) DM_TRANSLATION_OF wcm_category wcm_default_workflow wcm_doc_template wcm_dynamic_content wcm_layout_template wcm_my_template wcm_process_workflow wcm_publishing_template wcm_rules_template wcm_template_thumbnail wcm_html_editor wcm_rules_editor wcm_editor_link wcm_ewebeditpro_link wcm_native_edit wcm_link wcm_link_internal wcm_managed_link wcm_pb_template_blueprint Web Publisher Administration Guide 9

10 Table of Contents List of Figures Figure 1 1. Typical 5.3 Web Publisher system configuration Figure 6 1. Submit to Web Site Workflow Figure 6 2. Request New Content Workflow Figure 6 3. Sample French Translation workflow Figure 6 4. Sample translate and submit to Web Site workflow Figure 6 5. Simple Process Workflow with Translation Task Figure Transforming content through XDQL and Web Publisher Editor Figure XML-based Web Publisher Editor template and supporting files Figure Rules Editor Figure Calendar Figure Checkbox Figure Choice field Figure Content field in Web Publisher Editor Figure Graphic list selector Figure Graphic tree selector globalization disabled Figure Graphic tree selector globalization enabled Figure Block of repeatable fields Figure A block of nested fields Figure Multiple nested fields Figure Table Editor Figure Textarea field Figure cdata support in <textarea> element Figure Unformatted text in Web Publisher Editor Figure Field for Read-only text Figure Textselector using a list generated by a query Figure Textselector using a tree globalization disabled Figure Textselector using a tree globalization enabled Figure Any type selector page Figure Graphic type selector page Figure File selector Figure Template and blueprint association Figure Content schema example Figure How Web Publisher determines editable content Figure A 1. Web Publisher 5 Object Model Web Publisher Administration Guide

11 Table of Contents List of Tables Table 4 1. Access levels Table 4 2. Extended permissions Table 4 3. Additional access control entries Table 4 4. Permissions required under folder security Table 6 1. Sample language codes and addresses Table 6 2. Workflow tasks Table 6 3. Workflow methods Table 8 1. Multiple effective and expiration dates Table 8 2. Example users for site protection Table 8 3. Example user groups for site protection Table 8 4. Other example user groups for site protection Table 8 5. Example group assignments for site protection Table 8 6. Example alias set for site protection Table 9 1. Instruction elements Table 9 2. Elements that set instruction parameters Table Date format patterns Table Date format pattern examples Table Web Publisher 5.3 Methods Configurations (Java Method Server Support) Table Java Method Server Details on Server Machine Table Web Publisher Server Side Tracing Details Table Web Publisher application level configurations in the properties file Table A 1. dm_sysobject Table A 2. wcm_config Table A 3. wcm_user_pref Table A 4. dm_folder Table A 5. wcm_change_set Table A 6. wcm_channel Table A 7. wcm_edition Table A 8. wcm_edition_fld Table A 9. wcm_auto_naming Table A 10. wcm_locale Table A 11. wcm_category Table A 12. wcm_default_workflow Table A 13. wcm_doc_template Table A 14. wcm_dynamic_content Table A 15. wcm_layout_template Web Publisher Administration Guide 11

12 Table of Contents Table A 16. wcm_my_template Table A 17. wcm_process_workflow Table A 18. wcm_publishing_template Table A 19. wcm_rules_template Table A 20. wcm_template_thumbnail Table A 21. wcm_html_editor Table A 22. wcm_rules_editor Table A 23. wcm_editor_link Table A 24. wcm_ewebeditpro_link Table A 25. wcm_native_edit Table A 26. wcm_link Table A 27. wcm_link_internal Table A 28. wcm_managed_link Table A 29. wcm_pb_template_blueprint Web Publisher Administration Guide

13 Preface This manual explains how to define Web Publisher settings and how to create websites. You should read this publication if you are responsible for designing and maintaining templates and websites, and defining Web Publisher settings. You should have basic knowledge of Documentum s Web Development Kit, of XML, and of Documentum repositories. For more information on configuring XML definition files in Web Publisher, refer to the Web Publisher Development Guide. Intended audience This guide is intended for system administrators who need to configure Web Publisher to work in their specific business environments, and web developers who need to create websites and website publishing configurations. Revision History The following changes have been made to this publication since the previous edition: Revision history Revision Date December 2006 Description Initial release. Related documentation You should be familiar with the following Web Publisher documentation: Web Publisher User Guide Web Publisher Release Notes Web Development Kit and Applications Installation Guide Web Publisher Administration Guide 13

14 Preface To download related documentation, go to the support area of 14 Web Publisher Administration Guide

15 Introduction Chapter 1 Web Publisher simplifies and automates the creation, review and publication of content to websites. Web Publisher manages all content (including code) that goes into a website. Web Publisher runs as part of a Documentum system. The following diagram shows the system architecture for a typical Web Publisher system configuration. Web Publisher Administration Guide 15

16 Introduction Figure 1-1. Typical 5.3 Web Publisher system con guration 16 Web Publisher Administration Guide

17 Sequence for con guring Web Publisher and setting up websites Chapter 2 This guide explains how to configure Web Publisher for your business environment and how to create and publish websites. To do so, you perform the sequence of procedures listed here. Your sequence might differ, depending on your organization s setup: To con gure Web Publisher and set up websites, use the following sequence of procedures: 1. Use Documentum Administrator to create Web Publisher users, groups, and roles; and assign users and groups to groups and roles. Refer to: Chapter 3, Setting Up Users, Groups, and Roles Chapter 4, Setting Up Security 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 to Chapter 7, Defining Web Publisher Integrations 5. Set up your websites. Refer to Chapter 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 Web Publisher Administration Guide 17

18 Sequence for con guring Web Publisher and setting up websites Chapter 10, Creating Templates for Web Publisher Editor Chapter 12, Defining Folder Mapping 7. Design websites that publish in multiple languages. Refer to Chapter 13, Setting Up Multi-Language Websites 8. Set up alternate taxonomies for organizing content for your authors to access. Refer to Chapter 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 to Chapter 16, Setting Up In-Context Editing (ICE) 10. Create custom tags to enable authors to generate special information for websites. Refer to Chapter 17, Creating Custom Tags 11. Monitor Web Publisher operations and activities. Refer to Chapter 19, Monitoring Web Publisher 12. Address any errors that occur in Web Publisher using error messages and notifications. Refer to Chapter 20, Troubleshooting 13. Familiarize yourself with the repository object types that are used in Web Publisher. Refer to Appendix A, The Web Publisher Object Model 18 Web Publisher Administration Guide

19 Chapter 3 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 Web Publisher Administration Guide 19

20 Setting Up Users, Groups, and Roles 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. 20 Web Publisher Administration Guide

21 Setting Up Users, Groups, and Roles 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. Web Publisher Administration Guide 21

22 Setting Up Users, Groups, and Roles 22 Web Publisher Administration Guide

23 Chapter 4 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 in Access levels, page 25. Web Publisher Administration Guide 23

24 Setting Up Security In addition to the seven levels of basic access, there are six levels of extended permissions. For more information on extended permissions, refer to Extended 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. 24 Web Publisher Administration Guide

25 Setting Up Security 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 None Browse Read Relate Version Write Delete What it allows No access is permitted to the item. Users can view the item s properties but not the item s content. Users can view both the properties and content of the item. Users can do the above plus they can add annotations to the item. 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. Users can do the above plus they can edit item properties and check in the item as the same version. 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 Execute Procedure Change Location What it allows Superusers can change the owner of an item and can use Execute Procedure to run external procedures on certain item types. Users with Change Location permissions can move an item in the repository. Web Publisher Administration Guide 25

26 Setting Up Security Extended permission Change State Change Permission Change Ownership Delete Object What it allows Users with Change State permissions can change the state of an item that has a lifecycle applied to it. Users with Change Permissions can modify the basic permissions of an item. Users with Change Ownership permissions can change the owner of the item. 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 Access Restriction Extended Restriction Effect of the entry 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. 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. 26 Web Publisher Administration Guide

27 Setting Up Security Access control entry Required Group Required Group Sets Effect of the entry 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. 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 Create an object Import a file(s) or folder Move an object Requires at least write permission for: Cabinet or folder in which you create the new object Cabinet or folder to which you import the file(s) or folder Both the cabinet or folder from which you remove the object and the destination folder or cabinet Web Publisher Administration Guide 27

28 Setting Up Security Action Requires at least write permission for: Copy an object Link an object Unlink an object Delete one version of a document Delete all versions of a document Delete unused versions of a document Destination cabinet or folder Destination cabinet or folder Cabinet or folder from which you unlink the object The document s primary folder The document s primary folder 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 DocApp assumes the value of the Content Servers default_acl attribute is set to Web Publisher Administration Guide

29 Setting Up Security 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. Web Publisher Administration Guide 29

30 Setting Up Security 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 Add. To remove an item from the list of selected items, select the item s checkbox and click Remove. d. Click OK. e. In the Basic Permissions area, select the access level. f. In the Extended Permissions area, check the checkboxes of any extended permissions you want to add. g. If you have added multiple users or groups, you can click Next to apply different permissions to each. When you are done, click OK. 7. To edit a user or group s permissions, make sure the Permissions section is expanded. Then do the following: a. Select the checkboxes for the users or groups for which you want to edit permissions. b. Click Edit. c. In the Permission area, select the access level. d. In the Extended Permissions area, check the checkboxes of any extended permissions you want to add. e. Click OK. 8. To remove users or groups, make sure the Permissions section is expanded. Then select the checkboxes for the users or groups and click Remove. 30 Web Publisher Administration Guide

31 Setting Up Security 9. To add access restrictions, make sure the Access Restrictions section is expanded. Then do the following: a. Click Add. b. Select users and groups whose rights must be restricted. c. Click the right arrow. d. Click OK. If there are validation conflicts, they are displayed along with reasons for the conflicts. To continue despite the conflicts, click OK. To resolve the conflicts, click Cancel and select new users or groups. e. Select the permission level to deny the accessor. f. Select the extended permission level to deny the accessor. g. Click Next to go on to the next accessor or Finish to apply the same restrictions to all accessors. 10. To delete or edit Access Restrictions, make sure the Access Restrictions section is expanded. Then select the accessors and click Remove or Edit. 11. Do one of the following: To save your changes, click OK. To go to another tab, click the tab or click Next (if available). Web Publisher Administration Guide 31

32 Setting Up Security 32 Web Publisher Administration Guide

33 Chapter 5 Setting Up Lifecycles Lifecycles specify the states of documents as they move through different phases on their way to publication. This chapter describes the following: Lifecycles overview, page 33 Required lifecycle states, page 34 Reconfiguring the default lifecycle, page 36 Advancing files through their lifecycle states, page 39 Lifecycles and permissions on active and expired objects, page 39 Lifecycles overview Many companies have policies that govern how specific types of content work their way through their useful lives, and beyond. Such policies typically specify the stages that content passes through and the activities that occur at each stage. Content policy can be separated into two concepts: lifecycles, which define the life stages of content, and workflows, which direct a sequence of actions that users must perform on the content. Document lifecycles and workflows complement each other. A lifecycle specifies the states content occupies during its life. The lifecycle does not define what activities happen to content while it resides in a state, who is responsible for those activities, or when the content should move to another state. A workflow uses a template to define a connected set of activities, including who performs the activities and when. The workflow itself is a running version of the workflow template. Document lifecycles enable you to automate the publishing and expiration of files by specifying the states of a document as it moves through the stages of its life (for example, review, publishing, and end-of-life) on its way to being published on an Active website. All Web Publisher lifecycles have a minimum of four states: Start, WIP, Staging, and Approved. Web Publisher provides you with a default lifecycle, but administrators can Web Publisher Administration Guide 33

34 Setting Up Lifecycles create custom lifecycles with additional states between the WIP and Approved states, and different names for the default states. Every file in Web Publisher must have a valid lifecycle. Web Publisher provides a default lifecycle or you can use Documentum Administrator to create a custom lifecycle. For information on creating lifecycles, refer to the Documentum Administrator User Guide. When you create a lifecycle, it inherits your permissions (ACL) so you must ensure your permissions enable users to access the lifecycle. Users need to access the lifecycle to assign it to content templates during import into a Web Publisher repository. We recommend using the Web Publisher User Default ACL or using a permission set with identical permissions. Creating a system-level option on a user s permission set allows objects to be updated by a specific user. The system-level option enables changes to an object even if the object s status is Staging or above regardless of the user s permission set. Changes include changing locations, changing attributes and editing content. Once you create a custom lifecycle you can include the lifecycle in your custom DocApp to propagate the lifecycle to your repository. If you store lifecycles in the Web Publisher application, you should insert them into your custom DocApp to retain them as part of your configuration for future installations. If you create a lifecycle to use as the Web Publisher default, you must set it as the default in the document lifecycle setting in system settings. For information on defining system settings, see the topic on defining system settings in the Web Publisher User Guide or Web Publisher online help. Web Publisher automatically assigns lifecycles to content files, based on the lifecycles of templates. In Web Publisher s settings, the following settings affect how lifecycles operate. Lifecycle States Lifecycle State Aliases Delay Publish Active Required lifecycle states All Web Publisher lifecycles must have the four states listed here or have aliases of these states. If you use a different name for a state, you must use the name in all Web Publisher lifecycles and indicate the name in Web Publisher s system settings. For information on system settings, see the topic on defining system settings in the Web Publisher User Guide or Web Publisher online help. These are the four required states and their required values: Start 34 Web Publisher Administration Guide

35 Setting Up Lifecycles General tab: Set the State name to Start. Uncheck Demote document to base state on checkin. Check Allowed attachment directly to this state. WIP General tab: Set State name to WIP. Uncheck Demote document to base state on checkin. Check Allowed attachment directly to this state. Check Allow Demotion to previous state. Action tab: Set Add Version Label: to WIP. Set Remove Version Label: to Active. Set Remove Version Label: to Approved. Set Remove Version Label: to Expired. Set Set Permission Set to Default WIP ACL. Post Change tab: Set Repository Path Name: to the following: /System/Applications/WebPublisher/wcmLifecycleScript Staging General tab: Set State name to Staging. Uncheck Demote document to base state on checkin. Check Allow Demotion to previous state. Action tab: Set Add Version Label: to Staging. Set Remove Version Label: to Approved. Set Set Permission Set to Default Staging ACL. Approved General tab: Set State name to Approved. Web Publisher Administration Guide 35

36 Setting Up Lifecycles Uncheck Demote document to base state on checkin. Check Allow Demotion to previous state. Action tab: Set Add Version Label: to Approved Set Set Permission Set to Default Approved ACL Post Change tab: Set Repository Path Name: to the following: /System/Applications/WebPublisher/wcmLifecycleScript You must create these lifecycle states using Documentum Application Builder. Log in to Documentum Application Builder, open an existing application for example, Web Publisher, and navigate to DefaultLifecycle under the lifecycle node. For information on creating lifecycle states, refer to Documentum Application Builder Help. Recon guring the default lifecycle When a file is demoted to WIP, Web Publisher looks at the version tree. If there is an Active version of the file, Web Publisher promotes the file to Staging and push the Active version of the file to the Staging site. This is done via a lifecycle post change script. A lifecycle script is now added to the WIP state by Web Publishers DocApp. When the lifecycle WIP state is entered, the wcmlifecyclescript is called. If the file enters WIP state via demote from Staging the updated script promotes the Active file to Staging and pushes the Active version to the Staging site. Remove Staging Version Label action is removed from the WIP state. Staging state no longer refers to lifecycle script. Web Publisher DocApp bundles a sample default lifecycle called. We strongly recommend using an identical copy of the lifecycle rather than the default lifecycle. If you are using default lifecycle without any customizations then perform the following changes. To con gure the default lifecycle: 1. Open the Web Publisher default DocApp using Documentum Application Installer. 2. Check out the default lifecycle. 3. Uninstall the default lifecycle. 4. Select WIP state and click the View State button. 5. Navigate to the Action tab and remove the Remove Version Label = Staging action. 36 Web Publisher Administration Guide

37 Setting Up Lifecycles 6. Navigate to the Post Change tab and browse to locate the wcmlifecyclescript script under the /System/Applications/WebPublisher folder. Select it. Make sure it is a current version. This step configures the wcmlifecyclescript to run in the WIP state. 7. Select the Staging state and click the View State button. 8. Navigate to the Post Change tab and remove the wcmlifecyclescript reference from the state. For example, Staging state should not run wcmlifecyclescript. 9. Check in the default lifecycle as a Same Version. 10. Install the default lifecycle. Changes in the lifecycle can be explained as follows: When a file is demoted to WIP, Web Publisher looks at the version tree. If there is an Active version of the file, Web Publisher promotes the file to Staging and push the Active version of the file to the Staging site. This is done via the lifecycle post change script. A lifecycle script is now added to the WIP state by Web Publishers DocApp. When the lifecycle WIP state is entered, the wcmlifecyclescript is called. If the file is entering the WIP state via demote from Staging state the updated script demotes the file back to Staging, to the Active version, and push the Active version to the Staging site. The Remove Staging Version Label action is removed from the WIP state. Staging state no longer refers to lifecycle script. Default lifecycle con guration The wcmlifecyclescript only handles the default case of Web Publishers default lifecycle states. The wcmlifecyclescript assumes the next state of WIP is Staging. If there are additional custom states between WIP and Staging or between Staging and Approved, some customizations to the wcmlifecyclescript may be needed depending on your usage. If you have custom states between WIP and Staging or between Staging and Approved, you may need to customize the wcmlifecyclescript object. You do not need to customize the script if you only change the alias of the default states. The wcmlifecyclescript itself already includes sample code to handle a lifecycle between Staging and Approved called QA. Here is what the lifecycle looks like: WIP -> Staging -> QA -> Approved -> Active When a file is demoted from QA to Staging, we want to make sure the Active version of the file is pushed to the QA site so that no link is broken. Here is a portion of the wcmlifecyclescript code shipped. Fix Bug 67235: restore the previous version label and data Dim prevstate As String Dim republish As Boolean if TargetState = wipsymbol then prevstate = stagingsymbol if demote from Staging republish = TRUE re-publish the Active version to Staging server again Web Publisher Administration Guide 37