[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
|
|
|
.. _reference/data:
|
|
|
|
|
|
|
|
==========
|
|
|
|
Data Files
|
|
|
|
==========
|
|
|
|
|
|
|
|
Odoo is greatly data-driven, and a big part of modules definition is thus
|
|
|
|
the definition of the various records it manages: UI (menus and views),
|
2021-12-15 18:43:42 +07:00
|
|
|
security (access rights and record rules), reports and plain data are all
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
defined via records.
|
|
|
|
|
|
|
|
Structure
|
|
|
|
=========
|
|
|
|
|
|
|
|
The main way to define data in Odoo is via XML data files: The broad structure
|
|
|
|
of an XML data file is the following:
|
|
|
|
|
|
|
|
* Any number of operation elements within the root element ``odoo``
|
|
|
|
|
|
|
|
.. code-block:: xml
|
|
|
|
|
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
2022-11-21 23:29:59 +07:00
|
|
|
<!-- the root elements of the data file -->
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
<odoo>
|
2022-11-21 23:29:59 +07:00
|
|
|
<operation/>
|
|
|
|
...
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
</odoo>
|
|
|
|
|
|
|
|
Data files are executed sequentially, operations can only refer to the result
|
|
|
|
of operations defined previously
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
If the content of the data file is expected to be applied only once, you
|
|
|
|
can specify the odoo flag ``noupdate`` set to 1. If part of
|
|
|
|
the data in the file is expected to be applied once, you can place this part
|
|
|
|
of the file in a <data noupdate="1"> domain.
|
|
|
|
|
|
|
|
.. code-block:: xml
|
|
|
|
|
2022-11-21 23:29:59 +07:00
|
|
|
<odoo>
|
|
|
|
<data noupdate="1">
|
|
|
|
<!-- Only loaded when installing the module (odoo-bin -i module) -->
|
|
|
|
<operation/>
|
|
|
|
</data>
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
2022-11-21 23:29:59 +07:00
|
|
|
<!-- (Re)Loaded at install and update (odoo-bin -i/-u) -->
|
|
|
|
<operation/>
|
|
|
|
</odoo>
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
|
|
|
Core operations
|
|
|
|
===============
|
|
|
|
|
|
|
|
.. _reference/data/record:
|
|
|
|
|
|
|
|
``record``
|
|
|
|
----------
|
|
|
|
|
|
|
|
``record`` appropriately defines or updates a database record, it has the
|
|
|
|
following attributes:
|
|
|
|
|
|
|
|
``model`` (required)
|
|
|
|
name of the model to create (or update)
|
|
|
|
``id``
|
|
|
|
the :term:`external identifier` for this record. It is strongly
|
|
|
|
recommended to provide one
|
|
|
|
|
|
|
|
* for record creation, allows subsequent definitions to either modify or
|
|
|
|
refer to this record
|
|
|
|
* for record modification, the record to modify
|
|
|
|
``context``
|
|
|
|
context to use when creating the record
|
|
|
|
``forcecreate``
|
|
|
|
in update mode whether the record should be created if it doesn't exist
|
|
|
|
|
|
|
|
Requires an :term:`external id`, defaults to ``True``.
|
|
|
|
|
|
|
|
``field``
|
2023-02-13 22:50:13 +07:00
|
|
|
---------
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
|
|
|
Each record can be composed of ``field`` tags, defining values to set when
|
|
|
|
creating the record. A ``record`` with no ``field`` will use all default
|
|
|
|
values (creation) or do nothing (update).
|
|
|
|
|
|
|
|
A ``field`` has a mandatory ``name`` attribute, the name of the field to set,
|
|
|
|
and various methods to define the value itself:
|
|
|
|
|
|
|
|
Nothing
|
|
|
|
if no value is provided for the field, an implicit ``False`` will be set
|
|
|
|
on the field. Can be used to clear a field, or avoid using a default value
|
|
|
|
for the field.
|
|
|
|
``search``
|
2021-05-04 21:31:06 +07:00
|
|
|
for :ref:`relational fields <reference/fields/relational>`, should be
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
a :ref:`domain <reference/orm/domains>` on the field's model.
|
|
|
|
|
|
|
|
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:`~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:`~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
|
|
|
|
external file using the ``file`` attribute, or through the node's body.
|
|
|
|
|
|
|
|
Available types are:
|
|
|
|
|
|
|
|
``xml``, ``html``
|
|
|
|
extracts the ``field``'s children as a single document, evaluates
|
|
|
|
any :term:`external id` specified with the form ``%(external_id)s``.
|
|
|
|
``%%`` can be used to output actual *%* signs.
|
|
|
|
``file``
|
|
|
|
ensures that the field content is a valid file path in the current
|
|
|
|
model, saves the pair :samp:`{module},{path}` as the field value
|
|
|
|
``char``
|
|
|
|
sets the field content directly as the field's value without
|
|
|
|
alterations
|
|
|
|
``base64``
|
|
|
|
base64_-encodes the field's content, useful combined with the ``file``
|
|
|
|
*attribute* to load e.g. image data into attachments
|
|
|
|
``int``
|
|
|
|
converts the field's content to an integer and sets it as the field's
|
|
|
|
value
|
|
|
|
``float``
|
|
|
|
converts the field's content to a float and sets it as the field's
|
|
|
|
value
|
|
|
|
``list``, ``tuple``
|
|
|
|
should contain any number of ``value`` elements with the same
|
|
|
|
properties as ``field``, each element resolves to an item of a
|
|
|
|
generated tuple or list, and the generated collection is set as the
|
|
|
|
field's value
|
|
|
|
``eval``
|
|
|
|
for cases where the previous methods are unsuitable, the ``eval``
|
|
|
|
attributes simply evaluates whatever Python expression it is provided and
|
|
|
|
sets the result as the field's value.
|
|
|
|
|
|
|
|
The evaluation context contains various modules (``time``, ``datetime``,
|
|
|
|
``timedelta``, ``relativedelta``), a function to resolve :term:`external
|
|
|
|
identifiers` (``ref``) and the model object for the current field if
|
|
|
|
applicable (``obj``)
|
|
|
|
|
|
|
|
``delete``
|
|
|
|
----------
|
|
|
|
|
|
|
|
The ``delete`` tag can remove any number of records previously defined. It
|
|
|
|
has the following attributes:
|
|
|
|
|
|
|
|
``model`` (required)
|
|
|
|
the model in which a specified record should be deleted
|
|
|
|
``id``
|
|
|
|
the :term:`external id` of a record to remove
|
|
|
|
``search``
|
|
|
|
a :ref:`domain <reference/orm/domains>` to find records of the model to
|
|
|
|
remove
|
|
|
|
|
|
|
|
``id`` and ``search`` are exclusive
|
|
|
|
|
|
|
|
``function``
|
|
|
|
------------
|
|
|
|
|
|
|
|
The ``function`` tag calls a method on a model, with provided parameters.
|
|
|
|
It has two mandatory parameters ``model`` and ``name`` specifying respectively
|
|
|
|
the model and the name of the method to call.
|
|
|
|
|
|
|
|
Parameters can be provided using ``eval`` (should evaluate to a sequence of
|
|
|
|
parameters to call the method with) or ``value`` elements (see ``list``
|
|
|
|
values).
|
|
|
|
|
|
|
|
.. code-block:: xml
|
|
|
|
|
2022-11-21 23:29:59 +07:00
|
|
|
<odoo>
|
|
|
|
<data noupdate="1">
|
2024-08-05 19:47:34 +07:00
|
|
|
<record id="partner_1" model="res.partner">
|
2022-11-21 23:29:59 +07:00
|
|
|
<field name="name">Odude</field>
|
|
|
|
</record>
|
|
|
|
|
|
|
|
<function model="res.partner" name="send_inscription_notice"
|
|
|
|
eval="[[ref('partner_1'), ref('partner_2')]]"/>
|
|
|
|
|
|
|
|
<function model="res.users" name="send_vip_inscription_notice">
|
|
|
|
<function eval="[[('vip','=',True)]]" model="res.partner" name="search"/>
|
|
|
|
</function>
|
|
|
|
</data>
|
|
|
|
|
|
|
|
<record id="model_form_view" model="ir.ui.view">
|
|
|
|
...
|
|
|
|
</record>
|
|
|
|
</odoo>
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
|
|
|
.. ignored assert
|
|
|
|
|
|
|
|
.. _reference/data/shortcuts:
|
|
|
|
|
|
|
|
Shortcuts
|
|
|
|
=========
|
|
|
|
|
|
|
|
Because some important structural models of Odoo are complex and involved,
|
|
|
|
data files provide shorter alternatives to defining them using
|
|
|
|
:ref:`record tags <reference/data/record>`:
|
|
|
|
|
|
|
|
``menuitem``
|
|
|
|
------------
|
|
|
|
|
|
|
|
Defines an ``ir.ui.menu`` record with a number of defaults and fallbacks:
|
|
|
|
|
|
|
|
``parent``
|
|
|
|
* If a ``parent`` attribute is set, it should be the :term:`external id`
|
|
|
|
of an other menu item, used as the new item's parent
|
|
|
|
* If no ``parent`` is provided, tries to interpret the ``name`` attribute
|
|
|
|
as a ``/``-separated sequence of menu names and find a place in the menu
|
|
|
|
hierarchy. In that interpretation, intermediate menus are automatically
|
|
|
|
created
|
|
|
|
* Otherwise the menu is defined as a "top-level" menu item (*not* a menu
|
|
|
|
with no parent)
|
|
|
|
``name``
|
|
|
|
If no ``name`` attribute is specified, tries to get the menu name from
|
|
|
|
a linked action if any. Otherwise uses the record's ``id``
|
|
|
|
``groups``
|
|
|
|
A ``groups`` attribute is interpreted as a comma-separated sequence of
|
|
|
|
:term:`external identifiers` for ``res.groups`` models. If an
|
|
|
|
:term:`external identifier` is prefixed with a minus (``-``), the group
|
|
|
|
is *removed* from the menu's groups
|
|
|
|
``action``
|
|
|
|
if specified, the ``action`` attribute should be the :term:`external id`
|
|
|
|
of an action to execute when the menu is open
|
|
|
|
``id``
|
|
|
|
the menu item's :term:`external id`
|
|
|
|
|
|
|
|
.. _reference/data/template:
|
|
|
|
|
|
|
|
``template``
|
|
|
|
------------
|
|
|
|
|
|
|
|
Creates a :ref:`QWeb view <reference/views/qweb>` requiring only the ``arch``
|
|
|
|
section of the view, and allowing a few *optional* attributes:
|
|
|
|
|
|
|
|
``id``
|
|
|
|
the view's :term:`external identifier`
|
|
|
|
``name``, ``inherit_id``, ``priority``
|
|
|
|
same as the corresponding field on ``ir.ui.view`` (nb: ``inherit_id``
|
|
|
|
should be an :term:`external identifier`)
|
|
|
|
``primary``
|
|
|
|
if set to ``True`` and combined with a ``inherit_id``, defines the view
|
|
|
|
as a primary
|
|
|
|
``groups``
|
|
|
|
comma-separated list of group :term:`external identifiers`
|
|
|
|
``page``
|
|
|
|
if set to ``"True"``, the template is a website page (linkable to,
|
|
|
|
deletable)
|
|
|
|
``optional``
|
|
|
|
``enabled`` or ``disabled``, whether the view can be disabled (in the
|
|
|
|
website interface) and its default status. If unset, the view is always
|
|
|
|
enabled.
|
|
|
|
|
2021-05-11 17:57:39 +07:00
|
|
|
.. _reference/data/csvdatafiles:
|
|
|
|
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
CSV data files
|
|
|
|
==============
|
|
|
|
|
|
|
|
XML data files are flexible and self-descriptive, but very verbose when
|
|
|
|
creating a number of simple records of the same model in bulk.
|
|
|
|
|
|
|
|
For this case, data files can also use csv_, this is often the case for
|
|
|
|
:ref:`access rights <reference/security/acl>`:
|
|
|
|
|
|
|
|
* the file name is :file:`{model_name}.csv`
|
|
|
|
* the first row lists the fields to write, with the special field ``id``
|
|
|
|
for :term:`external identifiers` (used for creation or update)
|
|
|
|
* each row thereafter creates a new record
|
|
|
|
|
2021-06-02 16:35:14 +07:00
|
|
|
Here's the first lines of the data file defining country states
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
``res.country.state.csv``
|
|
|
|
|
[MOV] content/*: move resource files into their related page's directory
Since odoo/documentation#903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.
For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:
├── parent_doc/
│ └── doc1/
│ │ └── image.png
│ │ └── download.zip
│ └── doc1.rst
│ └── doc2.rst
├── parent_doc.rst
Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.
In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.
task-2497965
Part-of: odoo/documentation#2068
2022-05-20 16:54:32 +07:00
|
|
|
.. literalinclude:: data/res.country.state.csv
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
:language: text
|
|
|
|
|
|
|
|
rendered in a more readable format:
|
|
|
|
|
|
|
|
.. csv-table::
|
[MOV] content/*: move resource files into their related page's directory
Since odoo/documentation#903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.
For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:
├── parent_doc/
│ └── doc1/
│ │ └── image.png
│ │ └── download.zip
│ └── doc1.rst
│ └── doc2.rst
├── parent_doc.rst
Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.
In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.
task-2497965
Part-of: odoo/documentation#2068
2022-05-20 16:54:32 +07:00
|
|
|
:file: data/res.country.state.csv
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
:header-rows: 1
|
|
|
|
:class: table-striped table-hover table-sm
|
|
|
|
|
|
|
|
For each row (record):
|
|
|
|
|
|
|
|
* the first column is the :term:`external id` of the record to create or
|
|
|
|
update
|
|
|
|
* the second column is the :term:`external id` of the country object to link
|
|
|
|
to (country objects must have been defined beforehand)
|
|
|
|
* the third column is the ``name`` field for ``res.country.state``
|
|
|
|
* the fourth column is the ``code`` field for ``res.country.state``
|
|
|
|
|
|
|
|
.. _base64: https://tools.ietf.org/html/rfc3548.html#section-3
|
|
|
|
.. _csv: https://en.wikipedia.org/wiki/Comma-separated_values
|