Version 5.3 SP4 December 2006
Preface
...
13Chapter 1 Introduction
...
15Chapter 2 Sequence for conguring Web Publisher and setting up websites
...
17Chapter 3 Setting Up Users, Groups, and Roles
...
19Users in Web Publisher
...
19Groups in Web Publisher
...
20Roles in Web Publisher
...
21Chapter 4 Setting Up Security
...
23Permissions
...
23Access levels
...
25Extended permissions
...
25Additional access control entries
...
26Folder security
...
27Default alias sets
...
28Permission sets and the Web Publisher DocApp
...
28Editing permissions in the Permissions tab
...
29Chapter 5 Setting Up Lifecycles
...
33Lifecycles overview
...
33Required lifecycle states
...
34Reconfiguring the default lifecycle
...
36Default lifecycle configuration
...
37Advancing files through their lifecycle states
...
39Lifecycles and permissions on active and expired objects
...
39Chapter 6 Creating and Installing Workow Templates
...
43Workflow templates overview
...
43Demoting a change set
...
49Custom dynamic performer values
...
50Simple process workflows
...
51Activating the Web Publisher extended search option (ECI Services)
...
65Saved searches
...
66Defining iMarkup
...
66Storing annotations
...
67Localizing iMarkup
...
68Authoring in supported languages in eWebEditPro
...
68Setting up a link checker
...
69Configuring clients to open web files in authoring applications
...
70Editing XML files in Internet Explorer 5.5 or higher
...
70Setting up Web Publisher to send HTML mail
...
71Integrating Web Publisher with Business Process Services
...
73Configure listeners and message processors for Web Publisher
...
74Prepare and register inbound message handlers and add supporting files
...
76Create a Web Publisher email alias
...
77Create a cabinet to store messages
...
78Copy Web Publisher SBO
...
79Defining integration with CI Server
...
79Integrating Web Publisher and CI Server
...
80Defining CI Server system settings
...
81Mapping CI Server properties with repository properties
...
82Defining automatic property population
...
83Setting property population
...
84Chapter 8 Creating Websites
...
87Overview of creating websites
...
87Site publishing configurations
...
87Default publishing configurations for exporting editions
...
88Synchronous and asynchronous publishing
...
89Site protection
...
90Mirror objects
...
91Determining what content is published
...
92Publishing to multiple sites
...
92Publishing a site in multiple languages
...
93Publishing with different effective dates on different sites
...
93Publishing change sets
...
94Storing multiple effective and expiration dates
...
94Setting effective date as a date in the past
...
96Resetting effective and expiration dates upon checkout
...
96Publishing externally created XML
...
96Web-safe characters
...
97Sequence for creating a new website
...
98Example of setting up a protected site
...
99Creating a site publishing configuration
...
105Updated XML and XSL
...
114Dynamic content using XDQL
...
114Automatically generated names
...
115Extended characters in XML files
...
116XSL includes
...
116Sequence for creating templates
...
117Creating templates for external applications
...
118Creating presentation files for external applications
...
118Presentation files for external applications
...
118Presentation files for eWebEditPro
...
119Defining folder structures for templates
...
120Testing a template
...
120Deleting a rendition
...
121Updating the structure of XML files
...
122Updating XML structure
...
122Creating an instruction file
...
123Examples of instruction files
...
126Updating multiple XML files
...
126Example of how an instruction file updates the structure of an XML file
...
127Chapter 10 Creating Templates for Web Publisher Editor
...
131Web Publisher Editor overview
...
131Transforming content through XDQL and Web Publisher Editor
...
132Sequence for creating Web Publisher Editor templates
...
134Creating content templates for Web Publisher Editor
...
134Creating a content template
...
135Creating an XML-based content template
...
136Creating an HTML-based content template
...
138Examples of Web Publisher Editor templates
...
141Using symbols in XML
...
141Web Publisher Editor attribute extraction
...
142Web Publisher Editor comments
...
143Link management
...
144Creating Editor rules files
...
145Overview of Editor rules files
...
145Absolute and relative paths
...
147Path rule matching
...
147Attribute name value matching
...
147Preview and web view
...
148Repeatdef
...
148Component types
...
149<calendar> element
...
149<checkbox> element
...
152Sample checkbox rules
...
154<choice> element
...
154Sample choice rules
...
157<content> element
...
158<content> element attributes
...
159<repeatdef> nesting elements
...
1871.4 multiple nesting levels
...
188<tabledef> element
...
190Sample <tabledef> elements
...
192<tagcontent> element in non-XML templates
...
193<textarea> element
...
193<textline> element
...
197Sample textline rules
...
199<textselector> element
...
200Sample textselector rules
...
209<xselector> element
...
211Sample xselector rules
...
219Sample xselector filters
...
221Defining a format list
...
223The rules file on the sample website
...
224Creating Editor presentation files (XSL stylesheets)
...
231Validating Web Publisher Editor templates
...
236Chapter 11 Creating Templates for Page Builder
...
239Understanding Web Publisher Page Builder
...
239Understanding the content template
...
240Understanding the blueprint
...
241What a web page looks like
...
243Updating and rendering content for a web page
...
244Using views
...
246Layout view
...
246Content view
...
246Preview
...
247Site view
...
247Rendering content into HTML
...
247Creating a translated web site
...
248Channels
...
248Understanding the blueprint descriptor
...
248Creating a new Page Builder template
...
250Editing Page Builder templates
...
250Importing Page Builder templates
...
251Importing Page Builder Dreamweaver template
...
252Exporting Page Builder templates
...
254Globalization support in Page Builder
...
254How it works?
...
254Choosing an image of a specific locale
...
256Content migration
...
256Update template
...
261Enabling SSI support on the Web View server
...
262Repeating properties in <path_list>
...
272Rules-searching order
...
273How to debug or create a catch-all rule
...
275How folder mapping handles symbols
...
275How folder mapping handles special characters
...
276Specifying that an attribute has no value
...
276Dynamic folder mapping
...
277Dynamic folder mapping with full or partial paths
...
278How dynamic folder mapping handles special characters
...
279How folder mapping uses language_code
...
279Chapter 13 Setting Up Multi-Language Websites
...
281Sequence for setting up multi-language websites
...
281Enabling globalization
...
282Adding a new country and language to the locale creation page
...
282Specifying Web Publisher Editor’s dictionary
...
283Chapter 14 Setting Up Portlets
...
287Portlets overview
...
287Sequence for creating a portal and its components
...
289Creating a new portal
...
290Creating a new target portal server
...
291Creating portlet templates
...
294Portlet Builder templates overview
...
294Creating a new portlet template by an extension of an existing template
...
295Customizing your portlet template components
...
296Examples of customizing portlet template components
...
296Deleting a portlet template
...
300Publishing a portal
...
300Manually publishing a portal
...
302Deploying a web archive (war) file on BEA WebLogic Workshop
...
303Configuring the connection to an LDAP server
...
304Resolving links repository content at runtime
...
305Chapter 15 Using Taxonomies and Categories
...
307How taxonomies work in Web Publisher
...
307Using taxonomies in Web Publisher
...
308Assigning taxonomies to web cabinets
...
310Publishing taxonomies to websites
...
310Storing taxonomy values in properties other than keywords
...
311Chapter 16 Setting Up In-Context Editing (ICE)
...
313Enabling authors to create new content files from the web page
...
318Chapter 17 Creating Custom Tags
...
321Overview of custom tags
...
321Create custom tags in an element definition file
...
322Assign a custom tag set to a content rule
...
324Chapter 18 Understanding Discussions and Comments
...
327Discussion permissions
...
327Using discussions
...
328Searching discussions
...
330Chapter 19 Monitoring Web Publisher
...
331Content transfer
...
331Tracing
...
332Turning on the DFC tracing tool
...
332Accessing tracing
...
332Setting tracing
...
333Testing your API
...
334Testing your DQL
...
335Java Method Server
...
336Verifying the Method Server
...
338Tracing details
...
339Web Publisher application-level settings
...
343Log files
...
345Chapter 20 Troubleshooting
...
347Shared memory error
...
347Java Method Server errors
...
347Effective and expired content
...
348Problems sending HTML mail
...
348Web view
...
349Translation workflows
...
349Troubleshoot Business Process Services
...
350Site publishing configuration
...
350Setting the error_threshold key in Site Caching Services
...
350Translation workflow configuration
...
351In-context editing
...
351Java plug-in install
...
352Formatted text appears different when previewing
...
352wcm_edition
...
366 wcm_channel_fld...
367 wcm_edition_fld...
367 wcm_supporting_doc_folder...
368 wcm_auto_naming...
368 wcm_locale...
368 dm_relation (relations)...
369 DM_TRANSLATION_OF...
370 wcm_category...
370 wcm_default_workflow...
371 wcm_doc_template...
371 wcm_dynamic_content...
372 wcm_layout_template...
372 wcm_my_template...
373 wcm_process_workflow...
374 wcm_publishing_template...
374 wcm_rules_template...
375 wcm_template_thumbnail...
375 wcm_html_editor...
376 wcm_rules_editor...
377 wcm_editor_link...
377 wcm_ewebeditpro_link...
378 wcm_native_edit...
378 wcm_link...
378 wcm_link_internal...
379 wcm_managed_link...
379 wcm_pb_template_blueprint...
380List of Figures
Figure 1–1. Typical 5.3 Web Publisher system configuration
...
16Figure 6–1. Submit to Web Site Workflow
...
46Figure 6–2. Request New Content Workflow
...
47Figure 6–3. Sample French Translation workflow
...
47Figure 6–4. Sample translate and submit to Web Site workflow
...
49Figure 6–5. Simple Process Workflow with Translation Task
...
54Figure 10–1. Transforming content through XDQL and Web Publisher Editor
...
133Figure 10–2. XML-based Web Publisher Editor template and supporting files
...
136Figure 10–3. Rules Editor
...
146Figure 10–4. Calendar
...
150Figure 10–5. Checkbox
...
152Figure 10–6. Choice field
...
155Figure 10–7. Content field in Web Publisher Editor
...
158Figure 10–8. Graphic list selector
...
172Figure 10–9. Graphic tree selector globalization disabled
...
173Figure 10–10. Graphic tree selector globalization enabled
...
174Figure 10–11. Block of repeatable fields
...
182Figure 10–12. A block of nested fields
...
187Figure 10–13. Multiple nested fields
...
189Figure 10–14. Table Editor
...
190Figure 10–15. Textarea field
...
194Figure 10–16. cdata support in <textarea> element
...
196Figure 10–17. Unformatted text in Web Publisher Editor
...
197Figure 10–18. Field for Read-only text
...
198Figure 10–19. Textselector using a list generated by a query
...
201Figure 10–20. Textselector using a tree globalization disabled
...
201Figure 10–21. Textselector using a tree globalization enabled
...
202Figure 10–22. Any type selector page
...
212Figure 10–23. Graphic type selector page
...
212Figure 10–24. File selector
...
219List of Tables
Table 4–1. Access levels
...
25Table 4–2. Extended permissions
...
25Table 4–3. Additional access control entries
...
26Table 4–4. Permissions required under folder security
...
27Table 6–1. Sample language codes and email addresses
...
60Table 6–2. Workflow tasks
...
62Table 6–3. Workflow methods
...
63Table 8–1. Multiple effective and expiration dates
...
95Table 8–2. Example users for site protection
...
99Table 8–3. Example user groups for site protection
...
101Table 8–4. Other example user groups for site protection
...
101Table 8–5. Example group assignments for site protection
...
101Table 8–6. Example alias set for site protection
...
104Table 9–1. Instruction elements
...
124Table 9–2. Elements that set instruction parameters
...
125Table 10–1. Date format patterns
...
151Table 10–2. Date format pattern examples
...
152Table 19–1. Web Publisher 5.3 Methods Configurations (Java Method Server Support)
...
336Table 19–2. Java Method Server Details on Server Machine
...
339Table 19–3. Web Publisher Server Side Tracing Details
...
339Table 19–4. Web Publisher application level configurations in the properties file
...
343Table A–1. dm_sysobject
...
355Table A–2. wcm_config
...
356Table A–3. wcm_user_pref
...
362Table A–4. dm_folder
...
364Table A–5. wcm_change_set
...
364Table A–6. wcm_channel
...
366Table A–7. wcm_edition
...
367Table A–8. wcm_edition_fld
...
367Table A–9. wcm_auto_naming
...
368Table A–10. wcm_locale
...
368Table A–16. wcm_my_template
...
373Table A–17. wcm_process_workflow
...
374Table A–18. wcm_publishing_template
...
374Table A–19. wcm_rules_template
...
375Table A–20. wcm_template_thumbnail
...
376Table A–21. wcm_html_editor
...
376Table A–22. wcm_rules_editor
...
377Table A–23. wcm_editor_link
...
377Table A–24. wcm_ewebeditpro_link
...
378Table A–25. wcm_native_edit
...
378Table A–26. wcm_link
...
379Table A–27. wcm_link_internal
...
379Table A–28. wcm_managed_link
...
380This 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 Description
December 2006 Initial release.
Related documentation
You should be familiar with the following Web Publisher documentation: • Web Publisher User Guide
To download related documentation, go to the support area of
Introduction
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.
Sequence for conguring Web
Publisher and setting up websites
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 congure 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 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 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
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 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.
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.
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
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.
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:
— 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.
Reconguring 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 congure 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.
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 conguration
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
status = AdjustVersionLabel(ObjectId, TargetState, sessionID, docBase, prevState, republish)
LifeCycleAction = status status = CloseLogFile() exit Function Done
else if TargetState = stagingSymbol then
Bug 67235 fix: customize the follow commented out code if demoting to staging from a state that you want to restore the previous data to the cache server for that state. Republish may not be necessary once we fix the other code to include demote.
Dim prevState As String Dim republish As Boolean
prevState = "QA" previous state is QA republish = TRUE
TRUE if you publish the Active version to QA server again status = AdjustVersionLabel(objectID, TargetState,
sessionID, docBase, prevState, republish) LifeCycleAction = status
status = CloseLogFile() exit Function Done end if
You must uncomment out the else part.
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
status = AdjustVersionLabel(ObjectId, TargetState, sessionID, docBase, prevState, republish)
LifeCycleAction = status status = CloseLogFile() exit Function Done
else if TargetState = stagingSymbol then
Bug 67235 fix: customize the follow commented out code if demoting to staging from a state
that you want to restore the previous data to the cache server for that state.
Republish may not be necessary once we fix the other code to include demote.
Dim prevState As String Dim republish As Boolean
prevState = "QA" previous state is QA
republish = TRUE TRUE if you publish the Active version to QA server again
status = AdjustVersionLabel(objectID, TargetState, sessionID, docBase, prevState, republish)
LifeCycleAction = status status = CloseLogFile() exit Function Done end if
Advancing les through their lifecycle states
When you manually promote a document, Web Publisher checks if the document is linked to any other objects that are candidates for promotion. Candidate objects must satisfy the following conditions:
• Have lifecycles that are compatible with the original lifecycle, for example the lifecycle is a super set or subset of the original lifecycle.
• Are in the same lifecycle state (or below) as the original object.
For example, if you promote a WIP object, Web Publisher checks for linked WIP objects. If promoting a Staging object, Web Publisher checks for linked WIP and Staging objects.
• Are not in a change set.
Content must not be bundled together in a change set to be routed through a workflow and lifecycle as a group.
• Are either an automatically linked object (for example, created via an editing application) or a manually linked object where the link type has been defined as one that automatically includes links.
If the object has at least one linked object that is a candidate for promotion, Web Publisher prompts you if you want to promote all linked objects in addition to the original object. If you specify Yes, all candidate objects are promoted to the same target state as the original object. If you specify No, only the selected object(s) are promoted. All promotions of linked objects are asynchronous regardless of how many objects were originally selected.
Synchronization fails if filenames contain commas or if Web configuration objects have names or titles that contain commas, semicolons, or apostrophes.
Lifecycles and permissions on active and
expired objects
In the 4.2 and earlier versions of Web Publisher, the default DocApp contained an alias set called WebPublisherAliasSet. Starting in version 4.3, a new alias set called ACL was introduced. Each of these alias sets contained different alias values that need to be resolved to work with future Web Publisher versions.
Web Publisher uses a lifecycle PostProcedure script called wcmLifecycleScript to resolve alias values from an object’s alias set. The lifecycle PostProcedure script uses a logic to try and resolve the alias value from an object’s alias set (Web Publisher Default lifecycle
always has one default alias set WPGroups. The PostProcedure lifecycle script works in the following way:
• If Web Publisher first uses the alias set, WPGroups, which is the default alias set for the Default Lifecycle, and an object is attached to Default Lifecycle with the alias entries ActiveACL and ExpiredACL then Web Publisher tries to resolve the alias values using the default alias set.
• If Web Publisher does not find any alias values in the default alias set then the PostProcedure script tries to resolve the alias values from the WebPublisherAliasSet alias set.
• If Web Publisher does not find any aliases in the WebPublisherAliasSet alias set then the PostProcedure script tries to resolve the alias values from the ACL alias set. Web Publisher uses an ACL and the ACL alias set to set permissions on an object in the Active or Expired state. The ACL alias set contains the following aliases:
• ActiveACL = Default Active ACL • ExpiredACL = Default Expired ACL
Each value is a permission set template. Content Server resolves alias values using the alias set called WPGroups.
You can set different ACL values on any object in the Active or Expired state by adding the following entries in Documentum Application Builder with custom ACL values to the default lifecycle alias set, WPGroups.
• ActiveACL = Custom ACL name • ExpiredACL = Custom ACL name
To assign new aliases to WPGroups:
1. Launch Documentum Application Builder. 2. Choose File>Open from Docbase.
3. Navigate to the Web Publisher DocApp and double-click its icon to open it. 4. Double-click Default Lifecycle under the Document Lifecycles folder, and click
View.
The default alias set says WPGroups.
5. Double-click ACL under the Alias Sets node, and click View.
Two default aliases are defined in this alias set, ActiveACL and ExpiredACL. 6. Double-click WPGroups under the Alias Sets node, and click Edit.
Four default aliases are defined in this alias set, administrator, content author, content manager, web developer.
7. To assign custom ACLs to objects in the Active and Expired state you must modify the WPGroups alias set.
Add the ActiveACL and ExpiredACL aliases.
For more information on adding a new alias, see the Documentum Application Builder online help.
Creating and Installing Workow
Templates
This chapter describes the following: • Workflow templates overview, page 43
• Custom dynamic performer values, page 50
• Simple process workflows, page 51
• Translation workflows, page 52
• Workflow tasks, page 62
• Workflow methods, page 62
For the procedures for making workflow templates available, associating them, and removing them, see the chapter on Managing Workflow Templates in the Web Publisher User Guide or Web Publisher online help.
Workow templates 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 is 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.
Web Publisher provides default process workflows that enable you to create and publish websites through a series of tasks.
You make a workflow the default for a particular type of content by making it the default for the template that creates that content.
Web Publisher uses process workflows to ensure that Web pages adhere to your organization’s review and management requirements before they are published to a production website. Process workflows manage Web page content from its creation in a repository to its publication on an external website. A process workflow consists of a standard workflow integrated with a lifecycle. You can use the same workflow for all content or create many different workflows for different kinds of content or different authoring groups.
Administrators can use default process workflows as a basis for creating new process workflows with different reviewers, steps, and actions, depending on your organization’s requirements. Administrators can modify task performers using groups or alias sets, modify approval and rejection paths, and customize workflow source files to provide their own alias suggestion values for every alias.
Using a process workflow, you can set Web Publisher to promote content objects automatically to the next state in their lifecycle when a particular task owner submits the change set. The lifecycle controls the publishing and end-of-life processing for the objects in the change set. The creator of a workflow or lifecycle needs to have the Web Publisher Default ACL assigned to them. This allows users to participate in the workflow or lifecycle.
All Web Publisher workflows must begin with a Start task, which is an automatic task that runs the method wcmInitializeProcessWorkflow. The Start task ensures that while a workflow is in progress, attached files are blocked from being sent to other workflows. After the Start task begins Web Publisher labels the file as in a workflow using a special icon. Web Publisher automatically launches a process workflow when a user submits a WIP file and the file has a mandatory default workflow. If the file does not have a mandatory default workflow then users will need to select a workflow from a list of default workflows. Web Publisher then automatically creates a change set for the file. Once the process workflow begins, the change set appears as a task for the next performer. Performers can view or edit the files and supporting files in the change set and they can add files or delete files from the change set before the change set is in Staging. Only local files and replicated files residing in the same repository as the local files can be added to the same change set. Replicas can be added to the change set only as supporting files. When a performer forwards the task, Web Publisher automatically promotes the change set (if configured to do so) to the next state in the lifecycle. The change set then appears as a task for the next performer in the workflow.
back to the previous state. The actions of a reject task are determined by the workflow template designed by the workflow designer. By default, demoting a change set demotes all the files in the change set. Administrators can change the default so only the change set, not the files in the change set, are demoted.
If a workflow task is rejected, and the workflow template rejection path points back to a group, all users of that group will receive the rejection notice, not just the user who originally acquired the task in the group.
All Web Publisher workflows must end with a Cleanup task, which is an automatic task that runs the method wcmTerminateProcessWorkflow. The Cleanup task removes the block that bars files from being sent to other workflows.
Workflow templates are a reusable network of activities and the relationships between the activities that can be used to create workflows.
Administrators use Workflow Manager (WFM) or Business Process Manager (BPM) to create workflow templates that specify a series of tasks to be performed by specific participants in a specific order. Workflow Manager or Business Process Manager provides a graphical environment to design or modify workflow templates. Workflow templates behave like other objects in the repository. You can check them out, modify them, and check them in as new versions.
You can access Workflow Manager through Web Publisher or through Documentum Application Builder. Business Process Manager is a separate application that must be installed using Business Process Manager Installation Guide.
Web Publisher provides you with a default workflow template, but administrators can create custom workflow templates to meet business specific needs. When you create a workflow template, it inherits your permissions so you must ensure your permissions enable users to access the workflow template. Users need to access the workflow template to assign it to files during import into a Web Publisher repository. We recommend using the Web Publisher User Default ACL or an ACL with identical permissions.
To create a new workflow template in Workflow Manager, use Web Publisher’s New Workflow Template command or File>New>Workflow Template command. Workflow Manager opens. For information on creating a new workflow template, open Workflow Managers online help.
To create a new workflow template from Business Process Manager use the instructions in the Business Process Manager Administration Guide.
Default Web Publisher workflow templates are stored in Cabinets/System/ Applications/Web Publisher. Custom workflow templates are stored in
Cabinets/System/Applications/Web Publisher/user defined. Only Web Publisher workflow templates stored in the user defined folder can be added or removed from the Web Publisher workflow template list stored in Administration/Web Publisher Admin/Workflow Templates. Once a workflow is installed using Workflow Manager, you must make it available to Web Publisher users.
If you create a custom workflow template to use as the Web Publisher default, you must set the workflow default on the Properties page of a specific locale or the Associate page of a specific content template.
To add workflow templates to Web Publisher, refer to the chapter on Managing Workflow Templates in the Web Publisher User Guide or Web Publisher online help. Because workflows route change sets, all Web Publisher workflow templates must have one, and only one, package that contains a dm_sysobject. This allows Web Publisher to attach the change set to any workflow template. A change set is an object that contains the files being routed. Only local files and replicated files residing in the same repository as the local files can be added to the same change set. Replicas can be added to the change set only as supporting files. When a user submits a content file to a workflow, Web Publisher automatically creates a change set to hold the file. The change set allows users to add or remove files from the workflow, and promote or demote groups of files within a workflow as it progresses.
Note: By default, demoting a change set demotes all the files in the change set. Administrators can change the default so only the change set not the files in the change set are demoted.
Web Publisher provides the default workflow templates described here. These templates are shown in Workflow Manager not Business Process Manager.
Submit to Web site is a simple workflow intended to be used by content authors to publish their content to the website. When a content author submits a file to this workflow template, Web Publisher creates a change set and promotes the change set to Staging prior to review. If a reviewer rejects the task, Web Publisher demotes the change set to WIP and routes it back to its originator. If a reviewer approves the task, Web Publisher routes the change set to an approver, who forwards it, and the change set is promoted to Approved.
Figure 6-1. Submit to Web Site Workow
Request new content, which allows content managers to assign authors to create content. When starting this workflow template (either with or without a file in the change set), the content manager specifies an author to work on the content. The author might need to first create the content file and add the file to a workflow. After the content author completes the work, Web Publisher promotes the change to Staging prior to review. If a reviewer rejects the task, Web Publisher demotes the change set to WIP and routes it
back to the author. If a reviewer approves the task, Web Publisher routes the change set to an approver who forwards it for promotion to Approved.
Figure 6-2. Request New Content Workow
Sample French translation workflow allows participants, users and groups inside or outside your organization to work on translations. When a participant works on a translate task, Web Publisher automatically filters on the locale specified in the subject to indicate which objects need to be translated. Participants are then able to launch the object to be translated into the appropriate editing application and look at the previously translated version, if one exists. After the participant completes the translation, Web Publisher promotes the translation to Staging prior to review. If a reviewer rejects the task, Web Publisher demotes the translation to WIP and routes it to the translator participant. If a reviewer approves the task, Web Publisher forwards it for promotion to Approved.
This workflow is a sample because you may not be able to use this workflow template out of the box. You must modify the translation workflow for your specific locales.