Part 2.2 - Configuring availiable_templates.cfg

---

The available_templates.cfg file is an XML configuration file that lists all of the workflow templates that are available for use on the TeamSite server. For each workflow, this file indicates the name of workflow, the location of the workflow template file, and the conditions under which the workflow is available.

By default, the available_templates.cfg file is located in:

C:\Program Files\Interwoven\TeamSite\local\config\wft (Windows)
/Interwoven/TeamSite/local/config/wft (UNIX)




Note: If available_templates.cfg is edited and contains non-ASCII text, it must be saved in UTF-8 encoding.

The available_templates element is the container element for the file. This element contains the following attribute:

require_workarea — specify whether (true) or not (false) workflow templates selection screen will include a branch/workarea chooser if workarea context is not present. Most of the out of the box workflow template examples require this to be enabled (require_workarea="true") to work properly. Default value is false.

Within the available_templates element is the template_file element:

<available_templates require_workarea="true">

  <template_file name="Author Submit Workflow"

    path="solutions/configurable_author_submit.wft">

    ...

  </template_file>

</available_templates>

The template_file element has the following attributes:

name — specify the title of the workflow, for example:
name="Author Submit Workflow"

active — indicate whether (yes) or not (no) the workflow template is enabled. Default value is yes.
path — specify the path where the template file resides. Template files must reside in one of the following locations:


iw‑home/local/config/wft/default
iw‑home/local/config/wft/examples
iw‑home/local/config/wft/solutions




The value you specify is relative to the iw‑home/local/config/wft directory, so if the template file resided in the following absolute path:






iw‑home/local/config/wft/default/author_submit.wft






then you would specify the value:
path="default/author_submit.wft"

Specifying Template Access

You can configure access to each template listed in the available_templates.cfg file by using any combination of the following categories:

Command
Role
Group
User
Branch

The categories can be combined using boolean terms such as AND, OR, and NOT to include and exclude those that meet the inclusion or exclusion criteria you configure. Template access is configured within the allowed element, which is a subelement of template_file:

Within the template_file element is the allowed element, where you can configure user access by matching workflow commands with user roles:

<template_file ...>

  <allowed>

    ...

  </allowed>

</template_file>

Command Access

Workflow commands are specified by the command element. The command element specifies the user-activity that starts the corresponding workflow. For example, the following configuration:

<command name="submit"/>

specifies that the associated workflow is started when performing a Submit and that it cannot be invoked by other means.

The valid command values that you can associate with a workflow are:

submit (submitting files)
assign (assign button or menu item)
new_job (new job)
new_TFO_job (new job, in TeamSite FrontOffice)
tt_data (saving FormsPublisher data records)
tt_deletedcr (deleting FormsPublisher data records in ContentCenter Standard only)
all (all possible values from this list)




Note: The tt_data command is valid in ContentCenter Standard and can be configured in ContentCenter Professional; see the User Interface Customization Guide. The tt_deletedcr command is only valid when users are using the ContentCenter Standard interface; in ContentCenter Professional, this command is not valid and data records are treated like any other assets.

Role Access

Access based on TeamSite roles is specified by the role element’s name attribute. For example, the following configuration:

<role name="author"/>

specifies that if the user is logged in as an Author.

Group Access

Access based on user groups is specified by the group element:

<group name="marketing"/>

User Access

Access based on individual user name is specified by the user element:

<user name="jdoe"/>

Branch Access
Access based on TeamSite branch is specified by the branch element: 

<branch="/default/products"/>

Combining Access Categories

Pairings of individual or multiple access elements can be included or excluded using the and, or, and not elements within the allowed element. You can use boolean logic to create combinations of categories that can either have access to a specific template, or be excluded from it.
In the following example: 

<template_file name="Author Submit" path="default/author_submit.wft">

  <allowed>

    <and>

      <command name="submit"/>

      <or>

        <role name="author"/>

        <role name="editor"/>

        <group name="marketing"/>

        <and>

          <role name="admin"/>

          <not>

            <user name="jdoe"/>

          </not>

        </and>

      </or>

    </and>

  </allowed>

</template_file>

the following individuals have access to the Author Submit workflow:

Those who are authorized to perform submit commands.
Those who have the author or editor role.
Those who are members of the marketing group.
Those who have the admin role, with the exception of the user jdoe.

If no access category is specified, it is assumed that category has full access to the workflow template.

Regular Expression Support

You can use regular expressions when specifying branch element constraints within available_templates.cfg to search for a specified pattern and specify what to do when matching patterns are found. Using regular expressions allows a greater level of flexibility when adding items.

For example, if you want only the users in the three administration_1 branches (a1, a2, and a3) to access a workflow template, you can set the following constraint:

<allowed>

  <or>

    <branch name="/default/main/administrator_1/a1"/>

    <branch name="/default/main/administrator_1/a2"/>

    <branch name="/default/main/administrator_1/a3"/>

  </or>

  ...

</allowed>

If a new branch called a4 is added to /default/main/administrator_1 you could manually update the available_templates.cfg file to allow access for users in the new branch by adding the branch element to the existing ones:

<branch name="/default/main/administrator_1/a4"/>

Or you could modify the available templates.cfg file to use the following regular expression and, thus, automate the constraints placed on the a4 branch:

<allowed>

  <and>

    <branch name="/deault/main/administrator_1/.*"/>

  </and>

  ...

</allowed>

This regular expression allows users from any branch under /deault/main/administrator_1 to have access to the template.

Path Separators

When using regular expressions, the path-separators (“\”, “\\”, “/”) are all translated to “/” in both the pattern and the string to match against before attempting the match.
In the following example:

<branch name="foo"/>

any branch path that includes the string foo will be matched. Here the following examples match:

/default/main/food/...

/default/main/barfoo/...

In the next example:

<branch name="^/default/main/foo"/>

any branch path that begins with the value-string will be matched. Here the following example matches:

/default/main/food/...

while this one does not:

/default/main/barfoo/...

The following examples are all treated as identical on both Windows and UNIX.

<branch name="^/default/main/foo" include="yes"/>

<branch name="^\default\main\foo" include="yes"/>

<branch name="^\\default\\main\\foo" include="yes"/>

<branch name="^/default\main\\foo" include="yes"/>