[FIX] doc: building correctly autoclass references

16 files changed, 276 insertions, 276 deletions

diff --git a/doc/reference/actions.rst b/doc/reference/actions.rst
index 7a796c59322..221c01ecfe6 100644
--- a/doc/reference/actions.rst
+++ b/doc/reference/actions.rst
@@ -52,7 +52,7 @@ Its fields are:
     an optional database id (or ``False``). If no id is provided, the client
     should fetch the default view of the specified type for the requested
     model (this is automatically done by
-    :meth:`~openerp.models.Model.fields_view_get`). The first type of the
+    :meth:`~odoo.models.Model.fields_view_get`). The first type of the
     list is the default view type and will be open by default when the action
     is executed. Each view type should be present at most once in the list
 ``res_id`` (optional)
@@ -248,8 +248,8 @@ from the UI, but not from :ref:`data files <reference/data>`.
 ``object_create``
 -----------------
 
-Creates a new record, from scratch (via :meth:`~openerp.models.Model.create`)
-or by copying an existing record (via :meth:`~openerp.models.Model.copy`)
+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:
@@ -264,7 +264,7 @@ or by copying an existing record (via :meth:`~openerp.models.Model.copy`)
         copies an other record, obtained via ``ref_object``
 ``fields_lines``
     fields to override when creating or copying the record.
-    :class:`~openerp.fields.One2many` with the fields:
+    :class:`~odoo.fields.One2many` with the fields:
 
     ``col1``
         ``ir.model.fields`` to set in the model implied by ``use_create``
@@ -278,7 +278,7 @@ or by copying an existing record (via :meth:`~openerp.models.Model.copy`)
     model in which to create a new record, if ``use_create`` is set to
     ``new_other``
 ``ref_object``
-    :class:`~openerp.fields.Reference` to an arbitrary record to copy, used if
+    :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
@@ -330,7 +330,7 @@ one will be returned to the client as the multi's own next action
 Sends a signal to a workflow.
 
 ``wkf_transition_id``
-    :class:`~openerp.fields.Many2one` to a ``workflow.transition`` to trigger
+    :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
@@ -388,10 +388,10 @@ Triggers the printing of a report
 ``report_name``
     the name of your report (which will be the name of the PDF output)
 ``groups_id``
-    :class:`~openerp.fields.Many2many` field to the groups allowed to view/use
+    :class:`~odoo.fields.Many2many` field to the groups allowed to view/use
     the current report
 ``paperformat_id``
-    :class:`~openerp.fields.Many2one` field to the paper format you wish to
+    :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)
 ``attachment_use``
     if set to ``True``, the report is only generated once the first time it is
diff --git a/doc/reference/cmdline.rst b/doc/reference/cmdline.rst
index a14956f2bea..cbee882bec4 100644
--- a/doc/reference/cmdline.rst
+++ b/doc/reference/cmdline.rst
@@ -228,7 +228,7 @@ customize the amount of logging output
 .. option:: --log-handler <handler-spec>
 
     :samp:`{LOGGER}:{LEVEL}`, enables ``LOGGER`` at the provided ``LEVEL``
-    e.g. ``openerp.models:DEBUG`` will enable all logging messages at or above
+    e.g. ``odoo.models:DEBUG`` will enable all logging messages at or above
     ``DEBUG`` level in the models.
 
     * The colon ``:`` is mandatory
@@ -239,34 +239,34 @@ customize the amount of logging output
 
     .. code-block:: console
 
-        $ odoo.py --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler openerp.fields:WARNING
+        $ odoo.py --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler odoo.fields:WARNING
 
 .. option:: --log-request
 
     enable DEBUG logging for RPC requests, equivalent to
-    ``--log-handler=openerp.http.rpc.request:DEBUG``
+    ``--log-handler=odoo.http.rpc.request:DEBUG``
 
 .. option:: --log-response
 
     enable DEBUG logging for RPC responses, equivalent to
-    ``--log-handler=openerp.http.rpc.response:DEBUG``
+    ``--log-handler=odoo.http.rpc.response:DEBUG``
 
 .. option:: --log-web
 
     enables DEBUG logging of HTTP requests and responses, equivalent to
-    ``--log-handler=openerp.http:DEBUG``
+    ``--log-handler=odoo.http:DEBUG``
 
 .. option:: --log-sql
 
     enables DEBUG logging of SQL querying, equivalent to
-    ``--log-handler=openerp.sql_db:DEBUG``
+    ``--log-handler=odoo.sql_db:DEBUG``
 
 .. option:: --log-level <level>
 
     Shortcut to more easily set predefined levels on specific loggers. "real"
     levels (``critical``, ``error``, ``warn``, ``debug``) are set on the
-    ``openerp`` and ``werkzeug`` loggers (except for ``debug`` which is only
-    set on ``openerp``).
+    ``odoo`` and ``werkzeug`` loggers (except for ``debug`` which is only
+    set on ``odoo``).
 
     Odoo also provides debugging pseudo-levels which apply to different sets
     of loggers:
@@ -276,11 +276,11 @@ customize the amount of logging output
 
         equivalent to ``--log-sql``
     ``debug_rpc``
-        sets the ``openerp`` and HTTP request loggers to ``debug``
+        sets the ``odoo`` and HTTP request loggers to ``debug``
 
         equivalent to ``--log-level debug --log-request``
     ``debug_rpc_answer``
-        sets the ``openerp`` and HTTP request and response loggers to
+        sets the ``odoo`` and HTTP request and response loggers to
         ``debug``
 
         equivalent to ``--log-level debug --log-request --log-response``
diff --git a/doc/reference/data.rst b/doc/reference/data.rst
index cb17b7e866a..0b2338b6633 100644
--- a/doc/reference/data.rst
+++ b/doc/reference/data.rst
@@ -77,13 +77,13 @@ Nothing
 
     Will evaluate the domain, search the field's model using it and set the
     search's result as the field's value. Will only use the first result if
-    the field is a :class:`~openerp.fields.Many2one`
+    the field is a :class:`~odoo.fields.Many2one`
 ``ref``
     if a ``ref`` attribute is provided, its value must be a valid
     :term:`external id`, which will be looked up and set as the field's value.
 
-    Mostly for :class:`~openerp.fields.Many2one` and
-    :class:`~openerp.fields.Reference` fields
+    Mostly for :class:`~odoo.fields.Many2one` and
+    :class:`~odoo.fields.Reference` fields
 ``type``
     if a ``type`` attribute is provided, it is used to interpret and convert
     the field's content. The field's content can be provided through an
@@ -253,14 +253,14 @@ For this case, data files can also use csv_, this is often the case for
 Here's the first lines of the data file defining US states
 ``res.country.state.csv``
 
-.. literalinclude:: ../../openerp/addons/base/res/res.country.state.csv
+.. literalinclude:: ../../odoo/addons/base/res/res.country.state.csv
     :language: text
     :lines: 1-15
 
 rendered in a more readable format:
 
 .. csv-table::
-    :file: ../../openerp/addons/base/res/res.country.state.csv
+    :file: ../../odoo/addons/base/res/res.country.state.csv
     :header-rows: 1
     :class: table-striped table-hover table-condensed
 
diff --git a/doc/reference/guidelines.rst b/doc/reference/guidelines.rst
index 8a1831c469d..aa691311cd2 100644
--- a/doc/reference/guidelines.rst
+++ b/doc/reference/guidelines.rst
@@ -902,7 +902,7 @@ Javascript and CSS
 
 .. code-block:: javascript
 
-    openerp.website.if_dom_contains('.jquery_class_selector', function () {
+    odoo.website.if_dom_contains('.jquery_class_selector', function () {
         /*your code here*/
     });
 
diff --git a/doc/reference/http.rst b/doc/reference/http.rst
index e6946beda49..9dbb61f7727 100644
--- a/doc/reference/http.rst
+++ b/doc/reference/http.rst
@@ -9,28 +9,28 @@ Web Controllers
 Routing
 =======
 
-.. autofunction:: openerp.http.route
+.. autofunction:: odoo.http.route
 
 .. _reference/http/request:
 
 Request
 =======
 
-The request object is automatically set on :data:`openerp.http.request` at
+The request object is automatically set on :data:`odoo.http.request` at
 the start of the request
 
-.. autoclass:: openerp.http.WebRequest
+.. autoclass:: odoo.http.WebRequest
     :members:
     :member-order: bysource
-.. autoclass:: openerp.http.HttpRequest
+.. autoclass:: odoo.http.HttpRequest
     :members:
-.. autoclass:: openerp.http.JsonRequest
+.. autoclass:: odoo.http.JsonRequest
     :members:
 
 Response
 ========
 
-.. autoclass:: openerp.http.Response
+.. autoclass:: odoo.http.Response
     :members:
     :member-order: bysource
 
@@ -44,7 +44,7 @@ Controllers
 ===========
 
 Controllers need to provide extensibility, much like
-:class:`~openerp.models.Model`, but can't use the same mechanism as the
+:class:`~odoo.models.Model`, but can't use the same mechanism as the
 pre-requisites (a database with loaded modules) may not be available yet (e.g.
 no database created, or no database selected).
 
@@ -53,11 +53,11 @@ models:
 
 Controllers are created by :ref:`inheriting <python:tut-inheritance>` from
 
-.. autoclass:: openerp.http.Controller
+.. autoclass:: odoo.http.Controller
 
-and defining methods decorated with :func:`~openerp.http.route`::
+and defining methods decorated with :func:`~odoo.http.route`::
 
-    class MyController(openerp.http.Controller):
+    class MyController(odoo.http.Controller):
         @route('/some_url', auth='public')
         def handler(self):
             return stuff()
@@ -71,7 +71,7 @@ class and override relevant methods, re-exposing them if necessary::
             do_before()
             return super(Extension, self).handler()
 
-* decorating with :func:`~openerp.http.route` is necessary to keep the method
+* decorating with :func:`~odoo.http.route` is necessary to keep the method
   (and route) visible: if the method is redefined without decorating, it
   will be "unpublished"
 * the decorators of all methods are combined, if the overriding method's
diff --git a/doc/reference/javascript.rst b/doc/reference/javascript.rst
index 342d8484b67..2a1e2b3a018 100644
--- a/doc/reference/javascript.rst
+++ b/doc/reference/javascript.rst
@@ -457,8 +457,8 @@ with three differences:
 
 :func:`~Model.query` is a shortcut for a builder-style
 interface to searches (``search`` + ``read`` in Odoo RPC terms). It
-returns a :class:`~openerp.web.Query` object which is immutable but
-allows building new :class:`~openerp.web.Query` instances from the
+returns a :class:`~odoo.web.Query` object which is immutable but
+allows building new :class:`~odoo.web.Query` instances from the
 first one, adding new properties or modifiying the parent object's::
 
     Users.query(['name', 'login', 'user_email', 'signature'])
@@ -469,8 +469,8 @@ first one, adding new properties or modifiying the parent object's::
     });
 
 The query is only actually performed when calling one of the query
-serialization methods, :func:`~openerp.web.Query.all` and
-:func:`~openerp.web.Query.first`. These methods will perform a new
+serialization methods, :func:`~odoo.web.Query.all` and
+:func:`~odoo.web.Query.first`. These methods will perform a new
 RPC call every time they are called.
 
 For that reason, it's actually possible to keep "intermediate" queries
@@ -499,38 +499,38 @@ around and use them differently/add new specifications on them.
 
          :param Array<String> fields: list of fields to fetch during
                                       the search
-         :returns: a :class:`~openerp.web.Query` object
+         :returns: a :class:`~odoo.web.Query` object
                    representing the search to perform
 
-.. class:: openerp.web.Query(fields)
+.. class:: odoo.web.Query(fields)
 
     The first set of methods is the "fetching" methods. They perform
     RPC queries using the internal data of the object they're called
     on.
 
-    .. function:: openerp.web.Query.all()
+    .. function:: odoo.web.Query.all()
 
-        Fetches the result of the current :class:`~openerp.web.Query` object's
+        Fetches the result of the current :class:`~odoo.web.Query` object's
         search.
 
         :rtype: Deferred<Array<>>
 
-    .. function:: openerp.web.Query.first()
+    .. function:: odoo.web.Query.first()
 
        Fetches the **first** result of the current
-       :class:`~openerp.web.Query`, or ``null`` if the current
-       :class:`~openerp.web.Query` does have any result.
+       :class:`~odoo.web.Query`, or ``null`` if the current
+       :class:`~odoo.web.Query` does have any result.
 
        :rtype: Deferred<Object | null>
 
-    .. function:: openerp.web.Query.count()
+    .. function:: odoo.web.Query.count()
 
        Fetches the number of records the current
-       :class:`~openerp.web.Query` would retrieve.
+       :class:`~odoo.web.Query` would retrieve.
 
        :rtype: Deferred<Number>
 
-    .. function:: openerp.web.Query.group_by(grouping...)
+    .. function:: odoo.web.Query.group_by(grouping...)
 
        Fetches the groups for the query, using the first specified
        grouping parameter
@@ -539,18 +539,18 @@ around and use them differently/add new specifications on them.
                                       asked of the server. Grouping
                                       can actually be an array or
                                       varargs.
-       :rtype: Deferred<Array<openerp.web.QueryGroup>> | null
+       :rtype: Deferred<Array<odoo.web.QueryGroup>> | null
 
     The second set of methods is the "mutator" methods, they create a
-    **new** :class:`~openerp.web.Query` object with the relevant
+    **new** :class:`~odoo.web.Query` object with the relevant
     (internal) attribute either augmented or replaced.
 
-    .. function:: openerp.web.Query.context(ctx)
+    .. function:: odoo.web.Query.context(ctx)
 
        Adds the provided ``ctx`` to the query, on top of any existing
        context
 
-    .. function:: openerp.web.Query.filter(domain)
+    .. function:: odoo.web.Query.filter(domain)
 
        Adds the provided domain to the query, this domain is
        ``AND``-ed to the existing query domain.
@@ -560,12 +560,12 @@ around and use them differently/add new specifications on them.
        Sets the provided offset on the query. The new offset
        *replaces* the old one.
 
-    .. function:: openerp.web.Query.limit(limit)
+    .. function:: odoo.web.Query.limit(limit)
 
        Sets the provided limit on the query. The new limit *replaces*
        the old one.
 
-    .. function:: openerp.web.Query.order_by(fields…)
+    .. function:: odoo.web.Query.order_by(fields…)
 
        Overrides the model's natural order with the provided field
        specifications. Behaves much like Django's :py:meth:`QuerySet.order_by
@@ -589,11 +589,11 @@ Aggregation (grouping)
 Odoo has powerful grouping capacities, but they are kind-of strange
 in that they're recursive, and level n+1 relies on data provided
 directly by the grouping at level n. As a result, while
-:py:meth:`openerp.models.Model.read_group` works it's not a very intuitive
+:py:meth:`odoo.models.Model.read_group` works it's not a very intuitive
 API.
 
-Odoo Web eschews direct calls to :py:meth:`~openerp.models.Model.read_group`
-in favor of calling a method of :class:`~openerp.web.Query`, :py:meth:`much
+Odoo Web eschews direct calls to :py:meth:`~odoo.models.Model.read_group`
+in favor of calling a method of :class:`~odoo.web.Query`, :py:meth:`much
 in the way it is one in SQLAlchemy <sqlalchemy.orm.query.Query.group_by>`
 [#terminal]_::
 
@@ -634,12 +634,12 @@ regular query for records):
           }
       });
 
-The result of a (successful) :func:`~openerp.web.Query.group_by` is
-an array of :class:`~openerp.web.QueryGroup`:
+The result of a (successful) :func:`~odoo.web.Query.group_by` is
+an array of :class:`~odoo.web.QueryGroup`:
 
-.. class:: openerp.web.QueryGroup
+.. class:: odoo.web.QueryGroup
 
-    .. function:: openerp.web.QueryGroup.get(key)
+    .. function:: odoo.web.QueryGroup.get(key)
 
         returns the group's attribute ``key``. Known attributes are:
 
@@ -652,16 +652,16 @@ an array of :class:`~openerp.web.QueryGroup`:
         ``aggregates``
             a {field: value} mapping of aggregations for the group
 
-    .. function:: openerp.web.QueryGroup.query([fields...])
+    .. function:: odoo.web.QueryGroup.query([fields...])
 
         equivalent to :func:`Model.query` but pre-filtered to
         only include the records within this group. Returns a
-        :class:`~openerp.web.Query` which can be further manipulated as
+        :class:`~odoo.web.Query` which can be further manipulated as
         usual.
 
-    .. function:: openerp.web.QueryGroup.subgroups()
+    .. function:: odoo.web.QueryGroup.subgroups()
 
-        returns a deferred to an array of :class:`~openerp.web.QueryGroup`
+        returns a deferred to an array of :class:`~odoo.web.QueryGroup`
         below this one
 
 Low-level API: RPC calls to Python side
@@ -720,7 +720,7 @@ It has also some disadvantages:
   that one needs to be careful.
 
 This is obviously a very large change and will require everyone to
-adopt new habits.  For example, the variable openerp does not exist
+adopt new habits.  For example, the variable odoo does not exist
 anymore.  The new way of doing things is to import explicitely the module 
 you need, and declaring explicitely the objects you export.  Here is a
 simple example::
@@ -790,7 +790,7 @@ Here is a description of the current file structure:
   * ``web.Widget`` contains the widget class
   * ``web.Model`` is an abstraction over ``web.ajax`` to make
     calls to the server model methods
-  * ``web.session`` is the former ``openerp.session``
+  * ``web.session`` is the former ``odoo.session``
   * ``web.utils`` for useful code snippets
   * ``web.time`` for every time-related generic functions
 * the ``views/`` folder contains all view definitions
@@ -807,8 +807,8 @@ The ``js/`` folder also contains some important files:
 The two other files are ``tour.js`` for the tours and ``compatibility.js``.
 The latter file is a compatibility layer bridging the old system to the
 new module system.  This is where every module names are exported to the
-global variable ``openerp``.  In theory, our addons should work without
-ever using the variable ``openerp``, and the compatibility module can be
+global variable ``odoo``.  In theory, our addons should work without
+ever using the variable ``odoo``, and the compatibility module can be
 disabled safely.
 
 Javascript conventions
@@ -888,19 +888,19 @@ and allow running all of its (0 so far) tests:
 
 The next step is to create a test case::
 
-    openerp.testing.section('basic section', function (test) {
+    odoo.testing.section('basic section', function (test) {
         test('my first test', function () {
             ok(false, "this test has run");
         });
     });
 
-All testing helpers and structures live in the ``openerp.testing``
-module. Odoo tests live in a :func:`~openerp.testing.section`,
+All testing helpers and structures live in the ``odoo.testing``
+module. Odoo tests live in a :func:`~odoo.testing.section`,
 which is itself part of a module. The first argument to a section is
 the name of the section, the second one is the section body.
 
-:func:`test <openerp.testing.case>`, provided by the
-:func:`~openerp.testing.section` to the callback, is used to
+:func:`test <odoo.testing.case>`, provided by the
+:func:`~odoo.testing.section` to the callback, is used to
 register a given test case which will be run whenever the test runner
 actually does its job. Odoo Web test case use standard `QUnit
 assertions`_ within them.
@@ -995,7 +995,7 @@ test module:
 ::
 
     // src/js/demo.js
-    openerp.web_tests_demo = function (instance) {
+    odoo.web_tests_demo = function (instance) {
         instance.web_tests_demo = {
             value_true: true,
             SomeType: instance.web.Class.extend({
@@ -1022,7 +1022,7 @@ DOM Scratchpad
 
 As in the wider client, arbitrarily accessing document content is
 strongly discouraged during tests. But DOM access is still needed to
-e.g. fully initialize :class:`widgets <~openerp.Widget>` before
+e.g. fully initialize :class:`widgets <~odoo.Widget>` before
 testing them.
 
 Thus, a test case gets a DOM scratchpad as its second positional
@@ -1054,7 +1054,7 @@ To avoid the corresponding processing costs, by default templates are
 not loaded into QWeb. If you need to render e.g. widgets making use of
 QWeb templates, you can request their loading through the
 :attr:`~TestOptions.templates` option to the :func:`test case
-function <openerp.testing.case>`.
+function <odoo.testing.case>`.
 
 This will automatically load all relevant templates in the instance's
 qweb before running the test case:
@@ -1161,7 +1161,7 @@ To enable mock RPC, set the :attr:`rpc option <TestOptions.rpc>` to
     * If it matches the pattern ``model:method`` (if it contains a
       colon, essentially) the call will set up the mocking of an RPC
       call straight to the Odoo server (through XMLRPC) as
-      performed via e.g. :func:`openerp.web.Model.call`.
+      performed via e.g. :func:`odoo.web.Model.call`.
 
       In that case, ``handler`` should be a function taking two
       arguments ``args`` and ``kwargs``, matching the corresponding
@@ -1209,7 +1209,7 @@ To enable mock RPC, set the :attr:`rpc option <TestOptions.rpc>` to
               });
 
               // widget needs that or it blows up
-              instance.webclient = {toggle_bars: openerp.testing.noop};
+              instance.webclient = {toggle_bars: odoo.testing.noop};
               var dbm = new instance.web.DatabaseManager({});
               return dbm.appendTo($s).then(function () {
                   ok(fetched_dbs, "should have fetched databases");
@@ -1228,7 +1228,7 @@ To enable mock RPC, set the :attr:`rpc option <TestOptions.rpc>` to
 Testing API
 -----------
 
-.. function:: openerp.testing.section(name[, options], body)
+.. function:: odoo.testing.section(name[, options], body)
 
     A test section, serves as shared namespace for related tests (for
     constants or values to only set up once). The ``body`` function
@@ -1240,9 +1240,9 @@ Testing API
     :param String name:
     :param TestOptions options:
     :param body:
-    :type body: Function<:func:`~openerp.testing.case`, void>
+    :type body: Function<:func:`~odoo.testing.case`, void>
 
-.. function:: openerp.testing.case(name[, options], callback)
+.. function:: odoo.testing.case(name[, options], callback)
 
     Registers a test case callback in the test runner, the callback
     will only be run once the runner is started (or maybe not at all,
@@ -1256,16 +1256,16 @@ Testing API
 .. class:: TestOptions
 
     the various options which can be passed to
-    :func:`~openerp.testing.section` or
-    :func:`~openerp.testing.case`. Except for
+    :func:`~odoo.testing.section` or
+    :func:`~odoo.testing.case`. Except for
     :attr:`~TestOptions.setup` and
     :attr:`~TestOptions.teardown`, an option on
-    :func:`~openerp.testing.case` will overwrite the corresponding
-    option on :func:`~openerp.testing.section` so
+    :func:`~odoo.testing.case` will overwrite the corresponding
+    option on :func:`~odoo.testing.section` so
     e.g. :attr:`~TestOptions.rpc` can be set for a
-    :func:`~openerp.testing.section` and then differently set for
-    some :func:`~openerp.testing.case` of that
-    :func:`~openerp.testing.section`
+    :func:`~odoo.testing.section` and then differently set for
+    some :func:`~odoo.testing.case` of that
+    :func:`~odoo.testing.section`
 
     .. attribute:: TestOptions.asserts
 
diff --git a/doc/reference/mixins.rst b/doc/reference/mixins.rst
index 4e001aae583..5d919226ac5 100644
--- a/doc/reference/mixins.rst
+++ b/doc/reference/mixins.rst
@@ -248,30 +248,30 @@ subtype of notifications they wish to receive.
 
 Subtypes are created as data in your module; the model has the following fields:
 
-``name`` (mandatory) - :class:`~openerp.fields.Char` 
+``name`` (mandatory) - :class:`~odoo.fields.Char` 
     name of the subtype, will be displayed in the notification customization
     popup
-``description`` - :class:`~openerp.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:`~openerp.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:`~openerp.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:`~openerp.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:`~openerp.fields.Char` 
+``res_model`` - :class:`~odoo.fields.Char` 
     model the subtype applies to; if False, this subtype applies to all models
-``default`` - :class:`~openerp.fields.Boolean` 
+``default`` - :class:`~odoo.fields.Boolean` 
     wether the subtype is activated by default when subscribing
-``sequence`` - :class:`~openerp.fields.Integer` 
+``sequence`` - :class:`~odoo.fields.Integer` 
     used to order subtypes in the notification customization popup
-``hidden`` - :class:`~openerp.fields.Boolean` 
+``hidden`` - :class:`~odoo.fields.Boolean` 
     wether the subtype is hidden in the notification customization popup
     
 
@@ -494,7 +494,7 @@ Overriding defaults
 There are several ways you can customize the behaviour of ``mail.thread`` models,
 including (but not limited to):
 
-``_mail_post_access`` - :class:`~openerp.models.Model`  attribute
+``_mail_post_access`` - :class:`~odoo.models.Model`  attribute
     the required access rights to be able to post a message on the model; by
     default a ``write`` access is needed, can be set to ``read`` as well
 
@@ -566,7 +566,7 @@ gets created (for example, every ``project.project`` record having its ``mail.al
 record initialized on creation).
 
 .. note:: Aliases can also be created manually and supported by a simple
-    :class:`~openerp.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.
 
@@ -602,22 +602,22 @@ 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:`~openerp.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:`~openerp.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:`~openerp.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:`~openerp.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:`~openerp.fields.Selection` 
+``alias_contact`` - :class:`~odoo.fields.Selection` 
     Policy to post a message on the document using the mailgateway
     
     - *everyone*: everyone can post
@@ -756,11 +756,11 @@ The ``utm.mixin`` class can be used to track online marketing/communication
 campaigns through arguments in links to specified resources. The mixin adds
 3 fields to your model:
 
-* ``campaign_id``: :class:`~openerp.fields.Many2one` field to a ``utm.campaign``
+* ``campaign_id``: :class:`~odoo.fields.Many2one` field to a ``utm.campaign``
   object (i.e. Christmas_Special, Fall_Collection, etc.)
-* ``source_id``: :class:`~openerp.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:`~openerp.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
@@ -840,9 +840,9 @@ To include the functionnality, you only need to inherit ``website.published.mixi
 
 This mixin adds 2 fields on your model:
 
-* ``website_published``: :class:`~openerp.fields.Boolean` field which represents
+* ``website_published``: :class:`~odoo.fields.Boolean` field which represents
   the status of the publication
-* ``website_url``: :class:`~openerp.fields.Char` field which represents
+* ``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:
@@ -911,11 +911,11 @@ pages.
 
 This mixin adds 3 fields on your model:
 
-* ``website_meta_title``: :class:`~openerp.fields.Char` field that allow you to set
+* ``website_meta_title``: :class:`~odoo.fields.Char` field that allow you to set
   an additional title to your page
-* ``website_meta_description``: :class:`~openerp.fields.Char` field that contains a
+* ``website_meta_description``: :class:`~odoo.fields.Char` field that contains a
   short description of the page (sometimes used in search engines results)
-* ``website_meta_keywords``: :class:`~openerp.fields.Char` field that contains some
+* ``website_meta_keywords``: :class:`~odoo.fields.Char` field that contains some
   keywords to help your page to be classified more precisely by search engines; the
   "Promote" tool will help you select lexically-related keywords easily
 
diff --git a/doc/reference/module.rst b/doc/reference/module.rst
index 010e10e2095..76200fbc9a1 100644
--- a/doc/reference/module.rst
+++ b/doc/reference/module.rst
@@ -87,4 +87,4 @@ Available manifest fields are:
 
 .. _semantic versioning: http://semver.org
 .. _existing categories:
-     https://github.com/odoo/odoo/blob/master/openerp/addons/base/module/module_data.xml
+     https://github.com/odoo/odoo/blob/master/odoo/addons/base/module/module_data.xml
diff --git a/doc/reference/orm.rst b/doc/reference/orm.rst
index 6a017d24e80..2be496d8abe 100644
--- a/doc/reference/orm.rst
+++ b/doc/reference/orm.rst
@@ -56,15 +56,15 @@ recordsets). Setting a field's value triggers an update to the database::
 
 Trying to read or write a field on multiple records will raise an error.
 
-Accessing a relational field (:class:`~openerp.fields.Many2one`,
-:class:`~openerp.fields.One2many`, :class:`~openerp.fields.Many2many`)
+Accessing a relational field (:class:`~odoo.fields.Many2one`,
+:class:`~odoo.fields.One2many`, :class:`~odoo.fields.Many2many`)
 *always* returns a recordset, empty if the field is not set.
 
 .. danger::
 
     each assignment to a field triggers a database update, when setting
     multiple fields at the same time or setting fields on multiple records
-    (to the same value), use :meth:`~openerp.models.Model.write`::
+    (to the same value), use :meth:`~odoo.models.Model.write`::
 
         # 3 * len(records) database updates
         for record in records:
@@ -153,7 +153,7 @@ call methods on their result, or to use set operations.
 Recordsets therefore provide these operations returning recordsets themselves
 (when possible):
 
-:meth:`~openerp.models.Model.filtered`
+:meth:`~odoo.models.Model.filtered`
     returns a recordset containing only records satisfying the provided
     predicate function. The predicate can also be a string to filter by a
     field being true or false::
@@ -164,14 +164,14 @@ Recordsets therefore provide these operations returning recordsets themselves
         # only keep records whose partner is a company
         records.filtered("partner_id.is_company")
 
-:meth:`~openerp.models.Model.sorted`
+:meth:`~odoo.models.Model.sorted`
     returns a recordset sorted by the provided key function. If no key
     is provided, use the model's default sort order::
 
         # sort records by name
         records.sorted(key=lambda r: r.name)
 
-:meth:`~openerp.models.Model.mapped`
+:meth:`~odoo.models.Model.mapped`
     applies the provided function to each record in the recordset, returns
     a recordset if the results are recordsets::
 
@@ -192,16 +192,16 @@ Recordsets therefore provide these operations returning recordsets themselves
 Environment
 ===========
 
-The :class:`~openerp.api.Environment` stores various contextual data used by
+The :class:`~odoo.api.Environment` stores various contextual data used by
 the ORM: the database cursor (for database queries), the current user
 (for access rights checking) and the current context (storing arbitrary
 metadata). The environment also stores caches.
 
 All recordsets have an environment, which is immutable, can be accessed
-using :attr:`~openerp.models.Model.env` and gives access to the current user
-(:attr:`~openerp.api.Environment.user`), the cursor
-(:attr:`~openerp.api.Environment.cr`) or the context
-(:attr:`~openerp.api.Environment.context`)::
+using :attr:`~odoo.models.Model.env` and gives access to the current user
+(:attr:`~odoo.api.Environment.user`), the cursor
+(:attr:`~odoo.api.Environment.cr`) or the context
+(:attr:`~odoo.api.Environment.context`)::
 
     >>> records.env
     <Environment object ...>
@@ -225,7 +225,7 @@ Altering the environment
 The environment can be customized from a recordset. This returns a new
 version of the recordset using the altered environment.
 
-:meth:`~openerp.models.Model.sudo`
+:meth:`~odoo.models.Model.sudo`
     creates a new environment with the provided user set, uses the
     administrator if none is provided (to bypass access rights/rules in safe
     contexts), returns a copy of the recordset it is called on using the
@@ -238,7 +238,7 @@ version of the recordset using the altered environment.
         public = env.ref('base.public_user')
         env['res.partner'].sudo(public).search([])
 
-:meth:`~openerp.models.Model.with_context`
+:meth:`~odoo.models.Model.with_context`
     #. can take a single positional parameter, which replaces the current
        environment's context
     #. can take any number of parameters by keyword, which are added to either
@@ -250,7 +250,7 @@ version of the recordset using the altered environment.
         # found
         env['res.partner'].with_context(tz=a_tz).find_or_create(email_address)
 
-:meth:`~openerp.models.Model.with_env`
+:meth:`~odoo.models.Model.with_env`
     replaces the existing environment entirely
 
 Common ORM methods
@@ -258,7 +258,7 @@ Common ORM methods
 
 .. maybe these clarifications/examples should be in the APIDoc?
 
-:meth:`~openerp.models.Model.search`
+:meth:`~odoo.models.Model.search`
    Takes a :ref:`search domain <reference/orm/domains>`, returns a recordset
    of matching records. Can return a subset of matching records (``offset``
    and ``limit`` parameters) and be ordered (``order`` parameter)::
@@ -271,21 +271,21 @@ Common ORM methods
 
    .. tip:: to just check if any record matches a domain, or count the number
              of records which do, use
-             :meth:`~openerp.models.Model.search_count`
-:meth:`~openerp.models.Model.create`
+             :meth:`~odoo.models.Model.search_count`
+:meth:`~odoo.models.Model.create`
     Takes a number of field values, and returns a recordset containing the
     record created::
 
         >>> self.create({'name': "New Name"})
         res.partner(78)
 
-:meth:`~openerp.models.Model.write`
+:meth:`~odoo.models.Model.write`
     Takes a number of field values, writes them to all the records in its
     recordset. Does not return anything::
 
         self.write({'name': "Newer Name"})
 
-:meth:`~openerp.models.Model.browse`
+:meth:`~odoo.models.Model.browse`
     Takes a database id or a list of ids and returns a recordset, useful when
     record ids are obtained from outside Odoo (e.g. round-trip through
     external system) or :ref:`when calling methods in the old API
@@ -294,7 +294,7 @@ Common ORM methods
         >>> self.browse([7, 18, 12])
         res.partner(7, 18, 12)
 
-:meth:`~openerp.models.Model.exists`
+:meth:`~odoo.models.Model.exists`
     Returns a new recordset containing only the records which exist in the
     database. Can be used to check whether a record (e.g. obtained externally)
     still exists::
@@ -308,14 +308,14 @@ Common ORM methods
         # only keep records which were not deleted
         records = records.exists()
 
-:meth:`~openerp.api.Environment.ref`
+:meth:`~odoo.api.Environment.ref`
     Environment method returning the record matching a provided
     :term:`external id`::
 
         >>> env.ref('base.group_public')
         res.groups(2)
 
-:meth:`~openerp.models.Model.ensure_one`
+:meth:`~odoo.models.Model.ensure_one`
     checks that the recordset is a singleton (only contains a single record),
     raises an error otherwise::
 
@@ -328,7 +328,7 @@ Creating Models
 
 Model fields are defined as attributes on the model itself::
 
-    from openerp import models, fields
+    from odoo import models, fields
     class AModel(models.Model):
         _name = 'a.model.name'
 
@@ -362,9 +362,9 @@ Computed fields
 Fields can be computed (instead of read straight from the database) using the
 ``compute`` parameter. **It must assign the computed value to the field**. If
 it uses the values of other *fields*, it should specify those fields using
-:func:`~openerp.api.depends`::
+:func:`~odoo.api.depends`::
 
-    from openerp import api
+    from odoo import api
     total = fields.Float(compute='_compute_total')
 
     @api.depends('value', 'tax')
@@ -443,7 +443,7 @@ added.
 
 * computed fields are automatically checked and recomputed, they do not need
   an ``onchange``
-* for non-computed fields, the :func:`~openerp.api.onchange` decorator is used
+* for non-computed fields, the :func:`~odoo.api.onchange` decorator is used
   to provide new field values::
 
     @api.onchange('field1', 'field2') # if these fields are changed, call method
@@ -474,22 +474,22 @@ added.
 Low-level SQL
 -------------
 
-The :attr:`~openerp.api.Environment.cr` attribute on environments is the
+The :attr:`~odoo.api.Environment.cr` attribute on environments is the
 cursor for the current database transaction and allows executing SQL directly,
 either for queries which are difficult to express using the ORM (e.g. complex
 joins) or for performance reasons::
 
     self.env.cr.execute("some_sql", param1, param2, param3)
 
-Because models use the same cursor and the :class:`~openerp.api.Environment`
+Because models use the same cursor and the :class:`~odoo.api.Environment`
 holds various caches, these caches must be invalidated when *altering* the
 database in raw SQL, or further uses of models may become incoherent. It is
 necessary to clear caches when using ``CREATE``, ``UPDATE`` or ``DELETE`` in
 SQL, but not ``SELECT`` (which simply reads the database).
 
 Clearing caches can be performed using the
-:meth:`~openerp.api.Environment.invalidate_all` method of the
-:class:`~openerp.api.Environment` object.
+:meth:`~odoo.api.Environment.invalidate_all` method of the
+:class:`~odoo.api.Environment` object.
 
 
 .. _reference/orm/oldapi:
@@ -507,9 +507,9 @@ necessary to manually bridge from one to the other manually:
 
 The big differences between the old and new APIs are:
 
-* values of the :class:`~openerp.api.Environment` (cursor, user id and
+* values of the :class:`~odoo.api.Environment` (cursor, user id and
   context) are passed explicitly to methods instead
-* record data (:attr:`~openerp.models.Model.ids`) are passed explicitly to
+* record data (:attr:`~odoo.models.Model.ids`) are passed explicitly to
   methods, and possibly not passed at all
 * methods tend to work on lists of ids instead of recordsets
 
@@ -538,7 +538,7 @@ from the old API style.
 
 Two decorators can expose a new-style method to the old API:
 
-:func:`~openerp.api.model`
+:func:`~odoo.api.model`
     the method is exposed as not using ids, its recordset will generally be
     empty. Its "old API" signature is ``cr, uid, *arguments, context``::
 
@@ -548,7 +548,7 @@ Two decorators can expose a new-style method to the old API:
         # can be called as
         old_style_model.some_method(cr, uid, a_value, context=context)
 
-:func:`~openerp.api.multi`
+:func:`~odoo.api.multi`
     the method is exposed as taking a list of ids (possibly empty), its
     "old API" signature is ``cr, uid, ids, *arguments, context``::
 
@@ -561,7 +561,7 @@ Two decorators can expose a new-style method to the old API:
 Because new-style APIs tend to return recordsets and old-style APIs tend to
 return lists of ids, there is also a decorator managing this:
 
-:func:`~openerp.api.returns`
+:func:`~odoo.api.returns`
     the function is assumed to return a recordset, the first parameter should
     be the name of the recordset's model or ``self`` (for the current model).
 
@@ -587,9 +587,9 @@ Model Reference
 .. - can't get autoattribute to import docstrings, so use regular attribute
    - no autoclassmethod
 
-.. currentmodule:: openerp.models
+.. currentmodule:: odoo.models
 
-.. autoclass:: openerp.models.Model
+.. autoclass:: odoo.models.Model
 
     .. rubric:: Structural attributes
 
@@ -628,7 +628,7 @@ Model Reference
     .. attribute:: _table
 
         Name of the table backing the model created when
-        :attr:`~openerp.models.Model._auto`, automatically generated by
+        :attr:`~odoo.models.Model._auto`, automatically generated by
         default.
 
     .. attribute:: _inherits
@@ -642,14 +642,14 @@ Model Reference
             }
 
         implements composition-based inheritance: the new model exposes all
-        the fields of the :attr:`~openerp.models.Model._inherits`-ed model but
+        the fields of the :attr:`~odoo.models.Model._inherits`-ed model but
         stores none of them: the values themselves remain stored on the linked
         record.
 
         .. warning::
 
             if the same field is defined on multiple
-            :attr:`~openerp.models.Model._inherits`-ed
+            :attr:`~odoo.models.Model._inherits`-ed
 
     .. attribute:: _constraints
 
@@ -658,7 +658,7 @@ Model Reference
 
         .. deprecated:: 8.0
 
-            use :func:`~openerp.api.constrains`
+            use :func:`~odoo.api.constrains`
 
     .. attribute:: _sql_constraints
 
@@ -723,7 +723,7 @@ Model Reference
 
     .. attribute:: id
 
-        Identifier :class:`field <openerp.fields.Field>`
+        Identifier :class:`field <odoo.fields.Field>`
 
     .. attribute:: _log_access
 
@@ -734,7 +734,7 @@ Model Reference
 
         Date at which the record was created
 
-        :type: :class:`~openerp.field.Datetime`
+        :type: :class:`~odoo.field.Datetime`
 
     .. attribute:: create_uid
 
@@ -746,7 +746,7 @@ Model Reference
 
         Date at which the record was last modified
 
-        :type: :class:`~openerp.field.Datetime`
+        :type: :class:`~odoo.field.Datetime`
 
     .. attribute:: write_uid
 
@@ -766,35 +766,35 @@ Model Reference
         display records in context where a representative "naming" is
         necessary.
 
-        :type: :class:`~openerp.fields.Char`
+        :type: :class:`~odoo.fields.Char`
 
     .. attribute:: active
 
         toggles the global visibility of the record, if ``active`` is set to
         ``False`` the record is invisible in most searches and listing
 
-        :type: :class:`~openerp.fields.Boolean`
+        :type: :class:`~odoo.fields.Boolean`
 
     .. attribute:: sequence
 
         Alterable ordering criteria, allows drag-and-drop reordering of models
         in list views
 
-        :type: :class:`~openerp.fields.Integer`
+        :type: :class:`~odoo.fields.Integer`
 
     .. attribute:: state
 
         lifecycle stages of the object, used by the ``states`` attribute on
-        :class:`fields <openerp.fields.Field>`
+        :class:`fields <odoo.fields.Field>`
 
-        :type: :class:`~openerp.fields.Selection`
+        :type: :class:`~odoo.fields.Selection`
 
     .. attribute:: parent_id
 
         used to order records in a tree structure and enables the ``child_of``
         operator in domains
 
-        :type: :class:`~openerp.fields.Many2one`
+        :type: :class:`~odoo.fields.Many2one`
 
     .. attribute:: parent_left
 
@@ -809,7 +809,7 @@ Model Reference
 Method decorators
 =================
 
-.. automodule:: openerp.api
+.. automodule:: odoo.api
     :members: multi, model, depends, constrains, onchange, returns,
               one, v7, v8
 
@@ -824,39 +824,39 @@ Basic fields
 ------------
 
 .. autodoc documents descriptors as attributes, even for the *definition* of
-   descriptors. As a result automodule:: openerp.fields lists all the field
+   descriptors. As a result automodule:: odoo.fields lists all the field
    classes as attributes without providing inheritance info or methods (though
    we don't document methods as they're not useful for "external" devs)
    (because we don't support pluggable field types) (or do we?)
 
-.. autoclass:: openerp.fields.Field
+.. autoclass:: odoo.fields.Field
 
-.. autoclass:: openerp.fields.Char
+.. autoclass:: odoo.fields.Char
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Boolean
+.. autoclass:: odoo.fields.Boolean
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Integer
+.. autoclass:: odoo.fields.Integer
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Float
+.. autoclass:: odoo.fields.Float
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Text
+.. autoclass:: odoo.fields.Text
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Selection
+.. autoclass:: odoo.fields.Selection
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Html
+.. autoclass:: odoo.fields.Html
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Date
+.. autoclass:: odoo.fields.Date
     :show-inheritance:
     :members: today, context_today, from_string, to_string
 
-.. autoclass:: openerp.fields.Datetime
+.. autoclass:: odoo.fields.Datetime
     :show-inheritance:
     :members: now, context_timestamp, from_string, to_string
 
@@ -865,16 +865,16 @@ Basic fields
 Relational fields
 -----------------
 
-.. autoclass:: openerp.fields.Many2one
+.. autoclass:: odoo.fields.Many2one
     :show-inheritance:
 
-.. autoclass:: openerp.fields.One2many
+.. autoclass:: odoo.fields.One2many
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Many2many
+.. autoclass:: odoo.fields.Many2many
     :show-inheritance:
 
-.. autoclass:: openerp.fields.Reference
+.. autoclass:: odoo.fields.Reference
     :show-inheritance:
 
 .. _reference/orm/inheritance:
@@ -896,25 +896,25 @@ Odoo provides three different mechanisms to extend models in a modular way:
 Classical inheritance
 ---------------------
 
-When using the :attr:`~openerp.models.Model._inherit` and
-:attr:`~openerp.models.Model._name` attributes together, Odoo creates a new
+When using the :attr:`~odoo.models.Model._inherit` and
+:attr:`~odoo.models.Model._name` attributes together, Odoo creates a new
 model using the existing one (provided via
-:attr:`~openerp.models.Model._inherit`) as a base. The new model gets all the
+:attr:`~odoo.models.Model._inherit`) as a base. The new model gets all the
 fields, methods and meta-information (defaults & al) from its base.
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/inheritance.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/inheritance.py
     :language: python
     :lines: 5-
 
 and using them:
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_inheritance.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_inheritance.py
     :language: python
     :lines: 8,12,9,19
 
 will yield:
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_inheritance.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_inheritance.py
     :language: text
     :lines: 15,22
 
@@ -925,23 +925,23 @@ the second model has inherited from the first model's ``check`` method and its
 Extension
 ---------
 
-When using :attr:`~openerp.models.Model._inherit` but leaving out
-:attr:`~openerp.models.Model._name`, the new model replaces the existing one,
+When using :attr:`~odoo.models.Model._inherit` but leaving out
+:attr:`~odoo.models.Model._name`, the new model replaces the existing one,
 essentially extending it in-place. This is useful to add new fields or methods
 to existing models (created in other modules), or to customize or reconfigure
 them (e.g. to change their default sort order):
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/extension.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/extension.py
     :language: python
     :lines: 5-
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_extension.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_extension.py
     :language: python
     :lines: 8,13
 
 will yield:
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_extension.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_extension.py
     :language: text
     :lines: 11
 
@@ -952,29 +952,29 @@ Delegation
 ----------
 
 The third inheritance mechanism provides more flexibility (it can be altered
-at runtime) but less power: using the :attr:`~openerp.models.Model._inherits`
+at runtime) but less power: using the :attr:`~odoo.models.Model._inherits`
 a model *delegates* the lookup of any field not found on the current model
 to "children" models. The delegation is performed via
-:class:`~openerp.fields.Reference` fields automatically set up on the parent
+:class:`~odoo.fields.Reference` fields automatically set up on the parent
 model:
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/delegation.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/delegation.py
     :language: python
     :lines: 5-
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_delegation.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_delegation.py
     :language: python
     :lines: 9-12,21,26
 
 will result in:
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_delegation.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_delegation.py
     :language: text
     :lines: 23,28
 
 and it's possible to write directly on the delegated field:
 
-.. literalinclude:: ../../openerp/addons/test_documentation_examples/tests/test_delegation.py
+.. literalinclude:: ../../odoo/addons/test_documentation_examples/tests/test_delegation.py
     :language: python
     :lines: 47
 
@@ -991,7 +991,7 @@ A domain is a list of criteria, each criterion being a triple (either a
 
 ``field_name`` (``str``)
     a field name of the current model, or a relationship traversal through
-    a :class:`~openerp.fields.Many2one` using dot-notation e.g. ``'street'``
+    a :class:`~odoo.fields.Many2one` using dot-notation e.g. ``'street'``
     or ``'partner_id.country'``
 ``operator`` (``str``)
     an operator used to compare the ``field_name`` with the ``value``. Valid
@@ -1037,7 +1037,7 @@ A domain is a list of criteria, each criterion being a triple (either a
 
         Takes the semantics of the model into account (i.e following the
         relationship field named by
-        :attr:`~openerp.models.Model._parent_name`).
+        :attr:`~odoo.models.Model._parent_name`).
 
 ``value``
     variable type, must be comparable (through ``operator``) to the named
@@ -1084,11 +1084,11 @@ Porting from the old API to the new API
 * methods still written in the old API should be automatically bridged by the
   ORM, no need to switch to the old API, just call them as if they were a new
   API method. See :ref:`reference/orm/oldapi/bridging` for more details.
-* :meth:`~openerp.models.Model.search` returns a recordset, no point in e.g.
+* :meth:`~odoo.models.Model.search` returns a recordset, no point in e.g.
   browsing its result
 * ``fields.related`` and ``fields.function`` are replaced by using a normal
   field type with either a ``related=`` or a ``compute=`` parameter
-* :func:`~openerp.api.depends` on ``compute=`` methods **must be complete**,
+* :func:`~odoo.api.depends` on ``compute=`` methods **must be complete**,
   it must list **all** the fields and sub-fields which the compute method
   uses. It is better to have too many dependencies (will recompute the field
   in cases where that is not needed) than not enough (will forget to recompute
@@ -1096,10 +1096,10 @@ Porting from the old API to the new API
 * **remove** all ``onchange`` methods on computed fields. Computed fields are
   automatically re-computed when one of their dependencies is changed, and
   that is used to auto-generate ``onchange`` by the client
-* the decorators :func:`~openerp.api.model` and :func:`~openerp.api.multi` are
+* the decorators :func:`~odoo.api.model` and :func:`~odoo.api.multi` are
   for bridging *when calling from the old API context*, for internal or pure
   new-api (e.g. compute) they are useless
-* remove :attr:`~openerp.models.Model._default`, replace by ``default=``
+* remove :attr:`~odoo.models.Model._default`, replace by ``default=``
   parameter on corresponding fields
 * if a field's ``string=`` is the titlecased version of the field name::
 
@@ -1114,49 +1114,49 @@ Porting from the old API to the new API
 * double check that all fields and methods have different names, there is no
   warning in case of collision (because Python handles it before Odoo sees
   anything)
-* the normal new-api import is ``from openerp import fields, models``. If
-  compatibility decorators are necessary, use ``from openerp import api,
+* the normal new-api import is ``from odoo import fields, models``. If
+  compatibility decorators are necessary, use ``from odoo import api,
   fields, models``
-* avoid the :func:`~openerp.api.one` decorator, it probably does not do what
+* avoid the :func:`~odoo.api.one` decorator, it probably does not do what
   you expect
-* remove explicit definition of :attr:`~openerp.models.Model.create_uid`,
-  :attr:`~openerp.models.Model.create_date`,
-  :attr:`~openerp.models.Model.write_uid` and
-  :attr:`~openerp.models.Model.write_date` fields: they are now created as
+* remove explicit definition of :attr:`~odoo.models.Model.create_uid`,
+  :attr:`~odoo.models.Model.create_date`,
+  :attr:`~odoo.models.Model.write_uid` and
+  :attr:`~odoo.models.Model.write_date` fields: they are now created as
   regular "legitimate" fields, and can be read and written like any other
   field out-of-the-box
 * when straight conversion is impossible (semantics can not be bridged) or the
   "old API" version is not desirable and could be improved for the new API, it
   is possible to use completely different "old API" and "new API"
-  implementations for the same method name using :func:`~openerp.api.v7` and
-  :func:`~openerp.api.v8`. The method should first be defined using the
-  old-API style and decorated with :func:`~openerp.api.v7`, it should then be
+  implementations for the same method name using :func:`~odoo.api.v7` and
+  :func:`~odoo.api.v8`. The method should first be defined using the
+  old-API style and decorated with :func:`~odoo.api.v7`, it should then be
   re-defined using the exact same name but the new-API style and decorated
-  with :func:`~openerp.api.v8`. Calls from an old-API context will be
+  with :func:`~odoo.api.v8`. Calls from an old-API context will be
   dispatched to the first implementation and calls from a new-API context will
   be dispatched to the second implementation. One implementation can call (and
   frequently does) call the other by switching context.
 
   .. danger:: using these decorators makes methods extremely difficult to
               override and harder to understand and document
-* uses of :attr:`~openerp.models.Model._columns` or
-  :attr:`~openerp.models.Model._all_columns` should be replaced by
-  :attr:`~openerp.models.Model._fields`, which provides access to instances of
-  new-style :class:`openerp.fields.Field` instances (rather than old-style
-  :class:`openerp.osv.fields._column`).
+* uses of :attr:`~odoo.models.Model._columns` or
+  :attr:`~odoo.models.Model._all_columns` should be replaced by
+  :attr:`~odoo.models.Model._fields`, which provides access to instances of
+  new-style :class:`odoo.fields.Field` instances (rather than old-style
+  :class:`odoo.osv.fields._column`).
 
   Non-stored computed fields created using the new API style are *not*
-  available in :attr:`~openerp.models.Model._columns` and can only be
-  inspected through :attr:`~openerp.models.Model._fields`
+  available in :attr:`~odoo.models.Model._columns` and can only be
+  inspected through :attr:`~odoo.models.Model._fields`
 * reassigning ``self`` in a method is probably unnecessary and may break
   translation introspection
-* :class:`~openerp.api.Environment` objects rely on some threadlocal state,
+* :class:`~odoo.api.Environment` objects rely on some threadlocal state,
   which has to be set up before using them. It is necessary to do so using the
-  :meth:`openerp.api.Environment.manage` context manager when trying to use
+  :meth:`odoo.api.Environment.manage` context manager when trying to use
   the new API in contexts where it hasn't been set up yet, such as new threads
   or a Python interactive environment::
 
-    >>> from openerp import api, modules
+    >>> from odoo import api, modules
     >>> r = modules.registry.RegistryManager.get('test')
     >>> cr = r.cursor()
     >>> env = api.Environment(cr, 1, {})
@@ -1186,30 +1186,30 @@ any parameter called ``context``.
 
 When calling such methods from a new API context, the system will
 automatically fill matched parameters from the current
-:class:`~openerp.api.Environment` (for :attr:`~openerp.api.Environment.cr`,
-:attr:`~openerp.api.Environment.user` and
-:attr:`~openerp.api.Environment.context`) or the current recordset (for ``id``
+:class:`~odoo.api.Environment` (for :attr:`~odoo.api.Environment.cr`,
+:attr:`~odoo.api.Environment.user` and
+:attr:`~odoo.api.Environment.context`) or the current recordset (for ``id``
 and ``ids``).
 
 In the rare cases where it is necessary, the bridging can be customized by
 decorating the old-style method:
 
 * disabling it entirely, by decorating a method with
-  :func:`~openerp.api.noguess` there will be no bridging and methods will be
+  :func:`~odoo.api.noguess` there will be no bridging and methods will be
   called the exact same way from the new and old API styles
 * defining the bridge explicitly, this is mostly for methods which are matched
   incorrectly (because parameters are named in unexpected ways):
 
-  :func:`~openerp.api.cr`
+  :func:`~odoo.api.cr`
      will automatically prepend the current cursor to explicitly provided
      parameters, positionally
-  :func:`~openerp.api.cr_uid`
+  :func:`~odoo.api.cr_uid`
      will automatically prepend the current cursor and user's id to explictly
      provided parameters
-  :func:`~openerp.api.cr_uid_ids`
+  :func:`~odoo.api.cr_uid_ids`
      will automatically prepend the current cursor, user's id and recordset's
      ids to explicitly provided parameters
-  :func:`~openerp.api.cr_uid_id`
+  :func:`~odoo.api.cr_uid_id`
      will loop over the current recordset and call the method once for each
      record, prepending the current cursor, user's id and record's id to
      explicitly provided parameters.
@@ -1218,7 +1218,7 @@ decorating the old-style method:
                  from a new-API context
 
   All of these methods have a ``_context``-suffixed version
-  (e.g. :func:`~openerp.api.cr_uid_context`) which also passes the current
+  (e.g. :func:`~odoo.api.cr_uid_context`) which also passes the current
   context *by keyword*.
-* dual implementations using :func:`~openerp.api.v7` and
-  :func:`~openerp.api.v8` will be ignored as they provide their own "bridging"
+* dual implementations using :func:`~odoo.api.v7` and
+  :func:`~odoo.api.v8` will be ignored as they provide their own "bridging"
diff --git a/doc/reference/qweb.rst b/doc/reference/qweb.rst
index e73de74b94d..f3e6a92e4b6 100644
--- a/doc/reference/qweb.rst
+++ b/doc/reference/qweb.rst
@@ -367,7 +367,7 @@ Request-based
 Most Python-side uses of QWeb are in controllers (and during HTTP requests),
 in which case templates stored in the database (as
 :ref:`views <reference/views/qweb>`) can be trivially rendered by calling
-:meth:`openerp.http.HttpRequest.render`:
+:meth:`odoo.http.HttpRequest.render`:
 
 .. code-block:: python
 
@@ -375,7 +375,7 @@ in which case templates stored in the database (as
         'context_value': 42
     })
 
-This automatically creates a :class:`~openerp.http.Response` object which can
+This automatically creates a :class:`~odoo.http.Response` object which can
 be returned from the controller (or further customized to suit).
 
 View-based
@@ -392,7 +392,7 @@ At a deeper level than the previous helper is the ``render`` method on
     Sets up a number of default values in the rendering context:
 
     ``request``
-        the current :class:`~openerp.http.WebRequest` object, if any
+        the current :class:`~odoo.http.WebRequest` object, if any
     ``debug``
         whether the current request (if any) is in ``debug`` mode
     :func:`quote_plus <werkzeug.urls.url_quote_plus>`
@@ -421,7 +421,7 @@ API
 It is also possible to use the ``ir.qweb`` model directly (and extend it, and
 inherit from it):
 
-.. automodule:: openerp.addons.base.ir.ir_qweb
+.. automodule:: odoo.addons.base.ir.ir_qweb
     :members: QWeb, QWebContext, FieldConverter, QwebWidget
 
 Javascript
diff --git a/doc/reference/reports.rst b/doc/reference/reports.rst
index 830bc3460fc..e324b132ae0 100644
--- a/doc/reference/reports.rst
+++ b/doc/reference/reports.rst
@@ -43,7 +43,7 @@ can take the following attributes:
 ``report_name``
     the name of your report (which will be the name of the PDF output)
 ``groups``
-    :class:`~openerp.fields.Many2many` field to the groups allowed to view/use
+    :class:`~odoo.fields.Many2many` field to the groups allowed to view/use
     the current report
 ``attachment_use``
     if set to True, the report will be stored as an attachment of the record
@@ -286,7 +286,7 @@ the function ``render_html`` and pass objects in the ``docargs`` dictionary:
 
 .. code-block:: python
 
-    from openerp import api, models
+    from odoo import api, models
 
     class ParticularReport(models.AbstractModel):
         _name = 'report.module.report_name'
diff --git a/doc/reference/security.rst b/doc/reference/security.rst
index 98999bf415b..fbc4cf1124a 100644
--- a/doc/reference/security.rst
+++ b/doc/reference/security.rst
@@ -80,7 +80,7 @@ Field Access
 
 .. versionadded:: 7.0
 
-An ORM :class:`~openerp.fields.Field` can have a ``groups`` attribute
+An ORM :class:`~odoo.fields.Field` can have a ``groups`` attribute
 providing a list of groups (as a comma-separated string of
 :term:`external identifiers`).
 
@@ -88,7 +88,7 @@ If the current user is not in one of the listed groups, he will not have
 access to the field:
 
 * restricted fields are automatically removed from requested views
-* restricted fields are removed from :meth:`~openerp.models.Model.fields_get`
+* restricted fields are removed from :meth:`~odoo.models.Model.fields_get`
   responses
 * attempts to (explicitly) read from or write to restricted fields results in
   an access error
diff --git a/doc/reference/test-report.txt b/doc/reference/test-report.txt
index ce52618fe20..795bc044074 100644
--- a/doc/reference/test-report.txt
+++ b/doc/reference/test-report.txt
@@ -1,6 +1,6 @@
-test_empty_find (openerp.addons.web.tests.test_dataset.TestDataSetController) ... ok
-test_ids_shortcut (openerp.addons.web.tests.test_dataset.TestDataSetController) ... ok
-test_regular_find (openerp.addons.web.tests.test_dataset.TestDataSetController) ... ok
+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
@@ -11,12 +11,12 @@ web.testing.stack: successful setup and teardown ... ok
 
 [snip ~150 lines]
 
-test_convert_complex_context (openerp.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_convert_complex_domain (openerp.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_convert_literal_context (openerp.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_convert_literal_domain (openerp.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_retrieve_nonliteral_context (openerp.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
-test_retrieve_nonliteral_domain (openerp.addons.web.tests.test_view.DomainsAndContextsTest) ... ok
+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
diff --git a/doc/reference/testing.rst b/doc/reference/testing.rst
index 53690426103..5d3a2d93f9b 100644
--- a/doc/reference/testing.rst
+++ b/doc/reference/testing.rst
@@ -42,22 +42,22 @@ 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):
 
-.. autoclass:: openerp.tests.common.TransactionCase
+.. autoclass:: odoo.tests.common.TransactionCase
     :members: browse_ref, ref
 
-.. autoclass:: openerp.tests.common.SingleTransactionCase
+.. autoclass:: odoo.tests.common.SingleTransactionCase
     :members: browse_ref, ref
 
 By default, tests are run once right after the corresponding module has been
 installed. Test cases can also be configured to run after all modules have
 been installed, and not run right after the module installation:
 
-.. autofunction:: openerp.tests.common.at_install
+.. autofunction:: odoo.tests.common.at_install
 
-.. autofunction:: openerp.tests.common.post_install
+.. autofunction:: odoo.tests.common.post_install
 
 The most common situation is to use
-:class:`~openerp.tests.common.TransactionCase` and test a property of a model
+:class:`~odoo.tests.common.TransactionCase` and test a property of a model
 in each method::
 
     class TestModelA(common.TransactionCase):
diff --git a/doc/reference/translations.rst b/doc/reference/translations.rst
index 9a2b6ae8b82..16c222ce25c 100644
--- a/doc/reference/translations.rst
+++ b/doc/reference/translations.rst
@@ -54,15 +54,15 @@ Odoo automatically exports translatable strings from "data"-type content:
   exported except inside ``t-translation="off"`` blocks, the content of the
   ``title``, ``alt``, ``label`` and ``placeholder`` attributes are also
   exported
-* for :class:`~openerp.fields.Field`, unless their model is marked with
+* for :class:`~odoo.fields.Field`, unless their model is marked with
   ``_translate = False``:
 
   * their ``string`` and ``help`` attributes are exported
   * if ``selection`` is present and a list (or tuple), it's exported
   * if their ``translate`` attribute is set to ``True``, all of their existing
     values (across all records) are exported
-* help/error messages of :attr:`~openerp.models.Model._constraints` and
-  :attr:`~openerp.models.Model._sql_constraints` are exported
+* help/error messages of :attr:`~odoo.models.Model._constraints` and
+  :attr:`~odoo.models.Model._sql_constraints` are exported
 
 Explicit exports
 ================
@@ -72,11 +72,11 @@ code, Odoo cannot automatically export translatable terms so they
 must be marked explicitly for export. This is done by wrapping a literal
 string in a function call.
 
-In Python, the wrapping function is :func:`openerp._`::
+In Python, the wrapping function is :func:`odoo._`::
 
     title = _("Bank Accounts")
 
-In JavaScript, the wrapping function is generally :js:func:`openerp.web._t`:
+In JavaScript, the wrapping function is generally :js:func:`odoo.web._t`:
 
 .. code-block:: javascript
 
diff --git a/doc/reference/views.rst b/doc/reference/views.rst
index a69c85d7e15..6fdccb0c8bb 100644
--- a/doc/reference/views.rst
+++ b/doc/reference/views.rst
@@ -31,7 +31,7 @@ otherwise.
 ``arch``
     the description of the view's layout
 ``groups_id``
-    :class:`~openerp.fields.Many2many` field to the groups allowed to view/use
+    :class:`~odoo.fields.Many2many` field to the groups allowed to view/use
     the current view
 ``inherit_id``
     the current view's parent view, see :ref:`reference/views/inheritance`,
@@ -363,8 +363,8 @@ system. Available semantic components are:
     the name of the field to render
   ``widget``
     fields have a default rendering based on their type
-    (e.g. :class:`~openerp.fields.Char`,
-    :class:`~openerp.fields.Many2one`). The ``widget`` attributes allows using
+    (e.g. :class:`~odoo.fields.Char`,
+    :class:`~odoo.fields.Many2one`). The ``widget`` attributes allows using
     a different rendering method and context.
 
     .. todo:: list of widgets
@@ -385,7 +385,7 @@ system. Available semantic components are:
       only displays the field in the corresponding form mode
     ``oe_no_button``
       avoids displaying the navigation button in a
-      :class:`~openerp.fields.Many2one`
+      :class:`~odoo.fields.Many2one`
     ``oe_avatar``
       for image fields, displays images as "avatar" (square, 90x90 maximum
       size, some image decorations)
@@ -397,7 +397,7 @@ system. Available semantic components are:
 
     .. deprecated:: 8.0
 
-       Use :func:`openerp.api.onchange` on the model
+       Use :func:`odoo.api.onchange` on the model
 
   ``attrs``
     dynamic meta-parameters based on record values
@@ -420,7 +420,7 @@ system. Available semantic components are:
     complex forms. *Should not* be an example of data as users are liable to
     confuse placeholder text with filled fields
   ``mode``
-    for :class:`~openerp.fields.One2many`, display mode (view type) to use for
+    for :class:`~odoo.fields.One2many`, display mode (view type) to use for
     the field's linked records. One of ``tree``, ``form``, ``kanban`` or
     ``graph``. The default is ``tree`` (a list display)
   ``help``
@@ -429,7 +429,7 @@ system. Available semantic components are:
     for binary fields, name of the related field providing the name of the
     file
   ``password``
-    indicates that a :class:`~openerp.fields.Char` field stores a password and
+    indicates that a :class:`~odoo.fields.Char` field stores a password and
     that its data shouldn't be displayed
 
 .. todo:: classes for forms
@@ -692,7 +692,7 @@ The form above contains a <sheet> element that starts with:
 Tags
 ....
 
-Most :class:`~openerp.fields.Many2many` fields, like categories, are better
+Most :class:`~odoo.fields.Many2many` fields, like categories, are better
 rendered as a list of tags. Use the widget ``many2many_tags`` for this:
 
 .. image:: forms/screenshot-04.png
@@ -864,7 +864,7 @@ Possible children of the view element are:
     an object with all the requested fields as its attributes. Each field has
     two attributes ``value`` and ``raw_value``, the former is formatted
     according to current user parameters, the latter is the direct value from
-    a :meth:`~openerp.models.Model.read` (except for date and datetime fields
+    a :meth:`~odoo.models.Model.read` (except for date and datetime fields
     that are `formatted according to user's locale
     <https://github.com/odoo/odoo/blob/a678bd4e/addons/web_kanban/static/src/js/kanban_record.js#L102>`_)
   ``formats``
@@ -1086,10 +1086,10 @@ Possible children of the diagram view are:
     ``object`` (required)
       the edge's Odoo model
     ``source`` (required)
-      :class:`~openerp.fields.Many2one` field of the edge's model pointing to
+      :class:`~odoo.fields.Many2one` field of the edge's model pointing to
       the edge's source node record
     ``destination`` (required)
-      :class:`~openerp.fields.Many2one` field of the edge's model pointing to
+      :class:`~odoo.fields.Many2one` field of the edge's model pointing to
       the edge's destination node record
     ``label``
       Python list of attributes (as quoted strings). The corresponding
@@ -1161,10 +1161,10 @@ Possible children elements of the search view are:
     ``widget``
         use specific search widget for the field (the only use case in
         standard Odoo 8.0 is a ``selection`` widget for
-        :class:`~openerp.fields.Many2one` fields)
+        :class:`~odoo.fields.Many2one` fields)
     ``domain``
         if the field can provide an auto-completion
-        (e.g. :class:`~openerp.fields.Many2one`), filters the possible
+        (e.g. :class:`~odoo.fields.Many2one`), filters the possible
         completion results.
 
 ``filter``