Skip to the content
Documentation

Workflows

No ratings yet

A workflow adds steps to an operation of the system. The usual example is an approval: when an editor publishes, an editor-in-chief must approve before the new version goes live. Other workflows wait until a date, choose a sub-workflow by class or section, ask for payment in the webshop or add shipping costs. Workflows are configured in the administration, without code; extensions can add new kinds of steps.

The parts of the workflow system

Term What it is Where
Workflow A named, ordered list of events, kept in a workflow group. Setup > Workflows (/workflow/grouplist)
Event One step of a workflow, of an event type. The workflow's edit page
Trigger Connects a workflow to an operation, before or after it: content/publish before, shop/checkout after and so on. One workflow per trigger. Setup > Triggers (/trigger/list)
Workflow process One run of a workflow for one object version and one user that has not finished yet. Setup > Workflow processes (/workflow/processlist)

The event types of the kernel

Event type What it does
Approve (ezapprove) Holds a version until an approver accepts it, through a collaboration item in the approver's inbox. Configured by sections, languages, editors and approvers.
Wait until date (ezwaituntildate) Holds publishing until the date in a date attribute of the object.
Multiplexer (ezmultiplexer) Starts another workflow depending on the class, section, language or user group.
Payment gateway (ezpaymentgateway) Hands an order to a payment provider in the webshop.
Simple shipping (ezsimpleshipping) Adds a shipping cost to an order (workflow.ini [SimpleShippingWorkflow]).
Finish user register (ezfinishuserregister) Completes a user registration.
Approve user accounts (expuserapprove) Holds a new account until an administrator approves it.

The event types on offer are listed in workflow.ini [EventSettings] AvailableEventTypes[]; extensions add their own event types (in their eventtypes/ directory, registered in their workflow.ini.append.php).

How a workflow runs: approval before publishing

  1. An editor presses Send for publishing. The publish operation marks the version pending.
  2. The trigger content/publish before finds the approval workflow and starts a process for this object version.
  3. The Approve event creates the approval request and answers "run me again later". The process now waits for the workflow cronjob, and the publish operation stops there.
  4. The approver opens the request and approves or denies it.
  5. The next run of the workflow cronjob continues the process. Approved: the rest of the publish operation runs and the version is published. Denied: the version goes back to its author, and the process ends.

What the kernel saved of the held-back operation so that the cronjob can finish it later is called a memento (the table ezoperation_memento).

Triggers and the cronjob

The operations that can trigger a workflow are listed in workflow.ini [OperationSettings] AvailableOperationList[]: content publishing (content_publish), and the shop operations add to basket, update basket, confirm order and checkout. Each can run a workflow before and after the operation.

Workflows that wait need the cronjob workflow.php, which is in the frequent part of cronjob.ini. Without it, an approved article is never published:

php runcronjobs.php -s <public siteaccess> frequent
php runcronjobs.php -s <public siteaccess> --script=workflow.php

The process list shows every waiting and stopped process, why it waits and what will move it on, and can cancel processes safely. Statuses, the trigger and group pages, troubleshooting and worked examples are in the Workflows guide; the approval of staff accounts in User account approval.

In this section

Contributors

Comments (4 historical)

Written by readers of the earlier documentation sites, kept as they were.

  1. Custom Triggers?

    Mindshare Tech ·

    Can you please post some documentation and examples of creating custom workflow events and custom triggers? I.e., a standard workflow event would be having an administrator approve or deny a request for new user registration on a site.
    Thanks!

    1. Re: Custom Triggers?

      Massimiliano Bariola ·

      Hi,
      I second your request. Meanwhile, maybe you could have a look at the worldpay extension, it has a custom event which maybe could get you started.
      cheers,
      Max

      1. Re: Re: Custom Triggers?

        Bertrand Dunogier ·

        As far as my knowledge goes, here is how it's done: Exponential module operations are defined in a file called operation_definition.php. Currently there are 2, one for content, and one for shop (kernel/content/operation_definition.php, kernel/shop/operation_definition.php).
        These files define operations. I'm not exactly sure how operations are different from views, but the definition is quite similar, except for the complexity. Operations have an additionnal key, 'body', which defines how the operation runs. body is defined by a sequence of methods AND triggers (there we are). For instance, the body for content/read is:
        - pre_read (trigger)
        - fetch-object (method)
        As far as I undertand it, what you have to do to add a custom trigger is replace the view you want to alter by an operation, and add the trigger. I hope it helps :)

  2. custom Workflows

    Mark Simon - all2e.com ·

    Take a look at workflow.ini
    [OperationSettings]
    AvailableOperationList[]
    ist an array holding all Triggers that will show up in the admin interface to set your workflows on.
    You can add right a couple of Triggers of the eZ Modules or your own Modules.
    i.e. content_delete or user_activation (added in 4.1)
    can simply be added to the list.
    I guess you can create own Module - Triggers based on
    kernel/content/operation_definition.php mentioned by Bertrand Dunogier
    but with the user module triggers already being ready I didn't need to work that out.
    Good Luck if thats what will be Your Way ;)
    Mark

Comments

Add a comment

Comments are read by a moderator before they appear.