Chia-liang Kao (高嘉良) > RTx-WorkflowBuilder-1.02 > rt-workflow

Download:
RTx-WorkflowBuilder-1.02.tar.gz

Annotate this POD

CPAN RT

New  2
Open  0
View/Report Bugs
Source  

NAME ^

rt-workflow - helper for configuring approval workflow in RT

SYNOPSIS ^

In your RT_SiteConfig.pm:

  Set( $WorkflowBuilderStages,
       { 'Manager approval' =>
         { content => '.....',
           subject => 'Manager Approval for PO: {$Approving->Id} - {$Approving->Subject}',

           owner => q!{{
    Fire                => "moss",
    IT                  => "roy",
    Marketing           => "jen"}->{ $Approving->FirstCustomFieldValue('Department') }}! },
         'Finance approval' =>
         { content => '... ',
           owner => 'CFO',
         },
         'CEO approval' =>
         { content => '..........',
           owner => 'CEO',
         }});

  Set( $WorkflowBuilderRules,
  { 'PO-Approval' => [ 'Manager approval' => 'Finance approval' => 'CEO approval'],
    'Vacation-Approval' => [ 'Manager approval' => 'CEO approval']
 }
);

# to enable the workflow rules described in "PO-Approval" for the PO queue: % bin/rt-workflow PO PO-Approval --create

# to update the workflow associated with the PO queue once you changed # the configuration % bin/rt-workflow PO PO-Approval

DESCRIPTION ^

This module allows you to define approval stages and approval rules in your RT_SiteConfig.pm and builds the appropriate scrips for you.

$WorkflowBuilderStages

The config value should be a hashref, with keys being the name of the approval stage, and values being a hashref of the approval specification, which can include the usual fields for ticket such as owner, subject. note that the values can be interpolated just like normal RT Template (escaped with {}), and you can access the ticket to be approved with the variable $Approving.

$WorkflowBuilderRules

The config value should be a hashref, with keys being the name of the approval rule, and the values being arrayref denoting the stages of the approval in the suitable order.

A stage with parallel approvals where any of them can move the approval workflow to next stage, can be represented as another arrayref in the approval chain. For example:

  ['Manager approval' => 'Financial approval' => 'CEO approval']

implies a monotonous approval chain that goes from manager to financial, and finally to CEO.

  ['Manager approval' => ['HR', 'VP'] => 'CEO approval']

implies after manager approval, either one of HR or VP approval will make it go to CEO approval.

syntax highlighting: