Custom Condition Types

Overview

Condition Types define the logic that determines whether an Action is allowed to execute under specific conditions. This mechanism ensures that actions are only triggered when predefined rules are met.

Each Action has a Conditions Type field that determines how the execution rules are defined. The system supports two built-in condition types and also allows for custom ones.

Condition Types

Basic

When the Basic type is selected, a simple rule builder UI is displayed, allowing users to define conditions using common logical comparisons. These conditions are evaluated based on the current entity context.

Examples:

• Status is "Completed"
• Quantity > 10

Expression

When the Expression type is selected, users write the condition as a Symfony Expression Language expression. This provides more flexibility and allows referencing complex expressions and conditions.

Example:

entity.get('status') == 'completed' and entity.get('priority') > 2

The result of the expression is cast to boolean. The expression is compiled into a PHP class when the Action is saved, so evaluating it at runtime costs a single method call — see Expression Language for the details and for the list of variables available in each context.

A third, deprecated type — Script — defined the condition as a Twig template that output a proceed variable. Existing records keep working, but the field is read-only and Script is no longer offered when configuring a new condition. Twig and the Expression Language are separate languages, so such conditions are rewritten by hand rather than converted.

Custom Condition Types

For advanced use cases where neither Basic nor Expression types are sufficient or performant — for example, when complex data relationships or multiple database lookups are required — the system provides support for Custom Condition Types.

Use Cases for Custom Condition Types

• Determine eligibility based on relationships across multiple entities.
• Implement role-based restrictions based on a dynamic permission model.
• Perform cross-entity validation or join-based lookups in the database.
• Evaluate external data or trigger remote validation services.

Best Practices

• Optimize Logic: Keep the proceed() method efficient and avoid unnecessary database queries.
• Use Services: Leverage existing service classes to encapsulate complex logic or data access.
• Keep It Focused: Design each condition type for a single, clear purpose to improve reusability and maintainability.

Creating a Custom Condition Types

To create a new custom condition type, run the following command on the server:

php console.php create condition type OwnCondition

Here, OwnCondition is the name of your custom condition class.

This command generates a PHP file with the following structure:

<?php

namespace CustomConditionTypes;

use Atro\ConditionTypes\AbstractConditionType;

class OwnCondition extends AbstractConditionType
{
    public static function getTypeLabel(): string
    {
        return 'OwnCondition';
    }

    public static function getEntityName(): string
    {
        return 'Product';
    }

    public function proceed(\stdClass $input): bool
    {
        return true;
    }
}

Key Methods