diff options
| author | Martin Trigaux <mat@odoo.com> | 2016-10-11 11:11:52 +0200 |
|---|---|---|
| committer | Martin Trigaux <mat@odoo.com> | 2016-10-11 12:09:27 +0200 |
| commit | 95280245367da42fead8be9892079a5795171fd0 (patch) | |
| tree | 072b5191d1ee1e30e8b5fa1cf23f8e5353a3c06e | |
| parent | acaf0f1e190326775e5bcd93daf4146e320e27e5 (diff) | |
[FIX] doc: building correctly autoclass references
50 files changed, 525 insertions, 525 deletions
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 > 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>`. |