diff --git a/doc/changelog.rst b/doc/changelog.rst index 70d959941ad..ce639d2d3c8 100644 --- a/doc/changelog.rst +++ b/doc/changelog.rst @@ -6,6 +6,16 @@ Changelog `trunk` ------- +- Improved ``html_email_clean`` in tools: better quote and signature finding, + added shortening. +- Cleaned and slightly refactored ``ir.actions.server``. The ``loop``, ``sms`` + and ``dummy`` server actions have been removed; ``object_create`` and + ``object_copy`` have been merged into ``object_create``; ``other`` is now ``multi`` + and raises in case of loops. See :ref:`ir-actions-server` for more details. +- Removed ``sms_send`` method. +- Added checking of recursions in many2many loops using ``_check_m2m_recursion``. +- Added MONTHS attribute on fields.date and fields.datetime, holding the list + (month_number, month_name) - Almost removed ``LocalService()``. For reports, ``openerp.osv.orm.Model.print_report()`` can be used. For workflows, see :ref:`orm-workflows`. diff --git a/doc/index.rst b/doc/index.rst index e641de1da67..4b988e747b4 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -14,11 +14,13 @@ OpenERP Server 02_architecture 03_module_dev 04_security + workflows 05_test_framework 06_misc deployment-gunicorn deployment-mod-wsgi form-view-guidelines + ir_actions OpenERP Command ''''''''''''''' diff --git a/doc/ir_actions.rst b/doc/ir_actions.rst new file mode 100644 index 00000000000..31d22a7ead9 --- /dev/null +++ b/doc/ir_actions.rst @@ -0,0 +1,48 @@ +.. _ir-actions: + +Ir Actions +=========== + +.. _ir-actions-server: + +Server actions +++++++++++++++ + +.. versionchanged:: 8.0 + +.. currentmodule:: openerp.addons.base.ir.ir_actions + +.. autoclass:: actions_server + :noindex: + +Adding a new sever action +------------------------- + +The ``state`` field holds the various available types of server action. In order +to add a new server action, the first thing to do is to override the ``_get_states`` +method that returns the list of values available for the selection field. + +.. automethod:: actions_server._get_states + :noindex: + +The method called when executing the server action is the ``run`` method. This +method calls ``run_action_``. When adding a new server action type, you +have to define the related method that will be called upon execution. + +.. automethod:: actions_server.run + :noindex: + +Changelog +--------- + +`8.0` +''''' + +The refactoring of OpenERP 8.0 server actions removed the following types of +server action: + + - ``loop``: can be replaced by a ``code`` action + - ``dummy``: can be replaced by a void ``code`` action + - ``object_create`` and ``object_copy`` have been merged into a single and + more understandable ``object_create`` action + - ``other`` is renamed ``multi`` and raises in case of loops diff --git a/doc/workflows.rst b/doc/workflows.rst new file mode 100644 index 00000000000..d8ba89bd1ad --- /dev/null +++ b/doc/workflows.rst @@ -0,0 +1,306 @@ +.. _workflows: + +Workflows +========= + +In OpenERP, a workflow is a technical artefact to manage a set of "things to do" +associated to the records of some data model. The workflow provides a higher- +level way to organize the things to do 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 OpenERP 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. + +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:: + + + test.workflow + test.workflow.model + True + + + + + True + a + function + print_a() + + + + True + b + function + print_b() + + + + + + + +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 +OpenERP 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" does not specify any condition. This means +that the workflow instance immediately goes from "a" to "b" after "a" has been +processed, and thus also processes activity "b". + +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 OpenERP, 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 OpenERP ``safe_eval`` environment): + +- all the model column names, and +- all the browse record's attributes. + +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 ``