[REM] workflow: Remove workflow engine, documentation and tests

20 files changed, 0 insertions, 613 deletions

diff --git a/doc/reference/actions.rst b/doc/reference/actions.rst
index 221c01ecfe6..d2e628dc363 100644
--- a/doc/reference/actions.rst
+++ b/doc/reference/actions.rst
@@ -324,18 +324,6 @@ Executes multiple actions one after the other. Actions to execute are defined
 via the ``child_ids`` m2m. If sub-actions themselves return actions, the last
 one will be returned to the client as the multi's own next action
 
-``trigger``
------------
-
-Sends a signal to a workflow.
-
-``wkf_transition_id``
-    :class:`~odoo.fields.Many2one` to a ``workflow.transition`` to trigger
-``use_relational_model``
-    if ``base`` (the default), trigger the signal on behalf of the current
-    record. If ``relational``, trigger the signal on behalf of a field of the
-    current record selected through ``wkf_model_id`` and ``wkf_field_id``
-
 ``client_action``
 -----------------
 
@@ -368,9 +356,6 @@ server actions:
 ``Warning``
     constructor for the ``Warning`` exception
 
-.. ignored uid (available through ``user``), workflow (available through
-   workflow methods on models)
-
 .. _reference/actions/report:
 
 Report Actions (``ir.actions.report.xml``)
diff --git a/doc/reference/data.rst b/doc/reference/data.rst
index 0b2338b6633..20172fa063b 100644
--- a/doc/reference/data.rst
+++ b/doc/reference/data.rst
@@ -152,16 +152,6 @@ Parameters can be provided using ``eval`` (should evaluate to a sequence of
 parameters to call the method with) or ``value`` elements (see ``list``
 values).
 
-``workflow``
-------------
-
-The ``workflow`` tag sends a signal to an existing workflow. The workflow
-can be specified via a ``ref`` attribute (the :term:`external id` of
-an existing workflow) or a ``value`` tag returning the id of a workflow.
-
-The tag also has two mandatory attributes ``model`` (the model linked to the
-workflow) and ``action`` (the name of the signal to send to the workflow).
-
 .. ignored assert
 
 Shortcuts
diff --git a/doc/reference/guidelines.rst b/doc/reference/guidelines.rst
index aa691311cd2..8f1f97c5ff0 100644
--- a/doc/reference/guidelines.rst
+++ b/doc/reference/guidelines.rst
@@ -182,7 +182,6 @@ To declare a record in XML, the **record** notation (using *<record>*) is recomm
 Odoo supports custom tags acting as syntactic sugar:
 
 - menuitem: use it as a shortcut to declare a ``ir.ui.menu``
-- workflow: the <workflow> tag sends a signal to an existing workflow.
 - template: use it to declare a QWeb View requiring only the ``arch`` section of the view.
 - report: use to declare a :ref:`report action <reference/actions/report>`
 - act_window: use it if the record notation can't do what you want
diff --git a/doc/reference/mixins.rst b/doc/reference/mixins.rst
index 5d919226ac5..1693ad321ac 100644
--- a/doc/reference/mixins.rst
+++ b/doc/reference/mixins.rst
@@ -428,9 +428,6 @@ The urls in the actions list can be generated automatically by calling the
           self-explanatory
         ``unfollow``
           self-explanatory
-        ``workflow``
-          trigger a workflow signal; the signal's name should be
-          provided as the kwarg ``signal``
         ``method``
           call a method on the record; the method's name should be
           provided as the kwarg ``method``
diff --git a/doc/reference/security.rst b/doc/reference/security.rst
index fbc4cf1124a..bacb02c787f 100644
--- a/doc/reference/security.rst
+++ b/doc/reference/security.rst
@@ -98,11 +98,5 @@ access to the field:
     field access groups apply to administrator in fields_get but not in
     read/write...
 
-Workflow transition rules
-=========================
-
-Workflow transitions can be restricted to a specific group. Users outside the
-group can not trigger the transition.
-
 .. _foo: http://google.com
 .. _time module: https://docs.python.org/2/library/time.html
diff --git a/doc/reference/views.rst b/doc/reference/views.rst
index 6fdccb0c8bb..186ab4eedf8 100644
--- a/doc/reference/views.rst
+++ b/doc/reference/views.rst
@@ -201,10 +201,6 @@ Possible children elements of the list view are:
     ``type``
         type of button, indicates how it clicking it affects Odoo:
 
-        ``workflow`` (default)
-            sends a signal to a workflow. The button's ``name`` is the
-            workflow signal, the row's record is passed as argument to the
-            signal
         ``object``
             call a method on the list's model. The button's ``name`` is the
             method, which is called with the current row's record id and the
diff --git a/doc/reference/workflow/Makefile b/doc/reference/workflow/Makefile
deleted file mode 100644
index 07bbb67dd55..00000000000
--- a/doc/reference/workflow/Makefile
+++ /dev/null
@@ -1,20 +0,0 @@
-DOTFILES:=$(wildcard *.dot)
-SVGFILES:=$(patsubst %.dot,%.svg,$(DOTFILES))
-PNGFILES:=$(patsubst %.dot,%.png,$(DOTFILES))
-
-# try to disable implicit rules
-.SUFFIXES:
-
-.PHONY: all clean
-
-all: $(SVGFILES) $(PNGFILES)
-
-# must -f to ignore errors when running clean multiple times in a row
-clean:
-	rm -f *.png *.svg
-
-%.svg: %.dot
-	dot -Tsvg $< > $@
-
-%.png: %.dot
-	dot -Tpng $< > $@
diff --git a/doc/reference/workflow/join.dot b/doc/reference/workflow/join.dot
deleted file mode 100644
index e413a8a8ebc..00000000000
--- a/doc/reference/workflow/join.dot
+++ /dev/null
@@ -1,10 +0,0 @@
-digraph join {
-    // dummy sources as support for edges, make invisible and height 0
-    a [style=invis height=0 fontsize=0]
-    b [style=invis height=0 fontsize=0]
-    c [style=invis height=0 fontsize=0]
-
-    a -> Activity
-    b -> Activity
-    c -> Activity
-}
diff --git a/doc/reference/workflow/join.png b/doc/reference/workflow/join.png
deleted file mode 100644
index cdc0bafb2ca..00000000000
--- a/doc/reference/workflow/join.png
+++ /dev/null
diff --git a/doc/reference/workflow/join.svg b/doc/reference/workflow/join.svg
deleted file mode 100644
index 1462281977f..00000000000
--- a/doc/reference/workflow/join.svg
+++ /dev/null
@@ -1,36 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
- "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.38.0 (20140413.2041)
- -->
-<!-- Title: join Pages: 1 -->
-<svg width="206pt" height="93pt"
- viewBox="0.00 0.00 206.00 92.73" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 88.7279)">
-<title>join</title>
-<polygon fill="white" stroke="none" points="-4,4 -4,-88.7279 202,-88.7279 202,4 -4,4"/>
-<!-- a -->
-<!-- Activity -->
-<g id="node4" class="node"><title>Activity</title>
-<ellipse fill="none" stroke="black" cx="99" cy="-18" rx="40.0939" ry="18"/>
-<text text-anchor="middle" x="99" y="-14.3" font-family="Times,serif" font-size="14.00">Activity</text>
-</g>
-<!-- a&#45;&gt;Activity -->
-<g id="edge1" class="edge"><title>a&#45;&gt;Activity</title>
-<path fill="none" stroke="black" d="M33.6445,-71.9778C42.4332,-64.8537 58.4442,-51.875 72.4186,-40.5472"/>
-<polygon fill="black" stroke="black" points="74.7768,-43.1411 80.3411,-34.1251 70.3688,-37.7033 74.7768,-43.1411"/>
-</g>
-<!-- b -->
-<!-- b&#45;&gt;Activity -->
-<g id="edge2" class="edge"><title>b&#45;&gt;Activity</title>
-<path fill="none" stroke="black" d="M99,-71.9778C99,-66.0508 99,-56.0715 99,-46.3619"/>
-<polygon fill="black" stroke="black" points="102.5,-46.1364 99,-36.1364 95.5001,-46.1365 102.5,-46.1364"/>
-</g>
-<!-- c -->
-<!-- c&#45;&gt;Activity -->
-<g id="edge3" class="edge"><title>c&#45;&gt;Activity</title>
-<path fill="none" stroke="black" d="M164.355,-71.9778C155.567,-64.8537 139.556,-51.875 125.581,-40.5472"/>
-<polygon fill="black" stroke="black" points="127.631,-37.7033 117.659,-34.1251 123.223,-43.1411 127.631,-37.7033"/>
-</g>
-</g>
-</svg>
diff --git a/doc/reference/workflow/order_0.dot b/doc/reference/workflow/order_0.dot
deleted file mode 100644
index 3932040e914..00000000000
--- a/doc/reference/workflow/order_0.dot
+++ /dev/null
@@ -1,9 +0,0 @@
-digraph order {
-    Draft [style=filled fillcolor="#73fa79"]
-    Closed [style=filled fillcolor="#98c7df"]
-    Canceled [style=filled fillcolor="#98c7df"]
-
-    Draft -> Confirmed
-    Confirmed -> Closed
-    Confirmed -> Canceled
-}
diff --git a/doc/reference/workflow/order_0.png b/doc/reference/workflow/order_0.png
deleted file mode 100644
index 7d16f96dcbc..00000000000
--- a/doc/reference/workflow/order_0.png
+++ /dev/null
diff --git a/doc/reference/workflow/order_0.svg b/doc/reference/workflow/order_0.svg
deleted file mode 100644
index 54a5c050238..00000000000
--- a/doc/reference/workflow/order_0.svg
+++ /dev/null
@@ -1,48 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
- "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.38.0 (20140413.2041)
- -->
-<!-- Title: order Pages: 1 -->
-<svg width="188pt" height="188pt"
- viewBox="0.00 0.00 188.24 188.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 184)">
-<title>order</title>
-<polygon fill="white" stroke="none" points="-4,4 -4,-184 184.243,-184 184.243,4 -4,4"/>
-<!-- Draft -->
-<g id="node1" class="node"><title>Draft</title>
-<ellipse fill="#73fa79" stroke="black" cx="85.3968" cy="-162" rx="30.5947" ry="18"/>
-<text text-anchor="middle" x="85.3968" y="-158.3" font-family="Times,serif" font-size="14.00">Draft</text>
-</g>
-<!-- Confirmed -->
-<g id="node4" class="node"><title>Confirmed</title>
-<ellipse fill="none" stroke="black" cx="85.3968" cy="-90" rx="51.9908" ry="18"/>
-<text text-anchor="middle" x="85.3968" y="-86.3" font-family="Times,serif" font-size="14.00">Confirmed</text>
-</g>
-<!-- Draft&#45;&gt;Confirmed -->
-<g id="edge1" class="edge"><title>Draft&#45;&gt;Confirmed</title>
-<path fill="none" stroke="black" d="M85.3968,-143.697C85.3968,-135.983 85.3968,-126.712 85.3968,-118.112"/>
-<polygon fill="black" stroke="black" points="88.8969,-118.104 85.3968,-108.104 81.8969,-118.104 88.8969,-118.104"/>
-</g>
-<!-- Closed -->
-<g id="node2" class="node"><title>Closed</title>
-<ellipse fill="#98c7df" stroke="black" cx="36.3968" cy="-18" rx="36.2938" ry="18"/>
-<text text-anchor="middle" x="36.3968" y="-14.3" font-family="Times,serif" font-size="14.00">Closed</text>
-</g>
-<!-- Canceled -->
-<g id="node3" class="node"><title>Canceled</title>
-<ellipse fill="#98c7df" stroke="black" cx="135.397" cy="-18" rx="44.6926" ry="18"/>
-<text text-anchor="middle" x="135.397" y="-14.3" font-family="Times,serif" font-size="14.00">Canceled</text>
-</g>
-<!-- Confirmed&#45;&gt;Closed -->
-<g id="edge2" class="edge"><title>Confirmed&#45;&gt;Closed</title>
-<path fill="none" stroke="black" d="M73.7845,-72.411C67.8042,-63.8677 60.3917,-53.2785 53.7479,-43.7874"/>
-<polygon fill="black" stroke="black" points="56.5277,-41.6552 47.9257,-35.4699 50.7931,-45.6694 56.5277,-41.6552"/>
-</g>
-<!-- Confirmed&#45;&gt;Canceled -->
-<g id="edge3" class="edge"><title>Confirmed&#45;&gt;Canceled</title>
-<path fill="none" stroke="black" d="M97.2461,-72.411C103.348,-63.8677 110.912,-53.2785 117.692,-43.7874"/>
-<polygon fill="black" stroke="black" points="120.668,-45.6416 123.633,-35.4699 114.972,-41.573 120.668,-45.6416"/>
-</g>
-</g>
-</svg>
diff --git a/doc/reference/workflow/order_1.dot b/doc/reference/workflow/order_1.dot
deleted file mode 100644
index cc204343172..00000000000
--- a/doc/reference/workflow/order_1.dot
+++ /dev/null
@@ -1,11 +0,0 @@
-digraph order {
-    Draft [style=filled fillcolor="#73fa79"]
-    Closed [style=filled fillcolor="#98c7df"]
-    Canceled [style=filled fillcolor="#98c7df"]
-
-    Draft -> Confirmed [label="discount <= 15%"]
-    Draft -> Validation [label="discount > 15%"]
-    Validation -> Confirmed [label="Accept"]
-    Confirmed -> Closed
-    Confirmed -> Canceled
-}
diff --git a/doc/reference/workflow/order_1.png b/doc/reference/workflow/order_1.png
deleted file mode 100644
index 0c38acd0413..00000000000
--- a/doc/reference/workflow/order_1.png
+++ /dev/null
diff --git a/doc/reference/workflow/order_1.svg b/doc/reference/workflow/order_1.svg
deleted file mode 100644
index 08f099e34c9..00000000000
--- a/doc/reference/workflow/order_1.svg
+++ /dev/null
@@ -1,66 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
- "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.38.0 (20140413.2041)
- -->
-<!-- Title: order Pages: 1 -->
-<svg width="260pt" height="291pt"
- viewBox="0.00 0.00 259.79 291.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 287)">
-<title>order</title>
-<polygon fill="white" stroke="none" points="-4,4 -4,-287 255.792,-287 255.792,4 -4,4"/>
-<!-- Draft -->
-<g id="node1" class="node"><title>Draft</title>
-<ellipse fill="#73fa79" stroke="black" cx="85.3968" cy="-265" rx="30.5947" ry="18"/>
-<text text-anchor="middle" x="85.3968" y="-261.3" font-family="Times,serif" font-size="14.00">Draft</text>
-</g>
-<!-- Confirmed -->
-<g id="node4" class="node"><title>Confirmed</title>
-<ellipse fill="none" stroke="black" cx="85.3968" cy="-91" rx="51.9908" ry="18"/>
-<text text-anchor="middle" x="85.3968" y="-87.3" font-family="Times,serif" font-size="14.00">Confirmed</text>
-</g>
-<!-- Draft&#45;&gt;Confirmed -->
-<g id="edge1" class="edge"><title>Draft&#45;&gt;Confirmed</title>
-<path fill="none" stroke="black" d="M72.5816,-248.399C62.7132,-235.312 49.8641,-215.656 44.3968,-196 40.1092,-180.585 40.1092,-175.415 44.3968,-160 48.7071,-144.503 57.6054,-129.007 66.0142,-116.73"/>
-<polygon fill="black" stroke="black" points="68.9995,-118.572 71.9779,-108.405 63.3089,-114.496 68.9995,-118.572"/>
-<text text-anchor="middle" x="94.3968" y="-174.3" font-family="Times,serif" font-size="14.00">discount &lt;= 15%</text>
-</g>
-<!-- Validation -->
-<g id="node5" class="node"><title>Validation</title>
-<ellipse fill="none" stroke="black" cx="202.397" cy="-178" rx="49.2915" ry="18"/>
-<text text-anchor="middle" x="202.397" y="-174.3" font-family="Times,serif" font-size="14.00">Validation</text>
-</g>
-<!-- Draft&#45;&gt;Validation -->
-<g id="edge2" class="edge"><title>Draft&#45;&gt;Validation</title>
-<path fill="none" stroke="black" d="M103.936,-250.531C122.48,-237.059 151.286,-216.131 172.959,-200.386"/>
-<polygon fill="black" stroke="black" points="175.139,-203.129 181.172,-194.42 171.024,-197.466 175.139,-203.129"/>
-<text text-anchor="middle" x="195.897" y="-217.8" font-family="Times,serif" font-size="14.00">discount &gt; 15%</text>
-</g>
-<!-- Closed -->
-<g id="node2" class="node"><title>Closed</title>
-<ellipse fill="#98c7df" stroke="black" cx="36.3968" cy="-18" rx="36.2938" ry="18"/>
-<text text-anchor="middle" x="36.3968" y="-14.3" font-family="Times,serif" font-size="14.00">Closed</text>
-</g>
-<!-- Canceled -->
-<g id="node3" class="node"><title>Canceled</title>
-<ellipse fill="#98c7df" stroke="black" cx="135.397" cy="-18" rx="44.6926" ry="18"/>
-<text text-anchor="middle" x="135.397" y="-14.3" font-family="Times,serif" font-size="14.00">Canceled</text>
-</g>
-<!-- Confirmed&#45;&gt;Closed -->
-<g id="edge4" class="edge"><title>Confirmed&#45;&gt;Closed</title>
-<path fill="none" stroke="black" d="M73.7845,-73.174C67.7175,-64.3831 60.1766,-53.4564 53.4596,-43.7236"/>
-<polygon fill="black" stroke="black" points="56.1491,-41.4588 47.5884,-35.2165 50.3879,-45.4348 56.1491,-41.4588"/>
-</g>
-<!-- Confirmed&#45;&gt;Canceled -->
-<g id="edge5" class="edge"><title>Confirmed&#45;&gt;Canceled</title>
-<path fill="none" stroke="black" d="M97.2461,-73.174C103.348,-64.5087 110.912,-53.7682 117.692,-44.1415"/>
-<polygon fill="black" stroke="black" points="120.736,-45.8965 123.633,-35.7052 115.013,-41.8661 120.736,-45.8965"/>
-</g>
-<!-- Validation&#45;&gt;Confirmed -->
-<g id="edge3" class="edge"><title>Validation&#45;&gt;Confirmed</title>
-<path fill="none" stroke="black" d="M181.209,-161.607C162.688,-148.152 135.604,-128.475 114.953,-113.472"/>
-<polygon fill="black" stroke="black" points="116.97,-110.612 106.822,-107.566 112.856,-116.275 116.97,-110.612"/>
-<text text-anchor="middle" x="170.397" y="-130.8" font-family="Times,serif" font-size="14.00">Accept</text>
-</g>
-</g>
-</svg>
diff --git a/doc/reference/workflow/split.dot b/doc/reference/workflow/split.dot
deleted file mode 100644
index b0f3831854a..00000000000
--- a/doc/reference/workflow/split.dot
+++ /dev/null
@@ -1,10 +0,0 @@
-digraph split {
-    // dummy destinations as support for edges, make invisible and height 0
-    a [style=invis height=0 fontsize=0]
-    b [style=invis height=0 fontsize=0]
-    c [style=invis height=0 fontsize=0]
-
-    Activity -> a
-    Activity -> b
-    Activity -> c
-}
diff --git a/doc/reference/workflow/split.png b/doc/reference/workflow/split.png
deleted file mode 100644
index d9d512cffa3..00000000000
--- a/doc/reference/workflow/split.png
+++ /dev/null
diff --git a/doc/reference/workflow/split.svg b/doc/reference/workflow/split.svg
deleted file mode 100644
index 139874fdc75..00000000000
--- a/doc/reference/workflow/split.svg
+++ /dev/null
@@ -1,36 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
- "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.38.0 (20140413.2041)
- -->
-<!-- Title: split Pages: 1 -->
-<svg width="206pt" height="93pt"
- viewBox="0.00 0.00 206.00 92.73" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 88.7279)">
-<title>split</title>
-<polygon fill="white" stroke="none" points="-4,4 -4,-88.7279 202,-88.7279 202,4 -4,4"/>
-<!-- a -->
-<!-- b -->
-<!-- c -->
-<!-- Activity -->
-<g id="node4" class="node"><title>Activity</title>
-<ellipse fill="none" stroke="black" cx="99" cy="-66.7279" rx="40.0939" ry="18"/>
-<text text-anchor="middle" x="99" y="-63.0279" font-family="Times,serif" font-size="14.00">Activity</text>
-</g>
-<!-- Activity&#45;&gt;a -->
-<g id="edge1" class="edge"><title>Activity&#45;&gt;a</title>
-<path fill="none" stroke="black" d="M80.4582,-50.6978C68.3594,-40.8903 52.7894,-28.2691 41.577,-19.1802"/>
-<polygon fill="black" stroke="black" points="43.641,-16.3478 33.6687,-12.7696 39.233,-21.7857 43.641,-16.3478"/>
-</g>
-<!-- Activity&#45;&gt;b -->
-<g id="edge2" class="edge"><title>Activity&#45;&gt;b</title>
-<path fill="none" stroke="black" d="M99,-48.5325C99,-40.494 99,-30.9869 99,-23.1351"/>
-<polygon fill="black" stroke="black" points="102.5,-22.8941 99,-12.8941 95.5001,-22.8942 102.5,-22.8941"/>
-</g>
-<!-- Activity&#45;&gt;c -->
-<g id="edge3" class="edge"><title>Activity&#45;&gt;c</title>
-<path fill="none" stroke="black" d="M117.542,-50.6978C129.641,-40.8903 145.211,-28.2691 156.423,-19.1802"/>
-<polygon fill="black" stroke="black" points="158.767,-21.7857 164.331,-12.7696 154.359,-16.3478 158.767,-21.7857"/>
-</g>
-</g>
-</svg>
diff --git a/doc/reference/workflows.rst b/doc/reference/workflows.rst
deleted file mode 100644
index c67784797c4..00000000000
--- a/doc/reference/workflows.rst
+++ /dev/null
@@ -1,328 +0,0 @@
-.. _reference/workflows:
-
-Workflows
-=========
-
-In Odoo, a workflow is a technical artefact to manage a set of "things to
-do" associated to the records of a model. The workflow provides a higher-level
-way to organize tasks to perform with or on a record.
-
-More specifically, a workflow is a directed graph where the nodes are called
-"activities" and the arcs are called "transitions".
-
-- Activities define work that should be done within the Odoo server, such
-  as changing the state of some records, or sending emails.
-- Transitions control how the workflow progresses from activity to activity.
-
-In the definition of a workflow, one can attach conditions, signals, and
-triggers to transitions, so that the behavior of the workflow depends on user
-actions (such as clicking on a button), changes to records, or arbitrary
-Python code.
-
-All in all, Odoo's workflow system provides:
-
-* a description of the evolution of a record (document) over time
-* automatic actions based on various and flexible conditions
-* management of company roles and validation steps
-* management of interactions between objects
-* a visual representation of document flows through their lifecycle
-
-For instance, a basic order could have the following flow:
-
-.. sphinx.ext.graphviz would be nice, but it requires ``dot`` on any machine
-.. where the doc is compiled... otoh this is a pain in the ass because you
-.. need 2 compilation steps (dot -> image and rst -> html) every time
-
-.. image:: workflow/order_0.*
-    :align: center
-
-Orders start in the *Draft* state, can be *Confirmed* by a user, and then
-either shipped (*Closed*) or *Canceled*.
-
-A company using Odoo may want to add discount support to orders, where sales
-staff has discretionary discounting powers up to 15%, but manager validation
-is required for discounts beyond 15%. The workflow can be altered online to
-add the relevant steps without editing Python or XML files:
-
-.. image:: workflow/order_1.*
-    :align: center
-
-Because Activities can perform arbitrary actions, the *Validation* can
-automatically send a validation request to the relevant employee.
-
-.. note:: the order view needs to be modified to add an *Accept Discount*
-          button for managers
-
-Basics
-------
-
-Defining a workflow with data files is straightforward: a record "workflow" is
-given together with records for the activities and the transitions. For
-instance, here is a simple sequence of two activities defined in XML
-
-.. code-block:: xml
-
-    <record id="test_workflow" model="workflow">
-        <field name="name">test.workflow</field>
-        <field name="osv">test.workflow.model</field>
-        <field name="on_create">True</field>
-    </record>
-
-    <record id="activity_a" model="workflow.activity">
-        <field name="wkf_id" ref="test_workflow"/>
-        <field name="flow_start">True</field>
-        <field name="name">a</field>
-        <field name="kind">function</field>
-        <field name="action">print_a()</field>
-    </record>
-    <record id="activity_b" model="workflow.activity">
-        <field name="wkf_id" ref="test_workflow"/>
-        <field name="flow_stop">True</field>
-        <field name="name">b</field>
-        <field name="kind">function</field>
-        <field name="action">print_b()</field>
-    </record>
-
-    <record id="trans_a_b" model="workflow.transition">
-        <field name="act_from" ref="activity_a"/>
-        <field name="act_to" ref="activity_b"/>
-        <field name="signal">signal_goto_b</signal>
-    </record>
-
-A worfklow is always defined with respect to a particular model (the model is
-given by the attribute ``osv`` on the model ``workflow``). Methods specified
-in the activities or transitions will be called on that model.
-
-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"
-to "b".
-
-The first activity has its attribute ``flow_start`` set to ``True`` so that
-Odoo knows where to start the workflow traversal after it is instanciated.
-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 by other means, such as from some module Python code.)
-
-When the workflow is instanciated, it begins with activity "a". That activity
-is of kind ``function``, which means that the action ``print_a()`` is a method
-call on the model ``test.workflow`` (the usual ``cr, uid, ids, context``
-arguments are passed for you).
-
-The transition between "a" and "b" specify a signal but not any condition. This
-means the workflow instance will immediately transition from "a" to "b" when the
-signal ``signal_goto_b`` is recieved and thus processes activity "b"'s action
-``print_b()``.
-
-Activities
-----------
-
-While the transitions can be seen as the control structures of the workflows,
-activities are where everything happens, from changing record
-states to sending email.
-
-Different kinds of activities exist: ``Dummy``, ``Function``, ``Subflow``, and
-``Stop all``, each doing different things when the activity is processed. In
-addition to their kind, activies have other properties, detailed in the next
-sections.
-
-Flow start and flow stop
-''''''''''''''''''''''''
-
-The attribute ``flow_start`` is a boolean value specifying whether the activity
-is processed when the workflow is instanciated. Multiple activities can have
-their attribute ``flow_start`` set to ``True``. When instanciating a workflow
-for a record, Odoo simply processes all of them, and evaluate all their
-outgoing transitions afterwards.
-
-The attribute ``flow_stop`` is a boolean value specifying whether the activity
-stops the workflow instance. A workflow instance is considered completed when
-all its activities with the attribute ``flow_stop`` set to ``True`` are
-completed.
-
-It is important for Odoo to know when a workflow instance is completed. A
-workflow can have an activity that is actually another workflow (called a
-subflow); that activity is completed when the subflow is completed.
-
-Subflow
-'''''''
-
-An activity can embed a complete workflow, called a subflow (the embedding
-workflow is called the parent workflow). The workflow to instanciate is
-specified by attribute ``subflow_id``.
-
-.. note:: In the GUI, that attribute can not be set unless the kind of the
-          activity is ``Subflow``.
-
-The activity is considered completed (and its outgoing transitions ready to be
-evaluated) when the subflow is completed (see attribute ``flow_stop`` above).
-
-Sending a signal from a subflow
-'''''''''''''''''''''''''''''''
-
-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
-giving a signal name in the attribute ``signal_send``. Odoo processes those
-activities by sending the value of ``signal_send`` prefixed by "subflow."  to
-the parent workflow instance.
-
-In other words, it is possible to react and get transitions in the parent
-workflow as activities are executed in the sublow.
-
-Server actions
-''''''''''''''
-
-An activity can run a "Server Action" by specifying its ID in the attribute
-``action_id``.
-
-Python action
-'''''''''''''
-
-An activity can execute some Python code, given by the attribute ``action``.
-The evaluation environment is the same as the one explained in the section
-`Conditions`_.
-
-Split mode
-''''''''''
-
-After an activity has been processed, Odoo evaluates its transition to reach
-the next activity in the flow.
-
-However if an activity has more than one transition, Odoo must decide which
-activity or activities to follow.
-
-.. image:: workflow/split.*
-    :align: center
-
-This choice is controlled by the ``split_mode`` attribute:
-
-``XOR`` (default)
-    By default, Odoo will use the first transition (in ``sequence`` order)
-    whose condition is satisfied. All other transitions are ignored.
-``OR``
-    In ``OR`` mode, all transitions with a satisfied condition are traversed
-    simultanously. Transitions not yet valid will be ignored, even if they
-    become valid later.
-``AND``
-    In ``AND`` mode, Odoo will wait until *all* transitions are satisfied, and
-    will traverse all of them (much like the ``OR`` mode).
-
-Both ``OR`` and ``AND`` mode will lead to activities being active in the same
-workflow.
-
-Join mode
-'''''''''
-
-Just like outgoing transition conditions can be combined together to decide
-whether they can be traversed or not, incoming transitions can be combined
-together to decide if and when an activity may be processed.
-
-.. image:: workflow/join.*
-    :align: center
-
-The ``join_mode`` attribute controls that behavior:
-
-``XOR`` (default)
-    Any incoming transition enables the activity and starts its processing.
-``AND``
-    The activity is enabled and processed only once *all* incoming transitions
-    have been traversed.
-
-Kinds
-'''''
-
-An activity's kind defines the type of work an activity can perform.
-
-Dummy (``dummy``, default)
-    Do nothing at all, or call a server action. Often used as dispatch or
-    gather "hubs" for transitions.
-Function (``function``)
-    Run some python code, execute a server action.
-Stop all (``stopall``)
-    Completely stops the workflow instance and marks it as completed.
-Subflow (``subflow``)
-    Starts executing an other workflow, once that workflow is completed the
-    activity is done processing.
-
-    By default, the subflow is instanciated for the same record as the parent
-    workflow. It is possible to change that behavior by providing Python code
-    that returns a record ID (of the same data model as the subflow). The
-    embedded subflow instance is then the one of the given record.
-
-
-Transitions
------------
-
-Transitions provide the control structures to orchestrate a workflow. When an
-activity is completed, the workflow engine tries to get across transitions
-departing from the completed activity, towards the next activities. In their
-simplest form (as in the example above), they link activities sequentially:
-activities are processed as soon as the activities preceding them are
-completed.
-
-Instead of running all activities in one fell swoop, it is also possible to
-wait on transitions, going through them only when some criteria are met. The
-criteria are the conditions, the signals, and the triggers. They are detailed
-in the following sections.
-
-Conditions
-''''''''''
-
-When an activity has been completed, its outgoing transitions are inspected to
-determine whether it is possible for the workflow instance to proceed through
-them and reach the next activities. When only a condition is defined (i.e., no
-signal or trigger is defined), the condition is evaluated by Odoo, and if
-it evaluates to ``True``, the worklfow instance progresses through the
-transition.  If the condition is not met, it will be reevaluated every time
-the associated record is modified, or by an explicit method call to do it.
-
-By default, the attribute ``condition`` (i.e., the expression to be evaluated)
-is just "True", which trivially evaluates to ``True``. Note that the condition
-may be several lines long; in that case, the value of the last one determines
-whether the transition can be taken.
-
-In the condition evaluation environment, several symbols are conveniently
-defined (in addition to the Odoo ``safe_eval`` environment):
-
-- all the model column names, and
-- all the browse record's attributes.
-
-.. _reference/workflows/signals:
-
-Signals
-'''''''
-
-In addition to a condition, a transition can specify a signal name. When such
-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
-woken up.
-
-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 in the user interface, using the element ``<button/>`` with the signal
-name as 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
-          workflow instance.
-
-Triggers
-''''''''
-
-With conditions that evaluate to ``False``, transitions are not taken (and
-thus 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-called triggers. The idea is that when the condition is not
-satisfied, triggers are recorded in database. Later, it is possible to wake up
-specifically the workflow instances that installed those triggers, offering
-them to reevaluate their transition conditions. This mechanism makes it
-cheaper to wake up workflow instances by targetting just a few of them (those
-that have installed the triggers) instead of all of them.
-
-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
-definition provides a model name (attribute ``trigger_model``) and a Python
-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 they are associated with.
-
-.. note:: triggers are not re-installed whenever the transition is re-tried.