i.e. a set of possible transitions from one state to another state.

*CubicWeb* instance in ten minutes (see :ref:`BlogFiveMinutes`).

submitted on the instance. When a BlogEntry is created by a user

There are two ways to create a workflow: from the user interface, or

by defining it in ``migration/postcreate.py``. This script is executed

each time a new ``cubicweb-ctl db-init`` is done.  We strongly

recommend to create the workflow in ``migration/postcreate.py`` and we

will now show you how. Read `Two bits of warning`_ to understand why.

The state of an entity is managed by the `in_state` attribute which

can be added to your entity schema by inheriting from

`cubicweb.schema.WorkflowableEntityType`.

  class BlogEntry(WorkflowableEntityType):

A workflow is a collection of entities of type ``State`` and of type

``Transition`` which are standard *CubicWeb* entity types.

To define a workflow for BlogDemo, please add the following lines

  wf = add_workflow(u'blog publication workflow', 'BlogEntry')

At first, instanciate a new workflow object with a gentle description

and the concerned entity types (this one can be a tuple for multiple

value).

This will create two entities of type ``State``, one with name

'submitted', and the other with name 'published'.

``add_state`` expects as first argument the name of the state you want

to create and an optional argument to say if it is supposed to be the

initial state of the entity type.

This will create an entity of type ``Transition`` with name

`approve_blogentry` which will be linked to the ``State`` entities

created before.

  * as the first argument: the name of the transition

In addition to the user groups (one of which the user needs to belong

to), we could have added a RQL condition.  In this case, the user can

only perform the action if the two conditions are satisfied.

If we use an RQL condition on a transition, we can use the following variables:

You can notice that in the action box of a BlogEntry, the state is now

listed as well as the possible transitions for the current state

defined by the workflow.

Two bits of warning

~~~~~~~~~~~~~~~~~~~

We could perfectly use the administration interface to do these

operations. It is a convenient thing to do at times (when doing

development, to quick-check things). But it is not recommended beyond

that because it is a bit complicated to do it right and it will be

only local to your instance (or, said a bit differently, such a

workflow only exists in an instance database). Furthermore, you cannot

write unit tests against deployed instances, and experience shows it

is mandatory to have tests for any mildly complicated workflow

setup.

Indeed, if you create the states and transitions through the user

interface, next time you initialize the database you will have to

re-create all the workflow entities. The user interface should only be

a reference for you to view the states and transitions, but is not the

appropriate interface to define your application workflow.