--- a/doc/book/en/development/datamodel/define-workflows.rst Fri Jun 19 09:19:27 2009 +0200
+++ b/doc/book/en/development/datamodel/define-workflows.rst Fri Jun 19 20:38:32 2009 +0200
@@ -8,30 +8,30 @@
General
-------
-A workflow describes how certain entities have to evolve between
-different states. Hence we have a set of states, and a "transition graph",
+A workflow describes how certain entities have to evolve between
+different states. Hence we have a set of states, and a "transition graph",
i.e. a list of possible transitions from one state to another state.
-We will define a simple workflow for a blog, with only the following
-two states: `submitted` and `published`. So first, we create a simple
+We will define a simple workflow for a blog, with only the following
+two states: `submitted` and `published`. So first, we create a simple
`CubicWeb` in ten minutes (see :ref:`BlogTenMinutes`).
Set-up a workflow
-----------------
-We want to create a workflow to control the quality of the BlogEntry
+We want to create a workflow to control the quality of the BlogEntry
submitted on your application. When a BlogEntry is created by a user
its state should be `submitted`. To be visible to all, it has to
be in the state `published`. To move it from `submitted` to `published`,
we need a transition that we can call `approve_blogentry`.
A BlogEntry state should not be modifiable by every user.
-So we have to define a group of users, `moderators`, and
+So we have to define a group of users, `moderators`, and
this group will have appropriate permissions to publish a BlogEntry.
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.
+or by defining it in ``migration/postcreate.py``.
+This script is executed each time a new ``cubicweb-ctl db-init`` is done.
We strongly recommand to create the workflow in ``migration/postcreate.py``
and we will now show you how. Read `Under the hood`_ to understand why.
@@ -66,7 +66,7 @@
To define our workflow for BlogDemo, please add the following lines
to ``migration/postcreate.py``::
-
+
_ = unicode
moderators = add_entity('CWGroup', name=u"moderators")
@@ -88,12 +88,12 @@
add_transition(_('approve_blogentry'), 'BlogEntry', (submitted,), published, ('moderators', 'managers'),)
-``add_transition`` expects
+``add_transition`` expects
* as the first argument the name of the
transition, then the entity type on which the transition can be applied,
* then the list of states on which the transition can be trigged,
- * the target state of the transition,
+ * the target state of the transition,
* and the permissions
(e.g. a list of user groups who can apply the transition; the user
has to belong to at least one of the listed group to perform the action).
@@ -106,11 +106,11 @@
Do not forget to add the `_()` in front of all states and transitions names while creating
a workflow so that they will be identified by the i18n catalog scripts.
-In addition to the user group condition, we could have added a RQL condition.
-In this case, the user can only perform the action if
-the two conditions are satisfied.
+In addition to the user group condition, 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 a RQL condition on a transition, we can use the following
+If we use a RQL condition on a transition, we can use the following
variables:
* `%(eid)s`, object's eid
@@ -123,7 +123,7 @@
You can notice that in the action box of a BlogEntry, the state
is now listed as well as the possible transitions defined by the workflow.
The transitions will only be displayed for users having the right permissions.
-In our example, the transition `approve_blogentry` will only be displayed
+In our example, the transition `approve_blogentry` will only be displayed
for the users belonging to the group `moderators` or `managers`.
@@ -141,7 +141,7 @@
with name 'published'. Whereas::
add_transition(_('approve_blogentry'), 'BlogEntry', (submitted,), published, ('moderators', 'managers'),)
-
+
will create an entity of type ``Transition`` with name 'approve_blogentry' which will
be linked to the ``State`` entities created before.
As a consequence, we could use the administration interface to do these operations.
@@ -151,8 +151,8 @@
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 entities.
-The user interface should only be a reference for you to view the states
+you will have to re-create all the 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.