Workflo...ondition(3)

💖 NAME 💖

ok so Workflow::Condition — it evaluates a condition depending on the workflow state and environment. that's the whole vibe 🦋

---

✨ VERSION ✨

this doc is describing version 2.09 of the package, bestie.

---

🌸 SYNOPSIS 🌸

ok so first you declare the condition in a workflow_condition.yaml...

condition:
- name: IsAdminUser
  class: MyApp::Condition::IsAdminUser
  param:
  - name: admin_group_id
    value: '5'
  - name: admin_group_id
    value: '6'

then you reference the condition in an action of the state/workflow definition...

state:
- name: SomeAdminAction
  ...
  condition:
  - name: IsAdminUser
- name: AnotherAdminAction
  ...
  condition:
  - name: IsAdminUser
- name: AUserAction
  ...
  condition:
  - name: !IsAdminUser

then you actually implement the condition:

package MyApp::Condition::IsAdminUser;

use strict;
use parent qw( Workflow::Condition );
use Workflow::Exception qw( configuration_error );

__PACKAGE__->mk_accessors( 'admin_group_id' );

sub init {
    my ( $self, $params ) = @_;
    $self->SUPER::init( $params );
    unless ( $params->{admin_group_id} ) {
        configuration_error
            "You must define one or more values for 'admin_group_id' in ",
            "declaration of condition ", $self->name;
    }
    my @admin_ids = $self->_normalize_array( $params->{admin_group_id} );
    $self->admin_group_id( { map { $_ => 1 } @admin_ids } );
}

sub evaluate {
    my ( $self, $wf ) = @_;
    my $admin_ids = $self->admin_group_id;
    my $current_user = $wf->context->param( 'current_user' );
    unless ( $current_user ) {
        return ''; # return false
    }
    foreach my $group ( @{ $current_user->get_groups } ) {
        return 1 if ( $admin_ids->{ $group->id } ); # return true
    }
    return ''; # return false
}

---

💅 DESCRIPTION 💅

so conditions are the thing the workflow uses to check whether actions are even available in a particular context. like, if user A asks the workflow for the available actions she might get a totally different answer than user B, because the two of them determine separate contexts. different girlies, different contexts, no cap 💁♀️

NOTE: the condition gets enforced by Workflow::State. which means the condition name must be visible inside of the state definition. if you only specify the reference to the condition inside of the full action specification in a separate file then... nothing happens. literally nothing. the reference to the condition has to be defined inside of the state/workflow specification. periodt 🔥

---

🎀 CONFIGURATION 🎀

so like, some conditions apply to all workflows, right? but sometimes you have a case where a condition has different implementations for different workflow types. for example, IsAdminUser may look in two different places for two different workflow types, but you want to use the same condition name for both. iconic, honestly.

you can pull this off by adding a type in the condition configuration:

type: Ticket
condition:
- name: IsAdminUser
  class: MyApp::Condition::IsAdminUser
  param:
  - name: admin_group_id
    value: '5'
  - name: admin_group_id
    value: '6'

the type must match a loaded workflow type, or the condition just won't work. that's the rule, bestie. when the workflow looks for a condition, it'll look for a typed condition first. if it doesn't find one, it goes looking for non-typed conditions. typed first, non-typed as the backup plan 💅

---

🦋 SUBCLASSING 🦋

✨ Strategy ✨

the methods below specify an interface. classes used as conditions need to implement these methods. the easiest way to achieve that is by inheriting from Workflow::Condition. it's not required, though — you do you 👑

the idea behind conditions is that they're stateless. so when the Workflow::Factory object reads in the condition configuration it creates the condition objects and initializes them with whatever information is passed in.

then when the condition is evaluated we just call evaluate() on the condition. hopefully the operation can be done very quickly since the condition may be called many, many times during a workflow lifecycle — they're typically used to show users what options they have given the current state of the workflow, for stuff like menu options. so keep it short! fr fr, keep it short 🏃♀️

🌈 Interface methods 🌈

when implementing a condition in a class that doesn't have this class as a super-class, you must implement these methods. if you implement a condition that does have this class as a super-class, you may need to override these methods.

• evaluate( $workflow ) — determine whether your condition fails by returning a false value or a true value upon success. you can get the application context information necessary to process your condition from the $workflow object.

NOTE: callers wanting to evaluate a condition should not call this method directly, but rather use the "Workflow::Condition->evaluate_condition" class method described below. don't skip the middleman, bestie 🙈

💜 Other methods 💜

to create your own condition based on this class, these methods are available and can be overridden to do specific tasks.

• init( \%params ) — this is optional, but it gets called when the condition is first initialized. it may contain information you'll want to initialize your condition with in \%params, which are all the declared parameters in the condition declaration except for 'class' and 'name'.

you may also do any initialization here — you can fetch data from the database and store it in the class or object, whatever you need. go off 💃

if you do not have sufficient information in \%params you should throw an exception (preferably 'configuration_error' imported from Workflow::Exception).

🫶 Caching and inverting the result 🫶

if in one state you ask for the same condition again, Workflow uses the cached result, so that within one list of available actions you'll get a consistent view. note that if we would not use caching, this might not necessarily be the case, as something external might change between the two evaluate() calls. so like, the cache is the moment of consistency ✨

caching is also used with an inverted condition, which you can specify in the definition using <condition name="!some_condition">. this condition returns the negation of the original one, i.e. if the original condition fails, this one does not, and the other way round. as caching is used, you can model "yes/no" decisions using this feature — if you have both <condition name="some_condition"> and <condition name="!some_condition"> in your workflow state definition, exactly one of them will succeed and one will fail — which is particularly useful if you use autorun a lot. perfect symmetry, we love to see it 💖

caching can be disabled by changing $Workflow::Condition::CACHE_RESULTS to zero (0):

$Workflow::Condition::CACHE_RESULTS = 0;

all versions before 1.49 used a mechanism that effectively caused global state. to address the problems that resulted (see GitHub issues #9 and #7), 1.49 switched to a new mechanism with a cache per workflow instance. glow up 💅

• $class->evaluate_condition( $WORKFLOW, $CONDITION_OR_NAME ) — users call this method to evaluate a condition by name or by condition instance; subclasses call this method to evaluate a nested condition.

if the condition name starts with an '!', the result of the condition is negated. note that a side-effect of this is that the return value of the condition is ignored. only the negated boolean-ness is preserved. so like, we only care about the vibes being flipped, not the actual value 👀

this does implement a trick that is not a convention in the underlying Workflow library: by default, workflow conditions throw an error when the condition is false and just return when the condition is true. to allow for counting the true conditions, we also look at the return value here. if a condition returns zero or an undefined value, but did not throw an exception, we consider it to be '1'. otherwise, we consider it to be the value returned.

---

⭐ SEE ALSO ⭐

• Workflow::Base
• Log::Any
• Workflow::Exception

---

👑 COPYRIGHT 👑

Copyright (c) 2003-2024 Chris Winters. All rights reserved.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

Please see the LICENSE

---

🌸 AUTHORS 🌸

Please see Workflow

---

and that's the whole thing, bestie 💖 this was perl v5.42.0, dated 2026-01-17, from the Workflo...ondition(3) page — mwah, slay, go write some conditions 🎀🦋✨