WORKFLOW* -- macros associated with WorkflowPlugin
All the following macros accept web and topic parameters:
Parameter |
Meaning |
Default |
web |
(Optional) name of the web containing the topic |
current web |
topic |
(Optional) name of the topic (may use web.topic syntax) |
current topic |
Where it makes sense, the macros also accept a
rev
parameter.
If the topic is
not controlled, then any references to
WORKFLOW
macros are simply removed. You can use this behaviour to place these
tags in the header or footer in your skin templates. They appear only
if the currently displayed topic is controlled.
%WORKATTACHTOPIC%
Expands to a link that lets you attach to the topic (if you are not
able to modify the topic, either in the workflow sense or according to the
tandard access controls, the link will be
struck out).
%WORKFLOWEDITTOPIC%
Expands to a link that lets you edit the topic (if you are not able to
modify the topic, either in the workflow sense or according to the
standard access controls, the link will be
struck
out).|
%WORKFLOWFORK{...}%
Expands to a button that will create one or more copies of a topic
(which must be in a workflow). You must have edit (CHANGE) access to
the topic to be forked.
Parameter |
Meaning |
Default |
newnames="NameOne,NameTwo,..." |
Comma-separated list of name(s) of the new topic(s) to create. AUTOINC is supported, and you can use a web specifier on the topic names. |
required, no default. |
label="Fork" |
Label to use in the button |
"Fork" |
lockdown="on" |
Set this if you want the forked topic to be set as uneditable by all except admins after the fork. This will also prevent the topic from being forked again. |
off |
Used when you have a topic that has to be split to follow different
routes through a workflow - for example, when a requirement is refined
to create two new requirements that must follow their own lifecycles;
or perhaps a problem report is found to affect two different
components of a system, and the resolutions have to be separately
tracked.
For example,
%WORKFLOWFORK{topic="OriginalTopic" label="Divide and conquer" newnames="ForkPathOne,ForkPathTwo" lockdown="on"}%
will create two copies of
OriginalTopic
, named
ForkPathOne
and
ForkPathTwo
and set the
OriginalTopic
as uneditable (using
ALLOWTOPICCHANGE).
The fork copies do not inherit the history of the forked topic - their
history starts afresh with the fork.
due to a bug in versions of the plugin prior to Oct 2009, the
default parameter was interpreted as the name of the
new topic to fork to. This has been corrected, but the macro will
revert to the old meaning if you omit the
newnames
parameter.
%WORKFLOWTRANSITION%
Expands to either (a) a pull-down menu if the user can perform more
than one transition, (b) a button if the current user can only perform
one transition, or © empty space if the current user is not allowed
to perform any action. You can change the format of the button using a
CSS class (see WORKFLOWTRANSITIONCSSCLASS below) or by deriving your own
version of
workflowstrings.tmpl
%WORKFLOWHISTORY{...}%
Expands to the history of state transitions the topic has undergone.
Parameter |
Meaning |
Default |
format |
Format of each transition |
$state -- $date |
header |
Header before results |
|
footer |
Footer after results |
|
separator |
Separator between results |
<br /> |
include |
Perl regular expression matching states to include |
|
exclude |
Perl regular expression matching states to exclude |
|
The
format
,
header
,
footer
and
separator
parameters provide the control necessary to make the history look nice
when it is viewed.
In this example the history is formatted as a simple table:
%WORKFLOWHISTORY{format="| $state | $author | $date |" separator="$n"}%
The standard
FormatTokens are supported, as well as the following
special tokens:
Token |
Expands to |
$author |
Who triggered the transition to this state (also $user and $wikiusername ) |
$comment |
Comment accompanying the record |
$date |
Date/time of the transition in the default format (you can format your own date using the same formatting tokens as used by %GMTIME% ) |
$index |
1-based number of this result |
$name |
Version at the transition (also $rev ) |
$state |
The state of the topic after the recorded event occurred |
%WORKFLOWLAST{...}%
Expands to the history recorded when the topic was last in a certain state.
The
format
is the same as that used for
%WORKFLOWHISTORY%
.
%WORKFLOWSTATE%
Expands to the current state of the topic.
%WORKFLOWSTATEMESSAGE%
Expands to the corresponding message in the state table for the current state.