pengyuthon/odoo_source
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[FIX] doc: building correctly autoclass references

Browse Source
This commit is contained in:
Martin Trigaux
2016-10-11 12:09:27 +02:00
parent acaf0f1e19
commit 9528024536
50 changed files with 525 additions and 525 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/api_integration.rst
+30 -30
View File
@@ -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
doc/howtos/backend.rst
+47 -47
View File
@@ -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.
doc/howtos/backend/exercise-access-rights
+2 -2
View File
@@ -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>
doc/howtos/backend/exercise-access-rules
+1 -1
View File
@@ -24,4 +24,4 @@ Index: addons/openacademy/security/security.xml
+ </field>
+ </record>
</data>
</openerp>
</odoo>
doc/howtos/backend/exercise-basic-action
+2 -2
View File
@@ -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>
doc/howtos/backend/exercise-calendar
+1 -1
View File
@@ -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):
doc/howtos/backend/exercise-constraint-python
+2 -2
View File
@@ -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'
doc/howtos/backend/exercise-creation
+7 -7
View File
@@ -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>
doc/howtos/backend/exercise-dashboard
+2 -2
View File
@@ -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>
doc/howtos/backend/exercise-demo
+2 -2
View File
@@ -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>
doc/howtos/backend/exercise-domain-advanced
+1 -1
View File
@@ -40,4 +40,4 @@ Index: addons/openacademy/views/partner.xml
+ <field name="name">Teacher / Level 2</field>
+ </record>
</data>
</openerp>
</odoo>
doc/howtos/backend/exercise-formview
+1 -1
View File
@@ -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>
doc/howtos/backend/exercise-model
+1 -1
View File
@@ -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'
doc/howtos/backend/exercise-model-inheritance
+3 -3
View File
@@ -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>
doc/howtos/backend/exercise-report
+2 -2
View File
@@ -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>
doc/howtos/backend/exercise-session
+1 -1
View File
@@ -55,4 +55,4 @@ Index: addons/openacademy/views/openacademy.xml
+ parent="openacademy_menu"
+ action="session_list_action"/>
</data>
</openerp>
</odoo>
doc/howtos/backend/exercise-state-workflow
+2 -2
View File
@@ -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>
doc/howtos/backend/exercise-state-workflow-automatic
+1 -1
View File
@@ -16,4 +16,4 @@ Index: addons/openacademy/views/session_workflow.xml
+ <field name="condition">taken_seats &gt; 50</field>
+ </record>
</data>
</openerp>
</odoo>
doc/howtos/backend/exercise-translations
+2 -2
View File
@@ -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'
doc/howtos/backend/exercise-wizard
+1 -1
View File
@@ -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'
doc/howtos/backend/exercise-wizard-launch
+1 -1
View File
@@ -43,4 +43,4 @@ Index: addons/openacademy/views/openacademy.xml
+ target="new"
+ key2="client_action_multi"/>
</data>
</openerp>
</odoo>
doc/howtos/themes.rst
+14 -14
View File
@@ -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() {
doc/howtos/web.rst
+92 -92
View File
@@ -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
doc/howtos/website.rst
+6 -6
View File
@@ -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
doc/howtos/website/basic-controller
+1 -1
View File
@@ -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')
doc/howtos/website/basic-model
+1 -1
View File
@@ -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'
doc/howtos/website/course-product
+3 -3
View File
@@ -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
doc/howtos/website/data-retrieval-orm
+1 -1
View File
@@ -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):
doc/howtos/website/demo-data
+2 -2
View File
@@ -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>
doc/howtos/website/module-empty
+8 -8
View File
@@ -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>
doc/howtos/website/teachers-menu
+2 -2
View File
@@ -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>
doc/howtos/website/template
+2 -2
View File
@@ -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> -->
doc/howtos/website/website-support
+2 -2
View File
@@ -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>
doc/reference/actions.rst
+8 -8
View File
@@ -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
doc/reference/cmdline.rst
+10 -10
View File
@@ -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``
doc/reference/data.rst
+5 -5
View File
@@ -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
doc/reference/guidelines.rst
+1 -1
View File
@@ -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*/
});
doc/reference/http.rst
+11 -11
View File
@@ -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
doc/reference/javascript.rst
+55 -55
View File
@@ -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
doc/reference/mixins.rst
+24 -24
View File
@@ -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
doc/reference/module.rst
+1 -1
View File
@@ -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
doc/reference/orm.rst
+121 -121
View File
@@ -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"
doc/reference/qweb.rst
+4 -4
View File
@@ -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
doc/reference/reports.rst
+2 -2
View File
@@ -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'
doc/reference/security.rst
+2 -2
View File
@@ -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
doc/reference/test-report.txt
+9 -9
View File
@@ -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
doc/reference/testing.rst
+5 -5
View File
@@ -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):
doc/reference/translations.rst
+5 -5
View File
@@ -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
doc/reference/views.rst
+13 -13
View File
@@ -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``
doc/setup/deploy.rst
+3 -3
View File
@@ -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>`.