diff --git a/doc/api_integration.rst b/doc/api_integration.rst
index 172eb0f3fa4..a0f26d39343 100644
--- a/doc/api_integration.rst
+++ b/doc/api_integration.rst
@@ -15,7 +15,7 @@ easily available over XML-RPC_ and accessible from a variety of languages.
 
 .. Odoo XML-RPC idiosyncracies:
    * uses multiple endpoint and a nested call syntax instead of a
-     "hierarchical" server structure (e.g. ``openerp.res.partner.read()``)
+     "hierarchical" server structure (e.g. ``odoo.res.partner.read()``)
    * uses its own own manual auth system instead of basic auth or sessions
      (basic is directly supported the Python and Ruby stdlibs as well as
      ws-xmlrpc, not sure about ripcord)
@@ -360,9 +360,9 @@ Each call to ``execute_kw`` takes the following parameters:
 List records
 ------------
 
-Records can be listed and filtered via :meth:`~openerp.models.Model.search`.
+Records can be listed and filtered via :meth:`~odoo.models.Model.search`.
 
-:meth:`~openerp.models.Model.search` takes a mandatory
+:meth:`~odoo.models.Model.search` takes a mandatory
 :ref:`domain <reference/orm/domains>` filter (possibly empty), and returns the
 database identifiers of all records matching the filter. To list customer
 companies for instance:
@@ -456,10 +456,10 @@ Count records
 -------------
 
 Rather than retrieve a possibly gigantic list of records and count them,
-:meth:`~openerp.models.Model.search_count` can be used to retrieve
+:meth:`~odoo.models.Model.search_count` can be used to retrieve
 only the number of records matching the query. It takes the same
 :ref:`domain <reference/orm/domains>` filter as
-:meth:`~openerp.models.Model.search` and no other parameter.
+:meth:`~odoo.models.Model.search` and no other parameter.
 
 .. container:: doc-aside
 
@@ -507,9 +507,9 @@ only the number of records matching the query. It takes the same
 Read records
 ------------
 
-Record data is accessible via the :meth:`~openerp.models.Model.read` method,
+Record data is accessible via the :meth:`~odoo.models.Model.read` method,
 which takes a list of ids (as returned by
-:meth:`~openerp.models.Model.search`) and optionally a list of fields to
+:meth:`~odoo.models.Model.search`) and optionally a list of fields to
 fetch. By default, it will fetch all the fields the current user can read,
 which tends to be a huge amount.
 
@@ -620,7 +620,7 @@ Conversedly, picking only three fields deemed interesting.
 Listing record fields
 ---------------------
 
-:meth:`~openerp.models.Model.fields_get` can be used to inspect
+:meth:`~odoo.models.Model.fields_get` can be used to inspect
 a model's fields and check which ones seem to be of interest.
 
 Because it returns a large amount of meta-information (it is also used by client
@@ -705,13 +705,13 @@ Search and read
 ---------------
 
 Because it is a very common task, Odoo provides a
-:meth:`~openerp.models.Model.search_read` shortcut which as its name suggests is
-equivalent to a :meth:`~openerp.models.Model.search` followed by a
-:meth:`~openerp.models.Model.read`, but avoids having to perform two requests
+:meth:`~odoo.models.Model.search_read` shortcut which as its name suggests is
+equivalent to a :meth:`~odoo.models.Model.search` followed by a
+:meth:`~odoo.models.Model.read`, but avoids having to perform two requests
 and keep ids around.
 
-Its arguments are similar to :meth:`~openerp.models.Model.search`'s, but it
-can also take a list of ``fields`` (like :meth:`~openerp.models.Model.read`,
+Its arguments are similar to :meth:`~odoo.models.Model.search`'s, but it
+can also take a list of ``fields`` (like :meth:`~odoo.models.Model.read`,
 if that list is not provided it will fetch all fields of matched records):
 
 .. container:: doc-aside
@@ -793,10 +793,10 @@ if that list is not provided it will fetch all fields of matched records):
 Create records
 --------------
 
-Records of a model are created using :meth:`~openerp.models.Model.create`. The
+Records of a model are created using :meth:`~odoo.models.Model.create`. The
 method will create a single record and return its database identifier.
 
-:meth:`~openerp.models.Model.create` takes a mapping of fields to values, used
+:meth:`~odoo.models.Model.create` takes a mapping of fields to values, used
 to initialize the record. For any field which has a default value and is not
 set through the mapping argument, the default value will be used.
 
@@ -837,21 +837,21 @@ set through the mapping argument, the default value will be used.
 .. warning::
 
     while most value types are what would be expected (integer for
-    :class:`~openerp.fields.Integer`, string for :class:`~openerp.fields.Char`
-    or :class:`~openerp.fields.Text`),
+    :class:`~odoo.fields.Integer`, string for :class:`~odoo.fields.Char`
+    or :class:`~odoo.fields.Text`),
 
-    * :class:`~openerp.fields.Date`, :class:`~openerp.fields.Datetime` and
-      :class:`~openerp.fields.Binary` fields use string values
-    * :class:`~openerp.fields.One2many` and :class:`~openerp.fields.Many2many`
+    * :class:`~odoo.fields.Date`, :class:`~odoo.fields.Datetime` and
+      :class:`~odoo.fields.Binary` fields use string values
+    * :class:`~odoo.fields.One2many` and :class:`~odoo.fields.Many2many`
       use a special command protocol detailed in :meth:`the documentation to
-      the write method <openerp.models.Model.write>`.
+      the write method <odoo.models.Model.write>`.
 
 Update records
 --------------
 
-Records can be updated using :meth:`~openerp.models.Model.write`, it takes
+Records can be updated using :meth:`~odoo.models.Model.write`, it takes
 a list of records to update and a mapping of updated fields to values similar
-to :meth:`~openerp.models.Model.create`.
+to :meth:`~odoo.models.Model.create`.
 
 Multiple records can be updated simultanously, but they will all get the same
 values for the fields being set. It is not currently possible to perform
@@ -911,7 +911,7 @@ Delete records
 --------------
 
 Records can be deleted in bulk by providing their ids to 
-:meth:`~openerp.models.Model.unlink`.
+:meth:`~odoo.models.Model.unlink`.
 
 .. container:: doc-aside
 
@@ -966,7 +966,7 @@ Inspection and introspection
           xid currently associated with the record. And operating with xids
           isn't exactly fun in RPC.
 
-While we previously used :meth:`~openerp.models.Model.fields_get` to query a
+While we previously used :meth:`~odoo.models.Model.fields_get` to query a
 model and have been using an arbitrary model from the start, Odoo stores
 most model metadata inside a few meta-models which allow both querying the
 system and altering models and fields (with some limitations) on the fly over
@@ -987,13 +987,13 @@ Provides information about Odoo models via its various fields
     whether the model was generated in Python code (``base``) or by creating
     an ``ir.model`` record (``manual``)
 ``field_id``
-    list of the model's fields through a :class:`~openerp.fields.One2many` to
+    list of the model's fields through a :class:`~odoo.fields.One2many` to
     :ref:`reference/webservice/inspection/fields`
 ``view_ids``
-    :class:`~openerp.fields.One2many` to the :ref:`reference/views` defined
+    :class:`~odoo.fields.One2many` to the :ref:`reference/views` defined
     for the model
 ``access_ids``
-    :class:`~openerp.fields.One2many` relation to the
+    :class:`~odoo.fields.One2many` relation to the
     :ref:`reference/security/acl` set on the model
 
 ``ir.model`` can be used to
@@ -1126,7 +1126,7 @@ Provides information about the fields of Odoo models and allows adding
 custom fields without using Python code
 
 ``model_id``
-    :class:`~openerp.fields.Many2one` to
+    :class:`~odoo.fields.Many2one` to
     :ref:`reference/webservice/inspection/models` to which the field belongs
 ``name``
     the field's technical name (used in ``read`` or ``write``)
@@ -1141,7 +1141,7 @@ custom fields without using Python code
     enables the corresponding flag on the field
 ``groups``
     :ref:`field-level access control <reference/security/fields>`, a
-    :class:`~openerp.fields.Many2many` to ``res.groups``
+    :class:`~odoo.fields.Many2many` to ``res.groups``
 ``selection``, ``size``, ``on_delete``, ``relation``, ``relation_field``, ``domain``
     type-specific properties and customizations, see :ref:`the fields
     documentation <reference/orm/fields>` for details
diff --git a/doc/howtos/backend.rst b/doc/howtos/backend.rst
index b362624a274..cf86992af4c 100644
--- a/doc/howtos/backend.rst
+++ b/doc/howtos/backend.rst
@@ -123,16 +123,16 @@ This layer avoids having to write most :abbr:`SQL (Structured Query Language)`
 by hand and provides extensibility and security services\ [#rawsql]_.
 
 Business objects are declared as Python classes extending
-:class:`~openerp.models.Model` which integrates them into the automated
+:class:`~odoo.models.Model` which integrates them into the automated
 persistence system.
 
 Models can be configured by setting a number of attributes at their
 definition. The most important attribute is
-:attr:`~openerp.models.Model._name` which is required and defines the name for
+:attr:`~odoo.models.Model._name` which is required and defines the name for
 the model in the Odoo system. Here is a minimally complete definition of a
 model::
 
-    from openerp import models
+    from odoo import models
     class MinimalModel(models.Model):
         _name = 'test.model'
 
@@ -142,7 +142,7 @@ Model fields
 Fields are used to define what the model can store and where. Fields are
 defined as attributes on the model class::
 
-    from openerp import models, fields
+    from odoo import models, fields
 
     class LessMinimalModel(models.Model):
         _name = 'test.model2'
@@ -159,14 +159,14 @@ configuration attributes as parameters::
 
 Some attributes are available on all fields, here are the most common ones:
 
-:attr:`~openerp.fields.Field.string` (``unicode``, default: field's name)
+:attr:`~odoo.fields.Field.string` (``unicode``, default: field's name)
     The label of the field in UI (visible by users).
-:attr:`~openerp.fields.Field.required` (``bool``, default: ``False``)
+:attr:`~odoo.fields.Field.required` (``bool``, default: ``False``)
     If ``True``, the field can not be empty, it must either have a default
     value or always be given a value when creating a record.
-:attr:`~openerp.fields.Field.help` (``unicode``, default: ``''``)
+:attr:`~odoo.fields.Field.help` (``unicode``, default: ``''``)
     Long-form, provides a help tooltip to users in the UI.
-:attr:`~openerp.fields.Field.index` (``bool``, default: ``False``)
+:attr:`~odoo.fields.Field.index` (``bool``, default: ``False``)
     Requests that Odoo create a `database index`_ on the column
 
 Simple fields
@@ -176,8 +176,8 @@ There are two broad categories of fields: "simple" fields which are atomic
 values stored directly in the model's table and "relational" fields linking
 records (of the same model or of different models).
 
-Example of simple fields are :class:`~openerp.fields.Boolean`,
-:class:`~openerp.fields.Date`, :class:`~openerp.fields.Char`.
+Example of simple fields are :class:`~odoo.fields.Boolean`,
+:class:`~odoo.fields.Date`, :class:`~odoo.fields.Char`.
 
 Reserved fields
 ###############
@@ -186,15 +186,15 @@ Odoo creates a few fields in all models\ [#autofields]_. These fields are
 managed by the system and shouldn't be written to. They can be read if
 useful or necessary:
 
-:attr:`~openerp.fields.Model.id` (:class:`~openerp.fields.Id`)
+:attr:`~odoo.fields.Model.id` (:class:`~odoo.fields.Id`)
     the unique identifier for a record in its model
-:attr:`~openerp.fields.Model.create_date` (:class:`~openerp.fields.Datetime`)
+:attr:`~odoo.fields.Model.create_date` (:class:`~odoo.fields.Datetime`)
     creation date of the record
-:attr:`~openerp.fields.Model.create_uid` (:class:`~openerp.fields.Many2one`)
+:attr:`~odoo.fields.Model.create_uid` (:class:`~odoo.fields.Many2one`)
     user who created the record
-:attr:`~openerp.fields.Model.write_date` (:class:`~openerp.fields.Datetime`)
+:attr:`~odoo.fields.Model.write_date` (:class:`~odoo.fields.Datetime`)
     last modification date of the record
-:attr:`~openerp.fields.Model.write_uid` (:class:`~openerp.fields.Many2one`)
+:attr:`~odoo.fields.Model.write_uid` (:class:`~odoo.fields.Many2one`)
     user who last modified the record
 
 Special fields
@@ -202,7 +202,7 @@ Special fields
 
 By default, Odoo also requires a ``name`` field on all models for various
 display and search behaviors. The field used for these purposes can be
-overridden by setting :attr:`~openerp.models.Model._rec_name`.
+overridden by setting :attr:`~odoo.models.Model._rec_name`.
 
 .. exercise:: Define a model
 
@@ -230,13 +230,13 @@ record.
 
 .. code-block:: xml
 
-    <openerp>
+    <odoo>
         <data>
             <record model="{model name}" id="{record identifier}">
                 <field name="{a field name}">{a value}</field>
             </record>
         </data>
-    </openerp>
+    </odoo>
 
 * ``model`` is the name of the Odoo model for the record
 * ``id`` is an :term:`external identifier`, it allows referring to the record
@@ -502,16 +502,16 @@ between different models.
 
 Relational field types are:
 
-:class:`Many2one(other_model, ondelete='set null') <openerp.fields.Many2one>`
+:class:`Many2one(other_model, ondelete='set null') <odoo.fields.Many2one>`
     A simple link to an other object::
 
         print foo.other_id.name
 
     .. seealso:: `foreign keys <http://www.postgresql.org/docs/9.3/static/tutorial-fk.html>`_
 
-:class:`One2many(other_model, related_field) <openerp.fields.One2many>`
-    A virtual relationship, inverse of a :class:`~openerp.fields.Many2one`.
-    A :class:`~openerp.fields.One2many` behaves as a container of records,
+:class:`One2many(other_model, related_field) <odoo.fields.One2many>`
+    A virtual relationship, inverse of a :class:`~odoo.fields.Many2one`.
+    A :class:`~odoo.fields.One2many` behaves as a container of records,
     accessing it results in a (possibly empty) set of records::
 
         for other in foo.other_ids:
@@ -519,11 +519,11 @@ Relational field types are:
 
     .. danger::
 
-        Because a :class:`~openerp.fields.One2many` is a virtual relationship,
-        there *must* be a :class:`~openerp.fields.Many2one` field in the
+        Because a :class:`~odoo.fields.One2many` is a virtual relationship,
+        there *must* be a :class:`~odoo.fields.Many2one` field in the
         :samp:`{other_model}`, and its name *must* be :samp:`{related_field}`
 
-:class:`Many2many(other_model) <openerp.fields.Many2many>`
+:class:`Many2many(other_model) <odoo.fields.Many2many>`
     Bidirectional multiple relationship, any record on one side can be related
     to any number of records on the other side. Behaves as a container of
     records, accessing it also results in a possibly empty set of records::
@@ -604,8 +604,8 @@ fields of the parent record.
 
 .. seealso::
 
-    * :attr:`~openerp.models.Model._inherit`
-    * :attr:`~openerp.models.Model._inherits`
+    * :attr:`~odoo.models.Model._inherit`
+    * :attr:`~odoo.models.Model._inherits`
 
 View inheritance
 ----------------
@@ -757,7 +757,7 @@ retrieved from the database but computed on-the-fly by calling a method of the
 model.
 
 To create a computed field, create a field and set its attribute
-:attr:`~openerp.fields.Field.compute` to the name of a method. The computation
+:attr:`~odoo.fields.Field.compute` to the name of a method. The computation
 method should simply set the value of the field to compute on every record in
 ``self``.
 
@@ -776,7 +776,7 @@ method should simply set the value of the field to compute on every record in
 .. code-block:: python
 
     import random
-    from openerp import models, fields, api
+    from odoo import models, fields, api
 
     class ComputedModel(models.Model):
         _name = 'test.computed'
@@ -794,11 +794,11 @@ Dependencies
 
 The value of a computed field usually depends on the values of other fields on
 the computed record. The ORM expects the developer to specify those dependencies
-on the compute method with the decorator :func:`~openerp.api.depends`.
+on the compute method with the decorator :func:`~odoo.api.depends`.
 The given dependencies are used by the ORM to trigger the recomputation of the
 field whenever some of its dependencies have been modified::
 
-    from openerp import models, fields, api
+    from odoo import models, fields, api
 
     class ComputedModel(models.Model):
         _name = 'test.computed'
@@ -850,7 +850,7 @@ float, string), or a function taking a recordset and returning a value::
 .. exercise:: Active objects – Default values
 
     * Define the start_date default value as today (see
-      :class:`~openerp.fields.Date`).
+      :class:`~odoo.fields.Date`).
     * Add a field ``active`` in the class Session, and set sessions as active by
       default.
 
@@ -873,7 +873,7 @@ to the database.
 For instance, suppose a model has three fields ``amount``, ``unit_price`` and
 ``price``, and you want to update the price on the form when any of the other
 fields is modified. To achieve this, define a method where ``self`` represents
-the record in the form view, and decorate it with :func:`~openerp.api.onchange`
+the record in the form view, and decorate it with :func:`~odoo.api.onchange`
 to specify on which field it has to be triggered. Any change you make on
 ``self`` will be reflected on the form.
 
@@ -916,16 +916,16 @@ Model constraints
 =================
 
 Odoo provides two ways to set up automatically verified invariants:
-:func:`Python constraints <openerp.api.constrains>` and
-:attr:`SQL constraints <openerp.models.Model._sql_constraints>`.
+:func:`Python constraints <odoo.api.constrains>` and
+:attr:`SQL constraints <odoo.models.Model._sql_constraints>`.
 
 A Python constraint is defined as a method decorated with
-:func:`~openerp.api.constrains`, and invoked on a recordset. The decorator
+:func:`~odoo.api.constrains`, and invoked on a recordset. The decorator
 specifies which fields are involved in the constraint, so that the constraint is
 automatically evaluated when one of them is modified. The method is expected to
 raise an exception if its invariant is not satisfied::
 
-    from openerp.exceptions import ValidationError
+    from odoo.exceptions import ValidationError
 
     @api.constrains('age')
     def _check_something(self):
@@ -944,7 +944,7 @@ raise an exception if its invariant is not satisfied::
         .. patch::
 
 SQL constraints are defined through the model attribute
-:attr:`~openerp.models.Model._sql_constraints`. The latter is assigned to a list
+:attr:`~odoo.models.Model._sql_constraints`. The latter is assigned to a list
 of triples of strings ``(name, sql_definition, message)``, where ``name`` is a
 valid SQL constraint name, ``sql_definition`` is a table_constraint_ expression,
 and ``message`` is the error message.
@@ -1390,7 +1390,7 @@ access rights are limited.
 
 Here is an example of a rule that prevents the deletion of leads that are not
 in state ``cancel``. Notice that the value of the field ``groups`` must follow
-the same convention as the method :meth:`~openerp.models.Model.write` of the ORM.
+the same convention as the method :meth:`~odoo.models.Model.write` of the ORM.
 
 .. code-block:: xml
 
@@ -1423,9 +1423,9 @@ Wizards
 
 Wizards describe interactive sessions with the user (or dialog boxes) through
 dynamic forms. A wizard is simply a model that extends the class
-:class:`~openerp.models.TransientModel` instead of
-:class:`~openerp.models.Model`. The class
-:class:`~openerp.models.TransientModel` extends :class:`~openerp.models.Model`
+:class:`~odoo.models.TransientModel` instead of
+:class:`~odoo.models.Model`. The class
+:class:`~odoo.models.TransientModel` extends :class:`~odoo.models.Model`
 and reuse all its existing mechanisms, with the following particularities:
 
 - Wizard records are not meant to be persistent; they are automatically deleted
@@ -1537,7 +1537,7 @@ for editing and merging PO/POT files.
 
    By default Odoo's POT export only extracts labels inside XML files or
    inside field definitions in Python code, but any Python string can be
-   translated this way by surrounding it with the function :func:`openerp._`
+   translated this way by surrounding it with the function :func:`odoo._`
    (e.g. ``_("Label")``)
 
 .. exercise:: Translate a module
@@ -1566,7 +1566,7 @@ for editing and merging PO/POT files.
            terms
 
         #. In ``models.py``, add an import statement for the function
-           ``openerp._`` and mark missing strings as translatable
+           ``odoo._`` and mark missing strings as translatable
 
         #. Repeat steps 3-6
 
@@ -1852,12 +1852,12 @@ Examples can be easily adapted from XML-RPC to JSON-RPC.
 
     * https://github.com/akretion/ooor
     * https://github.com/syleam/openobject-library
-    * https://github.com/nicolas-van/openerp-client-lib
+    * https://github.com/nicolas-van/odoo-client-lib
     * https://pypi.python.org/pypi/oersted/
-    * https://github.com/abhishek-jaiswal/php-openerp-lib
+    * https://github.com/abhishek-jaiswal/php-odoo-lib
 
 .. [#autofields] it is possible to :attr:`disable the automatic creation of some
-                 fields <openerp.models.Model._log_access>`
+                 fields <odoo.models.Model._log_access>`
 .. [#rawsql] writing raw SQL queries is possible, but requires care as it
              bypasses all Odoo authentication and security mechanisms.
 
diff --git a/doc/howtos/backend/exercise-access-rights b/doc/howtos/backend/exercise-access-rights
index e653cbadcd5..65165f14b29 100644
--- a/doc/howtos/backend/exercise-access-rights
+++ b/doc/howtos/backend/exercise-access-rights
@@ -31,10 +31,10 @@ Index: addons/openacademy/security/security.xml
 --- /dev/null	1970-01-01 00:00:00.000000000 +0000
 +++ addons/openacademy/security/security.xml	2014-08-26 17:26:18.135783102 +0200
 @@ -0,0 +1,7 @@
-+<openerp>
++<odoo>
 +    <data>
 +        <record id="group_manager" model="res.groups">
 +            <field name="name">OpenAcademy / Manager</field>
 +        </record>
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-access-rules b/doc/howtos/backend/exercise-access-rules
index 4ec91a3fcd4..40cdacfe03e 100644
--- a/doc/howtos/backend/exercise-access-rules
+++ b/doc/howtos/backend/exercise-access-rules
@@ -24,4 +24,4 @@ Index: addons/openacademy/security/security.xml
 +            </field>
 +        </record>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/backend/exercise-basic-action b/doc/howtos/backend/exercise-basic-action
index f5e5e9be9d5..b8876a1f9e8 100644
--- a/doc/howtos/backend/exercise-basic-action
+++ b/doc/howtos/backend/exercise-basic-action
@@ -18,7 +18,7 @@ Index: addons/openacademy/views/openacademy.xml
 +++ addons/openacademy/views/openacademy.xml	2014-08-26 17:25:53.511783468 +0200
 @@ -0,0 +1,35 @@
 +<?xml version="1.0" encoding="UTF-8"?>
-+<openerp>
++<odoo>
 +    <data>
 +        <!-- window action -->
 +        <!--
@@ -51,4 +51,4 @@ Index: addons/openacademy/views/openacademy.xml
 +             action="openacademy.course_list_action"
 +             It is not required when it is the same module -->
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-calendar b/doc/howtos/backend/exercise-calendar
index 6d85a64e05a..9a86e6b03de 100644
--- a/doc/howtos/backend/exercise-calendar
+++ b/doc/howtos/backend/exercise-calendar
@@ -9,7 +9,7 @@ diff --git a/openacademy/models.py b/openacademy/models.py
  # -*- coding: utf-8 -*-
  
 +from datetime import timedelta
- from openerp import models, fields, api, exceptions
+ from odoo import models, fields, api, exceptions
  
  class Session(models.Model):
 @@ -55,6 +56,8 @@ class Session(models.Model):
diff --git a/doc/howtos/backend/exercise-constraint-python b/doc/howtos/backend/exercise-constraint-python
index 290e09aa5a1..144a64e0325 100644
--- a/doc/howtos/backend/exercise-constraint-python
+++ b/doc/howtos/backend/exercise-constraint-python
@@ -8,8 +8,8 @@ diff --git a/openacademy/models.py b/openacademy/models.py
 @@ -1,6 +1,6 @@
  # -*- coding: utf-8 -*-
  
--from openerp import models, fields, api
-+from openerp import models, fields, api, exceptions
+-from odoo import models, fields, api
++from odoo import models, fields, api, exceptions
  
  class Course(models.Model):
      _name = 'openacademy.course'
diff --git a/doc/howtos/backend/exercise-creation b/doc/howtos/backend/exercise-creation
index 80911aa160e..490f7fd7a02 100644
--- a/doc/howtos/backend/exercise-creation
+++ b/doc/howtos/backend/exercise-creation
@@ -22,7 +22,7 @@ Index: addons/openacademy/__manifest__.py
 +    'website': "http://www.yourcompany.com",
 +
 +    # Categories can be used to filter modules in modules listing
-+    # Check https://github.com/odoo/odoo/blob/master/openerp/addons/base/module/module_data.xml
++    # Check https://github.com/odoo/odoo/blob/master/odoo/addons/base/module/module_data.xml
 +    # for the full list
 +    'category': 'Test',
 +    'version': '0.1',
@@ -54,7 +54,7 @@ Index: addons/openacademy/controllers.py
 +++ addons/openacademy/controllers.py	2014-08-26 17:25:49.791783523 +0200
 @@ -0,0 +1,20 @@
 +# -*- coding: utf-8 -*-
-+from openerp import http
++from odoo import http
 +
 +# class Openacademy(http.Controller):
 +#     @http.route('/openacademy/openacademy/', auth='public')
@@ -78,7 +78,7 @@ Index: addons/openacademy/demo.xml
 --- /dev/null	1970-01-01 00:00:00.000000000 +0000
 +++ addons/openacademy/demo.xml	2014-08-26 17:25:49.791783523 +0200
 @@ -0,0 +1,25 @@
-+<openerp>
++<odoo>
 +    <data>
 +        <!--  -->
 +        <!--   <record id="object0" model="openacademy.openacademy"> -->
@@ -102,7 +102,7 @@ Index: addons/openacademy/demo.xml
 +        <!--   </record> -->
 +        <!--  -->
 +    </data>
-+</openerp>
++</odoo>
 Index: addons/openacademy/models.py
 ===================================================================
 --- /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -110,7 +110,7 @@ Index: addons/openacademy/models.py
 @@ -0,0 +1,8 @@
 +# -*- coding: utf-8 -*-
 +
-+from openerp import models, fields, api
++from odoo import models, fields, api
 +
 +# class openacademy(models.Model):
 +#     _name = 'openacademy.openacademy'
@@ -128,7 +128,7 @@ Index: addons/openacademy/templates.xml
 --- /dev/null	1970-01-01 00:00:00.000000000 +0000
 +++ addons/openacademy/templates.xml	2014-08-26 17:25:49.791783523 +0200
 @@ -0,0 +1,22 @@
-+<openerp>
++<odoo>
 +    <data>
 +        <!-- <template id="listing"> -->
 +        <!--   <ul> -->
@@ -149,4 +149,4 @@ Index: addons/openacademy/templates.xml
 +        <!--   </dl> -->
 +        <!-- </template> -->
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-dashboard b/doc/howtos/backend/exercise-dashboard
index b1092479669..4a6eceb8fd9 100644
--- a/doc/howtos/backend/exercise-dashboard
+++ b/doc/howtos/backend/exercise-dashboard
@@ -28,7 +28,7 @@ Index: addons/openacademy/views/session_board.xml
 +++ addons/openacademy/views/session_board.xml	2014-08-26 17:26:21.531783052 +0200
 @@ -0,0 +1,66 @@
 +<?xml version="1.0"?>
-+<openerp>
++<odoo>
 +    <data>
 +        <record model="ir.actions.act_window" id="act_session_graph">
 +            <field name="name">Attendees by course</field>
@@ -92,4 +92,4 @@ Index: addons/openacademy/views/session_board.xml
 +            sequence="1"
 +            id="menu_board_session" icon="terp-graph"/>
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-demo b/doc/howtos/backend/exercise-demo
index 96d591a5fc1..a03007d7fe9 100644
--- a/doc/howtos/backend/exercise-demo
+++ b/doc/howtos/backend/exercise-demo
@@ -6,7 +6,7 @@ Index: addons/openacademy/demo.xml
 --- addons.orig/openacademy/demo.xml	2014-08-26 17:25:52.683783480 +0200
 +++ addons/openacademy/demo.xml	2014-08-26 17:25:52.679783480 +0200
 @@ -1,25 +1,19 @@
- <openerp>
+ <odoo>
      <data>
 -        <!--  -->
 -        <!--   <record id="object0" model="openacademy.openacademy"> -->
@@ -45,4 +45,4 @@ Index: addons/openacademy/demo.xml
 +            <field name="description">Course 2's description</field>
 +        </record>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/backend/exercise-domain-advanced b/doc/howtos/backend/exercise-domain-advanced
index 4b27ad89143..bed90880dcd 100644
--- a/doc/howtos/backend/exercise-domain-advanced
+++ b/doc/howtos/backend/exercise-domain-advanced
@@ -40,4 +40,4 @@ Index: addons/openacademy/views/partner.xml
 +            <field name="name">Teacher / Level 2</field>
 +        </record>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/backend/exercise-formview b/doc/howtos/backend/exercise-formview
index ad0dd4e9baf..8de3e69f7e6 100644
--- a/doc/howtos/backend/exercise-formview
+++ b/doc/howtos/backend/exercise-formview
@@ -7,7 +7,7 @@ Index: addons/openacademy/views/openacademy.xml
 +++ addons/openacademy/views/openacademy.xml	2014-08-26 17:25:54.283783457 +0200
 @@ -1,6 +1,21 @@
  <?xml version="1.0" encoding="UTF-8"?>
- <openerp>
+ <odoo>
      <data>
 +        <record model="ir.ui.view" id="course_form_view">
 +            <field name="name">course.form</field>
diff --git a/doc/howtos/backend/exercise-model b/doc/howtos/backend/exercise-model
index 57be0edad57..4c3b8573107 100644
--- a/doc/howtos/backend/exercise-model
+++ b/doc/howtos/backend/exercise-model
@@ -6,7 +6,7 @@ Index: addons/openacademy/models.py
 +++ addons/openacademy/models.py	2014-08-26 17:25:51.639783496 +0200
 @@ -2,7 +2,8 @@
  
- from openerp import models, fields, api
+ from odoo import models, fields, api
  
 -# class openacademy(models.Model):
 -#     _name = 'openacademy.openacademy'
diff --git a/doc/howtos/backend/exercise-model-inheritance b/doc/howtos/backend/exercise-model-inheritance
index 941ce0442df..f74e5e95c33 100644
--- a/doc/howtos/backend/exercise-model-inheritance
+++ b/doc/howtos/backend/exercise-model-inheritance
@@ -28,7 +28,7 @@ Index: addons/openacademy/partner.py
 +++ addons/openacademy/partner.py	2014-08-26 17:26:01.223783354 +0200
 @@ -0,0 +1,12 @@
 +# -*- coding: utf-8 -*-
-+from openerp import fields, models
++from odoo import fields, models
 +
 +class Partner(models.Model):
 +    _inherit = 'res.partner'
@@ -45,7 +45,7 @@ Index: addons/openacademy/views/partner.xml
 +++ addons/openacademy/views/partner.xml	2014-08-26 17:26:01.223783354 +0200
 @@ -0,0 +1,32 @@
 +<?xml version="1.0" encoding="UTF-8"?>
-+ <openerp>
++ <odoo>
 +    <data>
 +        <!-- Add instructor field to existing view -->
 +        <record model="ir.ui.view" id="partner_instructor_form_view">
@@ -75,4 +75,4 @@ Index: addons/openacademy/views/partner.xml
 +                  parent="configuration_menu"
 +                  action="contact_list_action"/>
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-report b/doc/howtos/backend/exercise-report
index b06e3fbf6ee..6e8a2d78705 100644
--- a/doc/howtos/backend/exercise-report
+++ b/doc/howtos/backend/exercise-report
@@ -18,7 +18,7 @@ Index: addons/openacademy/reports.xml
 --- /dev/null	1970-01-01 00:00:00.000000000 +0000
 +++ addons/openacademy/reports.xml	2014-08-29 08:41:12.663540061 +0200
 @@ -0,0 +1,30 @@
-+<openerp>
++<odoo>
 +<data>
 +    <report
 +        id="report_session"
@@ -47,4 +47,4 @@ Index: addons/openacademy/reports.xml
 +        </t>
 +    </template>
 +</data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-session b/doc/howtos/backend/exercise-session
index 993ee0a7dd6..9a6fe886932 100644
--- a/doc/howtos/backend/exercise-session
+++ b/doc/howtos/backend/exercise-session
@@ -55,4 +55,4 @@ Index: addons/openacademy/views/openacademy.xml
 +                  parent="openacademy_menu"
 +                  action="session_list_action"/>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/backend/exercise-state-workflow b/doc/howtos/backend/exercise-state-workflow
index 6178913d164..d97dce1b1ea 100644
--- a/doc/howtos/backend/exercise-state-workflow
+++ b/doc/howtos/backend/exercise-state-workflow
@@ -50,7 +50,7 @@ new file mode 100644
 --- /dev/null
 +++ b/openacademy/views/session_workflow.xml
 @@ -0,0 +1,50 @@
-+<openerp>
++<odoo>
 +    <data>
 +        <record model="workflow" id="wkf_session">
 +            <field name="name">OpenAcademy sessions workflow</field>
@@ -99,4 +99,4 @@ new file mode 100644
 +            <field name="signal">done</field>
 +        </record>
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/backend/exercise-state-workflow-automatic b/doc/howtos/backend/exercise-state-workflow-automatic
index 112d0a3cd20..c1f5d1c7e5a 100644
--- a/doc/howtos/backend/exercise-state-workflow-automatic
+++ b/doc/howtos/backend/exercise-state-workflow-automatic
@@ -16,4 +16,4 @@ Index: addons/openacademy/views/session_workflow.xml
 +            <field name="condition">taken_seats &gt; 50</field>
 +        </record>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/backend/exercise-translations b/doc/howtos/backend/exercise-translations
index 707abe27557..8ade655253d 100644
--- a/doc/howtos/backend/exercise-translations
+++ b/doc/howtos/backend/exercise-translations
@@ -8,8 +8,8 @@ diff --git a/openacademy/models.py b/openacademy/models.py
  # -*- coding: utf-8 -*-
  
  from datetime import timedelta
--from openerp import models, fields, api, exceptions
-+from openerp import models, fields, api, exceptions, _
+-from odoo import models, fields, api, exceptions
++from odoo import models, fields, api, exceptions, _
  
  class Course(models.Model):
      _name = 'openacademy.course'
diff --git a/doc/howtos/backend/exercise-wizard b/doc/howtos/backend/exercise-wizard
index 906cdef181b..400654c4ff3 100644
--- a/doc/howtos/backend/exercise-wizard
+++ b/doc/howtos/backend/exercise-wizard
@@ -14,7 +14,7 @@ Index: addons/openacademy/wizard.py
 @@ -0,0 +1,10 @@
 +# -*- coding: utf-8 -*-
 +
-+from openerp import models, fields, api
++from odoo import models, fields, api
 +
 +class Wizard(models.TransientModel):
 +    _name = 'openacademy.wizard'
diff --git a/doc/howtos/backend/exercise-wizard-launch b/doc/howtos/backend/exercise-wizard-launch
index bfd0f26bf30..605178e8375 100644
--- a/doc/howtos/backend/exercise-wizard-launch
+++ b/doc/howtos/backend/exercise-wizard-launch
@@ -43,4 +43,4 @@ Index: addons/openacademy/views/openacademy.xml
 +                    target="new"
 +                    key2="client_action_multi"/>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/themes.rst b/doc/howtos/themes.rst
index 9ad9c2a8673..531f5e2c8f0 100644
--- a/doc/howtos/themes.rst
+++ b/doc/howtos/themes.rst
@@ -144,17 +144,17 @@ Odoo's XML files, an overview
 -----------------------------
 
 Any Odoo XML file starts with encoding specifications.
-After that, you have to write your code inside a ``<data>`` tag, placed into an ``</openerp>`` tag.
+After that, you have to write your code inside a ``<data>`` tag, placed into an ``</odoo>`` tag.
 
 .. code-block:: xml
 
    [XML]
    <?xml version="1.0" encoding="utf-8" ?>
-   <openerp>
+   <odoo>
      <data>
        ## YOUR CODE HERE
      </data>
-   </openerp>
+   </odoo>
 
 Almost every element and option that you create has to be placed inside a ``<template>`` tag, like in this example.
 
@@ -223,7 +223,7 @@ Odoo’s themes are packaged like modules. Even if you are designing a very simp
 .. important::
 
   Use two underscore characters at the beginning
-  and two at the end of openerp and init file names.
+  and two at the end of odoo and init file names.
 
 The final result should be something like this:
 
@@ -309,11 +309,11 @@ To do so, create a **layout.xml** file in your **views** folder and add the defa
 .. code-block:: xml
 
    <?xml version="1.0" encoding="utf-8" ?>
-   <openerp>
+   <odoo>
      <data>
 
      </data>
-   </openerp>
+   </odoo>
 
 Create a new template into the ``<data>`` tag, copy-pasting the following
 code.
@@ -379,7 +379,7 @@ default Odoo markup.  Inside ``<data>`` create a ``<template>`` tag, set the
 .. code-block:: xml
 
    <?xml version="1.0" encoding="utf-8" ?>
-   <openerp>
+   <odoo>
      <data>
        <!-- === Services Page === -->
        <template name="Services page" id="website.services" page="True">
@@ -391,7 +391,7 @@ default Odoo markup.  Inside ``<data>`` create a ``<template>`` tag, set the
            </ul>
          </template>
        </data>
-     </openerp>
+     </odoo>
 
 The page title will be the template ID. In our case *Services* (from ``website.services``)
 
@@ -429,7 +429,7 @@ can fill with snippets. To achieve this, just create a ``div`` with
 .. code-block:: xml
 
    <?xml version="1.0" encoding="utf-8" ?>
-   <openerp>
+   <odoo>
    <data>
 
    <!-- === Services Page === -->
@@ -451,7 +451,7 @@ can fill with snippets. To achieve this, just create a ``div`` with
    </template>
 
    </data>
-   </openerp>
+   </odoo>
 
 .. tip::
 
@@ -787,8 +787,8 @@ the following code
 
     (function() {
         'use strict';
-        var website = openerp.website;
-        website.openerp_website = {};
+        var website = odoo.website;
+        website.odoo_website = {};
     })();
 
 Great, we successfully created our javascript editor file. This file will contain all the javascript functions used by our snippets in edit mode. Let’s create a new function for our testimonial snippet using the ``snippet_testimonial_options`` method that we created before.
@@ -797,8 +797,8 @@ Great, we successfully created our javascript editor file. This file will contai
 
    (function() {
        'use strict';
-       var website = openerp.website;
-       website.openerp_website = {};
+       var website = odoo.website;
+       website.odoo_website = {};
 
        website.snippet.options.snippet_testimonial_options = website.snippet.Option.extend({
            on_focus: function() {
diff --git a/doc/howtos/web.rst b/doc/howtos/web.rst
index 9c99b02d2ce..3f373cb4ecd 100644
--- a/doc/howtos/web.rst
+++ b/doc/howtos/web.rst
@@ -86,7 +86,7 @@ sub-folders are conventional and not strictly necessary.
     application (or at least its web-browser side) as javascript. It should
     currently look like::
 
-        openerp.oepetstore = function(instance, local) {
+        odoo.oepetstore = function(instance, local) {
             var _t = instance.web._t,
                 _lt = instance.web._lt;
             var QWeb = instance.web.qweb;
@@ -142,11 +142,11 @@ in order to both namespace code and correctly order its loading.
 
 ``oepetstore/static/js/petstore.js`` contains a module declaration::
 
-    openerp.oepetstore = function(instance, local) {
+    odoo.oepetstore = function(instance, local) {
         local.xxx = ...;
     }
 
-In Odoo web, modules are declared as functions set on the global ``openerp``
+In Odoo web, modules are declared as functions set on the global ``odoo``
 variable. The function's name must be the same as the addon (in this case
 ``oepetstore``) so the framework can find it, and automatically initialize it.
 
@@ -173,8 +173,8 @@ equivalent (if lower-level and more verbose) mechanisms.
 For simplicity and developer-friendliness Odoo web provides a class
 system based on John Resig's `Simple JavaScript Inheritance`_.
 
-New classes are defined by calling the :func:`~openerp.web.Class.extend`
-method of :class:`openerp.web.Class`::
+New classes are defined by calling the :func:`~odoo.web.Class.extend`
+method of :class:`odoo.web.Class`::
 
     var MyClass = instance.web.Class.extend({
         say_hello: function() {
@@ -182,7 +182,7 @@ method of :class:`openerp.web.Class`::
         },
     });
 
-The :func:`~openerp.web.Class.extend` method takes a dictionary describing
+The :func:`~odoo.web.Class.extend` method takes a dictionary describing
 the new class's content (methods and static attributes). In this case, it will
 only have a ``say_hello`` method which takes no parameters.
 
@@ -223,8 +223,8 @@ parameters passed when using the ``new`` operator::
     // print "hello Bob" in the console
 
 It is also possible to create subclasses from existing (used-defined) classes
-by calling :func:`~openerp.web.Class.extend` on the parent class, as is done
-to subclass :class:`~openerp.web.Class`::
+by calling :func:`~odoo.web.Class.extend` on the parent class, as is done
+to subclass :class:`~odoo.web.Class`::
 
     var MySpanishClass = MyClass.extend({
         say_hello: function() {
@@ -284,7 +284,7 @@ maintenance.
 
 Much like object-oriented desktop UI toolkits (e.g. Qt_, Cocoa_ or GTK_),
 Odoo Web makes specific components responsible for sections of a page. In
-Odoo web, the base for such components is the :class:`~openerp.Widget`
+Odoo web, the base for such components is the :class:`~odoo.Widget`
 class, a component specialized in handling a page section and displaying
 information for the user.
 
@@ -299,8 +299,8 @@ The initial demonstration module already provides a basic widget::
         },
     });
 
-It extends :class:`~openerp.Widget` and overrides the standard method
-:func:`~openerp.Widget.start`, which — much like the previous ``MyClass``
+It extends :class:`~odoo.Widget` and overrides the standard method
+:func:`~odoo.Widget.start`, which — much like the previous ``MyClass``
 — does little for now.
 
 This line at the end of the file::
@@ -327,14 +327,14 @@ Widgets have a number of methods and features, but the basics are simple:
 * format the widget's data
 * display the widget
 
-The ``HomePage`` widget already has a :func:`~openerp.Widget.start`
+The ``HomePage`` widget already has a :func:`~odoo.Widget.start`
 method. That method is part of the normal widget lifecycle and automatically
 called once the widget is inserted in the page. We can use it to display some
 content.
 
-All widgets have a :attr:`~openerp.Widget.$el` which represents the
+All widgets have a :attr:`~odoo.Widget.$el` which represents the
 section of page they're in charge of (as a jQuery_ object). Widget content
-should be inserted there. By default, :attr:`~openerp.Widget.$el` is an
+should be inserted there. By default, :attr:`~odoo.Widget.$el` is an
 empty ``<div>`` element.
 
 A ``<div>`` element is usually invisible to the user if it has no content (or
@@ -367,7 +367,7 @@ To learn how to use a widget "from scratch" let's create a new one::
     });
 
 We can now add our ``GreetingsWidget`` to the ``HomePage`` by using the
-``GreetingsWidget``'s :func:`~openerp.Widget.appendTo` method::
+``GreetingsWidget``'s :func:`~odoo.Widget.appendTo` method::
 
     local.HomePage = instance.Widget.extend({
         start: function() {
@@ -380,17 +380,17 @@ We can now add our ``GreetingsWidget`` to the ``HomePage`` by using the
 * ``HomePage`` first adds its own content to its DOM root
 * ``HomePage`` then instantiates ``GreetingsWidget``
 * Finally it tells ``GreetingsWidget`` where to insert itself, delegating part
-  of its :attr:`~openerp.Widget.$el` to the ``GreetingsWidget``.
+  of its :attr:`~odoo.Widget.$el` to the ``GreetingsWidget``.
 
-When the :func:`~openerp.Widget.appendTo` method is called, it asks the
+When the :func:`~odoo.Widget.appendTo` method is called, it asks the
 widget to insert itself at the specified position and to display its content.
-The :func:`~openerp.Widget.start` method will be called during the call
-to :func:`~openerp.Widget.appendTo`.
+The :func:`~odoo.Widget.start` method will be called during the call
+to :func:`~odoo.Widget.appendTo`.
 
 To see what happens under the displayed interface, we will use the browser's
 DOM Explorer. But first let's alter our widgets slightly so we can more easily
 find where they are, by :attr:`adding a class to their root elements
-<openerp.Widget.className>`::
+<odoo.Widget.className>`::
 
     local.HomePage = instance.Widget.extend({
         className: 'oe_petstore_homepage',
@@ -414,7 +414,7 @@ then :guilabel:`Inspect Element`), it should look like this:
     </div>
 
 Which clearly shows the two ``<div>`` elements automatically created by
-:class:`~openerp.Widget`, because we added some classes on them.
+:class:`~odoo.Widget`, because we added some classes on them.
 
 We can also see the two message-holding divs we added ourselves
 
@@ -442,7 +442,7 @@ of another widget, and exist on behalf of it. We call the container the
 Due to multiple technical and conceptual reasons, it is necessary for a widget
 to know who is its parent and who are its children.
 
-:func:`~openerp.Widget.getParent`
+:func:`~odoo.Widget.getParent`
     can be used to get the parent of a widget::
 
         local.GreetingsWidget = instance.Widget.extend({
@@ -452,7 +452,7 @@ to know who is its parent and who are its children.
             },
         });
 
-:func:`~openerp.Widget.getChildren`
+:func:`~odoo.Widget.getChildren`
     can be used to get a list of its children::
 
         local.HomePage = instance.Widget.extend({
@@ -464,7 +464,7 @@ to know who is its parent and who are its children.
             },
         });
 
-When overriding the :func:`~openerp.Widget.init` method of a widget it is
+When overriding the :func:`~odoo.Widget.init` method of a widget it is
 *of the utmost importance* to pass the parent to the ``this._super()`` call,
 otherwise the relation will not be set up correctly::
 
@@ -484,20 +484,20 @@ Destroying Widgets
 ------------------
 
 If you can display content to your users, you should also be able to erase
-it. This is done via the :func:`~openerp.Widget.destroy` method::
+it. This is done via the :func:`~odoo.Widget.destroy` method::
 
     greeting.destroy();
 
 When a widget is destroyed it will first call
-:func:`~openerp.Widget.destroy` on all its children. Then it erases itself
+:func:`~odoo.Widget.destroy` on all its children. Then it erases itself
 from the DOM. If you have set up permanent structures in
-:func:`~openerp.Widget.init` or :func:`~openerp.Widget.start` which
+:func:`~odoo.Widget.init` or :func:`~odoo.Widget.start` which
 must be explicitly cleaned up (because the garbage collector will not handle
-them), you can override :func:`~openerp.Widget.destroy`.
+them), you can override :func:`~odoo.Widget.destroy`.
 
 .. danger::
 
-    when overriding :func:`~openerp.Widget.destroy`, ``_super()``
+    when overriding :func:`~odoo.Widget.destroy`, ``_super()``
     *must always* be called otherwise the widget and its children are not
     correctly cleaned up leaving possible memory leaks and "phantom events",
     even if no error is displayed
@@ -525,9 +525,9 @@ characteristics:
 
 * It's implemented fully in JavaScript and rendered in the browser
 * Each template file (XML files) contains multiple templates
-* It has special support in Odoo Web's :class:`~openerp.Widget`, though it
+* It has special support in Odoo Web's :class:`~odoo.Widget`, though it
   can be used outside of Odoo's web client (and it's possible to use
-  :class:`~openerp.Widget` without relying on QWeb)
+  :class:`~odoo.Widget` without relying on QWeb)
 
 .. note::
 
@@ -569,9 +569,9 @@ template defined in the XML file::
 :func:`QWeb.render` looks for the specified template, renders it to a string
 and returns the result.
 
-However, because :class:`~openerp.Widget` has special integration for QWeb
+However, because :class:`~odoo.Widget` has special integration for QWeb
 the template can be set directly on the widget via its
-:attr:`~openerp.Widget.template` attribute::
+:attr:`~odoo.Widget.template` attribute::
 
     local.HomePage = instance.Widget.extend({
         template: "HomePageTemplate",
@@ -584,7 +584,7 @@ Although the result looks similar, there are two differences between these
 usages:
 
 * with the second version, the template is rendered right before
-  :func:`~openerp.Widget.start` is called
+  :func:`~odoo.Widget.start` is called
 * in the first version the template's content is added to the widget's root
   element, whereas in the second version the template's root element is
   directly *set as* the widget's root element. Which is why the "greetings"
@@ -593,7 +593,7 @@ usages:
 .. warning::
 
     templates should have a single non-``t`` root element, especially if
-    they're set as a widget's :attr:`~openerp.Widget.template`. If there are
+    they're set as a widget's :attr:`~odoo.Widget.template`. If there are
     multiple "root elements", results are undefined (usually only the first
     root element will be used and the others will be ignored)
 
@@ -621,11 +621,11 @@ will result in:
 
     <div>Hello Klaus</div>
 
-When using :class:`~openerp.Widget`'s integration it is not possible to
+When using :class:`~odoo.Widget`'s integration it is not possible to
 provide additional data to the template. The template will be given a single
 ``widget`` context variable, referencing the widget being rendered right
-before :func:`~openerp.Widget.start` is called (the widget's state will
-essentially be that set up by :func:`~openerp.Widget.init`):
+before :func:`~odoo.Widget.start` is called (the widget's state will
+essentially be that set up by :func:`~odoo.Widget.init`):
 
 .. code-block:: xml
 
@@ -850,7 +850,7 @@ Exercise
 
         ::
 
-            openerp.oepetstore = function(instance, local) {
+            odoo.oepetstore = function(instance, local) {
                 var _t = instance.web._t,
                     _lt = instance.web._lt;
                 var QWeb = instance.web.qweb;
@@ -918,8 +918,8 @@ Selecting DOM elements within a widget can be performed by calling the
 
     this.$el.find("input.my_input")...
 
-But because it's a common operation, :class:`~openerp.Widget` provides an
-equivalent shortcut through the :func:`~openerp.Widget.$` method::
+But because it's a common operation, :class:`~odoo.Widget` provides an
+equivalent shortcut through the :func:`~odoo.Widget.$` method::
 
     local.MyWidget = instance.Widget.extend({
         start: function() {
@@ -963,7 +963,7 @@ While this works it has a few issues:
 3. it requires dealing with ``this``-binding issues
 
 Widgets thus provide a shortcut to DOM event binding via
-:attr:`~openerp.Widget.events`::
+:attr:`~odoo.Widget.events`::
 
     local.MyWidget = instance.Widget.extend({
         events: {
@@ -974,7 +974,7 @@ Widgets thus provide a shortcut to DOM event binding via
         }
     });
 
-:attr:`~openerp.Widget.events` is an object (mapping) of an event to the
+:attr:`~odoo.Widget.events` is an object (mapping) of an event to the
 function or method to call when the event is triggered:
 
 * the key is an event name, possibly refined with a CSS selector in which
@@ -1025,12 +1025,12 @@ This widget acts as a facade, transforming user input (through DOM events)
 into a documentable internal event to which parent widgets can bind
 themselves.
 
-:func:`~openerp.Widget.trigger` takes the name of the event to trigger as
+:func:`~odoo.Widget.trigger` takes the name of the event to trigger as
 its first (mandatory) argument, any further arguments are treated as event
 data and passed directly to listeners.
 
 We can then set up a parent event instantiating our generic widget and
-listening to the ``user_chose`` event using :func:`~openerp.Widget.on`::
+listening to the ``user_chose`` event using :func:`~odoo.Widget.on`::
 
     local.HomePage = instance.Widget.extend({
         start: function() {
@@ -1047,11 +1047,11 @@ listening to the ``user_chose`` event using :func:`~openerp.Widget.on`::
         },
     });
 
-:func:`~openerp.Widget.on` binds a function to be called when the
+:func:`~odoo.Widget.on` binds a function to be called when the
 event identified by ``event_name`` is. The ``func`` argument is the
 function to call and ``object`` is the object to which that function is
 related if it is a method. The bound function will be called with the
-additional arguments of :func:`~openerp.Widget.trigger` if it has
+additional arguments of :func:`~odoo.Widget.trigger` if it has
 any. Example::
 
     start: function() {
@@ -1067,7 +1067,7 @@ any. Example::
 .. note::
 
     Triggering events on an other widget is generally a bad idea. The main
-    exception to that rule is ``openerp.web.bus`` which exists specifically
+    exception to that rule is ``odoo.web.bus`` which exists specifically
     to broadcasts evens in which any widget could be interested throughout
     the Odoo web application.
 
@@ -1087,10 +1087,10 @@ that they trigger events when set::
         console.log("The new value of the property 'name' is", this.widget.get("name"));
     }
 
-* :func:`~openerp.Widget.set` sets the value of a property and triggers
+* :func:`~odoo.Widget.set` sets the value of a property and triggers
   :samp:`change:{propname}` (where *propname* is the property name passed as
-  first parameter to :func:`~openerp.Widget.set`) and ``change``
-* :func:`~openerp.Widget.get` retrieves the value of a property.
+  first parameter to :func:`~odoo.Widget.set`) and ``change``
+* :func:`~odoo.Widget.get` retrieves the value of a property.
 
 Exercise
 --------
@@ -1119,7 +1119,7 @@ Exercise
 
         ::
 
-            openerp.oepetstore = function(instance, local) {
+            odoo.oepetstore = function(instance, local) {
                 var _t = instance.web._t,
                     _lt = instance.web._lt;
                 var QWeb = instance.web.qweb;
@@ -1189,7 +1189,7 @@ Modify existing widgets and classes
 ===================================
 
 The class system of the Odoo web framework allows direct modification of
-existing classes using the :func:`~openerp.web.Class.include` method::
+existing classes using the :func:`~odoo.web.Class.include` method::
 
     var TestClass = instance.web.Class.extend({
         testMethod: function() {
@@ -1212,9 +1212,9 @@ target class in-place instead of creating a new class.
 In that case, ``this._super()`` will call the original implementation of a
 method being replaced/redefined. If the class already had sub-classes, all
 calls to ``this._super()`` in sub-classes will call the new implementations
-defined in the call to :func:`~openerp.web.Class.include`. This will also work
+defined in the call to :func:`~odoo.web.Class.include`. This will also work
 if some instances of the class (or of any of its sub-classes) were created
-prior to the call to :func:`~openerp.Widget.include`.
+prior to the call to :func:`~odoo.Widget.include`.
 
 Translations
 ============
@@ -1235,7 +1235,7 @@ In Odoo, translations files are automatically generated by scanning the source
 code. All piece of code that calls a certain function are detected and their
 content is added to a translation file that will then be sent to the
 translators. In Python, the function is ``_()``. In JavaScript the function is
-:func:`~openerp.web._t` (and also :func:`~openerp.web._lt`).
+:func:`~odoo.web._t` (and also :func:`~odoo.web._lt`).
 
 ``_t()`` will return the translation defined for the text it is given. If no
 translation is defined for that text, it will return the original text as-is.
@@ -1255,7 +1255,7 @@ translation is defined for that text, it will return the original text as-is.
     This makes translatable strings more readable to translators, and gives
     them more flexibility to reorder or ignore parameters.
 
-:func:`~openerp.web._lt` ("lazy translate") is similar but somewhat more
+:func:`~odoo.web._lt` ("lazy translate") is similar but somewhat more
 complex: instead of translating its parameter immediately, it returns
 an object which, when converted to a string, will perform the translation.
 
@@ -1309,11 +1309,11 @@ Here is a sample widget that calls ``my_method()`` and displays the result::
         },
     });
 
-The class used to call Odoo models is :class:`openerp.Model`. It is
+The class used to call Odoo models is :class:`odoo.Model`. It is
 instantiated with the Odoo model's name as first parameter
 (``oepetstore.message_of_the_day`` here).
 
-:func:`~openerp.web.Model.call` can be used to call any (public) method of an
+:func:`~odoo.web.Model.call` can be used to call any (public) method of an
 Odoo model. It takes the following positional arguments:
 
 ``name``
@@ -1349,7 +1349,7 @@ Odoo model. It takes the following positional arguments:
       model.call("my_method", [], {a: 1, b: 2, c: 3, ...
       // with this a=1, b=2 and c=3
 
-:func:`~openerp.Widget.call` returns a deferred resolved with the value
+:func:`~odoo.Widget.call` returns a deferred resolved with the value
 returned by the model's method as first argument.
 
 CompoundContext
@@ -1370,13 +1370,13 @@ is used by people in different countries.
 The ``argument`` is necessary in all methods, otherwise bad things could
 happen (such as the application not being translated correctly). That's why,
 when you call a model's method, you should always provide that argument. The
-solution to achieve that is to use :class:`openerp.web.CompoundContext`.
+solution to achieve that is to use :class:`odoo.web.CompoundContext`.
 
-:class:`~openerp.web.CompoundContext` is a class used to pass the user's
+:class:`~odoo.web.CompoundContext` is a class used to pass the user's
 context (with language, time zone, etc...) to the server as well as adding new
 keys to the context (some models' methods use arbitrary keys added to the
 context). It is created by giving to its constructor any number of
-dictionaries or other :class:`~openerp.web.CompoundContext` instances. It will
+dictionaries or other :class:`~odoo.web.CompoundContext` instances. It will
 merge all those contexts before sending them to the server.
 
 .. code-block:: javascript
@@ -1393,17 +1393,17 @@ merge all those contexts before sending them to the server.
 You can see the dictionary in the argument ``context`` contains some keys that
 are related to the configuration of the current user in Odoo plus the
 ``new_key`` key that was added when instantiating
-:class:`~openerp.web.CompoundContext`.
+:class:`~odoo.web.CompoundContext`.
 
 Queries
 -------
 
-While :func:`~openerp.Model.call` is sufficient for any interaction with Odoo
+While :func:`~odoo.Model.call` is sufficient for any interaction with Odoo
 models, Odoo Web provides a helper for simpler and clearer querying of models
 (fetching of records based on various conditions):
-:func:`~openerp.Model.query` which acts as a shortcut for the common
-combination of :py:meth:`~openerp.models.Model.search` and
-::py:meth:`~openerp.models.Model.read`. It provides a clearer syntax to search
+:func:`~odoo.Model.query` which acts as a shortcut for the common
+combination of :py:meth:`~odoo.models.Model.search` and
+::py:meth:`~odoo.models.Model.read`. It provides a clearer syntax to search
 and read models::
 
     model.query(['name', 'login', 'user_email', 'signature'])
@@ -1423,19 +1423,19 @@ versus::
             // do work with users records
         });
 
-* :func:`~openerp.web.Model.query` takes an optional list of fields as
+* :func:`~odoo.web.Model.query` takes an optional list of fields as
   parameter (if no field is provided, all fields of the model are fetched). It
-  returns a :class:`openerp.web.Query` which can be further customized before
+  returns a :class:`odoo.web.Query` which can be further customized before
   being executed
-* :class:`~openerp.web.Query` represents the query being built. It is
+* :class:`~odoo.web.Query` represents the query being built. It is
   immutable, methods to customize the query actually return a modified copy,
   so it's possible to use the original and the new version side-by-side. See
-  :class:`~openerp.web.Query` for its customization options.
+  :class:`~odoo.web.Query` for its customization options.
 
 When the query is set up as desired, simply call
-:func:`~openerp.web.Query.all` to execute it and return a
+:func:`~odoo.web.Query.all` to execute it and return a
 deferred to its result. The result is the same as
-:py:meth:`~openerp.models.Model.read`'s, an array of dictionaries where each
+:py:meth:`~odoo.models.Model.read`'s, an array of dictionaries where each
 dictionary is a requested record, with each requested field a dictionary key.
 
 Exercises
@@ -1453,7 +1453,7 @@ Exercises
 
         .. code-block:: javascript
 
-            openerp.oepetstore = function(instance, local) {
+            odoo.oepetstore = function(instance, local) {
                 var _t = instance.web._t,
                     _lt = instance.web._lt;
                 var QWeb = instance.web.qweb;
@@ -1531,7 +1531,7 @@ Exercises
 
         .. code-block:: javascript
 
-            openerp.oepetstore = function(instance, local) {
+            odoo.oepetstore = function(instance, local) {
                 var _t = instance.web._t,
                     _lt = instance.web._lt;
                 var QWeb = instance.web.qweb;
@@ -1666,7 +1666,7 @@ The action manager can be invoked explicitly from javascript code by creating
 a dictionary describing :ref:`an action <reference/actions>` of the right
 type, and calling an action manager instance with it.
 
-:func:`~openerp.Widget.do_action` is a shortcut of :class:`~openerp.Widget`
+:func:`~odoo.Widget.do_action` is a shortcut of :class:`~odoo.Widget`
 looking up the "current" action manager and executing the action::
 
     instance.web.TestWidget = instance.Widget.extend({
@@ -1766,9 +1766,9 @@ Our widget is registered as the handler for the client action through this::
     instance.web.client_actions.add('petstore.homepage', 'instance.oepetstore.HomePage');
 
 
-``instance.web.client_actions`` is a :class:`~openerp.web.Registry` in which
+``instance.web.client_actions`` is a :class:`~odoo.web.Registry` in which
 the action manager looks up client action handlers when it needs to execute
-one. The first parameter of :class:`~openerp.web.Registry.add` is the name
+one. The first parameter of :class:`~odoo.web.Registry.add` is the name
 (tag) of the client action, and the second parameter is the path to the widget
 from the Odoo web client root.
 
@@ -1817,7 +1817,7 @@ The Views
 '''''''''
 
 Most :ref:`Odoo views <reference/views>` are implemented through a subclass
-of :class:`openerp.web.View` which provides a bit of generic basic structure
+of :class:`odoo.web.View` which provides a bit of generic basic structure
 for handling events and displaying model information.
 
 The *search view* is considered a view type by the main Odoo framework, but
@@ -1825,17 +1825,17 @@ handled separately by the web client (as it's a more permanent fixture and
 can interact with other views, which regular views don't do).
 
 A view is responsible for loading its own description XML (using
-:py:class:`~openerp.models.Model.fields_view_get`) and any other data source
+:py:class:`~odoo.models.Model.fields_view_get`) and any other data source
 it needs. To that purpose, views are provided with an optional view
-identifier set as the :attr:`~openerp.web.View.view_id` attribute.
+identifier set as the :attr:`~odoo.web.View.view_id` attribute.
 
-Views are also provided with a :class:`~openerp.web.DataSet` instance which
+Views are also provided with a :class:`~odoo.web.DataSet` instance which
 holds most necessary model information (the model name and possibly various
 record ids).
 
 Views may also want to handle search queries by overriding
-:func:`~openerp.web.View.do_search`, and updating their
-:class:`~openerp.web.DataSet` as necessary.
+:func:`~odoo.web.View.do_search`, and updating their
+:class:`~odoo.web.DataSet` as necessary.
 
 The Form View Fields
 --------------------
@@ -1847,7 +1847,7 @@ All built-in fields have a default display implementation, a new
 form widget may be necessary to correctly interact with a new field type
 (e.g. a :term:`GIS` field) or to provide new representations and ways to
 interact with existing field types (e.g. validate
-:py:class:`~openerp.fields.Char` fields which should contain email addresses
+:py:class:`~odoo.fields.Char` fields which should contain email addresses
 and display them as email links).
 
 To explicitly specify which form widget should be used to display a field,
@@ -2150,7 +2150,7 @@ abstract class.
 
 Form widgets can interact with form fields by listening for their changes and
 fetching or altering their values. They can access form fields through
-their :attr:`~openerp.web.form.FormWidget.field_manager` attribute::
+their :attr:`~odoo.web.form.FormWidget.field_manager` attribute::
 
     local.WidgetMultiplication = instance.web.form.FormWidget.extend({
         start: function() {
@@ -2168,14 +2168,14 @@ their :attr:`~openerp.web.form.FormWidget.field_manager` attribute::
 
     instance.web.form.custom_widgets.add('multiplication', 'instance.oepetstore.WidgetMultiplication');
 
-:attr:`~openerp.web.form.FormWidget` is generally the
-:class:`~openerp.web.form.FormView` itself, but features used from it should
-be limited to those defined by :class:`~openerp.web.form.FieldManagerMixin`,
+:attr:`~odoo.web.form.FormWidget` is generally the
+:class:`~odoo.web.form.FormView` itself, but features used from it should
+be limited to those defined by :class:`~odoo.web.form.FieldManagerMixin`,
 the most useful being:
 
-* :func:`~openerp.web.form.FieldManagerMixin.get_field_value(field_name)`
+* :func:`~odoo.web.form.FieldManagerMixin.get_field_value(field_name)`
   which returns the value of a field.
-* :func:`~openerp.web.form.FieldManagerMixin.set_values(values)` sets multiple
+* :func:`~odoo.web.form.FieldManagerMixin.set_values(values)` sets multiple
   field values, takes a mapping of ``{field_name: value_to_set}``
 * An event :samp:`field_changed:{field_name}` is triggered any time the value
   of the field called ``field_name`` is changed
diff --git a/doc/howtos/website.rst b/doc/howtos/website.rst
index 43c3a9a998a..7812ea7ec78 100644
--- a/doc/howtos/website.rst
+++ b/doc/howtos/website.rst
@@ -174,7 +174,7 @@ Accessing the data
 The last step is to alter model and template to use our demonstration data:
 
 #. fetch the records from the database instead of having a static list
-#. Because :meth:`~openerp.models.Model.search` returns a set of records
+#. Because :meth:`~odoo.models.Model.search` returns a set of records
    matching the filter ("all records" here), alter the template to print each
    teacher's ``name``
 
@@ -231,7 +231,7 @@ URLs and routing
 ================
 
 Controller methods are associated with *routes* via the
-:func:`~openerp.http.route` decorator which takes a routing string and a
+:func:`~odoo.http.route` decorator which takes a routing string and a
 number of attributes to customise its behavior or security.
 
 We've seen a "literal" routing string, which matches a URL section exactly,
@@ -384,7 +384,7 @@ let's also add views so we can see and edit a course's teacher:
 
 It should also be possible to create new courses directly from a teacher's
 page, or to see all the courses they teach, so add
-:class:`the inverse relationship <openerp.fields.One2many>` to the *teachers*
+:class:`the inverse relationship <odoo.fields.One2many>` to the *teachers*
 model:
 
 .. patch::
@@ -398,7 +398,7 @@ them by hand.
 
 One of these is the *Chatter* system, part of Odoo's email and messaging
 system, which can add notifications and discussion threads to any model.
-The model simply has to :attr:`~openerp.models.Model._inherit`
+The model simply has to :attr:`~odoo.models.Model._inherit`
 ``mail.thread``, and add the ``message_ids`` field to its form view to display
 the discussion thread. Discussion threads are per-record.
 
@@ -443,8 +443,8 @@ though they may have to be looked for.
 .. note::
 
     * to extend a model in-place, it's :attr:`inherited
-      <openerp.models.Model._inherit>` without giving it a new
-      :attr:`~openerp.models.Model._name`
+      <odoo.models.Model._inherit>` without giving it a new
+      :attr:`~odoo.models.Model._name`
     * ``product.template`` already uses the discussions system, so we can
       remove it from our extension model
     * we're creating our courses as *published* by default so they can be
diff --git a/doc/howtos/website/basic-controller b/doc/howtos/website/basic-controller
index 7b29c58f013..831ecf6fa25 100644
--- a/doc/howtos/website/basic-controller
+++ b/doc/howtos/website/basic-controller
@@ -7,7 +7,7 @@ diff --git a/academy/controllers.py b/academy/controllers.py
 +++ b/academy/controllers.py
 @@ -1,10 +1,10 @@
  # -*- coding: utf-8 -*-
- from openerp import http
+ from odoo import http
  
 -# class Academy(http.Controller):
 -#     @http.route('/academy/academy/', auth='public')
diff --git a/doc/howtos/website/basic-model b/doc/howtos/website/basic-model
index 4086c82b13d..a27d0543bce 100644
--- a/doc/howtos/website/basic-model
+++ b/doc/howtos/website/basic-model
@@ -7,7 +7,7 @@ diff --git a/academy/models.py b/academy/models.py
 +++ b/academy/models.py
 @@ -2,7 +2,7 @@
  
- from openerp import models, fields, api
+ from odoo import models, fields, api
  
 -# class academy(models.Model):
 -#     _name = 'academy.academy'
diff --git a/doc/howtos/website/course-product b/doc/howtos/website/course-product
index b6f9bfedff7..f5b25e36068 100644
--- a/doc/howtos/website/course-product
+++ b/doc/howtos/website/course-product
@@ -18,12 +18,12 @@ new file mode 100644
 --- /dev/null
 +++ b/academy/data.xml
 @@ -0,0 +1,6 @@
-+<openerp><data>
++<odoo><data>
 +  <record model="product.public.category" id="category_courses">
 +    <field name="name">Courses</field>
 +    <field name="parent_id" ref="website_sale.categ_others"/>
 +  </record>
-+</data></openerp>
++</data></odoo>
 diff --git a/academy/demo.xml b/academy/demo.xml
 --- a/academy/demo.xml
 +++ b/academy/demo.xml
@@ -57,7 +57,7 @@ diff --git a/academy/demo.xml b/academy/demo.xml
 +            <field name="type">service</field>
 +        </record>
      </data>
- </openerp>
+ </odoo>
 diff --git a/academy/models.py b/academy/models.py
 --- a/academy/models.py
 +++ b/academy/models.py
diff --git a/doc/howtos/website/data-retrieval-orm b/doc/howtos/website/data-retrieval-orm
index 514777beb14..425ba41b4d0 100644
--- a/doc/howtos/website/data-retrieval-orm
+++ b/doc/howtos/website/data-retrieval-orm
@@ -5,7 +5,7 @@
 diff --git a/academy/controllers.py b/academy/controllers.py
 --- a/academy/controllers.py
 +++ b/academy/controllers.py
-@@ -4,8 +4,9 @@ from openerp import http
+@@ -4,8 +4,9 @@ from odoo import http
  class Academy(http.Controller):
      @http.route('/academy/academy/', auth='public')
      def index(self, **kw):
diff --git a/doc/howtos/website/demo-data b/doc/howtos/website/demo-data
index c8fb7d849ad..18da4bcdf79 100644
--- a/doc/howtos/website/demo-data
+++ b/doc/howtos/website/demo-data
@@ -6,7 +6,7 @@ diff --git a/academy/demo.xml b/academy/demo.xml
 --- a/academy/demo.xml
 +++ b/academy/demo.xml
 @@ -1,25 +1,13 @@
- <openerp>
+ <odoo>
      <data>
 -        <!--  -->
 -        <!--   <record id="object0" model="academy.academy"> -->
@@ -39,4 +39,4 @@ diff --git a/academy/demo.xml b/academy/demo.xml
 +            <field name="name">Lester Vaughn</field>
 +        </record>
      </data>
- </openerp>
+ </odoo>
diff --git a/doc/howtos/website/module-empty b/doc/howtos/website/module-empty
index 8a144e05d09..71d56e6fc71 100644
--- a/doc/howtos/website/module-empty
+++ b/doc/howtos/website/module-empty
@@ -21,7 +21,7 @@ new file mode 100644
 +
 +    'summary': """
 +        Short (1 phrase/line) summary of the module's purpose, used as
-+        subtitle on modules listing or apps.openerp.com""",
++        subtitle on modules listing or apps.odoo.com""",
 +
 +    'description': """
 +        Long description of module's purpose
@@ -31,7 +31,7 @@ new file mode 100644
 +    'website': "http://www.yourcompany.com",
 +
 +    # Categories can be used to filter modules in modules listing
-+    # Check https://github.com/odoo/odoo/blob/master/openerp/addons/base/module/module_data.xml
++    # Check https://github.com/odoo/odoo/blob/master/odoo/addons/base/module/module_data.xml
 +    # for the full list
 +    'category': 'Uncategorized',
 +    'version': '0.1',
@@ -55,7 +55,7 @@ new file mode 100644
 +++ b/academy/controllers.py
 @@ -0,0 +1,20 @@
 +# -*- coding: utf-8 -*-
-+from openerp import http
++from odoo import http
 +
 +# class Academy(http.Controller):
 +#     @http.route('/academy/academy/', auth='public')
@@ -79,7 +79,7 @@ new file mode 100644
 --- /dev/null
 +++ b/academy/demo.xml
 @@ -0,0 +1,25 @@
-+<openerp>
++<odoo>
 +    <data>
 +        <!--  -->
 +        <!--   <record id="object0" model="academy.academy"> -->
@@ -103,7 +103,7 @@ new file mode 100644
 +        <!--   </record> -->
 +        <!--  -->
 +    </data>
-+</openerp>
++</odoo>
 diff --git a/academy/models.py b/academy/models.py
 new file mode 100644
 --- /dev/null
@@ -111,7 +111,7 @@ new file mode 100644
 @@ -0,0 +1,8 @@
 +# -*- coding: utf-8 -*-
 +
-+from openerp import models, fields, api
++from odoo import models, fields, api
 +
 +# class academy(models.Model):
 +#     _name = 'academy.academy'
@@ -129,7 +129,7 @@ new file mode 100644
 --- /dev/null
 +++ b/academy/templates.xml
 @@ -0,0 +1,22 @@
-+<openerp>
++<odoo>
 +    <data>
 +        <!-- <template id="listing"> -->
 +        <!--   <ul> -->
@@ -150,4 +150,4 @@ new file mode 100644
 +        <!--   </dl> -->
 +        <!-- </template> -->
 +    </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/website/teachers-menu b/doc/howtos/website/teachers-menu
index 27fd53b09aa..f5db4a0fd0e 100644
--- a/doc/howtos/website/teachers-menu
+++ b/doc/howtos/website/teachers-menu
@@ -18,7 +18,7 @@ new file mode 100644
 --- /dev/null
 +++ b/academy/views.xml
 @@ -0,0 +1,13 @@
-+<openerp>
++<odoo>
 + <data>
 +  <record id="action_academy_teachers" model="ir.actions.act_window">
 +    <field name="name">Academy teachers</field>
@@ -32,4 +32,4 @@ new file mode 100644
 +            parent="menu_academy_content"
 +            action="action_academy_teachers"/>
 + </data>
-+</openerp>
++</odoo>
diff --git a/doc/howtos/website/template b/doc/howtos/website/template
index 1647c16c1ba..541e39513fe 100644
--- a/doc/howtos/website/template
+++ b/doc/howtos/website/template
@@ -5,7 +5,7 @@
 diff --git a/academy/controllers.py b/academy/controllers.py
 --- a/academy/controllers.py
 +++ b/academy/controllers.py
-@@ -4,7 +4,9 @@ from openerp import http
+@@ -4,7 +4,9 @@ from odoo import http
  class Academy(http.Controller):
      @http.route('/academy/academy/', auth='public')
      def index(self, **kw):
@@ -20,7 +20,7 @@ diff --git a/academy/templates.xml b/academy/templates.xml
 --- a/academy/templates.xml
 +++ b/academy/templates.xml
 @@ -1,14 +1,11 @@
- <openerp>
+ <odoo>
      <data>
 -        <!-- <template id="listing"> -->
 -        <!--   <ul> -->
diff --git a/doc/howtos/website/website-support b/doc/howtos/website/website-support
index c3deb4f6896..49b2d7e88d7 100644
--- a/doc/howtos/website/website-support
+++ b/doc/howtos/website/website-support
@@ -18,7 +18,7 @@ diff --git a/academy/controllers.py b/academy/controllers.py
 --- a/academy/controllers.py
 +++ b/academy/controllers.py
 @@ -2,7 +2,7 @@
- from openerp import http
+ from odoo import http
  
  class Academy(http.Controller):
 -    @http.route('/academy/academy/', auth='public')
@@ -30,7 +30,7 @@ diff --git a/academy/templates.xml b/academy/templates.xml
 --- a/academy/templates.xml
 +++ b/academy/templates.xml
 @@ -1,9 +1,15 @@
- <openerp>
+ <odoo>
      <data>
          <template id="index">
 -            <title>Academy</title>
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``
diff --git a/doc/setup/deploy.rst b/doc/setup/deploy.rst
index 5b906bfcd7a..1efd6157dd8 100644
--- a/doc/setup/deploy.rst
+++ b/doc/setup/deploy.rst
@@ -312,9 +312,9 @@ Odoo as a WSGI Application
 ==========================
 
 It is also possible to mount Odoo as a standard WSGI_ application. Odoo
-provides the base for a WSGI launcher script as ``openerp-wsgi.py``. That
+provides the base for a WSGI launcher script as ``odoo-wsgi.py``. That
 script should be customized (possibly after copying it) to correctly set the
-configuration directly in :mod:`openerp.tools.config` rather than through the
+configuration directly in :mod:`odoo.tools.config` rather than through the
 command-line or a configuration file.
 
 However the WSGI server will only expose the main HTTP endpoint for the web
@@ -353,7 +353,7 @@ The solutions to support livechat/motifications in a WSGI application are:
   one) and redirect only requests to URLs starting with ``/longpolling/`` to
   that Odoo, this is the simplest and the longpolling URL can double up as
   the cron instance.
-* deploy an evented Odoo via ``openerp-gevent`` and proxy requests starting
+* deploy an evented Odoo via ``odoo-gevent`` and proxy requests starting
   with ``/longpolling/`` to
   :option:`the longpolling port <odoo.py --longpolling-port>`.