← Back to branch summary

~xrg/openobject-doc/trunk-xrg

« back to all changes in this revision

Viewing changes to i18n/es/source/developer/3_9_Workflow_Business_Process/index.rst

  • Committer: TruongSinh Tran
  • Date: 2009-07-17 18:59:45 UTC
  • Revision ID: truongsinh@vipescoserver-20090717185945-ajjp3zso6xh5jddm
[FIX]private issue

Show diffs side-by-side

added added

removed removed

Lines of Context:
i18n/es/source/developer/3_9_Workflow_Business_Process/index.rst
 
1
 
 
2
.. i18n: =========================
 
3
.. i18n: Workflow-Business Process
 
4
.. i18n: =========================
 
5
 
 
6
=========================
 
7
Workflow-Business Process
 
8
=========================
 
9
 
 
10
.. i18n: Introduction
 
11
.. i18n: ============
 
12
 
 
13
Introduction
 
14
============
 
15
 
 
16
.. i18n: The workflow system in Open ERP is a very powerful mechanism that can describe the evolution of documents (model) in time.
 
17
 
 
18
The workflow system in Open ERP is a very powerful mechanism that can describe the evolution of documents (model) in time.
 
19
 
 
20
.. i18n: Workflows are entirely customizable, they can be adapted to the flows and trade logic of almost any company. The workflow system makes Tiny ERP very flexible and allows it to easily support changing needs without having to program new functionalities.
 
21
 
 
22
Workflows are entirely customizable, they can be adapted to the flows and trade logic of almost any company. The workflow system makes Tiny ERP very flexible and allows it to easily support changing needs without having to program new functionalities.
 
23
 
 
24
.. i18n: **Goals**
 
25
 
 
26
**Goals**
 
27
 
 
28
.. i18n:     * description of document evolution in time
 
29
.. i18n:     * automatic trigger of actions if some conditions are met
 
30
.. i18n:     * management of company roles and validation steps
 
31
.. i18n:     * management of interactions between the different objects/modules
 
32
.. i18n:     * graphical tool for visualization of document flows
 
33
 
 
34
    * description of document evolution in time
 
35
    * automatic trigger of actions if some conditions are met
 
36
    * management of company roles and validation steps
 
37
    * management of interactions between the different objects/modules
 
38
    * graphical tool for visualization of document flows
 
39
 
 
40
.. i18n: **To understand its utility, see these three examples:**
 
41
 
 
42
**To understand its utility, see these three examples:**
 
43
 
 
44
.. i18n: WkfExample1: Discount On Orders
 
45
.. i18n: -------------------------------
 
46
 
 
47
WkfExample1: Discount On Orders
 
48
-------------------------------
 
49
 
 
50
.. i18n: The first diagram represent a very basic workflow of an order:
 
51
 
 
52
The first diagram represent a very basic workflow of an order:
 
53
 
 
54
.. i18n: .. image:: images/Workflow_bc1.png
 
55
 
 
56
.. image:: images/Workflow_bc1.png
 
57
 
 
58
.. i18n: The order starts in the 'draft' state, when it is in redaction and not approved. When the user press on the 'Confirm' button, the invoice is created and the order comes into the 'CONFIRMED' state.
 
59
 
 
60
The order starts in the 'draft' state, when it is in redaction and not approved. When the user press on the 'Confirm' button, the invoice is created and the order comes into the 'CONFIRMED' state.
 
61
 
 
62
.. i18n: Then, two operations are possible:
 
63
 
 
64
Then, two operations are possible:
 
65
 
 
66
.. i18n: #. the order is done (shipped)
 
67
.. i18n: 
 
68
.. i18n: #. the order is canceled
 
69
 
 
70
#. the order is done (shipped)
 
71
 
 
72
#. the order is canceled
 
73
 
 
74
.. i18n: Let's suppose a company has a need not implemented in OpenERP. For example, suppose their sales staff can only offer discounts of 15% or less. Every order having a discount above 15% must be approved by the sales manager.
 
75
 
 
76
Let's suppose a company has a need not implemented in OpenERP. For example, suppose their sales staff can only offer discounts of 15% or less. Every order having a discount above 15% must be approved by the sales manager.
 
77
 
 
78
.. i18n: This modification in the sale logic doesn't need any line of python code! A simple modification of the workflow allows us to take this new need into account and add the extra validation step.
 
79
 
 
80
This modification in the sale logic doesn't need any line of python code! A simple modification of the workflow allows us to take this new need into account and add the extra validation step.
 
81
 
 
82
.. i18n: .. image:: images/Workflow_bc2.png
 
83
 
 
84
.. image:: images/Workflow_bc2.png
 
85
 
 
86
.. i18n: The workflow is thus modified as above and the orders will react as we want to. We then only need to modify the order form view and add a validation button at the desired location.
 
87
 
 
88
The workflow is thus modified as above and the orders will react as we want to. We then only need to modify the order form view and add a validation button at the desired location.
 
89
 
 
90
.. i18n: We could then further improve this workflow by sending a request to the sales manager when an order enters the 'Validation' state. Workflow nodes can execute object methods; only two lines of Python are needed to send a request asking the sales manager to validate or not the order.
 
91
 
 
92
We could then further improve this workflow by sending a request to the sales manager when an order enters the 'Validation' state. Workflow nodes can execute object methods; only two lines of Python are needed to send a request asking the sales manager to validate or not the order.
 
93
 
 
94
.. i18n: WkfExample2: A sale order that generates an invoice and a shipping order.
 
95
.. i18n: -------------------------------------------------------------------------
 
96
 
 
97
WkfExample2: A sale order that generates an invoice and a shipping order.
 
98
-------------------------------------------------------------------------
 
99
 
 
100
.. i18n: .. image:: images/Workflow_sale.png
 
101
 
 
102
.. image:: images/Workflow_sale.png
 
103
 
 
104
.. i18n: WkfExample3: Acount invoice basic workflow
 
105
 
 
106
WkfExample3: Acount invoice basic workflow
 
107
 
 
108
.. i18n: .. image:: images/Acount_inv_wkf.jpg
 
109
 
 
110
.. image:: images/Acount_inv_wkf.jpg
 
111
 
 
112
.. i18n: Defining Workflow
 
113
.. i18n: =================
 
114
.. i18n: Workflows are defined in the file server/bin/addons/base/ir/workflow/workflow.py. The first three classes defined in this file are workflow, wkf_activity and wkf_transition. They correspond to the three types of resources that are necessary to describe a workflow :
 
115
 
 
116
Defining Workflow
 
117
=================
 
118
Workflows are defined in the file server/bin/addons/base/ir/workflow/workflow.py. The first three classes defined in this file are workflow, wkf_activity and wkf_transition. They correspond to the three types of resources that are necessary to describe a workflow :
 
119
 
 
120
.. i18n:     * `workflow <http://openobject.com/wiki/index.php/WkfDefXML>`_ : the workflow,
 
121
.. i18n:     * `wkf_activity <http://openobject.com/wiki/index.php/WorkflowActivity>`_ : the activities (nodes),
 
122
.. i18n:     * `wkf_transition <http://openobject.com/wiki/index.php/WorkflowTransition>`_ : the transitions between the activities.
 
123
 
 
124
    * `workflow <http://openobject.com/wiki/index.php/WkfDefXML>`_ : the workflow,
 
125
    * `wkf_activity <http://openobject.com/wiki/index.php/WorkflowActivity>`_ : the activities (nodes),
 
126
    * `wkf_transition <http://openobject.com/wiki/index.php/WorkflowTransition>`_ : the transitions between the activities.
 
127
 
 
128
.. i18n: General structure of a workflow XML file
 
129
.. i18n: ========================================
 
130
 
 
131
General structure of a workflow XML file
 
132
========================================
 
133
 
 
134
.. i18n: The general structure of a workflow XML file is as follows :
 
135
 
 
136
The general structure of a workflow XML file is as follows :
 
137
 
 
138
.. i18n: .. code-block:: xml
 
139
.. i18n: 
 
140
.. i18n:     <?xml version="1.0"?>
 
141
.. i18n:     <terp>
 
142
.. i18n:     <data>
 
143
.. i18n:     <record model="workflow" id=workflow_id>
 
144
.. i18n: 
 
145
.. i18n:         <field name="name">workflow.name</field>
 
146
.. i18n:         <field name="osv">resource.model</field>
 
147
.. i18n:         <field name="on_create">True | False</field>
 
148
.. i18n: 
 
149
.. i18n:     </record>
 
150
.. i18n: 
 
151
.. i18n:     </data>
 
152
.. i18n:     </terp>
 
153
 
 
154
.. code-block:: xml
 
155
 
 
156
    <?xml version="1.0"?>
 
157
    <terp>
 
158
    <data>
 
159
    <record model="workflow" id=workflow_id>
 
160
 
 
161
        <field name="name">workflow.name</field>
 
162
        <field name="osv">resource.model</field>
 
163
        <field name="on_create">True | False</field>
 
164
 
 
165
    </record>
 
166
 
 
167
    </data>
 
168
    </terp>
 
169
 
 
170
.. i18n: **Where**
 
171
 
 
172
**Where**
 
173
 
 
174
.. i18n:     * **id** (here "workflow_id") is a workflow identifier. Each workflow must have an unique identifier.
 
175
.. i18n:     * **name** (here "workflow.name") is the name of the workflow. The name of the workflow must respect the Open ERP syntax of "dotted names".
 
176
.. i18n:     * **osv** (here "resource.model") is the name of the Tiny object we use as a model [-(Remember a Open object inherits from osv.osv, hence the '<field name="osv">')-].
 
177
.. i18n:     * **on_create** is True if workflow.name must be instantiated automatically when resource.model is created, and False otherwise.
 
178
 
 
179
    * **id** (here "workflow_id") is a workflow identifier. Each workflow must have an unique identifier.
 
180
    * **name** (here "workflow.name") is the name of the workflow. The name of the workflow must respect the Open ERP syntax of "dotted names".
 
181
    * **osv** (here "resource.model") is the name of the Tiny object we use as a model [-(Remember a Open object inherits from osv.osv, hence the '<field name="osv">')-].
 
182
    * **on_create** is True if workflow.name must be instantiated automatically when resource.model is created, and False otherwise.
 
183
 
 
184
.. i18n: **Example**
 
185
 
 
186
**Example**
 
187
 
 
188
.. i18n: The workflow **"sale.order.basic"** defined in addons/sale/sale_workflow.xml follows exactly this model, the code of its workflow tag is :
 
189
 
 
190
The workflow **"sale.order.basic"** defined in addons/sale/sale_workflow.xml follows exactly this model, the code of its workflow tag is :
 
191
 
 
192
.. i18n: .. code-block:: xml
 
193
.. i18n: 
 
194
.. i18n:     <record model="workflow" id="wkf_sale">
 
195
.. i18n: 
 
196
.. i18n:         <field name="name">sale.order.basic</field>
 
197
.. i18n:         <field name="osv">sale.order</field>
 
198
.. i18n:         <field name="on_create">True</field>
 
199
.. i18n: 
 
200
.. i18n:     </record>
 
201
 
 
202
.. code-block:: xml
 
203
 
 
204
    <record model="workflow" id="wkf_sale">
 
205
 
 
206
        <field name="name">sale.order.basic</field>
 
207
        <field name="osv">sale.order</field>
 
208
        <field name="on_create">True</field>
 
209
 
 
210
    </record>
 
211
 
 
212
.. i18n: Activity
 
213
.. i18n: ==========
 
214
 
 
215
Activity
 
216
==========
 
217
 
 
218
.. i18n: Introduction
 
219
.. i18n: ------------
 
220
 
 
221
Introduction
 
222
------------
 
223
 
 
224
.. i18n: The wkf_activity class represents the nodes of workflows. These nodes are the actions to be executed.
 
225
 
 
226
The wkf_activity class represents the nodes of workflows. These nodes are the actions to be executed.
 
227
 
 
228
.. i18n: The fields
 
229
.. i18n: ----------
 
230
 
 
231
The fields
 
232
----------
 
233
 
 
234
.. i18n: split_mode
 
235
.. i18n: ----------
 
236
 
 
237
split_mode
 
238
----------
 
239
 
 
240
.. i18n: .. image::  images/Wkf_split.png
 
241
 
 
242
.. image::  images/Wkf_split.png
 
243
 
 
244
.. i18n: * XOR: One necessary transition, takes the first one found (default).
 
245
.. i18n: * OR : Take only valid transitions (0 or more) in sequential order.
 
246
.. i18n: * AND: All valid transitions are launched at the same time (fork).
 
247
 
 
248
* XOR: One necessary transition, takes the first one found (default).
 
249
* OR : Take only valid transitions (0 or more) in sequential order.
 
250
* AND: All valid transitions are launched at the same time (fork).
 
251
 
 
252
.. i18n: In the OR and AND separation mode, certain workitems can be generated.
 
253
 
 
254
In the OR and AND separation mode, certain workitems can be generated.
 
255
 
 
256
.. i18n: In the AND mode, the activity waits for all transitions to be valid, even if some of them are already valid. They are all triggered at the same time.
 
257
.. i18n: join_mode
 
258
.. i18n: join_mode:
 
259
 
 
260
In the AND mode, the activity waits for all transitions to be valid, even if some of them are already valid. They are all triggered at the same time.
 
261
join_mode
 
262
join_mode:
 
263
 
 
264
.. i18n: .. image:: images/Wkf_join.png
 
265
 
 
266
.. image:: images/Wkf_join.png
 
267
 
 
268
.. i18n: * **XOR**: One transition necessary to continue to the destination activity (default).
 
269
.. i18n: * **AND**: Waits for all transition conditions to be valid to execute the destination activity.
 
270
 
 
271
* **XOR**: One transition necessary to continue to the destination activity (default).
 
272
* **AND**: Waits for all transition conditions to be valid to execute the destination activity.
 
273
 
 
274
.. i18n: kind:
 
275
.. i18n: -----
 
276
 
 
277
kind:
 
278
-----
 
279
 
 
280
.. i18n: :The type of the activity can take several values:
 
281
 
 
282
:The type of the activity can take several values:
 
283
 
 
284
.. i18n:     * **DUMMY**: Do nothing (default).
 
285
.. i18n:     * **FUNCTION**: Execute the function selected by an action.
 
286
.. i18n:     * **SUBFLOW**: Execute a sub-workflow SUBFLOW_ID. The action method must return the ID of the concerned resource by the subflow ! If the action returns False, the workitem disappears !
 
287
.. i18n:     * **STOPALL**:
 
288
 
 
289
    * **DUMMY**: Do nothing (default).
 
290
    * **FUNCTION**: Execute the function selected by an action.
 
291
    * **SUBFLOW**: Execute a sub-workflow SUBFLOW_ID. The action method must return the ID of the concerned resource by the subflow ! If the action returns False, the workitem disappears !
 
292
    * **STOPALL**:
 
293
 
 
294
.. i18n: A sub-workflow is executed when an activity is of the type SUBFLOW. This activity ends when the sub-workflow has finished. While the sub-workflow is active, the workitem of this activity is frozen.
 
295
 
 
296
A sub-workflow is executed when an activity is of the type SUBFLOW. This activity ends when the sub-workflow has finished. While the sub-workflow is active, the workitem of this activity is frozen.
 
297
 
 
298
.. i18n: action:
 
299
.. i18n: -------
 
300
 
 
301
action:
 
302
-------
 
303
 
 
304
.. i18n: The action indicates the method to execute when a workitem comes into this activity. The method must be defined in a object which belongs this workflow and have the following signature:
 
305
 
 
306
The action indicates the method to execute when a workitem comes into this activity. The method must be defined in a object which belongs this workflow and have the following signature:
 
307
 
 
308
.. i18n:     def object_method(self, cr, uid, ids):
 
309
 
 
310
    def object_method(self, cr, uid, ids):
 
311
 
 
312
.. i18n: In the action though, they will be called by a statement like:
 
313
 
 
314
In the action though, they will be called by a statement like:
 
315
 
 
316
.. i18n:     object_method()
 
317
 
 
318
    object_method()
 
319
 
 
320
.. i18n: ::
 
321
.. i18n: 
 
322
.. i18n:        signal_send
 
323
 
 
324
::
 
325
 
 
326
        signal_send
 
327
 
 
328
.. i18n: ::
 
329
.. i18n: 
 
330
.. i18n:        flow_start
 
331
 
 
332
::
 
333
 
 
334
        flow_start
 
335
 
 
336
.. i18n: Indicates if the node is a start node. When a new instance of a workflow is created, a workitem is activated for each activity marked as a flow_start.
 
337
 
 
338
Indicates if the node is a start node. When a new instance of a workflow is created, a workitem is activated for each activity marked as a flow_start.
 
339
 
 
340
.. i18n: Be warned to not use this flag unless your activity really is a "flow start". There are tiny versions that do not care about the tags contents like "true" or "false". Using such tag and tiny version, you will always end up whith an activity which is tagged as "flow start = true", leaving u with a nasty hunt to find out where your workflowdesign could be wrong.
 
341
 
 
342
Be warned to not use this flag unless your activity really is a "flow start". There are tiny versions that do not care about the tags contents like "true" or "false". Using such tag and tiny version, you will always end up whith an activity which is tagged as "flow start = true", leaving u with a nasty hunt to find out where your workflowdesign could be wrong.
 
343
 
 
344
.. i18n: flow_stop
 
345
.. i18n: ---------
 
346
 
 
347
flow_stop
 
348
---------
 
349
 
 
350
.. i18n: Indicates if the node is an ending node. When all the active workitems for a given instance come in the node marked by flow_stop, the workflow is finished.
 
351
 
 
352
Indicates if the node is an ending node. When all the active workitems for a given instance come in the node marked by flow_stop, the workflow is finished.
 
353
 
 
354
.. i18n: Be warned to not use this flag unless your activity really is a "flow stop". There are tiny versions that do not care about the tags contents like "true" or "false". Using such tag and tiny version, you will always end up whith an activity which is tagged as "flow stop = true", leaving u with a nasty hunt to find out where your workflowdesign could be wrong.
 
355
 
 
356
Be warned to not use this flag unless your activity really is a "flow stop". There are tiny versions that do not care about the tags contents like "true" or "false". Using such tag and tiny version, you will always end up whith an activity which is tagged as "flow stop = true", leaving u with a nasty hunt to find out where your workflowdesign could be wrong.
 
357
 
 
358
.. i18n: wkf_id
 
359
.. i18n: ------
 
360
 
 
361
wkf_id
 
362
------
 
363
 
 
364
.. i18n: The workflow which this activity belongs to.
 
365
.. i18n: Defining activities using XML files
 
366
 
 
367
The workflow which this activity belongs to.
 
368
Defining activities using XML files
 
369
 
 
370
.. i18n: The general structure of an activity record is as follows
 
371
.. i18n: ---------------------------------------------------------
 
372
 
 
373
The general structure of an activity record is as follows
 
374
---------------------------------------------------------
 
375
 
 
376
.. i18n: .. code-block:: xml
 
377
.. i18n: 
 
378
.. i18n:        <record model="workflow.activity" id="''activity_id''">
 
379
.. i18n:              <field name="wkf_id" ref="''workflow_id''"/>
 
380
.. i18n:              <field name="name">''activity.name''</field>::
 
381
.. i18n: 
 
382
.. i18n:              <field name="split_mode">XOR | OR | AND</field>
 
383
.. i18n:              <field name="join_mode">XOR | AND</field>
 
384
.. i18n:              <field name="kind">dummy | function | subflow | stopall</field>
 
385
.. i18n: 
 
386
.. i18n:              <field name="action">''(...)''</field>
 
387
.. i18n:              <field name="signal_send">''(...)''</field>
 
388
.. i18n:              <field name="flow_start">True | False</field>
 
389
.. i18n:              <field name="flow_stop">True | False</field>
 
390
.. i18n:          </record>
 
391
 
 
392
.. code-block:: xml
 
393
 
 
394
        <record model="workflow.activity" id="''activity_id''">
 
395
              <field name="wkf_id" ref="''workflow_id''"/>
 
396
              <field name="name">''activity.name''</field>::
 
397
 
 
398
              <field name="split_mode">XOR | OR | AND</field>
 
399
              <field name="join_mode">XOR | AND</field>
 
400
              <field name="kind">dummy | function | subflow | stopall</field>
 
401
 
 
402
              <field name="action">''(...)''</field>
 
403
              <field name="signal_send">''(...)''</field>
 
404
              <field name="flow_start">True | False</field>
 
405
              <field name="flow_stop">True | False</field>
 
406
          </record>
 
407
 
 
408
.. i18n: The first two arguments **wkf_id** and name are mandatory. Be warned to not use **flow_start** and **flow_stop** unless your activity really is a **flow start** or **flow_stop**. There are tiny versions that do not care about the tags contents like "True" or "False".
 
409
 
 
410
The first two arguments **wkf_id** and name are mandatory. Be warned to not use **flow_start** and **flow_stop** unless your activity really is a **flow start** or **flow_stop**. There are tiny versions that do not care about the tags contents like "True" or "False".
 
411
 
 
412
.. i18n: Examples
 
413
 
 
414
Examples
 
415
 
 
416
.. i18n: There are too many possibilities of activity definition to choose from using this definition. We recommend you to have a look at the file **server/bin/addons/sale/sale_workflow.xml** for several examples of activity definitions.
 
417
 
 
418
There are too many possibilities of activity definition to choose from using this definition. We recommend you to have a look at the file **server/bin/addons/sale/sale_workflow.xml** for several examples of activity definitions.
 
419
 
 
420
.. i18n: Transition
 
421
.. i18n: ===========
 
422
 
 
423
Transition
 
424
===========
 
425
 
 
426
.. i18n: Introduction
 
427
.. i18n: ------------
 
428
 
 
429
Introduction
 
430
------------
 
431
 
 
432
.. i18n: Workflow transitions are the conditions to be satisfied to go from one activity to the next one. They are represented by one-way arrows joining two activities.
 
433
 
 
434
Workflow transitions are the conditions to be satisfied to go from one activity to the next one. They are represented by one-way arrows joining two activities.
 
435
 
 
436
.. i18n: The conditions are of different types:
 
437
 
 
438
The conditions are of different types:
 
439
 
 
440
.. i18n:     * role to satisfy by the user
 
441
.. i18n:     * button pressed in the interface
 
442
.. i18n:     * end of a subflow through a selected activity of subflow
 
443
 
 
444
    * role to satisfy by the user
 
445
    * button pressed in the interface
 
446
    * end of a subflow through a selected activity of subflow
 
447
 
 
448
.. i18n: The roles and signals are evaluated before the expression. If a role or a signal is false, the expression will not be evaluated.
 
449
 
 
450
The roles and signals are evaluated before the expression. If a role or a signal is false, the expression will not be evaluated.
 
451
 
 
452
.. i18n: Transition tests may not write values in objects.
 
453
.. i18n: The fields
 
454
.. i18n: ::
 
455
.. i18n: 
 
456
.. i18n:        act_from
 
457
 
 
458
Transition tests may not write values in objects.
 
459
The fields
 
460
::
 
461
 
 
462
        act_from
 
463
 
 
464
.. i18n: Source activity. When this activity is over, the condition is tested to determine if we can start the ACT_TO activity.
 
465
 
 
466
Source activity. When this activity is over, the condition is tested to determine if we can start the ACT_TO activity.
 
467
 
 
468
.. i18n: ::
 
469
.. i18n: 
 
470
.. i18n:        act_to
 
471
 
 
472
::
 
473
 
 
474
        act_to
 
475
 
 
476
.. i18n: The destination activity.
 
477
 
 
478
The destination activity.
 
479
 
 
480
.. i18n: ::
 
481
.. i18n: 
 
482
.. i18n:        condition
 
483
 
 
484
::
 
485
 
 
486
        condition
 
487
 
 
488
.. i18n: **Expression** to be satisfied if we want the transition done.
 
489
 
 
490
**Expression** to be satisfied if we want the transition done.
 
491
 
 
492
.. i18n: ::
 
493
.. i18n: 
 
494
.. i18n:        signal
 
495
 
 
496
::
 
497
 
 
498
        signal
 
499
 
 
500
.. i18n: When the operation of transition comes from a button pressed in the client form, signal tests the name of the pressed button.
 
501
 
 
502
When the operation of transition comes from a button pressed in the client form, signal tests the name of the pressed button.
 
503
 
 
504
.. i18n: If signal is NULL, no button is necessary to validate this transition.
 
505
 
 
506
If signal is NULL, no button is necessary to validate this transition.
 
507
 
 
508
.. i18n: ::
 
509
.. i18n: 
 
510
.. i18n:        role_id
 
511
 
 
512
::
 
513
 
 
514
        role_id
 
515
 
 
516
.. i18n: The **role** that a user must have to validate this transition.
 
517
.. i18n: Defining Transitions Using XML Files
 
518
 
 
519
The **role** that a user must have to validate this transition.
 
520
Defining Transitions Using XML Files
 
521
 
 
522
.. i18n: The general structure of a transition record is as follows
 
523
 
 
524
The general structure of a transition record is as follows
 
525
 
 
526
.. i18n: .. code-block:: xml
 
527
.. i18n: 
 
528
.. i18n:     <record model="workflow.transition" id="transition_id">
 
529
.. i18n: 
 
530
.. i18n:         <field name="act_from" ref="activity_id'_1_'"/>
 
531
.. i18n:         <field name="act_to" ref="activity_id'_2_'"/>
 
532
.. i18n: 
 
533
.. i18n:         <field name="signal">(...)</field>
 
534
.. i18n:         <field name="role_id" ref="role_id'_1_'"/>
 
535
.. i18n:         <field name="condition">(...)</field>
 
536
.. i18n: 
 
537
.. i18n:         <field name="trigger_model">(...)</field>
 
538
.. i18n:         <field name="trigger_expr_id">(...)</field>
 
539
.. i18n: 
 
540
.. i18n:     </record>
 
541
 
 
542
.. code-block:: xml
 
543
 
 
544
    <record model="workflow.transition" id="transition_id">
 
545
 
 
546
        <field name="act_from" ref="activity_id'_1_'"/>
 
547
        <field name="act_to" ref="activity_id'_2_'"/>
 
548
 
 
549
        <field name="signal">(...)</field>
 
550
        <field name="role_id" ref="role_id'_1_'"/>
 
551
        <field name="condition">(...)</field>
 
552
 
 
553
        <field name="trigger_model">(...)</field>
 
554
        <field name="trigger_expr_id">(...)</field>
 
555
 
 
556
    </record>
 
557
 
 
558
.. i18n: Only the fields **act_from** and **act_to** are mandatory.
 
559
 
 
560
Only the fields **act_from** and **act_to** are mandatory.
 
561
 
 
562
.. i18n: Expressions
 
563
.. i18n: ===========
 
564
 
 
565
Expressions
 
566
===========
 
567
 
 
568
.. i18n: Expressions are written as in python:
 
569
 
 
570
Expressions are written as in python:
 
571
 
 
572
.. i18n:     * True
 
573
.. i18n:     * 1==1
 
574
.. i18n:     * 'hello' in ['hello','bye']
 
575
 
 
576
    * True
 
577
    * 1==1
 
578
    * 'hello' in ['hello','bye']
 
579
 
 
580
.. i18n: Any field from the resource the workflow refers to can be used in these expressions. For example, if you were creating a workflow for partner addresses, you could use expressions like:
 
581
 
 
582
Any field from the resource the workflow refers to can be used in these expressions. For example, if you were creating a workflow for partner addresses, you could use expressions like:
 
583
 
 
584
.. i18n:     * zip==1400
 
585
.. i18n:     * phone==mobile
 
586
 
 
587
    * zip==1400
 
588
    * phone==mobile
 
589
 
 
590
.. i18n: User Role
 
591
.. i18n: =========
 
592
.. i18n: Roles can be attached to transitions. If a role is given for a transition, that transition can only be executed if the user who triggered it possess the necessary role.
 
593
 
 
594
User Role
 
595
=========
 
596
Roles can be attached to transitions. If a role is given for a transition, that transition can only be executed if the user who triggered it possess the necessary role.
 
597
 
 
598
.. i18n: Each user can have one or several roles. Roles are defined in a tree of roles, parent roles having the rights of all their children.
 
599
 
 
600
Each user can have one or several roles. Roles are defined in a tree of roles, parent roles having the rights of all their children.
 
601
 
 
602
.. i18n: Example:
 
603
 
 
604
Example:
 
605
 
 
606
.. i18n: CEO
 
607
 
 
608
CEO
 
609
 
 
610
.. i18n:   * Technical manager
 
611
.. i18n: 
 
612
.. i18n:     - Lead developper
 
613
 
 
614
  * Technical manager
 
615
 
 
616
    - Lead developper
 
617
 
 
618
.. i18n:       + Developpers
 
619
.. i18n:       + Testers
 
620
 
 
621
      + Developpers
 
622
      + Testers
 
623
 
 
624
.. i18n:   * Sales manager
 
625
.. i18n: 
 
626
.. i18n:     - Commercials
 
627
.. i18n:     - ...
 
628
 
 
629
  * Sales manager
 
630
 
 
631
    - Commercials
 
632
    - ...
 
633
 
 
634
.. i18n: Let's suppose we handle our own bug database and that the action of marking a bug as valid needs the Testers role. In the example tree above, marking a bug as valid could be done by all the users having the following roles: Testers, Lead developper, Technical manager, CEO.
 
635
 
 
636
Let's suppose we handle our own bug database and that the action of marking a bug as valid needs the Testers role. In the example tree above, marking a bug as valid could be done by all the users having the following roles: Testers, Lead developper, Technical manager, CEO.
 
637
 
 
638
.. i18n: Error handling
 
639
.. i18n: ==============
 
640
 
 
641
Error handling
 
642
==============
 
643
 
 
644
.. i18n: As of this writing, there is no exception handling in workflows.
 
645
 
 
646
As of this writing, there is no exception handling in workflows.
 
647
 
 
648
.. i18n: Workflows being made of several actions executed in batch, they can't trigger exceptions. In order to improve the execution efficiency and to release a maximum of locks, workflows commit at the end of each activity. This approach is reasonable because an activity is only started if the conditions of the transactions are satisfied.
 
649
 
 
650
Workflows being made of several actions executed in batch, they can't trigger exceptions. In order to improve the execution efficiency and to release a maximum of locks, workflows commit at the end of each activity. This approach is reasonable because an activity is only started if the conditions of the transactions are satisfied.
 
651
 
 
652
.. i18n: The only problem comes from exceptions due to programming errors; in that case, only transactions belonging to the entirely terminated activities are executed. Other transactions are "rolled back". 
 
653
 
 
654
The only problem comes from exceptions due to programming errors; in that case, only transactions belonging to the entirely terminated activities are executed. Other transactions are "rolled back". 
 
655
 
 
656
.. i18n: Creating a Workflow
 
657
.. i18n: ===================
 
658
 
 
659
Creating a Workflow
 
660
===================
 
661
 
 
662
.. i18n: Steps for creating a simple state-changing workflow for a custom module called **mymod**
 
663
 
 
664
Steps for creating a simple state-changing workflow for a custom module called **mymod**
 
665
 
 
666
.. i18n: Define the States of your object
 
667
.. i18n: --------------------------------
 
668
 
 
669
Define the States of your object
 
670
--------------------------------
 
671
 
 
672
.. i18n: The first step is to define the States your object can be in. We do this by adding a 'state' field to our object, in the _columns collection
 
673
 
 
674
The first step is to define the States your object can be in. We do this by adding a 'state' field to our object, in the _columns collection
 
675
 
 
676
.. i18n: .. code-block:: python
 
677
.. i18n: 
 
678
.. i18n:        _columns = {
 
679
.. i18n:         ...
 
680
.. i18n:            'state': fields.selection([
 
681
.. i18n:                ('new','New'),
 
682
.. i18n:                ('assigned','Assigned'),
 
683
.. i18n:                ('negotiation','Negotiation'),
 
684
.. i18n:                ('won','Won'),
 
685
.. i18n:                ('lost','Lost')], 'Stage', readonly=True),
 
686
.. i18n:        }
 
687
 
 
688
.. code-block:: python
 
689
 
 
690
        _columns = {
 
691
         ...
 
692
            'state': fields.selection([
 
693
                ('new','New'),
 
694
                ('assigned','Assigned'),
 
695
                ('negotiation','Negotiation'),
 
696
                ('won','Won'),
 
697
                ('lost','Lost')], 'Stage', readonly=True),
 
698
        }
 
699
 
 
700
.. i18n: Define the State-change Handling Methods
 
701
.. i18n: ----------------------------------------
 
702
 
 
703
Define the State-change Handling Methods
 
704
----------------------------------------
 
705
 
 
706
.. i18n: Add the following additional methods to your object. These will be called by our workflow buttons
 
707
 
 
708
Add the following additional methods to your object. These will be called by our workflow buttons
 
709
 
 
710
.. i18n: .. code-block:: python
 
711
.. i18n: 
 
712
.. i18n:        def mymod_new(self, cr, uid, ids):
 
713
.. i18n:                 self.write(cr, uid, ids, { 'state' : 'new' })
 
714
.. i18n:                 return True
 
715
.. i18n: 
 
716
.. i18n:        def mymod_assigned(self, cr, uid, ids):
 
717
.. i18n:                 self.write(cr, uid, ids, { 'state' : 'assigned' })
 
718
.. i18n:                 return True
 
719
.. i18n: 
 
720
.. i18n:        def mymod_negotiation(self, cr, uid, ids):
 
721
.. i18n:                 self.write(cr, uid, ids, { 'state' : 'negotiation' })
 
722
.. i18n:                 return True
 
723
.. i18n: 
 
724
.. i18n:        def mymod_won(self, cr, uid, ids):
 
725
.. i18n:                 self.write(cr, uid, ids, { 'state' : 'won' })
 
726
.. i18n:                 return True
 
727
.. i18n: 
 
728
.. i18n:        def mymod_lost(self, cr, uid, ids):
 
729
.. i18n:                 self.write(cr, uid, ids, { 'state' : 'lost' })
 
730
.. i18n:                 return True
 
731
 
 
732
.. code-block:: python
 
733
 
 
734
        def mymod_new(self, cr, uid, ids):
 
735
                 self.write(cr, uid, ids, { 'state' : 'new' })
 
736
                 return True
 
737
 
 
738
        def mymod_assigned(self, cr, uid, ids):
 
739
                 self.write(cr, uid, ids, { 'state' : 'assigned' })
 
740
                 return True
 
741
 
 
742
        def mymod_negotiation(self, cr, uid, ids):
 
743
                 self.write(cr, uid, ids, { 'state' : 'negotiation' })
 
744
                 return True
 
745
 
 
746
        def mymod_won(self, cr, uid, ids):
 
747
                 self.write(cr, uid, ids, { 'state' : 'won' })
 
748
                 return True
 
749
 
 
750
        def mymod_lost(self, cr, uid, ids):
 
751
                 self.write(cr, uid, ids, { 'state' : 'lost' })
 
752
                 return True
 
753
 
 
754
.. i18n: Obviously you would extend these methods in the future to do something more useful!
 
755
.. i18n: Create your Workflow XML file
 
756
.. i18n: -----------------------------
 
757
 
 
758
Obviously you would extend these methods in the future to do something more useful!
 
759
Create your Workflow XML file
 
760
-----------------------------
 
761
 
 
762
.. i18n: There are three types of records we need to define in a file called mymod_workflow.xml
 
763
 
 
764
There are three types of records we need to define in a file called mymod_workflow.xml
 
765
 
 
766
.. i18n: #. Workflow header record (only one of these)
 
767
 
 
768
#. Workflow header record (only one of these)
 
769
 
 
770
.. i18n:        .. code-block:: xml
 
771
.. i18n: 
 
772
.. i18n:                <record model="workflow" id="wkf_mymod">
 
773
.. i18n:                    <field name="name">mymod.wkf</field>
 
774
.. i18n:                    <field name="osv">mymod.mymod</field>
 
775
.. i18n:                    <field name="on_create">True</field>
 
776
.. i18n:                </record>
 
777
 
 
778
        .. code-block:: xml
 
779
 
 
780
                <record model="workflow" id="wkf_mymod">
 
781
                    <field name="name">mymod.wkf</field>
 
782
                    <field name="osv">mymod.mymod</field>
 
783
                    <field name="on_create">True</field>
 
784
                </record>
 
785
 
 
786
.. i18n: #. Workflow Activity records
 
787
 
 
788
#. Workflow Activity records
 
789
 
 
790
.. i18n:        These define the actions that should be executed when the workflow reaches a particular state
 
791
 
 
792
        These define the actions that should be executed when the workflow reaches a particular state
 
793
 
 
794
.. i18n:        .. code-block:: xml
 
795
.. i18n: 
 
796
.. i18n:                <record model="workflow.activity" id="act_new">
 
797
.. i18n:                        <field name="wkf_id" ref="wkf_mymod" />
 
798
.. i18n:                        <field name="flow_start">True</field>
 
799
.. i18n:                        <field name="name">new</field>
 
800
.. i18n:                        <field name="kind">function</field>
 
801
.. i18n:                        <field name="action">mymod_new()</field>
 
802
.. i18n:                </record>
 
803
.. i18n: 
 
804
.. i18n:                <record model="workflow.activity" id="act_assigned">
 
805
.. i18n:                        <field name="wkf_id" ref="wkf_mymod" />
 
806
.. i18n:                        <field name="name">assigned</field>
 
807
.. i18n:                        <field name="kind">function</field>
 
808
.. i18n:                        <field name="action">mymod_assigned()</field>
 
809
.. i18n:                </record>
 
810
.. i18n: 
 
811
.. i18n:                <record model="workflow.activity" id="act_negotiation">
 
812
.. i18n:                        <field name="wkf_id" ref="wkf_mymod" />
 
813
.. i18n:                        <field name="name">negotiation</field>
 
814
.. i18n:                        <field name="kind">function</field>
 
815
.. i18n:                        <field name="action">mymod_negotiation()</field>
 
816
.. i18n:                </record>
 
817
.. i18n: 
 
818
.. i18n:                <record model="workflow.activity" id="act_won">
 
819
.. i18n:                        <field name="wkf_id" ref="wkf_mymod" />
 
820
.. i18n:                        <field name="name">won</field>
 
821
.. i18n:                        <field name="kind">function</field>
 
822
.. i18n:                        <field name="action">mymod_won()</field>
 
823
.. i18n:                        <field name="flow_stop">True</field>
 
824
.. i18n:                </record>
 
825
.. i18n: 
 
826
.. i18n:                <record model="workflow.activity" id="act_lost">
 
827
.. i18n:                        <field name="wkf_id" ref="wkf_mymod" />
 
828
.. i18n:                        <field name="name">lost</field>
 
829
.. i18n:                        <field name="kind">function</field>
 
830
.. i18n:                        <field name="action">mymod_lost()</field>
 
831
.. i18n:                        <field name="flow_stop">True</field>
 
832
.. i18n:                </record>
 
833
 
 
834
        .. code-block:: xml
 
835
 
 
836
                <record model="workflow.activity" id="act_new">
 
837
                        <field name="wkf_id" ref="wkf_mymod" />
 
838
                        <field name="flow_start">True</field>
 
839
                        <field name="name">new</field>
 
840
                        <field name="kind">function</field>
 
841
                        <field name="action">mymod_new()</field>
 
842
                </record>
 
843
 
 
844
                <record model="workflow.activity" id="act_assigned">
 
845
                        <field name="wkf_id" ref="wkf_mymod" />
 
846
                        <field name="name">assigned</field>
 
847
                        <field name="kind">function</field>
 
848
                        <field name="action">mymod_assigned()</field>
 
849
                </record>
 
850
 
 
851
                <record model="workflow.activity" id="act_negotiation">
 
852
                        <field name="wkf_id" ref="wkf_mymod" />
 
853
                        <field name="name">negotiation</field>
 
854
                        <field name="kind">function</field>
 
855
                        <field name="action">mymod_negotiation()</field>
 
856
                </record>
 
857
 
 
858
                <record model="workflow.activity" id="act_won">
 
859
                        <field name="wkf_id" ref="wkf_mymod" />
 
860
                        <field name="name">won</field>
 
861
                        <field name="kind">function</field>
 
862
                        <field name="action">mymod_won()</field>
 
863
                        <field name="flow_stop">True</field>
 
864
                </record>
 
865
 
 
866
                <record model="workflow.activity" id="act_lost">
 
867
                        <field name="wkf_id" ref="wkf_mymod" />
 
868
                        <field name="name">lost</field>
 
869
                        <field name="kind">function</field>
 
870
                        <field name="action">mymod_lost()</field>
 
871
                        <field name="flow_stop">True</field>
 
872
                </record>
 
873
 
 
874
.. i18n: #. Workflow Transition records
 
875
 
 
876
#. Workflow Transition records
 
877
 
 
878
.. i18n:        These define the possible transitions between workflow states
 
879
 
 
880
        These define the possible transitions between workflow states
 
881
 
 
882
.. i18n:        .. code-block:: xml
 
883
.. i18n: 
 
884
.. i18n:                <record model="workflow.transition" id="t1">
 
885
.. i18n:                        <field name="act_from" ref="act_new" />
 
886
.. i18n:                        <field name="act_to" ref="act_assigned" />
 
887
.. i18n:                        <field name="signal">mymod_assigned</field>
 
888
.. i18n:                </record>
 
889
.. i18n: 
 
890
.. i18n:                <record model="workflow.transition" id="t2">
 
891
.. i18n:                        <field name="act_from" ref="act_assigned" />
 
892
.. i18n:                        <field name="act_to" ref="act_negotiation" />
 
893
.. i18n:                        <field name="signal">mymod_negotiation</field>
 
894
.. i18n:                </record>
 
895
.. i18n: 
 
896
.. i18n:                <record model="workflow.transition" id="t3">
 
897
.. i18n:                        <field name="act_from" ref="act_negotiation" />
 
898
.. i18n:                        <field name="act_to" ref="act_won" />
 
899
.. i18n:                        <field name="signal">mymod_won</field>
 
900
.. i18n:                </record>
 
901
.. i18n: 
 
902
.. i18n:                <record model="workflow.transition" id="t4">
 
903
.. i18n:                        <field name="act_from" ref="act_negotiation" />
 
904
.. i18n:                        <field name="act_to" ref="act_lost" />
 
905
.. i18n:                        <field name="signal">mymod_lost</field>
 
906
.. i18n:                </record>
 
907
 
 
908
        .. code-block:: xml
 
909
 
 
910
                <record model="workflow.transition" id="t1">
 
911
                        <field name="act_from" ref="act_new" />
 
912
                        <field name="act_to" ref="act_assigned" />
 
913
                        <field name="signal">mymod_assigned</field>
 
914
                </record>
 
915
 
 
916
                <record model="workflow.transition" id="t2">
 
917
                        <field name="act_from" ref="act_assigned" />
 
918
                        <field name="act_to" ref="act_negotiation" />
 
919
                        <field name="signal">mymod_negotiation</field>
 
920
                </record>
 
921
 
 
922
                <record model="workflow.transition" id="t3">
 
923
                        <field name="act_from" ref="act_negotiation" />
 
924
                        <field name="act_to" ref="act_won" />
 
925
                        <field name="signal">mymod_won</field>
 
926
                </record>
 
927
 
 
928
                <record model="workflow.transition" id="t4">
 
929
                        <field name="act_from" ref="act_negotiation" />
 
930
                        <field name="act_to" ref="act_lost" />
 
931
                        <field name="signal">mymod_lost</field>
 
932
                </record>
 
933
 
 
934
.. i18n: Add mymod_workflow.xml to __terp__.py
 
935
 
 
936
Add mymod_workflow.xml to __terp__.py
 
937
 
 
938
.. i18n: Edit your module's __terp__.py and add mymod_workflow.xml to the "update_xml" array, so that OpenERP picks it up next time your module is loaded.
 
939
.. i18n: Add Workflow Buttons to your View
 
940
 
 
941
Edit your module's __terp__.py and add mymod_workflow.xml to the "update_xml" array, so that OpenERP picks it up next time your module is loaded.
 
942
Add Workflow Buttons to your View
 
943
 
 
944
.. i18n: The final step is to add the required buttons to mymod_views.xml file.
 
945
 
 
946
The final step is to add the required buttons to mymod_views.xml file.
 
947
 
 
948
.. i18n: Add the following at the end of the <form> section of your object's view definition:
 
949
 
 
950
Add the following at the end of the <form> section of your object's view definition:
 
951
 
 
952
.. i18n:        .. code-block:: xml
 
953
.. i18n: 
 
954
.. i18n:                <separator string="Workflow Actions" colspan="4"/>
 
955
.. i18n:                <group colspan="4" col="3">
 
956
.. i18n:                    <button name="mymod_assigned" string="Assigned" states="new" />
 
957
.. i18n:                    <button name="mymod_negotiation" string="In Negotiation" states="assigned" />
 
958
.. i18n:                    <button name="mymod_won" string="Won" states="negotiating" />
 
959
.. i18n:                    <button name="mymod_lost" string="Lost" states="negotiating" />
 
960
.. i18n:                </group>
 
961
 
 
962
        .. code-block:: xml
 
963
 
 
964
                <separator string="Workflow Actions" colspan="4"/>
 
965
                <group colspan="4" col="3">
 
966
                    <button name="mymod_assigned" string="Assigned" states="new" />
 
967
                    <button name="mymod_negotiation" string="In Negotiation" states="assigned" />
 
968
                    <button name="mymod_won" string="Won" states="negotiating" />
 
969
                    <button name="mymod_lost" string="Lost" states="negotiating" />
 
970
                </group>
 
971
 
 
972
.. i18n: Testing
 
973
.. i18n: -------
 
974
.. i18n: Now use the Module Manager to install or update your module. If you have done everything correctly you shouldn't get any errors. You can check if your workflow is installed in Administration -> Customisation -> Workflow Definitions
 
975
 
 
976
Testing
 
977
-------
 
978
Now use the Module Manager to install or update your module. If you have done everything correctly you shouldn't get any errors. You can check if your workflow is installed in Administration -> Customisation -> Workflow Definitions
 
979
 
 
980
.. i18n: When you are testing, remember that the workflow will only apply to NEW records that you create.
 
981
 
 
982
When you are testing, remember that the workflow will only apply to NEW records that you create.
 
983
 
 
984
.. i18n: Troubleshooting
 
985
.. i18n: ---------------
 
986
.. i18n: If your buttons do not seem to be doing anything, one of the following two things are likely:
 
987
 
 
988
Troubleshooting
 
989
---------------
 
990
If your buttons do not seem to be doing anything, one of the following two things are likely:
 
991
 
 
992
.. i18n:    1. The record you are working on does not have a Workflow Instance record associated with it (it was probably created before you defined your workflow)
 
993
.. i18n:    2. You have not set the "osv" field correctly in your workflow XML file
 
994
 
 
995
   1. The record you are working on does not have a Workflow Instance record associated with it (it was probably created before you defined your workflow)
 
996
   2. You have not set the "osv" field correctly in your workflow XML file