1Workflow::Condition(3)User Contributed Perl DocumentationWorkflow::Condition(3)
2
3
4

NAME

6       Workflow::Condition - Evaluate a condition depending on the workflow
7       state and environment
8

VERSION

10       This documentation describes version 1.51 of this package
11

SYNOPSIS

13        # First declare the condition in a 'workflow_condition.xml'...
14
15        <conditions>
16          <condition
17             name="IsAdminUser"
18             class="MyApp::Condition::IsAdminUser">
19                <param name="admin_group_id" value="5" />
20                <param name="admin_group_id" value="6" />
21          </condition>
22        ...
23
24        # Reference the condition in an action of the state/workflow definition...
25        <workflow>
26          <state>
27            ...
28            <action name="SomeAdminAction">
29              ...
30              <condition name="IsAdminUser" />
31            </action>
32            <action name="AnotherAdminAction">
33             ...
34             <condition name="IsAdminUser" />
35            </action>
36            <action name="AUserAction">
37             ...
38             <condition name="!IsAdminUser" />
39            </action>
40          </state>
41          ...
42        </workflow>
43
44        # Then implement the condition
45
46        package MyApp::Condition::IsAdminUser;
47
48        use strict;
49        use base qw( Workflow::Condition );
50        use Workflow::Exception qw( condition_error configuration_error );
51
52        __PACKAGE__->mk_accessors( 'admin_group_id' );
53
54        sub _init {
55            my ( $self, $params ) = @_;
56            unless ( $params->{admin_group_id} ) {
57                configuration_error
58                    "You must define one or more values for 'admin_group_id' in ",
59                    "declaration of condition ", $self->name;
60            }
61            my @admin_ids = $self->_normalize_array( $params->{admin_group_id} );
62            $self->admin_group_id( { map { $_ => 1 } @admin_ids } );
63        }
64
65        sub evaluate {
66            my ( $self, $wf ) = @_;
67            my $admin_ids = $self->admin_group_id;
68            my $current_user = $wf->context->param( 'current_user' );
69            unless ( $current_user ) {
70                condition_error "No user defined, cannot check groups";
71            }
72            foreach my $group ( @{ $current_user->get_groups } ) {
73                return if ( $admin_ids->{ $group->id } );
74            }
75            condition_error "Not member of any Admin groups";
76        }
77

DESCRIPTION

79       Conditions are used by the workflow to see whether actions are
80       available in a particular context. So if user A asks the workflow for
81       the available actions she might get a different answer than user B
82       since they determine separate contexts.
83
84       NOTE: The condition is enforced by Workflow::State. This means that the
85       condition name must be visible inside of the state definition. If you
86       specify the reference to the condition only inside of the full action
87       specification in a seperate file then nothing will happen. The
88       reference to the condition must be defined inside of the state/workflow
89       specification.
90

CONFIGURATION

92       While some conditions apply to all workflows, you may have a case where
93       a condition has different implementations for different workflow types.
94       For example, IsAdminUser may look in two different places for two
95       different workflow types, but you want to use the same condition name
96       for both.
97
98       You can accomplish this by adding a type in the condition
99       configuration.
100
101        <conditions>
102        <type>Ticket</type>
103          <condition
104             name="IsAdminUser"
105             class="MyApp::Condition::IsAdminUser">
106                <param name="admin_group_id" value="5" />
107                <param name="admin_group_id" value="6" />
108          </condition>
109        ...
110
111       The type must match a loaded workflow type, or the condition won't
112       work.  When the workflow looks for a condition, it will look for a
113       typed condition first. If it doesn't find one, it will look for non-
114       typed conditions.
115

SUBCLASSING

117   Strategy
118       The idea behind conditions is that they can be stateless. So when the
119       Workflow::Factory object reads in the condition configuration it
120       creates the condition objects and initializes them with whatever
121       information is passed in.
122
123       Then when the condition is evaluated we just call "evaluate()" on the
124       condition. Hopefully the operation can be done very quickly since the
125       condition may be called many, many times during a workflow lifecycle --
126       they are typically used to show users what options they have given the
127       current state of the workflow for things like menu options. So keep it
128       short!
129
130   Methods
131       To create your own condition you should implement the following:
132
133       init( \%params )
134
135       This is optional, but called when the condition is first initialized.
136       It may contain information you will want to initialize your condition
137       with in "\%params", which are all the declared parameters in the
138       condition declartion except for 'class' and 'name'.
139
140       You may also do any initialization here -- you can fetch data from the
141       database and store it in the class or object, whatever you need.
142
143       If you do not have sufficient information in "\%params" you should
144       throw an exception (preferably 'configuration_error' imported from
145       Workflow::Exception).
146
147       evaluate( $workflow )
148
149       Determine whether your condition fails by throwing an exception. You
150       can get the application context information necessary to process your
151       condition from the $workflow object.
152
153       _init
154
155       This is a dummy, please refer to "init"
156
157   Caching and inverting the result
158       If in one state, you ask for the same condition again, Workflow uses
159       the cached result, so that within one list of available actions, you
160       will get a consistent view. Note that if we would not use caching, this
161       might not necessary be the case, as something external might change
162       between the two evaluate() calls.
163
164       Caching is also used with an inverted condition, which you can specify
165       in the definition using "<condition name="!some_condition"">.  This
166       condition returns exactly the opposite of the original one, i.e.  if
167       the original condition fails, this one does not and the other way
168       round. As caching is used, you can model "yes/no" decisions using this
169       feature - if you have both "<condition name="some_condition""> and
170       "<condition name="!some_condition""> in your workflow state definition,
171       exactly one of them will succeed and one will fail - which is
172       particularly useful if you use "autorun" a lot.
173
174       Caching can be disabled by changing $Workflow::Condition::CACHE_RESULTS
175       to zero (0):
176
177           $Workflow::Condition::CACHE_RESULTS = 0;
178
179       All versions before 1.49 used a mechanism that effectively caused
180       global state. To address the problems that resulted (see GitHub issues
181       #9 and #7), 1.49 switched to a new mechanism with a cache per workflow
182       instance.
183
185       Copyright (c) 2003-2021 Chris Winters. All rights reserved.
186
187       This library is free software; you can redistribute it and/or modify it
188       under the same terms as Perl itself.
189
190       Please see the LICENSE
191

AUTHORS

193       Please see Workflow
194
195
196
197perl v5.32.1                      2021-01-31            Workflow::Condition(3)
Impressum