[MERGE] forward port branch saas-12.4 up to 9ed4872ea03

closes odoo/odoo#37372

Signed-off-by: Christophe Simonis <chs@odoo.com>

13 files changed, 522 insertions, 464 deletions

diff --git a/doc/reference/actions.rst b/doc/reference/actions.rst
index e247bde9e61..614c06187e4 100644
--- a/doc/reference/actions.rst
+++ b/doc/reference/actions.rst
@@ -18,19 +18,23 @@ e.g. button methods. All actions share two mandatory attributes:
 ``name``
     short user-readable description of the action, may be displayed in the
     client's interface
+``binding_model_id``
+    if set, the action is available in the action bar for the given model
+
+    .. note:: For Server Actions, use ``model_id``.
 
 A client can get actions in 4 forms:
 
-``False``
-    if any action dialog is currently open, close it
-A string
-    if a :ref:`client action <reference/actions/client>` matches, interpret as
-    a client action's tag, otherwise treat as a number
-A number
-    read the corresponding action record from the database, may be a database
-    identifier or an :term:`external id`
-A dictionary
-    treat as a client action descriptor and execute
+*  ``False``
+      if any action dialog is currently open, close it
+*  A string
+      if a :ref:`client action <reference/actions/client>` matches, interpret as
+      a client action's tag, otherwise treat as a number
+*  A number
+      read the corresponding action record from the database, may be a database
+      identifier or an :term:`external id`
+*  A dictionary
+      treat as a client action descriptor and execute
 
 Bindings
 ========
@@ -122,12 +126,27 @@ dialog::
 In-database window actions have a few different fields which should be ignored
 by clients, mostly to use in composing the ``views`` list:
 
-``view_mode``
-    comma-separated list of view types as a string. All of these types will be
+``view_mode`` (default= ``tree,form`` )
+    comma-separated list of view types as a string (/!\\ No spaces /!\\). All of these types will be
     present in the generated ``views`` list (with at least a ``False`` view_id)
 ``view_ids``
     M2M\ [#notquitem2m]_ to view objects, defines the initial content of
     ``views``
+
+    .. note:: Act_window views can also be defined cleanly through ``ir.actions.act_window.view``.
+
+        If you plan to allow multiple views for your model, prefer using
+        ir.actions.act_window.view instead of the action ``view_ids``
+
+        .. code-block:: xml
+
+            <record model="ir.actions.act_window.view" id="test_action_tree">
+               <field name="sequence" eval="1"/>
+               <field name="view_mode">tree</field>
+               <field name="view_id" ref="view_test_tree"/>
+               <field name="act_window_id" ref="test_action"/>
+            </record>
+
 ``view_id``
     specific view added to the ``views`` list in case its type is part of the
     ``view_mode`` list and not already filled by one of the views in
@@ -160,6 +179,9 @@ The server-side composition of the ``views`` sequence is the following:
     * ``groups_id``?
     * ``filter``?
 
+.. [#notquitem2m] technically not an M2M: adds a sequence field and may be
+                  composed of just a view type, without a view id.
+
 .. _reference/actions/url:
 
 URL Actions (``ir.actions.act_url``)
@@ -178,7 +200,7 @@ via two fields:
 
     {
         "type": "ir.actions.act_url",
-        "url": "http://odoo.com",
+        "url": "https://odoo.com",
         "target": "self",
     }
 
@@ -189,6 +211,8 @@ will replace the current content section by the Odoo home page.
 Server Actions (``ir.actions.server``)
 ======================================
 
+.. autoclass:: odoo.addons.base.models.ir_actions.IrActionsServer
+
 Allow triggering complex server code from any valid action location. Only
 two fields are relevant to clients:
 
@@ -202,151 +226,90 @@ specific or generic actions based on their ``state``. Some fields (and
 corresponding behaviors) are shared between states:
 
 ``model_id``
-    Odoo model linked to the action, made available in
-    :ref:`evaluation contexts <reference/actions/server/context>`
-``condition`` (optional)
-    evaluated as Python code using the server action's
-    :ref:`evaluation context <reference/actions/server/context>`. If
-    ``False``, prevents the action from running. Default: ``True``
+    Odoo model linked to the action.
 
-Valid action types (``state`` field) are extensible, the default types are:
+``state``
 
-``code``
---------
+* ``code``: Executes python code given through the ``code`` argument.
 
-The default and most flexible server action type, executes arbitrary Python
-code with the action's :ref:`evaluation context
-<reference/actions/server/context>`. Only uses one specific type-specific
-field:
+* ``object_create``: Creates a new record of model ``crud_model_id`` following ``fields_lines`` specifications.
 
-``code``
-    a piece of Python code to execute when the action is called
+* ``object_write``: Updates the current record(s) following ``fields_lines`` specifications
 
-.. code-block:: xml
+* ``multi``: Executes serveral actions given through the ``child_ids`` argument.
 
-    <record model="ir.actions.server" id="print_instance">
-        <field name="name">Res Partner Server Action</field>
-        <field name="model_id" ref="model_res_partner"/>
-        <field name="code">
-            raise Warning(object.name)
-        </field>
-    </record>
+State fields
+------------
+
+Depending on its state, the behavior is defined through different fields.
+The concerned state is given after each field.
+
+``code`` (code)
+  Specify a piece of Python code to execute when the action is called
+
+  .. code-block:: xml
+
+      <record model="ir.actions.server" id="print_instance">
+          <field name="name">Res Partner Server Action</field>
+          <field name="model_id" ref="model_res_partner"/>
+          <field name="code">
+              raise Warning(record.name)
+          </field>
+      </record>
+
+  .. note::
+
+      The code segment can define a variable called ``action``, which will be
+      returned to the client as the next action to execute:
+
+      .. code-block:: xml
+
+          <record model="ir.actions.server" id="print_instance">
+              <field name="name">Res Partner Server Action</field>
+              <field name="model_id" ref="model_res_partner"/>
+              <field name="code">
+                  if record.some_condition():
+                      action = {
+                          "type": "ir.actions.act_window",
+                          "view_mode": "form",
+                          "res_model": record._name,
+                          "res_id": record.id,
+                      }
+              </field>
+          </record>
+
+      will ask the client to open a form for the record if it fulfills some
+      condition
+
+  ..  This tends to be the only action type created from :ref:`data files
+      <reference/data>`, other types aside from
+      :ref:`reference/actions/server/multi` are simpler than Python code to define
+      from the UI, but not from :ref:`data files <reference/data>`.
+
+``crud_model_id`` (create)(required)
+    model in which to create a new record
+``link_field_id`` (create)
+    many2one to ``ir.model.fields``, specifies the current record's m2o field
+    on which the newly created record should be set (models should match)
 
-.. note::
-
-    The code segment can define a variable called ``action``, which will be
-    returned to the client as the next action to execute:
-
-    .. code-block:: xml
-
-        <record model="ir.actions.server" id="print_instance">
-            <field name="name">Res Partner Server Action</field>
-            <field name="model_id" ref="model_res_partner"/>
-            <field name="code">
-                if object.some_condition():
-                    action = {
-                        "type": "ir.actions.act_window",
-                        "view_mode": "form",
-                        "res_model": object._name,
-                        "res_id": object.id,
-                    }
-            </field>
-        </record>
-
-    will ask the client to open a form for the record if it fulfills some
-    condition
-
-This tends to be the only action type created from :ref:`data files
-<reference/data>`, other types aside from
-:ref:`reference/actions/server/multi` are simpler than Python code to define
-from the UI, but not from :ref:`data files <reference/data>`.
-
-.. _reference/actions/server/object_create:
-
-``object_create``
------------------
-
-Creates a new record, from scratch (via :meth:`~odoo.models.Model.create`)
-or by copying an existing record (via :meth:`~odoo.models.Model.copy`)
-
-``use_create``
-    the creation policy, one of:
-
-    ``new``
-        creates a record in the model specified by ``model_id``
-    ``new_other``
-        creates a record in the model specified by ``crud_model_id``
-    ``copy_current``
-        copies the record on which the action was invoked
-    ``copy_other``
-        copies an other record, obtained via ``ref_object``
-``fields_lines``
+``fields_lines`` (create/write)
     fields to override when creating or copying the record.
     :class:`~odoo.fields.One2many` with the fields:
 
     ``col1``
-        ``ir.model.fields`` to set in the model implied by ``use_create``
+        ``ir.model.fields`` to set in the concerned model
+        (``crud_model_id`` for creates, ``model_id`` for updates)
     ``value``
         value for the field, interpreted via ``type``
-    ``type``
+    ``type`` (value|reference|equation)
         If ``value``, the ``value`` field is interpreted as a literal value
         (possibly converted), if ``equation`` the ``value`` field is
         interpreted as a Python expression and evaluated
-``crud_model_id``
-    model in which to create a new record, if ``use_create`` is set to
-    ``new_other``
-``ref_object``
-    :class:`~odoo.fields.Reference` to an arbitrary record to copy, used if
-    ``use_create`` is set to ``copy_other``
-``link_new_record``
-    boolean flag linking the newly created record to the current one via a
-    many2one field specified through ``link_field_id``, defaults to ``False``
-``link_field_id``
-    many2one to ``ir.model.fields``, specifies the current record's m2o field
-    on which the newly created record should be set (models should match)
-
-``object_write``
-----------------
-
-Similar to :ref:`reference/actions/server/object_create` but alters an
-existing records instead of creating one
-
-``use_write``
-    write policy, one of:
-
-    ``current``
-        write to the current record
-    ``other``
-        write to an other record selected via ``crud_model_id`` and
-        ``ref_object``
-    ``expression``
-        write to an other record whose model is selected via ``crud_model_id``
-        and whose id is selected by evaluating ``write_expression``
-``write_expression``
-    Python expression returning a record or an object id, used when
-    ``use_write`` is set to ``expression`` in order to decide which record
-    should be modified
-``fields_lines``
-    see :ref:`reference/actions/server/object_create`
-``crud_model_id``
-    see :ref:`reference/actions/server/object_create`
-``ref_object``
-    see :ref:`reference/actions/server/object_create`
-
-.. _reference/actions/server/multi:
-
-``multi``
----------
-
-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
 
-``client_action``
------------------
-
-Indirection for directly returning an other action defined using
-``action_id``. Simply returns that action to the client for execution.
+``child_ids`` (multi)
+    Specify the multiple sub-actions (``ir.actions.server``) to enact in state multi.
+    If sub-actions themselves return actions, the last
+    one will be returned to the client as the multi's own next action
 
 .. _reference/actions/server/context:
 
@@ -356,23 +319,12 @@ Evaluation context
 A number of keys are available in the evaluation context of or surrounding
 server actions:
 
-``model``
-    the model object linked to the action via ``model_id``
-``object``, ``obj``
-    only available if ``active_model`` and ``active_id`` are provided (via
-    context) otherwise ``None``. The actual record selected by ``active_id``
-``pool``
-    the current database registry
-``datetime``, ``dateutil``, ``time``
-    corresponding Python modules
-``cr``
-    the current cursor
-``user``
-    the current user record
-``context``
-    execution context
-``Warning``
-    constructor for the ``Warning`` exception
+* ``model`` model object linked to the action via ``model_id``
+* ``record``/``records`` record/recorset on which the action is triggered, can be void.
+* ``env`` Odoo Environment
+* ``datetime``, ``dateutil``, ``time``, ``timezone`` corresponding Python modules
+* ``log: log(message, level='info')`` logging function to record debug information in ir.logging table
+* ``Warning`` constructor for the ``Warning`` exception
 
 .. _reference/actions/report:
 
@@ -386,13 +338,15 @@ Triggers the printing of a report
     in a list of some sort
 ``model`` (mandatory)
     the model your report will be about
-``report_type`` (mandatory)
+``report_type`` (default=qweb-pdf)
     either ``qweb-pdf`` for PDF reports or ``qweb-html`` for HTML
-``report_name``
+``report_name`` (mandatory)
     the name of your report (which will be the name of the PDF output)
 ``groups_id``
     :class:`~odoo.fields.Many2many` field to the groups allowed to view/use
     the current report
+``multi``
+    if set to ``True``, the action will not be displayed on a form view.
 ``paperformat_id``
     :class:`~odoo.fields.Many2one` field to the paper format you wish to
     use for this report (if not specified, the company format will be used)
@@ -436,5 +390,40 @@ Triggers an action implemented entirely in the client.
 tells the client to start the Point of Sale interface, the server has no idea
 how the POS interface works.
 
-.. [#notquitem2m] technically not an M2M: adds a sequence field and may be
-                  composed of just a view type, without a view id.
+.. _reference/actions/cron:
+
+Automated Actions (``ir.cron``)
+======================================
+
+Actions triggered automatically on a predefined frequency.
+
+``name``
+    Name of the automated action (Mainly used in log display)
+
+``interval_number``
+    Number of *interval_type* uom between two executions of the action
+
+``interval_type``
+    Unit of measure of frequency interval (``minutes``, ``hours``, ``days``, ``weeks``, ``months``,
+
+``numbercall``
+    Number of times this action has to be run.
+    If the action is expected to run indefinitely, set to ``-1``.
+
+``doall``
+    Boolean precising whether the missed actions have to be executed in case of
+    server restarts.
+
+``model_id``
+    Model on which this action will be called
+
+``code``
+    Code content of the action.
+    Can be a simple call to the model's method :
+
+    .. code-block:: python
+
+      model.<method_name>()
+
+``nextcall``
+    Next planned execution date of this action (date/time format)
diff --git a/doc/reference/cmdline.rst b/doc/reference/cmdline.rst
index 8ab38abdc51..5652571f9be 100644
--- a/doc/reference/cmdline.rst
+++ b/doc/reference/cmdline.rst
@@ -19,6 +19,8 @@ Running the server
     Providing a comma-separated list restrict access to databases provided in
     list.
 
+    For advanced database options, take a look :ref:`below <reference/cmdline/server/database>`.
+
 .. option:: -i <modules>, --init <modules>
 
     comma-separated list of modules to install before running the server
@@ -32,82 +34,24 @@ Running the server
 .. option:: --addons-path <directories>
 
     comma-separated list of directories in which modules are stored. These
-    directories are scanned for modules (nb: when and why?)
-
-.. option:: --workers <count>
-
-    if ``count`` is not 0 (the default), enables multiprocessing and sets up
-    the specified number of HTTP workers (sub-processes processing HTTP
-    and RPC requests).
-
-    .. note:: multiprocessing mode is only available on Unix-based systems
-
-    A number of options allow limiting and recycling workers:
-
-    .. option:: --limit-request <limit>
-
-        Number of requests a worker will process before being recycled and
-        restarted.
-
-        Defaults to 8196.
-
-    .. option:: --limit-memory-soft <limit>
-
-        Maximum allowed virtual memory per worker. If the limit is exceeded,
-        the worker is killed and recycled at the end of the current request.
-
-        Defaults to 2048MiB.
-
-    .. option:: --limit-memory-hard <limit>
-
-        Hard limit on virtual memory, any worker exceeding the limit will be
-        immediately killed without waiting for the end of the current request
-        processing.
+    directories are scanned for modules.
 
-        Defaults to 2560MiB.
-
-    .. option:: --limit-time-cpu <limit>
-
-        Prevents the worker from using more than <limit> CPU seconds for each
-        request. If the limit is exceeded, the worker is killed.
-
-        Defaults to 60.
-
-    .. option:: --limit-time-real <limit>
-
-        Prevents the worker from taking longer than <limit> seconds to process
-        a request. If the limit is exceeded, the worker is killed.
-
-        Differs from :option:`--limit-time-cpu` in that this is a "wall time"
-        limit including e.g. SQL queries.
-
-        Defaults to 120.
-
-.. option:: --max-cron-threads <count>
-
-    number of workers dedicated to cron jobs. Defaults to 2. The workers are
-    threads in multi-threading mode and processes in multi-processing mode.
-
-    For multi-processing mode, this is in addition to the HTTP worker
-    processes.
+    .. (nb: when and why?)
 
 .. option:: -c <config>, --config <config>
 
-    provide an alternate configuration file
+    provide an alternate :ref:`configuration file <reference/cmdline/config>`
 
 .. option:: -s, --save
 
     saves the server configuration to the current configuration file
     (:file:`{$HOME}/.odoorc` by default, and can be overridden using
-    :option:`-c`)
+    :option:`-c`).
 
-.. option:: --proxy-mode
-
-    enables the use of ``X-Forwarded-*`` headers through `Werkzeug's proxy
-    support`_.
+.. option:: --without-demo
 
-    .. warning:: proxy mode *must not* be enabled outside of a reverse proxy
-                 scenario
+    disables demo data loading for modules installed
+    comma-separated, use ``all`` for all modules.
 
 .. option:: --test-enable
 
@@ -131,25 +75,9 @@ Running the server
     ``1``, ``t`` or ``true`` can be used to use the same directory as the above
     mentioned ``--screenshots`` option.
 
-.. option:: --dev <feature,feature,...,feature>
-
-    * ``all``: all the features below are activated
-
-    * ``xml``: read template qweb from xml file directly instead of database.
-      Once a template has been modified in database, it will be not be read from
-      the xml file until the next update/init.
-
-    * ``reload``: restart server when python file are updated (may not be detected
-      depending on the text editor used)
-
-    * ``qweb``: break in the evaluation of qweb template when a node contains ``t-debug='debugger'``
-
-    * ``(i)p(u)db``: start the chosen python debugger in the code when an
-      unexpected error is raised before logging and returning the error.
-
 .. _reference/cmdline/server/database:
 
-database
+Database
 --------
 
 .. option:: -r <user>, --db_user <user>
@@ -189,40 +117,40 @@ database
     listen by using the --database parameter and specifying a comma-separated
     list of databases
 
-    When combining the two parameters, db-filter superseed the comma-separated
+    When combining the two parameters, db-filter supersedes the comma-separated
     database list for restricting database list, while the comma-separated list
     is used for performing requested operations like upgrade of modules.
-    
+
     .. code-block:: bash
 
-        odoo-bin --db-filter ^11.*$
+        $ odoo-bin --db-filter ^11.*$
 
     Restrict access to databases whose name starts with 11
 
     .. code-block:: bash
 
-        odoo-bin --database 11firstdatabase,11seconddatabase
+        $ odoo-bin --database 11firstdatabase,11seconddatabase
 
     Restrict access to only two databases, 11firstdatabase and 11seconddatabase
-    
+
     .. code-block:: bash
 
-        odoo-bin --database 11firstdatabase,11seconddatabase -u base
+        $ odoo-bin --database 11firstdatabase,11seconddatabase -u base
 
     Restrict access to only two databases, 11firstdatabase and 11seconddatabase,
-    and update base module on one database: 11firstdatabase
+    and update base module on one database: 11firstdatabase.
     If database 11seconddatabase doesn't exist, the database is created and base modules
     is installed
-    
+
     .. code-block:: bash
 
-        odoo-bin --db-filter ^11.*$ --database 11firstdatabase,11seconddatabase -u base
-        
+        $ odoo-bin --db-filter ^11.*$ --database 11firstdatabase,11seconddatabase -u base
+
     Restrict access to databases whose name starts with 11,
-    and update base module on one database: 11firstdatabase
+    and update base module on one database: 11firstdatabase.
     If database 11seconddatabase doesn't exist, the database is created and base modules
     is installed
-    
+
 .. option:: --db-template <template>
 
     when creating new databases from the database-management screens, use the
@@ -237,7 +165,7 @@ database
 .. option:: --no-database-list
 
     Suppresses the ability to list databases available on the system
-    
+
 .. option:: --db_sslmode
 
     Control the SSL security of the connection between Odoo and PostgreSQL.
@@ -245,6 +173,33 @@ database
     'verify-ca' or 'verify-full'
     Default value is 'prefer'
 
+.. _reference/cmdline/server/emails:
+
+Emails
+------
+
+.. option:: --email-from <address>
+
+    Email address used as <FROM> when Odoo needs to send mails
+
+.. option:: --smtp <server>
+
+    Address of the SMTP server to connect to in order to send mails
+
+.. option:: --smtp-port <port>
+
+.. option:: --smtp-ssl
+
+    If set, odoo should use SSL/STARTSSL SMTP connections
+
+.. option:: --smtp-user <name>
+
+    Username to connect to the SMTP server
+
+.. option:: --smtp-password <password>
+
+    Password to connect to the SMTP server
+
 .. _reference/cmdline/server/internationalisation:
 
 Internationalisation
@@ -283,13 +238,41 @@ of importation
 
     specify modules to export. Use in combination with --i18n-export
 
+.. _reference/cmdline/advanced:
+
+Advanced Options
+----------------
+
+.. _reference/cmdline/dev:
 
-built-in HTTP
--------------
+Developer features
+''''''''''''''''''
+
+.. option:: --dev <feature,feature,...,feature>
+
+    * ``all``: all the features below are activated
+
+    * ``xml``: read template qweb from xml file directly instead of database.
+      Once a template has been modified in database, it will be not be read from
+      the xml file until the next update/init.
+
+    * ``reload``: restart server when python file are updated (may not be detected
+      depending on the text editor used)
+
+    * ``qweb``: break in the evaluation of qweb template when a node contains ``t-debug='debugger'``
+
+    * ``(i)p(u)db``: start the chosen python debugger in the code when an
+      unexpected error is raised before logging and returning the error.
+
+
+.. _reference/cmdline/server/http:
+
+HTTP
+''''
 
 .. option:: --no-http
 
-    do not start the HTTP or long-polling workers (may still start cron
+    do not start the HTTP or long-polling workers (may still start :ref:`cron <reference/actions/cron>`
     workers)
 
     .. warning:: has no effect if :option:`--test-enable` is set, as tests
@@ -309,25 +292,35 @@ built-in HTTP
     TCP port for long-polling connections in multiprocessing or gevent mode,
     defaults to 8072. Not used in default (threaded) mode.
 
-logging
--------
+.. option:: --proxy-mode
+
+    enables the use of ``X-Forwarded-*`` headers through `Werkzeug's proxy
+    support`_.
+
+    .. warning:: proxy mode *must not* be enabled outside of a reverse proxy
+                 scenario
+
+.. _reference/cmdline/server/logging:
+
+Logging
+'''''''
 
 By default, Odoo displays all logging of level_ ``info`` except for workflow
 logging (``warning`` only), and log output is sent to ``stdout``. Various
 options are available to redirect logging to other destinations and to
-customize the amount of logging output
+customize the amount of logging output.
 
 .. option:: --logfile <file>
 
     sends logging output to the specified file instead of stdout. On Unix, the
     file `can be managed by external log rotation programs
-    <https://docs.python.org/2/library/logging.handlers.html#watchedfilehandler>`_
+    <https://docs.python.org/3/library/logging.handlers.html#watchedfilehandler>`_
     and will automatically be reopened when replaced
 
 .. option:: --syslog
 
-    logs to the system's event logger: `syslog on unices <https://docs.python.org/2/library/logging.handlers.html#sysloghandler>`_
-    and `the Event Log on Windows <https://docs.python.org/2/library/logging.handlers.html#nteventloghandler>`_.
+    logs to the system's event logger: `syslog on unices <https://docs.python.org/3/library/logging.handlers.html#sysloghandler>`_
+    and `the Event Log on Windows <https://docs.python.org/3/library/logging.handlers.html#nteventloghandler>`_.
 
     Neither is configurable
 
@@ -335,7 +328,7 @@ customize the amount of logging output
 
     logs to the ``ir.logging`` model (``ir_logging`` table) of the specified
     database. The database can be the name of a database in the "current"
-    PostgreSQL, or `a PostgreSQL URI`_ for e.g. log aggregation
+    PostgreSQL, or `a PostgreSQL URI`_ for e.g. log aggregation.
 
 .. option:: --log-handler <handler-spec>
 
@@ -402,60 +395,66 @@ customize the amount of logging output
         In case of conflict between :option:`--log-level` and
         :option:`--log-handler`, the latter is used
 
-emails
-------
+.. _reference/cdmline/workers:
 
-.. option:: --email-from <address>
+Multiprocessing
+'''''''''''''''
 
-    Email address used as <FROM> when Odoo needs to send mails
+.. option:: --workers <count>
 
-.. option:: --smtp <server>
+    if ``count`` is not 0 (the default), enables multiprocessing and sets up
+    the specified number of HTTP workers (sub-processes processing HTTP
+    and RPC requests).
 
-    Address of the SMTP server to connect to in order to send mails
+    .. note:: multiprocessing mode is only available on Unix-based systems
 
-.. option:: --smtp-port <port>
+    A number of options allow limiting and recycling workers:
 
-.. option:: --smtp-ssl
+    .. option:: --limit-request <limit>
 
-    If set, odoo should use SSL/STARTSSL SMTP connections
+        Number of requests a worker will process before being recycled and
+        restarted.
 
-.. option:: --smtp-user <name>
+        Defaults to *8196*.
 
-    Username to connect to the SMTP server
+    .. option:: --limit-memory-soft <limit>
 
-.. option:: --smtp-password <password>
+        Maximum allowed virtual memory per worker. If the limit is exceeded,
+        the worker is killed and recycled at the end of the current request.
 
-    Password to connect to the SMTP server
+        Defaults to *2048MiB*.
 
+    .. option:: --limit-memory-hard <limit>
 
-.. _reference/cmdline/scaffold:
+        Hard limit on virtual memory, any worker exceeding the limit will be
+        immediately killed without waiting for the end of the current request
+        processing.
 
-Scaffolding
-===========
+        Defaults to *2560MiB*.
 
-.. program:: odoo-bin scaffold
+    .. option:: --limit-time-cpu <limit>
 
-Scaffolding is the automated creation of a skeleton structure to simplify
-bootstrapping (of new modules, in the case of Odoo). While not necessary it
-avoids the tedium of setting up basic structures and looking up what all
-starting requirements are.
+        Prevents the worker from using more than <limit> CPU seconds for each
+        request. If the limit is exceeded, the worker is killed.
 
-Scaffolding is available via the :command:`odoo-bin scaffold` subcommand.
+        Defaults to *60*.
 
-.. option:: -t <template>
+    .. option:: --limit-time-real <limit>
 
-    a template directory, files are passed through jinja2_ then copied to
-    the ``destination`` directory
+        Prevents the worker from taking longer than <limit> seconds to process
+        a request. If the limit is exceeded, the worker is killed.
 
-.. option:: name
+        Differs from :option:`--limit-time-cpu` in that this is a "wall time"
+        limit including e.g. SQL queries.
 
-    the name of the module to create, may munged in various manners to
-    generate programmatic names (e.g. module directory name, model names, …)
+        Defaults to *120*.
 
-.. option:: destination
+.. option:: --max-cron-threads <count>
 
-    directory in which to create the new module, defaults to the current
-    directory
+    number of workers dedicated to :ref:`cron <reference/actions/cron>` jobs. Defaults to *2*.
+    The workers are threads in multi-threading mode and processes in multi-processing mode.
+
+    For multi-processing mode, this is in addition to the HTTP worker processes.
 
 .. _reference/cmdline/config:
 
@@ -487,15 +486,67 @@ can be overridden using :option:`--config <odoo-bin -c>`. Specifying
 to that file.
 
 .. _jinja2: http://jinja.pocoo.org
-.. _regular expression: https://docs.python.org/2/library/re.html
+.. _regular expression: https://docs.python.org/3/library/re.html
 .. _password authentication:
-    http://www.postgresql.org/docs/9.3/static/auth-methods.html#AUTH-PASSWORD
+    https://www.postgresql.org/docs/9.3/static/auth-methods.html#AUTH-PASSWORD
 .. _template database:
-    http://www.postgresql.org/docs/9.3/static/manage-ag-templatedbs.html
+    https://www.postgresql.org/docs/9.3/static/manage-ag-templatedbs.html
 .. _level:
-    https://docs.python.org/2/library/logging.html#logging.Logger.setLevel
+    https://docs.python.org/3/library/logging.html#logging.Logger.setLevel
 .. _a PostgreSQL URI:
-    http://www.postgresql.org/docs/9.2/static/libpq-connect.html#AEN38208
+    https://www.postgresql.org/docs/9.2/static/libpq-connect.html#AEN38208
 .. _Werkzeug's proxy support:
     http://werkzeug.pocoo.org/docs/contrib/fixers/#werkzeug.contrib.fixers.ProxyFix
 .. _pyinotify: https://github.com/seb-m/pyinotify/wiki
+
+
+Shell
+=====
+
+Odoo command-line also allows to launch odoo as a python console environment.
+This enables direct interaction with the :ref:`orm <reference/orm>` and its functionalities.
+
+
+.. code-block:: console
+
+   $ odoo_bin shell
+
+.. option:: --shell-interface (ipython|ptpython|bpython|python)
+
+    Specify a preferred REPL to use in shell mode.
+
+
+.. _reference/cmdline/scaffold:
+
+Scaffolding
+===========
+
+.. program:: odoo-bin scaffold
+
+Scaffolding is the automated creation of a skeleton structure to simplify
+bootstrapping (of new modules, in the case of Odoo). While not necessary it
+avoids the tedium of setting up basic structures and looking up what all
+starting requirements are.
+
+Scaffolding is available via the :command:`odoo-bin scaffold` subcommand.
+
+.. option:: name (required)
+
+    the name of the module to create, may munged in various manners to
+    generate programmatic names (e.g. module directory name, model names, …)
+
+.. option:: destination (default=current directory)
+
+    directory in which to create the new module, defaults to the current
+    directory
+
+.. option:: -t <template>
+
+    a template directory, files are passed through jinja2_ then copied to
+    the ``destination`` directory
+
+.. code-block:: console
+
+    $ odoo_bin scaffold my_module /addons/
+
+This will create module *my_module* in directory */addons/*.
\ No newline at end of file
diff --git a/doc/reference/data.rst b/doc/reference/data.rst
index 2165a490dd0..416121b8255 100644
--- a/doc/reference/data.rst
+++ b/doc/reference/data.rst
@@ -22,6 +22,7 @@ of an XML data file is the following:
 .. code-block:: xml
 
     <!-- the root elements of the data file -->
+    <?xml version="1.0" encoding="UTF-8"?>
     <odoo>
       <operation/>
       ...
@@ -30,6 +31,25 @@ of an XML data file is the following:
 Data files are executed sequentially, operations can only refer to the result
 of operations defined previously
 
+.. note::
+
+    If the content of the data file is expected to be applied only once, you
+    can specify the odoo flag ``noupdate`` set to 1.  If part of
+    the data in the file is expected to be applied once, you can place this part
+    of the file in a <data noupdate="1"> domain.
+
+    .. code-block:: xml
+
+      <odoo>
+          <data noupdate="1">
+              <!-- Only loaded when installing the module (odoo-bin -i module) -->
+              <operation/>
+          </data>
+
+          <!-- (Re)Loaded at install and update (odoo-bin -i/-u) -->
+          <operation/>
+      </odoo>
+
 Core operations
 ===============
 
@@ -152,8 +172,31 @@ Parameters can be provided using ``eval`` (should evaluate to a sequence of
 parameters to call the method with) or ``value`` elements (see ``list``
 values).
 
+.. code-block:: xml
+
+  <odoo>
+      <data noupdate="1">
+          <record name="partner_1" model="res.partner">
+              <field name="name">Odude</field>
+          </record>
+
+          <function model="res.partner" name="send_inscription_notice"
+              eval="[[ref('partner_1'), ref('partner_2')]]"/>
+
+          <function model="res.users" name="send_vip_inscription_notice">
+              <function eval="[[('vip','=',True)]]" model="res.partner" name="search"/>
+          </function>
+      </data>
+
+      <record id="model_form_view" model="ir.ui.view">
+
+      </record>
+  </odoo>
+
 .. ignored assert
 
+.. _reference/data/shortcuts:
+
 Shortcuts
 =========
 
@@ -166,7 +209,7 @@ data files provide shorter alternatives to defining them using
 
 Defines an ``ir.ui.menu`` record with a number of defaults and fallbacks:
 
-Parent menu
+``parent``
     * If a ``parent`` attribute is set, it should be the :term:`external id`
       of an other menu item, used as the new item's parent
     * If no ``parent`` is provided, tries to interpret the ``name`` attribute
@@ -175,10 +218,10 @@ Parent menu
       created
     * Otherwise the menu is defined as a "top-level" menu item (*not* a menu
       with no parent)
-Menu name
+``name``
     If no ``name`` attribute is specified, tries to get the menu name from
     a linked action if any. Otherwise uses the record's ``id``
-Groups
+``groups``
     A ``groups`` attribute is interpreted as a comma-separated sequence of
     :term:`external identifiers` for ``res.groups`` models. If an
     :term:`external identifier` is prefixed with a minus (``-``), the group
@@ -218,7 +261,7 @@ section of the view, and allowing a few *optional* attributes:
 ``report``
 ----------
 
-Creates a ``ir.actions.report`` record with a few default values.
+Creates a :ref:`IrActionsReport <reference/actions/report>` record with a few default values.
 
 Mostly just proxies attributes to the corresponding fields on
 ``ir.actions.report``, but also automatically creates the item in the
@@ -263,5 +306,5 @@ For each row (record):
 * the third column is the ``name`` field for ``res.country.state``
 * the fourth column is the ``code`` field for ``res.country.state``
 
-.. _base64: http://tools.ietf.org/html/rfc3548.html#section-3
-.. _csv: http://en.wikipedia.org/wiki/Comma-separated_values
+.. _base64: https://tools.ietf.org/html/rfc3548.html#section-3
+.. _csv: https://en.wikipedia.org/wiki/Comma-separated_values
diff --git a/doc/reference/javascript_api.rst b/doc/reference/javascript_api.rst
index bc17cd0c82a..23faacd3836 100644
--- a/doc/reference/javascript_api.rst
+++ b/doc/reference/javascript_api.rst
@@ -1,9 +1,12 @@
+:orphan:
 :banner: banners/javascript.jpg
 
 .. highlight:: javascript
 
 .. default-domain:: js
 
+.. _api/js:
+
 ==============
 Javascript API
 ==============
diff --git a/doc/reference/javascript_cheatsheet.rst b/doc/reference/javascript_cheatsheet.rst
index 97f7ba5cb5c..b6c5251c46c 100644
--- a/doc/reference/javascript_cheatsheet.rst
+++ b/doc/reference/javascript_cheatsheet.rst
@@ -1,5 +1,7 @@
 :banner: banners/javascript.jpg
 
+.. _reference/jscs:
+
 =====================
 Javascript Cheatsheet
 =====================
@@ -280,6 +282,7 @@ using the view in the kanban arch (a specific example is the helpdesk dashboard)
 
 Promises and asynchronous code
 ===============================
+
 For a very good and complete introduction to promises, please read this excellent article https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md
 
 Creating new Promises
@@ -418,6 +421,7 @@ Waiting for Promises
 
 Error handling
 --------------
+
 - in general in promises
         The general idea is that a promise should not be rejected for control flow, but should only be rejected for errors.
         When that is the case, you would have multiple resolutions of your promise with, for instance status codes that you would have to check in the `then` handlers and a single `catch` handler at the end of the promise chain.
@@ -540,4 +544,4 @@ Testing asynchronous code
                     });
                 });
 
-        as you can see, the nicer form is to use `async/await` as it is clearer and shorter to write.
\ No newline at end of file
+        as you can see, the nicer form is to use `async/await` as it is clearer and shorter to write.
diff --git a/doc/reference/javascript_reference.rst b/doc/reference/javascript_reference.rst
index a6eeb5e8d4e..f724485f86a 100644
--- a/doc/reference/javascript_reference.rst
+++ b/doc/reference/javascript_reference.rst
@@ -15,13 +15,8 @@ description into a live application, able to interact with every model and
 records in the database.  It is even possible to use the web client to modify
 the interface of the web client.
 
-.. note:: An html version of all docstrings in Odoo is available at:
-
-    .. toctree::
-        :maxdepth: 2
-
-        javascript_api
-
+.. note:: An html version of all js docstrings in Odoo is available at:
+      :ref:`JS API <api/js>`
 
 Overview
 =========
@@ -1421,7 +1416,7 @@ the AbstractView, AbstractController, AbstractRenderer and AbstractModel classes
 .. raw:: html
 
     <svg width="550" height="173">
-        <!-- Created with Method Draw - http://github.com/duopixel/Method-Draw/ -->
+        <!-- Created with Method Draw - https://github.com/duopixel/Method-Draw/ -->
         <path id="svg_1" d="m147.42498,79.79206c0.09944,-8.18859 -0.06363,-16.38812 0.81774,-24.5623c21.65679,2.68895 43.05815,7.08874 64.35,11.04543c1.14304,-4.01519 0.60504,-7.34585 1.59817,-11.05817c13.67878,7.81176 27.23421,15.73476 40.23409,24.03505c-12.47212,9.41539 -26.77809,17.592 -40.82272,25.96494c-0.4548,-3.89916 -0.90967,-7.79828 -1.36448,-11.69744c-20.69972,3.77225 -42.59036,7.6724 -63.42391,11.12096c-1.41678,-7.95741 -1.37514,-16.62327 -1.38888,-24.84846z" stroke-width="1.5" stroke="#000" fill="#fff"/>
         <rect id="svg_3" height="41" width="110" y="57.5" x="7" fill-opacity="null" stroke-opacity="null" stroke-width="1.5" stroke="#000" fill="#fff"/>
         <rect stroke="#000" id="svg_5" height="41" width="135" y="20.5" x="328" fill-opacity="null" stroke-opacity="null" stroke-width="1.5" fill="#fff"/>
@@ -1467,6 +1462,8 @@ the AbstractView, AbstractController, AbstractRenderer and AbstractModel classes
     context of a view manager/action manager.  They could be used in a client action,
     or, they could be displayed in the public website (with some work on the assets).
 
+.. _reference/js/widgets:
+
 Field Widgets
 =============
 
@@ -1927,7 +1924,6 @@ order.
 
     Options:
 
-    - title: title of the bar, displayed on top of the bar options
     - editable: boolean if value is editable
     - current_value: get the current_value from the field that must be present in the view
     - max_value: get the max_value from the field that must be present in the view
@@ -2278,18 +2274,18 @@ do that, several steps should be done.
 For more information, look into the *control_panel.js* file.
 
 .. _.appendTo():
-    http://api.jquery.com/appendTo/
+    https://api.jquery.com/appendTo/
 
 .. _.prependTo():
-    http://api.jquery.com/prependTo/
+    https://api.jquery.com/prependTo/
 
 .. _.insertAfter():
-    http://api.jquery.com/insertAfter/
+    https://api.jquery.com/insertAfter/
 
 .. _.insertBefore():
-    http://api.jquery.com/insertBefore/
+    https://api.jquery.com/insertBefore/
 
 .. _event delegation:
-    http://api.jquery.com/delegate/
+    https://api.jquery.com/delegate/
 
 .. _datepicker: https://github.com/Eonasdan/bootstrap-datetimepicker
diff --git a/doc/reference/mixins.rst b/doc/reference/mixins.rst
index 2f8e79bf649..7e72f533c77 100644
--- a/doc/reference/mixins.rst
+++ b/doc/reference/mixins.rst
@@ -39,11 +39,11 @@ widgets) to your form view will get you up and running in no time.
             _name = 'business.trip'
             _inherit = ['mail.thread']
             _description = 'Business Trip'
-            
+
             name = fields.Char()
             partner_id = fields.Many2one('res.partner', 'Responsible')
             guest_ids = fields.Many2many('res.partner', 'Participants')
-        
+
     In the form view:
 
     .. code-block:: xml
@@ -78,10 +78,10 @@ to manage followers on your record:
 .. rubric:: Posting messages
 
 .. method:: message_post(self, body='', subject=None, message_type='notification', subtype=None, parent_id=False, attachments=None, **kwargs)
-    
+
     Post a new message in an existing thread, returning the new
     mail.message ID.
-    
+
     :param str body: body of the message, usually raw HTML that will
         be sanitized
     :param str message_type: see mail_message.message_type field
@@ -95,20 +95,20 @@ to manage followers on your record:
     :rtype: int
 
 .. method:: message_post_with_view(views_or_xmlid, **kwargs):
-    
+
     Helper method to send a mail / post a message using a view_id to
     render using the ir.qweb engine. This method is stand alone, because
     there is nothing in template and composer that allows to handle
     views in batch. This method will probably disappear when templates
     handle ir ui views.
-    
+
     :param str or ``ir.ui.view`` record: external id or record of the view that
         should be sent
 
 .. method:: message_post_with_template(template_id, **kwargs)
-        
+
     Helper method to send a mail with a template
-    
+
     :param template_id: the id of the template to render to create the body of the message
     :param `\**kwargs`: parameter to create a mail.compose.message wizzard (which inherit from mail.message)
 
@@ -121,7 +121,7 @@ on the thread's record depending on some values from the email itself (i.e. upda
 a date or an e-mail address, add CC's addresses as followers, etc.).
 
 .. method:: message_new(msg_dict, custom_values=None)
-    
+
     Called by ``message_process`` when a new message is received
     for a given thread model, if the message did not belong to
     an existing thread.
@@ -129,7 +129,7 @@ a date or an e-mail address, add CC's addresses as followers, etc.).
     The default behavior is to create a new record of the corresponding
     model (based on some very basic info extracted from the message).
     Additional behavior may be implemented by overriding this method.
-    
+
     :param dict msg_dict: a map containing the email details and
         attachments. See ``message_process`` and ``mail.message.parse`` for details
     :param dict custom_values: optional dictionary of additional
@@ -140,14 +140,14 @@ a date or an e-mail address, add CC's addresses as followers, etc.).
     :return: the id of the newly created thread object
 
 .. method:: message_update(msg_dict, update_vals=None)
-        
+
     Called by ``message_process`` when a new message is received
     for an existing thread. The default behavior is to update the record
     with ``update_vals`` taken from the incoming email.
-    
+
     Additional behavior may be implemented by overriding this
     method.
-    
+
     :param dict msg_dict: a map containing the email details and attachments;
         see ``message_process`` and ``mail.message.parse()`` for details.
     :param dict update_vals: a dict containing values to update records given
@@ -159,7 +159,7 @@ a date or an e-mail address, add CC's addresses as followers, etc.).
 .. method:: message_subscribe(partner_ids=None, channel_ids=None, subtype_ids=None, force=True)
 
     Add partners to the records followers.
-    
+
     :param list(int) partner_ids: IDs of the partners that will be subscribed
         to the record
     :param list(int) channel_ids: IDs of the channels that will be subscribed
@@ -175,7 +175,7 @@ a date or an e-mail address, add CC's addresses as followers, etc.).
 .. method:: message_unsubscribe(partner_ids=None, channel_ids=None)
 
     Remove partners from the record's followers.
-    
+
     :param list(int) partner_ids: IDs of the partners that will be subscribed
         to the record
     :param list(int) channel_ids: IDs of the channels that will be subscribed
@@ -211,12 +211,12 @@ to a field, simple set the tracking attribute to True.
             _name = 'business.trip'
             _inherit = ['mail.thread']
             _description = 'Business Trip'
-            
+
             name = fields.Char(tracking=True)
             partner_id = fields.Many2one('res.partner', 'Responsible',
                                          tracking=True)
             guest_ids = fields.Many2many('res.partner', 'Participants')
-    
+
     From now on, every change to a trip's name or responsible will log a note
     on the record. The ``name`` field will be displayed in the notification as
     well to give more context about the notification (even if the name did not
@@ -232,32 +232,32 @@ subtype of notifications they wish to receive.
 
 Subtypes are created as data in your module; the model has the following fields:
 
-``name`` (mandatory) - :class:`~odoo.fields.Char` 
+``name`` (mandatory) - :class:`~odoo.fields.Char`
     name of the subtype, will be displayed in the notification customization
     popup
-``description`` - :class:`~odoo.fields.Char` 
+``description`` - :class:`~odoo.fields.Char`
     description that will be added in the message posted for this
     subtype. If void, the name will be added instead
-``internal`` - :class:`~odoo.fields.Boolean` 
+``internal`` - :class:`~odoo.fields.Boolean`
     messages with internal subtypes will be visible only by employees,
     aka members of the ``base.group_user`` group
-``parent_id`` - :class:`~odoo.fields.Many2one` 
+``parent_id`` - :class:`~odoo.fields.Many2one`
     link subtypes for automatic subscription; for example project subtypes are
     linked to task subtypes through this link. When someone is subscribed to
     a project, he will be subscribed to all tasks of this project with
     subtypes found using the parent subtype
-``relation_field`` - :class:`~odoo.fields.Char` 
+``relation_field`` - :class:`~odoo.fields.Char`
     as an example, when linking project and tasks subtypes, the relation
     field is the project_id field of tasks
-``res_model`` - :class:`~odoo.fields.Char` 
+``res_model`` - :class:`~odoo.fields.Char`
     model the subtype applies to; if False, this subtype applies to all models
-``default`` - :class:`~odoo.fields.Boolean` 
+``default`` - :class:`~odoo.fields.Boolean`
     wether the subtype is activated by default when subscribing
-``sequence`` - :class:`~odoo.fields.Integer` 
+``sequence`` - :class:`~odoo.fields.Integer`
     used to order subtypes in the notification customization popup
-``hidden`` - :class:`~odoo.fields.Boolean` 
+``hidden`` - :class:`~odoo.fields.Boolean`
     wether the subtype is hidden in the notification customization popup
-    
+
 
 Interfacing subtypes with field tracking allows to subscribe to different kind
 of notifications depending on what might interest users. To do this, you
@@ -301,7 +301,7 @@ can override the ``_track_subtype()`` function:
             _name = 'business.trip'
             _inherit = ['mail.thread']
             _description = 'Business Trip'
-            
+
             name = fields.Char(tracking=True)
             partner_id = fields.Many2one('res.partner', 'Responsible',
                                          tracking=True)
@@ -392,7 +392,7 @@ yourself by overriding the function ``_notification_recipients``.
     :returns: a subtype's full external id or False if no subtype is triggered
 
 
-The urls in the actions list can be generated automatically by calling the 
+The urls in the actions list can be generated automatically by calling the
 ``_notification_link_helper()`` function:
 
 
@@ -402,7 +402,7 @@ The urls in the actions list can be generated automatically by calling the
     record if the kwargs ``model`` and ``res_id`` are set).
 
     :param str link_type: link type to be generated; can be any of these values:
-    
+
         ``view``
           link to form view of the record
         ``assign``
@@ -418,8 +418,8 @@ The urls in the actions list can be generated automatically by calling the
         ``new``
           open an empty form view for a new record; you can specify
           a specific action by providing its id (database id or fully resolved
-          external id) in the kwarg ``action_id``        
-    
+          external id) in the kwarg ``action_id``
+
     :returns: link of the type selected for the record
     :rtype: str
 
@@ -428,7 +428,7 @@ The urls in the actions list can be generated automatically by calling the
     Let's add a custom button to the Business Trip state change notification;
     this button will reset the state to Draft and will be only visible to a member
     of the (imaginary) group Travel Manager (``business.group_trip_manager``)
-    
+
     .. code-block:: python
 
         class BusinessTrip(models.Model):
@@ -437,10 +437,10 @@ The urls in the actions list can be generated automatically by calling the
             _description = 'Business Trip'
 
             # Pevious code goes here
-            
+
             def action_cancel(self):
                 self.write({'state': 'draft'})
-            
+
             def _notification_recipients(self, message, groups):
                 """ Handle Trip Manager recipients that can cancel the trip at the last
                 minute and kill all the fun. """
@@ -451,7 +451,7 @@ The urls in the actions list can be generated automatically by calling the
                     app_action = self._notification_link_helper('method',
                                         method='action_cancel')
                     trip_actions = [{'url': app_action, 'title': _('Cancel')}]
-                
+
                 new_group = (
                     'group_trip_manager',
                     lambda partner: bool(partner.user_ids) and
@@ -462,11 +462,11 @@ The urls in the actions list can be generated automatically by calling the
                     })
 
                 return [new_group] + groups
-            
 
-    Note that that I could have defined my evaluation function outside of this 
+
+    Note that that I could have defined my evaluation function outside of this
     method and define a global function to do it instead of a lambda, but for
-    the sake of being more brief and less verbose in these documentation files 
+    the sake of being more brief and less verbose in these documentation files
     that can sometimes be boring, I choose the former instead of the latter.
 
 Overriding defaults
@@ -483,7 +483,7 @@ Context keys:
     These context keys can be used to somewhat control ``mail.thread`` features
     like auto-subscription or field tracking during calls to ``create()`` or
     ``write()`` (or any other method where it may be useful).
-    
+
     - ``mail_create_nosubscribe``: at create or message_post, do not subscribe
       the current user to the record thread
     - ``mail_create_nolog``: at create, do not log the automatic '<Document>
@@ -496,7 +496,7 @@ Context keys:
     - ``mail_notify_force_send``: if less than 50 email notifications to send,
       send them directly instead of using the queue; True by default
     - ``mail_notify_user_signature``: add the current user signature in
-      email notifications; True by default          
+      email notifications; True by default
 
 
 .. _reference/mixins/mail/alias:
@@ -540,14 +540,14 @@ or issues, Sales Team have aliases to generate Leads.
 
 .. note:: The model that will be created by the alias **must** inherit the
           ``mail_thread`` model.
-                    
+
 Alias support is added by inheriting ``mail.alias.mixin``; this mixin will
 generate a new ``mail.alias`` record for each record of the parent class that
 gets created (for example, every ``project.project`` record having its ``mail.alias``
 record initialized on creation).
 
 .. note:: Aliases can also be created manually and supported by a simple
-    :class:`~odoo.fields.Many2one` field. This guide assumes you wish a 
+    :class:`~odoo.fields.Many2one` field. This guide assumes you wish a
     more complete integration with automatic creation of the alias, record-specific
     default values, etc.
 
@@ -557,25 +557,25 @@ of the created alias, like the kind of record it must create and possibly
 some default values these records may have depending on the parent object:
 
 .. method:: get_alias_model_name(vals)
-    
+
     Return the model name for the alias. Incoming emails that are not
     replies to existing records will cause the creation of a new record
     of this alias model. The value may depend on ``vals``, the dict of
     values passed to ``create`` when a record of this model is created.
-    
+
     :param vals dict: values of the newly created record that will holding
                       the alias
     :return: model name
     :rtype: str
 
 .. method:: get_alias_values()
-    
+
     Return values to create an alias, or to write on the alias after its
     creation. While not completely mandatory, it is usually required to make
     sure that newly created records will be linked to the alias' parent (i.e.
     tasks getting created in the right project) by setting a dictionary of
     default values in the alias' ``alias_defaults`` field.
-    
+
     :return: dictionnary of values that will be written to the new alias
     :rtype: dict
 
@@ -583,24 +583,24 @@ The ``get_alias_values()`` override is particularly interesting as it allows you
 to modify the behaviour of your aliases easily. Among the fields that can be set
 on the alias, the following are of particular interest:
 
-``alias_name`` - :class:`~odoo.fields.Char` 
+``alias_name`` - :class:`~odoo.fields.Char`
     name of the email alias, e.g. 'jobs' if you want to catch emails for
     <jobs@example.odoo.com>
-``alias_user_id`` - :class:`~odoo.fields.Many2one` (``res.users``) 
+``alias_user_id`` - :class:`~odoo.fields.Many2one` (``res.users``)
     owner of records created upon receiving emails on this alias;
     if this field is not set the system will attempt to find the right owner
     based on the sender (From) address, or will use the Administrator account
     if no system user is found for that address
-``alias_defaults`` - :class:`~odoo.fields.Text` 
+``alias_defaults`` - :class:`~odoo.fields.Text`
     Python dictionary that will be evaluated to provide
     default values when creating new records for this alias
-``alias_force_thread_id`` - :class:`~odoo.fields.Integer` 
+``alias_force_thread_id`` - :class:`~odoo.fields.Integer`
     optional ID of a thread (record) to which all incoming messages will be
     attached, even if they did not reply to it; if set, this will disable the
     creation of new records completely
-``alias_contact`` - :class:`~odoo.fields.Selection` 
+``alias_contact`` - :class:`~odoo.fields.Selection`
     Policy to post a message on the document using the mailgateway
-    
+
     - *everyone*: everyone can post
     - *partners*: only authenticated partners
     - *followers*: only followers of the related document or members of following channels
@@ -631,7 +631,7 @@ you to make your alias easily configurable from the record's form view.
             expense_ids = fields.One2many('business.expense', 'trip_id', 'Expenses')
             alias_id = fields.Many2one('mail.alias', string='Alias', ondelete="restrict",
                                        required=True)
-                     
+
             def get_alias_model_name(self, vals):
             """ Specify the model that will get created when the alias receives a message """
                 return 'business.expense'
@@ -641,7 +641,7 @@ you to make your alias easily configurable from the record's form view.
                 values = super(BusinessTrip, self).get_alias_values()
                 # alias_defaults holds a dictionnary that will be written
                 # to all records created by this alias
-                # 
+                #
                 # in this case, we want all expense records sent to a trip alias
                 # to be linked to the corresponding business trip
                 values['alias_defaults'] = {'trip_id': self.id}
@@ -649,7 +649,7 @@ you to make your alias easily configurable from the record's form view.
                 # by default
                 values['alias_contact'] = 'followers'
                 return values
-                
+
         class BusinessExpense(models.Model):
             _name = 'business.expense'
             _inherit = ['mail.thread']
@@ -662,9 +662,9 @@ you to make your alias easily configurable from the record's form view.
 
     We would like our alias to be easily configurable from the form view of our
     business trips, so let's add the following to our form view:
-    
+
     .. code-block:: xml
-    
+
         <page string="Emails">
             <group name="group_alias">
                 <label for="alias_name" string="Email Alias"/>
@@ -684,7 +684,7 @@ you to make your alias easily configurable from the record's form view.
                         string="Accept Emails From"/>
             </group>
         </page>
-        
+
     Now we can change the alias address directly from the form view and change
     who can send e-mails to the alias.
 
@@ -696,12 +696,12 @@ you to make your alias easily configurable from the record's form view.
         class BusinessExpense(models.Model):
             # Previous code goes here
             # ...
-            
+
             def message_new(self, msg, custom_values=None):
-                """ Override to set values according to the email. 
-                
+                """ Override to set values according to the email.
+
                 In this simple example, we simply use the email title as the name
-                of the expense, try to find a partner with this email address and 
+                of the expense, try to find a partner with this email address and
                 do a regex match to find the amount of the expense."""
                 name = msg_dict.get('subject', 'New Expense')
                 # Match the last occurence of a float in the string
@@ -728,7 +728,7 @@ Activities tracking
 -------------------
 
 Activities are actions users have to take on a document like making a phone call
-or organizing a meeting. Activities come with the mail module as they are 
+or organizing a meeting. Activities come with the mail module as they are
 integrated in the Chatter but are *not bundled with mail.thread*. Activities
 are records of the ``mail.activity`` class, which have a type (``mail.activity.type``),
 name, description, scheduled time (among others). Pending activities are visible
@@ -798,16 +798,16 @@ campaigns through arguments in links to specified resources. The mixin adds
 
 * ``campaign_id``: :class:`~odoo.fields.Many2one` field to a ``utm.campaign``
   object (i.e. Christmas_Special, Fall_Collection, etc.)
-* ``source_id``: :class:`~odoo.fields.Many2one` field to a ``utm.source`` 
+* ``source_id``: :class:`~odoo.fields.Many2one` field to a ``utm.source``
   object (i.e. Search Engine, mailing list, etc.)
-* ``medium_id``: :class:`~odoo.fields.Many2one` field to a ``utm.medium`` 
+* ``medium_id``: :class:`~odoo.fields.Many2one` field to a ``utm.medium``
   object (i.e. Snail Mail, e-Mail, social network update, etc.)
 
 These models have a single field ``name`` (i.e. they are simply there to
 distinguish campaigns but don't have any specific behaviour).
 
 Once a customer visits your website with these parameters set in the url
-(i.e. http://www.odoo.com/?campaign_id=mixin_talk&source_id=www.odoo.com&medium_id=website),
+(i.e. https://www.odoo.com/?campaign_id=mixin_talk&source_id=www.odoo.com&medium_id=website),
 three cookies are set in the visitor's website for these parameters.
 Once a object that inherits the utm.mixin is created from the website (i.e. lead
 form, job application, etc.), the utm.mixin code kicks in and fetches the values
@@ -834,7 +834,7 @@ model should support the *quick create* (i.e. call to ``create()`` with a single
         _description = 'My Tracked Object'
 
         my_field = fields.Many2one('my_module.my_track', 'My Field')
-        
+
         @api.model
         def tracking_fields(self):
             result = super(MyModel, self).tracking_fields()
@@ -884,7 +884,7 @@ This mixin adds 2 fields on your model:
   the status of the publication
 * ``website_url``: :class:`~odoo.fields.Char` field which represents
   the URL through which the object is accessed
-  
+
 Note that this last field is a computed field and must be implemented for your class:
 
 .. code-block:: python
@@ -918,13 +918,13 @@ buttons to website visitors:
         </t>
     </div>
 
-Note that you must pass your object as the variable ``object`` to the template; 
+Note that you must pass your object as the variable ``object`` to the template;
 in this example, the ``blog.post`` record was passed as the ``blog_post`` variable
 to the ``qweb`` rendering engine, it is necessary to specify this to the publish
 management template. The ``publish_edit`` variable allow the frontend
 button to link to the backend (allowing you to switch from frontend to backend
 and vice-versa easily); if set, you must specify the full external id of the action
-you want to call in the backend in the ``action`` variable (note that a Form View 
+you want to call in the backend in the ``action`` variable (note that a Form View
 must exist for the model).
 
 The action ``website_publish_button`` is defined in the mixin and adapts its
@@ -987,7 +987,7 @@ To add rating support, simply inherit the ``rating.mixin`` model:
     class MyModel(models.Models):
         _name = 'my_module.my_model'
         _inherit = ['rating.mixin', 'mail.thread']
-        
+
         user_id = fields.Many2one('res.users', 'Responsible')
         partner_id = fields.Many2one('res.partner', 'Customer')
 
@@ -995,18 +995,18 @@ The behaviour of the mixin adapts to your model:
 
 * The ``rating.rating`` record will be linked to the ``partner_id`` field of your
   model (if the field is present).
-  
+
   - this behaviour can be overridden with the function ``rating_get_partner_id()``
     if you use another field than ``partner_id``
-      
+
 * The ``rating.rating`` record will be linked to the partner of the ``user_id``
   field of your model (if the field is present) (i.e. the partner who is rated)
-  
+
   - this behaviour can be overridden with the function ``rating_get_rated_partner_id()``
     if you use another field than ``user_id`` (note that the function must return a
     ``res.partner``, for ``user_id`` the system automatically fetches the partner
     of the user)
-      
+
 * The chatter history will display the rating event (if your model inherits from
   ``mail.thread``)
 
@@ -1036,7 +1036,7 @@ links to the rating object. A very basic email template could look like this:
     </ul>
     ]]></field>
     </record>
-    
+
 Your customer will then receive an e-mail with links to a simple webpage allowing
 them to provide a feedback on their interaction with your users (including a free-text
 feedback message).
@@ -1074,4 +1074,3 @@ You can find concrete examples of integration in the following models:
 
 * ``project.task`` in the Project (*rating_project*) Application
 * ``helpdesk.ticket`` in the Helpdesk (*helpdesk* - Odoo Enterprise only) Application
-
diff --git a/doc/reference/module.rst b/doc/reference/module.rst
index 3ab1b8c9b38..437d2c411ee 100644
--- a/doc/reference/module.rst
+++ b/doc/reference/module.rst
@@ -106,7 +106,7 @@ Available manifest fields are:
     located in ``static/src/css`` inside the module.
 ``images`` (``list(str)``)
     Specify image files to be used by the module.
-``installable`` (``bool`` default: ``False``)
+``installable`` (``bool`` default: ``True``)
     Whether a user should be able to install the module from the Web UI or not.
 ``maintainer`` (``str``)
     Person or entity in charge of the maintenance of this module, by default
@@ -128,6 +128,6 @@ Available manifest fields are:
     These hooks should only be used when setup/cleanup required for this module
     is either extremely difficult or impossible through the api.
 
-.. _semantic versioning: http://semver.org
+.. _semantic versioning: https://semver.org
 .. _existing categories:
      https://github.com/odoo/odoo/blob/12.0/odoo/addons/base/data/ir_module_category_data.xml
diff --git a/doc/reference/qweb.rst b/doc/reference/qweb.rst
index 541788d508c..4bec9c900cf 100644
--- a/doc/reference/qweb.rst
+++ b/doc/reference/qweb.rst
@@ -42,7 +42,7 @@ will result in::
 
 .. _reference/qweb/output:
 
-data output
+Data output
 ===========
 
 QWeb has a primary output directive which automatically HTML-escape its
@@ -63,7 +63,7 @@ sanitized user-provided markup.
 
 .. _reference/qweb/conditionals:
 
-conditionals
+Conditionals
 ============
 
 QWeb has a conditional directive ``if``, which evaluates an expression given
@@ -107,7 +107,7 @@ available::
 
 .. _reference/qweb/loops:
 
-loops
+Loops
 =====
 
 QWeb has an iteration directive ``foreach`` which take an expression returning
@@ -335,7 +335,7 @@ Python
 Exclusive directives
 --------------------
 
-asset bundles
+Asset bundles
 '''''''''''''
 
 .. todo:: have fme write these up because I've no idea how they work
@@ -351,7 +351,7 @@ website's rich text edition.
 ``t-options`` can be used to customize fields, the most common option
 is ``widget``, other options are field- or widget-dependent.
 
-debugging
+Debugging
 ---------
 
 ``t-debug``
@@ -552,6 +552,8 @@ Helpers
     :js:func:`core.qweb.render <QWeb2.Engine.render>` can be used to
     easily render basic module templates
 
+.. _reference/qweb/api:
+
 API
 ---
 
@@ -638,13 +640,13 @@ API
                      use case. Odoo 9.0 still depends on Jinja_ and Mako_.
 
 .. _templating:
-    http://en.wikipedia.org/wiki/Template_processor
+    https://en.wikipedia.org/wiki/Template_processor
 
 .. _Jinja: http://jinja.pocoo.org
-.. _Mako: http://www.makotemplates.org
-.. _Genshi: http://genshi.edgewall.org
-.. _XML namespaces: http://en.wikipedia.org/wiki/XML_namespace
-.. _HTML: http://en.wikipedia.org/wiki/HTML
-.. _XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
+.. _Mako: https://www.makotemplates.org
+.. _Genshi: https://genshi.edgewall.org
+.. _XML namespaces: https://en.wikipedia.org/wiki/XML_namespace
+.. _HTML: https://en.wikipedia.org/wiki/HTML
+.. _XSS: https://en.wikipedia.org/wiki/Cross-site_scripting
 .. _JSON: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON
-.. _CSS selector: http://api.jquery.com/category/selectors/
+.. _CSS selector: https://api.jquery.com/category/selectors/
diff --git a/doc/reference/reports.rst b/doc/reference/reports.rst
index f12efdcab07..696eabc5809 100644
--- a/doc/reference/reports.rst
+++ b/doc/reference/reports.rst
@@ -129,13 +129,13 @@ you need to define two templates:
 * The main report template
 * The translatable document
 
-You can then call the translatable document from your main template with the attribute 
+You can then call the translatable document from your main template with the attribute
 ``t-lang`` set to a language code (for example ``fr`` or ``en_US``) or to a record field.
 You will also need to re-browse the related records with the proper context if you use
 fields that are translatable (like country names, sales conditions, etc.)
 
 .. warning::
-    
+
     If your report template does not use translatable record fields, re-browsing the record
     in another language is *not* necessary and will impact performances.
 
@@ -169,10 +169,10 @@ For example, let's look at the Sale Order report from the Sale module::
     </template>
 
 
-The main template calls the translatable template with ``doc.partner_id.lang`` as a 
-``t-lang`` parameter, so it will be rendered in the language of the partner. This way, 
-each Sale Order will be printed in the language of the corresponding customer. If you wish 
-to translate only the body of the document, but keep the header and footer in a default 
+The main template calls the translatable template with ``doc.partner_id.lang`` as a
+``t-lang`` parameter, so it will be rendered in the language of the partner. This way,
+each Sale Order will be printed in the language of the corresponding customer. If you wish
+to translate only the body of the document, but keep the header and footer in a default
 language, you could call the report's external layout this way::
 
     <t t-call="web.external_layout" t-lang="en_US">
@@ -180,7 +180,7 @@ language, you could call the report's external layout this way::
 .. tip::
 
     Please take note that this works only when calling external templates, you will not be
-    able to translate part of a document by setting a ``t-lang`` attribute on an xml node other 
+    able to translate part of a document by setting a ``t-lang`` attribute on an xml node other
     than ``t-call``. If you wish to translate part of a template, you can create an external
     template with this partial template and call it from the main one with the ``t-lang``
     attribute.
@@ -345,4 +345,4 @@ For example, you can access a Sale Order report in html mode by going to
 Or you can access the pdf version at
 \http://<server-address>/report/pdf/sale.report_saleorder/38
 
-.. _wkhtmltopdf: http://wkhtmltopdf.org
+.. _wkhtmltopdf: https://wkhtmltopdf.org
diff --git a/doc/reference/test-report.txt b/doc/reference/test-report.txt
deleted file mode 100644
index 795bc044074..00000000000
--- a/doc/reference/test-report.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-test_empty_find (odoo.addons.web.tests.test_dataset.TestDataSetController) ... ok
-test_ids_shortcut (odoo.addons.web.tests.test_dataset.TestDataSetController) ... ok
-test_regular_find (odoo.addons.web.tests.test_dataset.TestDataSetController) ... ok
-web.testing.stack: direct, value, success ... ok
-web.testing.stack: direct, deferred, success ... ok
-web.testing.stack: direct, value, error ... ok
-web.testing.stack: direct, deferred, failure ... ok
-web.testing.stack: successful setup ... ok
-web.testing.stack: successful teardown ... ok
-web.testing.stack: successful setup and teardown ... ok
-
-[snip ~150 lines]
-
-test_convert_complex_context (odoo.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_convert_complex_domain (odoo.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_convert_literal_context (odoo.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_convert_literal_domain (odoo.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_retrieve_nonliteral_context (odoo.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_retrieve_nonliteral_domain (odoo.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-
-----------------------------------------------------------------------
-Ran 181 tests in 15.706s
-
-OK
-
diff --git a/doc/reference/testing.rst b/doc/reference/testing.rst
index 4175c709719..54c46da3b96 100644
--- a/doc/reference/testing.rst
+++ b/doc/reference/testing.rst
@@ -43,12 +43,6 @@ and ``__init__.py`` contains::
     test modules which are not imported from ``tests/__init__.py`` will not be
     run
 
-.. versionchanged:: 8.0
-
-    previously, the test runner would only run modules added to two lists
-    ``fast_suite`` and ``checks`` in ``tests/__init__.py``. In 8.0 it will
-    run all imported modules
-
 The test runner will simply run any test case, as described in the official
 `unittest documentation`_, but Odoo provides a number of utilities and helpers
 related to testing Odoo content (modules, mainly):
@@ -108,10 +102,7 @@ Tests are automatically run when installing or updating modules if
 :option:`--test-enable <odoo-bin --test-enable>` was enabled when starting the
 Odoo server.
 
-As of Odoo 8, running tests outside of the install/update cycle is not
-supported.
-
-.. _unittest documentation: https://docs.python.org/2/library/unittest.html
+.. _unittest documentation: https://docs.python.org/3/library/unittest.html
 
 Test selection
 --------------
@@ -528,7 +519,7 @@ Two new command line arguments were added since Odoo 13.0 to control this behavi
 :option:`--screenshots <odoo-bin --screenshots>` and :option:`--screencasts <odoo-bin --screencasts>`
 
 
-.. _qunit: http://qunitjs.com/
+.. _qunit: https://qunitjs.com/
 .. _qunit_config.js: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/static/tests/helpers/qunit_config.js#L49
 .. _web.js_tests_assets: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/views/webclient_templates.xml#L427
 .. _web.qunit_suite: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/views/webclient_templates.xml#L509
@@ -537,4 +528,4 @@ Two new command line arguments were added since Odoo 13.0 to control this behavi
 .. _test_utils.js: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/static/tests/helpers/test_utils.js
 .. _mock server: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/static/tests/helpers/mock_server.js
 .. _qunit assertions: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/static/tests/helpers/qunit_asserts.js
-.. _createView: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/static/tests/helpers/test_utils_create.js#L267
\ No newline at end of file
+.. _createView: https://github.com/odoo/odoo/blob/51ee0c3cb59810449a60dae0b086b49b1ed6f946/addons/web/static/tests/helpers/test_utils_create.js#L267
diff --git a/doc/reference/translations.rst b/doc/reference/translations.rst
index 23641f3b895..c7997e1e966 100644
--- a/doc/reference/translations.rst
+++ b/doc/reference/translations.rst
@@ -7,6 +7,11 @@
 Translating Modules
 ===================
 
+This section explains how to provide translation abilities to your module.
+
+.. note:: If you want to contribute to the translation of Odoo itself, please refer to the
+  `Odoo Wiki page <https://github.com/odoo/odoo/wiki/Translations>`_.
+
 Exporting translatable term
 ===========================
 
@@ -203,6 +208,6 @@ or **do** evaluate dynamically the translatable content::
     };
 
 
-.. _PO File: http://en.wikipedia.org/wiki/Gettext#Translating
-.. _msginit: http://www.gnu.org/software/gettext/manual/gettext.html#Creating
-.. _POEdit: http://poedit.net/
+.. _PO File: https://en.wikipedia.org/wiki/Gettext#Translating
+.. _msginit: https://www.gnu.org/software/gettext/manual/gettext.html#Creating
+.. _POEdit: https://poedit.net/