[DOC] workflows: typos, and removed inaccurate environment symbols.
bzr revid: vmt@openerp.com-20130731150943-etfvn08fnkhcecvt
This commit is contained in:
parent
3c0d11271e
commit
3d1d7ee39c
|
@ -54,8 +54,8 @@ instance, here is a simple sequence of two activities defined in XML::
|
||||||
</record>
|
</record>
|
||||||
|
|
||||||
A worfklow is always defined with respect to a particular model (the model is
|
A worfklow is always defined with respect to a particular model (the model is
|
||||||
given by attribute ``osv`` on the model ``workflow``). Methods specified in the
|
given by the attribute ``osv`` on the model ``workflow``). Methods specified in
|
||||||
activities or transitions will be called on that model.
|
the activities or transitions will be called on that model.
|
||||||
|
|
||||||
In the example code above, a workflow called "test_workflow" is created. It is
|
In the example code above, a workflow called "test_workflow" is created. It is
|
||||||
made up of two activies, named "a" and "b", and one transition, going from "a"
|
made up of two activies, named "a" and "b", and one transition, going from "a"
|
||||||
|
@ -67,10 +67,10 @@ Because ``on_create`` is set to True on the workflow record, the workflow is
|
||||||
instanciated for each newly created record. (Otherwise, the workflow should be
|
instanciated for each newly created record. (Otherwise, the workflow should be
|
||||||
instanciated by other means, such as from some module Python code.)
|
instanciated by other means, such as from some module Python code.)
|
||||||
|
|
||||||
When the workflow is instanciated, it begins with activity "a". That activity is
|
When the workflow is instanciated, it begins with activity "a". That activity
|
||||||
of kind ``function``, which means that the action ``print_a()`` is method call
|
is of kind ``function``, which means that the action ``print_a()`` is a method
|
||||||
on the model ``test.workflow`` (the usual ``cr, uid, ids, context`` arguments
|
call on the model ``test.workflow`` (the usual ``cr, uid, ids, context``
|
||||||
are passed for you).
|
arguments are passed for you).
|
||||||
|
|
||||||
The transition between "a" and "b" does not specify any condition. This means
|
The transition between "a" and "b" does not specify any condition. This means
|
||||||
that the workflow instance immediately goes from "a" to "b" after "a" has been
|
that the workflow instance immediately goes from "a" to "b" after "a" has been
|
||||||
|
@ -107,14 +107,8 @@ may be several lines long; in that case, the value of the last one determines
|
||||||
whether the transition can be taken.
|
whether the transition can be taken.
|
||||||
|
|
||||||
In the condition evaluation environment, several symbols are conveniently
|
In the condition evaluation environment, several symbols are conveniently
|
||||||
defined:
|
defined (in addition to the OpenERP ``safe_eval`` environment):
|
||||||
|
|
||||||
- the database cursor (``cr``),
|
|
||||||
- the user ID (``uid``),
|
|
||||||
- the record ID tied to the workflow instance (``id``),
|
|
||||||
- the record ID wrapped in a list (``ids``),
|
|
||||||
- the model name (``model``),
|
|
||||||
- the model instance (``obj``),
|
|
||||||
- all the model column names, and
|
- all the model column names, and
|
||||||
- all the browse record's attributes.
|
- all the browse record's attributes.
|
||||||
|
|
||||||
|
@ -122,14 +116,15 @@ Signals
|
||||||
'''''''
|
'''''''
|
||||||
|
|
||||||
In addition to a condition, a transition can specify a signal name. When such
|
In addition to a condition, a transition can specify a signal name. When such
|
||||||
signal name is present, the transition is not taken directly, even if the
|
a signal name is present, the transition is not taken directly, even if the
|
||||||
condition evaluates to ``True``. Instead the transition blocks, waiting to be
|
condition evaluates to ``True``. Instead the transition blocks, waiting to be
|
||||||
woken up.
|
woken up.
|
||||||
|
|
||||||
In order to wake up a transition with a defined signal name, the signal must be
|
In order to wake up a transition with a defined signal name, the signal must be
|
||||||
sent to the workflow instance. A common way to send a signal is to use a button
|
sent to the workflow instance. A common way to send a signal is to use a button
|
||||||
in the user interface, using the element ``<button/>`` with the signal name as
|
in the user interface, using the element ``<button/>`` with the signal name as
|
||||||
the ``name`` attribute of the button. Once the button is clicked,
|
the attribute ``name`` of the button. Once the button is clicked, the signal is
|
||||||
|
sent to the workflow instance of the current record.
|
||||||
|
|
||||||
.. note:: The condition is still evaluated when the signal is sent to the
|
.. note:: The condition is still evaluated when the signal is sent to the
|
||||||
workflow instance.
|
workflow instance.
|
||||||
|
@ -139,20 +134,20 @@ Triggers
|
||||||
|
|
||||||
With conditions that evaluate to ``False``, transitions are not taken (and thus
|
With conditions that evaluate to ``False``, transitions are not taken (and thus
|
||||||
the activity it leads to is not processed immediately). Still, the workflow
|
the activity it leads to is not processed immediately). Still, the workflow
|
||||||
instance can get new chances to progress across that transition by providing so-
|
instance can get new chances to progress across that transition by providing
|
||||||
called triggers. The idea is that when the condition is not satisfied, triggers
|
so-called triggers. The idea is that when the condition is not satisfied,
|
||||||
are recorded in database. Later, it is possible to wake up specifically the
|
triggers are recorded in database. Later, it is possible to wake up
|
||||||
workflow instances that installed those triggers, offering them to reevaluate
|
specifically the workflow instances that installed those triggers, offering
|
||||||
their transition conditions. This mechanism makes it cheaper to wake up workflow
|
them to reevaluate their transition conditions. This mechanism makes it cheaper
|
||||||
instances by targetting just a few of them (those that have installed the
|
to wake up workflow instances by targetting just a few of them (those that have
|
||||||
triggers) instead of all of them.
|
installed the triggers) instead of all of them.
|
||||||
|
|
||||||
Triggers are recorded in database as record IDs (together with the model name)
|
Triggers are recorded in database as record IDs (together with the model name)
|
||||||
and refer to the workflow instance waiting for those records. The transition
|
and refer to the workflow instance waiting for those records. The transition
|
||||||
definition provides a model name (attribute ``trigger_model``) and a Python
|
definition provides a model name (attribute ``trigger_model``) and a Python
|
||||||
expression (attribute ``trigger_expression``) that evaluates to a list of record
|
expression (attribute ``trigger_expression``) that evaluates to a list of record
|
||||||
IDs in the given model. Any of those records can wake up the workflow instance
|
IDs in the given model. Any of those records can wake up the workflow instance
|
||||||
they are associated to.
|
they are associated with.
|
||||||
|
|
||||||
.. note:: Note that triggers are not re-installed whenever the transition is
|
.. note:: Note that triggers are not re-installed whenever the transition is
|
||||||
re-tried.
|
re-tried.
|
||||||
|
@ -189,7 +184,7 @@ outgoing transitions afterwards.
|
||||||
|
|
||||||
The attribute ``flow_stop`` is a boolean value specifying whether the activity
|
The attribute ``flow_stop`` is a boolean value specifying whether the activity
|
||||||
stops the workflow instance. A workflow instance is considered completed when
|
stops the workflow instance. A workflow instance is considered completed when
|
||||||
all its activities with the ``flow_stop`` attribute set to ``True`` are
|
all its activities with the attribute ``flow_stop`` set to ``True`` are
|
||||||
completed.
|
completed.
|
||||||
|
|
||||||
It is important for OpenERP to know when a workflow instance is completed. A
|
It is important for OpenERP to know when a workflow instance is completed. A
|
||||||
|
@ -214,9 +209,9 @@ Sending a signal from a subflow
|
||||||
|
|
||||||
When a workflow is embedded in an activity (as a subflow) of a workflow, the
|
When a workflow is embedded in an activity (as a subflow) of a workflow, the
|
||||||
sublow can send a signal from its own activities to the parent workflow by
|
sublow can send a signal from its own activities to the parent workflow by
|
||||||
giving a signal name in attribute ``signal_send``. OpenERP processes those
|
giving a signal name in the attribute ``signal_send``. OpenERP processes those
|
||||||
activities by sending the value of ``signal_send`` prefixed by "subflow" to the
|
activities by sending the value of ``signal_send`` prefixed by "subflow." to
|
||||||
parent workflow instance.
|
the parent workflow instance.
|
||||||
|
|
||||||
In other words, it is possible to react and get transitions in the parent
|
In other words, it is possible to react and get transitions in the parent
|
||||||
workflow as activities are executed in the sublow.
|
workflow as activities are executed in the sublow.
|
||||||
|
@ -230,8 +225,8 @@ An activity can run a "Server Action" by specifying its ID in the attribute
|
||||||
Python action
|
Python action
|
||||||
'''''''''''''
|
'''''''''''''
|
||||||
|
|
||||||
An activity can execute some Python code, given by attribute ``action``. The
|
An activity can execute some Python code, given by the attribute ``action``.
|
||||||
evaluation environment is the same as the one explained in the section
|
The evaluation environment is the same as the one explained in the section
|
||||||
`Conditions`_.
|
`Conditions`_.
|
||||||
|
|
||||||
Split mode
|
Split mode
|
||||||
|
@ -242,7 +237,7 @@ Normally, if a transition can be taken, OpenERP traverses it and proceed to the
|
||||||
activity the transition leads to.
|
activity the transition leads to.
|
||||||
|
|
||||||
Actually, when more than a single transition is leaving an activity, OpenERP may
|
Actually, when more than a single transition is leaving an activity, OpenERP may
|
||||||
proceed or not, depending on the other transitions. That is, the condition on
|
proceed or not, depending on the other transitions. That is, the conditions on
|
||||||
the transitions can be combined together, and the combined result instructs
|
the transitions can be combined together, and the combined result instructs
|
||||||
OpenERP to traverse zero, one, or all the transitions. The way they are combined
|
OpenERP to traverse zero, one, or all the transitions. The way they are combined
|
||||||
is controlled by the attribute ``split_mode``.
|
is controlled by the attribute ``split_mode``.
|
||||||
|
|
Loading…
Reference in New Issue