msgid "string identifier stored in ``ir.model.data``, can be used to refer to a record regardless of its database identifier during data imports or export/import roundtrips."
msgstr ""
#: ../../content/developer/glossary.rst:16
msgid "External identifiers are in the form :samp:`{module}.{id}` (e.g. ``account.invoice_graph``). From within a module, the :samp:`{module}.` prefix can be left out."
msgstr ""
#: ../../content/developer/glossary.rst:20
msgid "Sometimes referred to as \"xml id\" or ``xml_id`` as XML-based :ref:`reference/data` make extensive use of them."
msgstr ""
#: ../../content/developer/glossary.rst:22
msgid "format string"
msgstr ""
#: ../../content/developer/glossary.rst:24
msgid "inspired by `jinja variables`_, format strings allow more easily mixing literal content and computed content (expressions): content between ``{{`` and ``}}`` is interpreted as an expression and evaluated, other content is interpreted as literal strings and displayed as-is"
msgstr ""
#: ../../content/developer/glossary.rst:29
msgid "GIS"
msgstr ""
#: ../../content/developer/glossary.rst:30
msgid "Geographic Information System"
msgstr ""
#: ../../content/developer/glossary.rst:32
msgid "any computer system or subsystem to capture, store, manipulate, analyze, manage or present spatial and geographical data."
msgstr ""
#: ../../content/developer/glossary.rst:34
msgid "minified"
msgstr ""
#: ../../content/developer/glossary.rst:35
msgid "minification"
msgstr ""
#: ../../content/developer/glossary.rst:37
msgid "process of removing extraneous/non-necessary sections of files (comments, whitespace) and possibly recompiling them using equivalent but shorter structures (`ternary operator`_ instead of ``if/else``) in order to reduce network traffic"
msgid "Odoo uses a client/server architecture in which clients are web browsers accessing the Odoo server via RPC."
msgstr ""
#: ../../content/developer/howtos/backend.rst:19
msgid "Business logic and extension is generally performed on the server side, although supporting client features (e.g. new data representation such as interactive maps) can be added to the client."
msgstr ""
#: ../../content/developer/howtos/backend.rst:23
msgid "In order to start the server, simply invoke the command :ref:`odoo-bin <reference/cmdline>` in the shell, adding the full path to the file if necessary:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:31
msgid "The server is stopped by hitting ``Ctrl-C`` twice from the terminal, or by killing the corresponding OS process."
msgstr ""
#: ../../content/developer/howtos/backend.rst:35
msgid "Build an Odoo module"
msgstr ""
#: ../../content/developer/howtos/backend.rst:37
msgid "Both server and client extensions are packaged as *modules* which are optionally loaded in a *database*."
msgstr ""
#: ../../content/developer/howtos/backend.rst:40
msgid "Odoo modules can either add brand new business logic to an Odoo system, or alter and extend existing business logic: a module can be created to add your country's accounting rules to Odoo's generic accounting support, while the next module adds support for real-time visualisation of a bus fleet."
msgstr ""
#: ../../content/developer/howtos/backend.rst:45
msgid "Everything in Odoo thus starts and ends with modules."
msgid "Each module is a directory within a *module directory*. Module directories are specified by using the :option:`--addons-path <odoo-bin --addons-path>` option."
msgstr ""
#: ../../content/developer/howtos/backend.rst:83
msgid "most command-line options can also be set using :ref:`a configuration file <reference/cmdline/config>`"
msgid "An Odoo module is declared by its :ref:`manifest <reference/module/manifest>`."
msgstr ""
#: ../../content/developer/howtos/backend.rst:88
msgid "A module is also a `Python package <http://docs.python.org/2/tutorial/modules.html#packages>`_ with a ``__init__.py`` file, containing import instructions for various Python files in the module."
msgstr ""
#: ../../content/developer/howtos/backend.rst:93
msgid "For instance, if the module has a single ``mymodule.py`` file ``__init__.py`` might contain::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:98
msgid "Odoo provides a mechanism to help set up a new module, :ref:`odoo-bin <reference/cmdline/server>` has a subcommand :ref:`scaffold <reference/cmdline/scaffold>` to create an empty module:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:106
msgid "The command creates a subdirectory for your module, and automatically creates a bunch of standard files for a module. Most of them simply contain commented code or XML. The usage of most of those files will be explained along this tutorial."
msgstr ""
#: ../../content/developer/howtos/backend.rst:110
msgid "Module creation"
msgstr ""
#: ../../content/developer/howtos/backend.rst:112
msgid "Use the command line above to create an empty module Open Academy, and install it in Odoo."
msgid "A key component of Odoo is the :abbr:`ORM (Object-Relational Mapping)` layer. This layer avoids having to write most :abbr:`SQL (Structured Query Language)` by hand and provides extensibility and security services\\ [#rawsql]_."
msgstr ""
#: ../../content/developer/howtos/backend.rst:122
msgid "Business objects are declared as Python classes extending :class:`~odoo.models.Model` which integrates them into the automated persistence system."
msgstr ""
#: ../../content/developer/howtos/backend.rst:126
msgid "Models can be configured by setting a number of attributes at their definition. The most important attribute is :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::"
msgid "Requests that Odoo create a `database index`_ on the column."
msgstr ""
#: ../../content/developer/howtos/backend.rst:170
msgid "Simple fields"
msgstr ""
#: ../../content/developer/howtos/backend.rst:172
msgid "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)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:176
msgid "Example of simple fields are :class:`~odoo.fields.Boolean`, :class:`~odoo.fields.Date`, :class:`~odoo.fields.Char`."
msgstr ""
#: ../../content/developer/howtos/backend.rst:180
msgid "Reserved fields"
msgstr ""
#: ../../content/developer/howtos/backend.rst:182
msgid "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:"
msgid "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:`~odoo.models.Model._rec_name`."
msgstr ""
#: ../../content/developer/howtos/backend.rst:204
msgid "Define a model"
msgstr ""
#: ../../content/developer/howtos/backend.rst:206
msgid "Define a new data model *Course* in the *openacademy* module. A course has a title and a description. Courses must have a title."
msgstr ""
#: ../../content/developer/howtos/backend.rst:210
msgid "Data files"
msgstr ""
#: ../../content/developer/howtos/backend.rst:212
msgid "Odoo is a highly data driven system. Although behavior is customized using Python_ code part of a module's value is in the data it sets up when loaded."
msgstr ""
#: ../../content/developer/howtos/backend.rst:215
msgid "some modules exist solely to add data into Odoo"
msgstr ""
#: ../../content/developer/howtos/backend.rst:218
msgid "Module data is declared via :ref:`data files <reference/data>`, XML files with ``<record>`` elements. Each ``<record>`` element creates or updates a database record."
msgstr ""
#: ../../content/developer/howtos/backend.rst:232
msgid "``model`` is the name of the Odoo model for the record."
msgstr ""
#: ../../content/developer/howtos/backend.rst:233
msgid "``id`` is an :term:`external identifier`, it allows referring to the record (without having to know its in-database identifier)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:235
msgid "``<field>`` elements have a ``name`` which is the name of the field in the model (e.g. ``description``). Their body is the field's value."
msgstr ""
#: ../../content/developer/howtos/backend.rst:238
msgid "Data files have to be declared in the manifest file to be loaded, they can be declared in the ``'data'`` list (always loaded) or in the ``'demo'`` list (only loaded in demonstration mode)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:242
msgid "Define demonstration data"
msgstr ""
#: ../../content/developer/howtos/backend.rst:244
msgid "Create demonstration data filling the *Courses* model with a few demonstration courses."
msgstr ""
#: ../../content/developer/howtos/backend.rst:247
msgid "The content of the data files is only loaded when a module is installed or updated."
msgstr ""
#: ../../content/developer/howtos/backend.rst:250
msgid "After making some changes, do not forget to use :ref:`odoo-bin -u openacademy <reference/cmdline>` to save the changes to your database."
msgstr ""
#: ../../content/developer/howtos/backend.rst:257
msgid "Actions and Menus"
msgstr ""
#: ../../content/developer/howtos/backend.rst:259
msgid "Actions and menus are regular records in database, usually declared through data files. Actions can be triggered in three ways:"
msgid "Because menus are somewhat complex to declare there is a ``<menuitem>`` shortcut to declare an ``ir.ui.menu`` and connect it to the corresponding action more easily."
msgstr ""
#: ../../content/developer/howtos/backend.rst:283
msgid "The action must be declared before its corresponding menu in the XML file."
msgstr ""
#: ../../content/developer/howtos/backend.rst:285
msgid "Data files are executed sequentially, the action's ``id`` must be present in the database before the menu can be created."
msgstr ""
#: ../../content/developer/howtos/backend.rst:288
msgid "Define new menu entries"
msgstr ""
#: ../../content/developer/howtos/backend.rst:290
msgid "Define new menu entries to access courses under the OpenAcademy menu entry. A user should be able to :"
msgstr ""
#: ../../content/developer/howtos/backend.rst:293
msgid "display a list of all the courses"
msgstr ""
#: ../../content/developer/howtos/backend.rst:294
msgid "create/modify courses"
msgstr ""
#: ../../content/developer/howtos/backend.rst:297
msgid "Basic views"
msgstr ""
#: ../../content/developer/howtos/backend.rst:299
msgid "Views define the way the records of a model are displayed. Each type of view represents a mode of visualization (a list of records, a graph of their aggregation, …). Views can either be requested generically via their type (e.g. *a list of partners*) or specifically via their id. For generic requests, the view with the correct type and the lowest priority will be used (so the lowest-priority view of each type is the default view for that type)."
msgid "A view is declared as a record of the model ``ir.ui.view``. The view type is implied by the root element of the ``arch`` field:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:327
msgid "The view's content is XML."
msgstr ""
#: ../../content/developer/howtos/backend.rst:330
msgid "The ``arch`` field must thus be declared as ``type=\"xml\"`` to be parsed correctly."
msgstr ""
#: ../../content/developer/howtos/backend.rst:334
#: ../../content/developer/howtos/backend.rst:855
msgid "Tree views"
msgstr ""
#: ../../content/developer/howtos/backend.rst:336
msgid "Tree views, also called list views, display records in a tabular form."
msgstr ""
#: ../../content/developer/howtos/backend.rst:338
msgid "Their root element is ``<tree>``. The simplest form of the tree view simply lists all the fields to display in the table (each field as a column):"
msgid "Forms are used to create and edit single records."
msgstr ""
#: ../../content/developer/howtos/backend.rst:356
msgid "Their root element is ``<form>``. They are composed of high-level structure elements (groups, notebooks) and interactive elements (buttons and fields):"
msgstr ""
#: ../../content/developer/howtos/backend.rst:385
msgid "Customise form view using XML"
msgstr ""
#: ../../content/developer/howtos/backend.rst:387
msgid "Create your own form view for the Course object. Data displayed should be: the name and the description of the course."
msgstr ""
#: ../../content/developer/howtos/backend.rst:390
msgid "Notebooks"
msgstr ""
#: ../../content/developer/howtos/backend.rst:392
msgid "In the Course form view, put the description field under a tab, such that it will be easier to add other tabs later, containing additional information."
msgstr ""
#: ../../content/developer/howtos/backend.rst:396
msgid "Form views can also use plain HTML for more flexible layouts:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:423
#: ../../content/developer/howtos/backend.rst:928
#: ../../content/developer/howtos/backend.rst:970
msgid "Search views"
msgstr ""
#: ../../content/developer/howtos/backend.rst:425
msgid "Search views customize the search field associated with the list view (and other aggregated views). Their root element is ``<search>`` and they're composed of fields defining which fields can be searched on:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:436
msgid "If no search view exists for the model, Odoo generates one which only allows searching on the ``name`` field."
msgstr ""
#: ../../content/developer/howtos/backend.rst:439
msgid "Search courses"
msgstr ""
#: ../../content/developer/howtos/backend.rst:441
msgid "Allow searching for courses based on their title or their description."
msgstr ""
#: ../../content/developer/howtos/backend.rst:444
#: ../../content/developer/howtos/website.rst:644
msgid "Relations between models"
msgstr ""
#: ../../content/developer/howtos/backend.rst:446
msgid "A record from a model may be related to a record from another model. For instance, a sale order record is related to a client record that contains the client data; it is also related to its sale order line records."
msgstr ""
#: ../../content/developer/howtos/backend.rst:450
msgid "Create a session model"
msgstr ""
#: ../../content/developer/howtos/backend.rst:452
msgid "For the module Open Academy, we consider a model for *sessions*: a session is an occurrence of a course taught at a given time for a given audience."
msgstr ""
#: ../../content/developer/howtos/backend.rst:455
msgid "Create a model for *sessions*. A session has a name, a start date, a duration and a number of seats. Add an action and a menu item to display them. Make the new model visible via a menu item."
msgid "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::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:484
msgid "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}`"
msgid "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::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:496
msgid "Many2one relations"
msgstr ""
#: ../../content/developer/howtos/backend.rst:498
msgid "Using a many2one, modify the *Course* and *Session* models to reflect their relation with other models:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:501
msgid "A course has a *responsible* user; the value of that field is a record of the built-in model ``res.users``."
msgstr ""
#: ../../content/developer/howtos/backend.rst:503
msgid "A session has an *instructor*; the value of that field is a record of the built-in model ``res.partner``."
msgstr ""
#: ../../content/developer/howtos/backend.rst:505
msgid "A session is related to a *course*; the value of that field is a record of the model ``openacademy.course`` and is required."
msgstr ""
#: ../../content/developer/howtos/backend.rst:507
msgid "Adapt the views."
msgstr ""
#: ../../content/developer/howtos/backend.rst:509
msgid "Inverse one2many relations"
msgstr ""
#: ../../content/developer/howtos/backend.rst:511
msgid "Using the inverse relational field one2many, modify the models to reflect the relation between courses and sessions."
msgstr ""
#: ../../content/developer/howtos/backend.rst:514
msgid "Multiple many2many relations"
msgstr ""
#: ../../content/developer/howtos/backend.rst:516
msgid "Using the relational field many2many, modify the *Session* model to relate every session to a set of *attendees*. Attendees will be represented by partner records, so we will relate to the built-in model ``res.partner``. Adapt the views accordingly."
msgid "Odoo provides two *inheritance* mechanisms to extend an existing model in a modular way."
msgstr ""
#: ../../content/developer/howtos/backend.rst:530
msgid "The first inheritance mechanism allows a module to modify the behavior of a model defined in another module:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:533
msgid "add fields to a model,"
msgstr ""
#: ../../content/developer/howtos/backend.rst:534
msgid "override the definition of fields on a model,"
msgstr ""
#: ../../content/developer/howtos/backend.rst:535
msgid "add constraints to a model,"
msgstr ""
#: ../../content/developer/howtos/backend.rst:536
msgid "add methods to a model,"
msgstr ""
#: ../../content/developer/howtos/backend.rst:537
msgid "override existing methods on a model."
msgstr ""
#: ../../content/developer/howtos/backend.rst:539
msgid "The second inheritance mechanism (delegation) allows to link every record of a model to a record in a parent model, and provides transparent access to the fields of the parent record."
msgstr ""
#: ../../content/developer/howtos/backend.rst:548
msgid ":attr:`~odoo.models.Model._inherit`"
msgstr ""
#: ../../content/developer/howtos/backend.rst:549
msgid ":attr:`~odoo.models.Model._inherits`"
msgstr ""
#: ../../content/developer/howtos/backend.rst:552
msgid "View inheritance"
msgstr ""
#: ../../content/developer/howtos/backend.rst:554
msgid "Instead of modifying existing views in place (by overwriting them), Odoo provides view inheritance where children \"extension\" views are applied on top of root views, and can add or remove content from their parent."
msgstr ""
#: ../../content/developer/howtos/backend.rst:558
msgid "An extension view references its parent using the ``inherit_id`` field, and instead of a single view its ``arch`` field is composed of any number of ``xpath`` elements selecting and altering the content of their parent view:"
msgid "alters the attributes of the matched element using special ``attribute`` elements in the ``xpath``'s body"
msgstr ""
#: ../../content/developer/howtos/backend.rst:599
msgid "When matching a single element, the ``position`` attribute can be set directly on the element to be found. Both inheritances below will give the same result."
msgstr ""
#: ../../content/developer/howtos/backend.rst:613
msgid "Alter existing content"
msgstr ""
#: ../../content/developer/howtos/backend.rst:615
msgid "Using model inheritance, modify the existing *Partner* model to add an ``instructor`` boolean field, and a many2many field that corresponds to the session-partner relation"
msgstr ""
#: ../../content/developer/howtos/backend.rst:618
msgid "Using view inheritance, display this fields in the partner form view"
msgid "In Odoo, :ref:`reference/orm/domains` are values that encode conditions on records. A domain is a list of criteria used to select a subset of a model's records. Each criteria is a triple with a field name, an operator and a value."
msgstr ""
#: ../../content/developer/howtos/backend.rst:627
msgid "For instance, when used on the *Product* model the following domain selects all *services* with a unit price over *1000*::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:632
msgid "By default criteria are combined with an implicit AND. The logical operators ``&`` (AND), ``|`` (OR) and ``!`` (NOT) can be used to explicitly combine criteria. They are used in prefix position (the operator is inserted before its arguments rather than between). For instance to select products \"which are services *OR* have a unit price which is *NOT* between 1000 and 2000\"::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:644
msgid "A ``domain`` parameter can be added to relational fields to limit valid records for the relation when trying to select records in the client interface."
msgstr ""
#: ../../content/developer/howtos/backend.rst:647
msgid "Domains on relational fields"
msgstr ""
#: ../../content/developer/howtos/backend.rst:649
msgid "When selecting the instructor for a *Session*, only instructors (partners with ``instructor`` set to ``True``) should be visible."
msgstr ""
#: ../../content/developer/howtos/backend.rst:652
msgid "More complex domains"
msgstr ""
#: ../../content/developer/howtos/backend.rst:654
msgid "Create new partner categories *Teacher / Level 1* and *Teacher / Level 2*. The instructor for a session can be either an instructor or a teacher (of any level)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:659
msgid "Computed fields and default values"
msgstr ""
#: ../../content/developer/howtos/backend.rst:661
msgid "So far fields have been stored directly in and retrieved directly from the database. Fields can also be *computed*. In that case, the field's value is not retrieved from the database but computed on-the-fly by calling a method of the model."
msgstr ""
#: ../../content/developer/howtos/backend.rst:666
msgid "To create a computed field, create a field and set its attribute :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``."
msgstr ""
#: ../../content/developer/howtos/backend.rst:671
msgid "``self`` is a collection"
msgstr ""
#: ../../content/developer/howtos/backend.rst:674
msgid "The object ``self`` is a *recordset*, i.e., an ordered collection of records. It supports the standard Python operations on collections, like ``len(self)`` and ``iter(self)``, plus extra set operations like ``recs1 + recs2``."
msgstr ""
#: ../../content/developer/howtos/backend.rst:679
msgid "Iterating over ``self`` gives the records one by one, where each record is itself a collection of size 1. You can access/assign fields on single records by using the dot notation, like ``record.name``."
msgid "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:`~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::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:720
msgid "Computed fields"
msgstr ""
#: ../../content/developer/howtos/backend.rst:722
msgid "Add the percentage of taken seats to the *Session* model"
msgstr ""
#: ../../content/developer/howtos/backend.rst:723
msgid "Display that field in the tree and form views"
msgstr ""
#: ../../content/developer/howtos/backend.rst:724
msgid "Display the field as a progress bar"
msgstr ""
#: ../../content/developer/howtos/backend.rst:727
msgid "Default values"
msgstr ""
#: ../../content/developer/howtos/backend.rst:729
msgid "Any field can be given a default value. In the field definition, add the option ``default=X`` where ``X`` is either a Python literal value (boolean, integer, float, string), or a function taking a recordset and returning a value::"
msgid "``self.env[model_name]`` returns an instance of the given model"
msgstr ""
#: ../../content/developer/howtos/backend.rst:749
msgid "Active objects – Default values"
msgstr ""
#: ../../content/developer/howtos/backend.rst:751
msgid "Define the start_date default value as today (see :class:`~odoo.fields.Date`)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:753
msgid "Add a field ``active`` in the class Session, and set sessions as active by default."
msgstr ""
#: ../../content/developer/howtos/backend.rst:757
msgid "Onchange"
msgstr ""
#: ../../content/developer/howtos/backend.rst:759
msgid "The \"onchange\" mechanism provides a way for the client interface to update a form whenever the user has filled in a value in a field, without saving anything to the database."
msgstr ""
#: ../../content/developer/howtos/backend.rst:763
msgid "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:`~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."
msgstr ""
#: ../../content/developer/howtos/backend.rst:792
msgid "For computed fields, valued ``onchange`` behavior is built-in as can be seen by playing with the *Session* form: change the number of seats or participants, and the ``taken_seats`` progressbar is automatically updated."
msgstr ""
#: ../../content/developer/howtos/backend.rst:796
msgid "Warning"
msgstr ""
#: ../../content/developer/howtos/backend.rst:798
msgid "Add an explicit onchange to warn about invalid values, like a negative number of seats, or more participants than seats."
msgid "Odoo provides two ways to set up automatically verified invariants: :func:`Python constraints <odoo.api.constrains>` and :attr:`SQL constraints <odoo.models.Model._sql_constraints>`."
msgstr ""
#: ../../content/developer/howtos/backend.rst:808
msgid "A Python constraint is defined as a method decorated with :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::"
msgstr ""
#: ../../content/developer/howtos/backend.rst:823
msgid "Add Python constraints"
msgstr ""
#: ../../content/developer/howtos/backend.rst:825
msgid "Add a constraint that checks that the instructor is not present in the attendees of his/her own session."
msgstr ""
#: ../../content/developer/howtos/backend.rst:828
msgid "SQL constraints are defined through the model attribute :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."
msgstr ""
#: ../../content/developer/howtos/backend.rst:834
msgid "Add SQL constraints"
msgstr ""
#: ../../content/developer/howtos/backend.rst:836
msgid "With the help of `PostgreSQL's documentation`_ , add the following constraints:"
msgstr ""
#: ../../content/developer/howtos/backend.rst:839
msgid "CHECK that the course description and the course title are different"
msgstr ""
#: ../../content/developer/howtos/backend.rst:840
msgid "Make the Course's name UNIQUE"
msgstr ""
#: ../../content/developer/howtos/backend.rst:842
msgid "Exercise 6 - Add a duplicate option"
msgstr ""
#: ../../content/developer/howtos/backend.rst:844
msgid "Since we added a constraint for the Course name uniqueness, it is not possible to use the \"duplicate\" function anymore (:menuselection:`Form --> Duplicate`)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:848
msgid "Re-implement your own \"copy\" method which allows to duplicate the Course object, changing the original name into \"Copy of [original name]\"."
msgstr ""
#: ../../content/developer/howtos/backend.rst:852
msgid "Advanced Views"
msgstr ""
#: ../../content/developer/howtos/backend.rst:857
msgid "Tree views can take supplementary attributes to further customize their behavior:"
msgid "Values are Python expressions. For each record, the expression is evaluated with the record's attributes as context values and if ``true``, the corresponding style is applied to the row. Here are some of the other values available in the context:"
msgid "``now``: same as ``today`` with the addition of the current time. This value is formatted as ``YYYY-MM-DD hh:mm:ss``."
msgstr ""
#: ../../content/developer/howtos/backend.rst:874
msgid "``{$name}`` can be ``bf`` (``font-weight: bold``), ``it`` (``font-style: italic``), or any `bootstrap contextual color <https://getbootstrap.com/docs/3.3/components/#available-variations>`_ (``danger``, ``info``, ``muted``, ``primary``, ``success`` or ``warning``)."
msgid "Either ``\"top\"`` or ``\"bottom\"``. Makes the tree view editable in-place (rather than having to go through the form view), the value is the position where new rows appear."
msgstr ""
#: ../../content/developer/howtos/backend.rst:892
msgid "List coloring"
msgstr ""
#: ../../content/developer/howtos/backend.rst:894
msgid "Modify the Session tree view in such a way that sessions lasting less than 5 days are colored blue, and the ones lasting more than 15 days are colored red."
msgstr ""
#: ../../content/developer/howtos/backend.rst:899
msgid "Calendars"
msgstr ""
#: ../../content/developer/howtos/backend.rst:901
msgid "Displays records as calendar events. Their root element is ``<calendar>`` and their most common attributes are:"
msgid "The name of the field used for *color segmentation*. Colors are automatically distributed to events, but events in the same color segment (records which have the same value for their ``@color`` field) will be given the same color."
msgstr ""
#: ../../content/developer/howtos/backend.rst:909
msgid "``date_start``"
msgstr ""
#: ../../content/developer/howtos/backend.rst:910
msgid "record's field holding the start date/time for the event"
msgstr ""
#: ../../content/developer/howtos/backend.rst:911
msgid "``date_stop`` (optional)"
msgstr ""
#: ../../content/developer/howtos/backend.rst:912
msgid "record's field holding the end date/time for the event"
msgid "record's field to define the label for each calendar event"
msgstr ""
#: ../../content/developer/howtos/backend.rst:922
msgid "Calendar view"
msgstr ""
#: ../../content/developer/howtos/backend.rst:924
msgid "Add a Calendar view to the *Session* model enabling the user to view the events associated to the Open Academy."
msgstr ""
#: ../../content/developer/howtos/backend.rst:930
msgid "Search view ``<field>`` elements can have a ``@filter_domain`` that overrides the domain generated for searching on the given field. In the given domain, ``self`` represents the value entered by the user. In the example below, it is used to search on both fields ``name`` and ``description``."
msgid "Search views can also contain ``<filter>`` elements, which act as toggles for predefined searches. Filters must have one of the following attributes:"
msgid "add some context to the current search; use the key ``group_by`` to group results on the given field name"
msgstr ""
#: ../../content/developer/howtos/backend.rst:961
msgid "To use a non-default search view in an action, it should be linked using the ``search_view_id`` field of the action record."
msgstr ""
#: ../../content/developer/howtos/backend.rst:964
msgid "The action can also set default values for search fields through its ``context`` field: context keys of the form :samp:`search_default_{field_name}` will initialize *field_name* with the provided value. Search filters must have an optional ``@name`` to have a default and behave as booleans (they can only be enabled by default)."
msgstr ""
#: ../../content/developer/howtos/backend.rst:972
msgid "Add a button to filter the courses for which the current user is the responsible in the course search view. Make it selected by default."
msgstr ""
#: ../../content/developer/howtos/backend.rst:974
msgid "Add a button to group courses by responsible user."
msgid "The gantt view requires the web_gantt module which is present in :ref:`the enterprise edition <setup/install/editions>` version."
msgstr ""
#: ../../content/developer/howtos/backend.rst:984
msgid "Horizontal bar charts typically used to show project planning and advancement, their root element is ``<gantt>``."
msgstr ""
#: ../../content/developer/howtos/backend.rst:995
msgid "Gantt charts"
msgstr ""
#: ../../content/developer/howtos/backend.rst:997
msgid "Add a Gantt Chart enabling the user to view the sessions scheduling linked to the Open Academy module. The sessions should be grouped by instructor."
msgid "Pivot views (element ``<pivot>``) a multidimensional table, allows the selection of filers and dimensions to get the right aggregated dataset before moving to a more graphical overview. The pivot view shares the same content definition as graph views."
msgid "A kanban view shows a set of cards possibly grouped in columns. Each card represents a record, and each column the values of an aggregation field."
msgid "Groups are created as normal records on the model ``res.groups``, and granted menu access via menu definitions. However even without a menu, objects may still be accessible indirectly, so actual object-level permissions (read, write, create, unlink) must be defined for groups. They are usually inserted via CSV files inside modules. It is also possible to restrict access to specific fields on a view or object using the field's groups attribute."
msgid "Access rights are defined as records of the model ``ir.model.access``. Each access right is associated to a model, a group (or no group for global access), and a set of permissions: read, write, create, unlink. Such access rights are usually created by a CSV file named after its model: ``ir.model.access.csv``."
msgid "A record rule restricts the access rights to a subset of records of the given model. A rule is a record of the model ``ir.rule``, and is associated to a model, a number of groups (many2many field), permissions to which the restriction applies, and a domain. The domain specifies to which records the access rights are limited."
msgid "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:`~odoo.models.Model.write` of the ORM."
msgid "Add a record rule for the model Course and the group \"OpenAcademy / Manager\", that restricts ``write`` and ``unlink`` accesses to the responsible of a course. If a course has no responsible, all users of the group must be able to modify it."
msgid "Wizards describe interactive sessions with the user (or dialog boxes) through dynamic forms. A wizard is simply a model that extends the class :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:"
msgid "Wizard records are not meant to be persistent; they are automatically deleted from the database after a certain time. This is why they are called *transient*."
msgid "Wizard records may refer to regular records or wizard records through relational fields(many2one or many2many), but regular records *cannot* refer to wizard records through a many2one field."
msgid "Wizards are simply :ref:`window actions <howtos/module/actions>` with a ``target`` field set to the value ``new``, which opens the view (usually :ref:`a form <howtos/module/views/form>`) in a separate dialog. The action may be triggered via a menu item, but is more generally triggered by a button."
msgid "An other way to launch wizards is through the :menuselection:`Action` menu of a tree or form view. This is done through the ``binding_model_id`` field of the action. Setting this field will make the action appear on the views of the model the action is \"bound\" to."
msgid "While wizards use regular views and buttons, normally clicking any button in a form would first save the form then close the dialog. Because this is often undesirable in wizards, a special attribute ``special=\"cancel\"`` is available which immediately closes the wizard without saving the form."
msgid "Each module can provide its own translations within the i18n directory, by having files named LANG.po where LANG is the locale code for the language, or the language and country combination when they differ (e.g. pt.po or pt_BR.po). Translations will be loaded automatically by Odoo for all enabled languages. Developers always use English when creating a module, then export the module terms using Odoo's gettext POT export feature (:menuselection:`Settings --> Translations --> Import/Export --> Export Translation` without specifying a language), to create the module template POT file, and then derive the translated PO files. Many IDE's have plugins or modes for editing and merging PO/POT files."
msgid "The Portable Object files generated by Odoo are published on `Transifex <https://www.transifex.com/odoo/public/>`__, making it easy to translate the software."
msgid "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:`odoo._` (e.g. ``_(\"Label\")``)"
msgid "an ``ir.actions.report`` which configures various basic parameters for the report (default type, whether the report should be saved to the database after generation,…)"
msgid "Because it largerly a standard action, as with :ref:`howto/module/wizard` it is generally useful to add the report as a *contextual item* on the tree and / or form views of the model being reported on via the ``binding_model_id`` field."
msgid "Here we are also using ``binding_type`` in order for the report to be in the *report* contextual menu rather than the *action* one. There is no technical difference but putting elements in the right place helps users."
msgid "Because reports are standard web pages, they are available through a URL and output parameters can be manipulated through this URL, for instance the HTML version of the *Invoice* report is available through http://localhost:8069/report/html/account.report_invoice/1 (if ``account`` is installed) and the PDF version through http://localhost:8069/report/pdf/account.report_invoice/1."
msgid "If it appears that your PDF report is missing the styles (i.e. the text appears but the style/layout is different from the html version), probably your wkhtmltopdf_ process cannot reach your web server to download them."
msgid "If you check your server logs and see that the CSS styles are not being downloaded when generating a PDF report, most surely this is the problem."
msgid "The wkhtmltopdf_ process will use the ``web.base.url`` system parameter as the *root path* to all linked files, but this parameter is automatically updated each time the Administrator is logged in. If your server resides behind some kind of proxy, that could not be reachable. You can fix this by adding one of these system parameters:"
msgid "``report.url``, pointing to an URL reachable from your server (probably ``http://localhost:8069`` or something similar). It will be used for this particular purpose only."
msgid "Define a dashboard containing the graph view you created, the sessions calendar view and a list view of the courses (switchable to a form view). This dashboard should be available through a menuitem in the menu, and automatically displayed in the web client when the OpenAcademy main menu is selected."
msgid "Business objects can also be accessed via the distributed object mechanism. They can all be modified via the client interface with contextual views."
msgid "Write a Python program able to send XML-RPC requests to a PC running Odoo (yours, or your instructor's). This program should display all the sessions, and their corresponding number of seats. It should also create a new session for one of the courses."
msgid "The following example is a Python 3 program that interacts with an Odoo server with the standard Python libraries ``urllib.request`` and ``json``. This example assumes the **Productivity** app (``note``) is installed::"
msgid "There are a number of high-level APIs in various languages to access Odoo systems without *explicitly* going through XML-RPC or JSON-RPC, such as:"
msgid "writing raw SQL queries is possible, but requires care as it bypasses all Odoo authentication and security mechanisms."
msgstr ""
#: ../../content/developer/howtos/company.rst:6
msgid "Multi-company Guidelines"
msgstr ""
#: ../../content/developer/howtos/company.rst:10
msgid "This tutorial requires good knowledge of Odoo. Please refer to the :ref:`basic tutorial <howto/base>` first if needed."
msgstr ""
#: ../../content/developer/howtos/company.rst:13
msgid "As of version 13.0, a user can be logged in multiple companies at once. This allows the user to access information from multiple companies but also to create/edit records in a multi-company environment."
msgstr ""
#: ../../content/developer/howtos/company.rst:17
msgid "If not handled correctly, it may be the source of a lot of inconsistent multi-company behaviors. For instance, a user logged in both companies A and B could create a sales order in company A and add products belonging to company B to it. It is only when the user will log out from company B that access errors will occur for the sales order."
msgid "When a record is available from multiple companies, we must expect that different values will be assigned to a given field depending on the company from which the value is set."
msgstr ""
#: ../../content/developer/howtos/company.rst:38
msgid "For the field of a same record to support several values, it must be defined with the attribute `company_dependent` set to `True`."
msgstr ""
#: ../../content/developer/howtos/company.rst:57
msgid "The `_compute_display_info` method is decorated with `depends_context('company')` (see :attr:`~odoo.api.depends_context`) to ensure that the computed field is recomputed depending on the current company (`self.env.company`)."
msgstr ""
#: ../../content/developer/howtos/company.rst:61
msgid "When a company-dependent field is read, the current company is used to retrieve its value. In other words, if a user is logged in companies A and B with A as main company and creates a record for company B, the values of company-dependent fields will be that of company A."
msgstr ""
#: ../../content/developer/howtos/company.rst:65
msgid "To read the values of company-dependent fields set from another company than the current one, we need to ensure the company we are using is the correct one. This can be done with :meth:`~odoo.models.Model.with_company`, which updates the current company."
msgstr ""
#: ../../content/developer/howtos/company.rst:80
msgid "Whenever you are computing/creating/... things that may behave differently in different companies, you should make sure whatever you are doing is done in the right company. It doesn't cost much to always use `with_company` to avoid problems later on."
msgstr ""
#: ../../content/developer/howtos/company.rst:101
msgid "Multi-company consistency"
msgstr ""
#: ../../content/developer/howtos/company.rst:103
msgid "When a record is made shareable between several companies by the mean of a `company_id` field, we must take care that it cannot be linked to the record of another company through a relational field. For instance, we do not want to have a sales order and its invoice belonging to different companies."
msgstr ""
#: ../../content/developer/howtos/company.rst:107
msgid "To ensure this multi-company consistency, you must:"
msgstr ""
#: ../../content/developer/howtos/company.rst:109
msgid "Set the class attribute `_check_company_auto` to `True`."
msgstr ""
#: ../../content/developer/howtos/company.rst:110
msgid "Define relational fields with the attribute `check_company` set to `True` if their model has a `company_id` field."
msgstr ""
#: ../../content/developer/howtos/company.rst:113
msgid "On each :meth:`~odoo.models.Model.create` and :meth:`~odoo.models.Model.write`, automatic checks will be triggered to ensure the multi-company consistency of the record."
msgstr ""
#: ../../content/developer/howtos/company.rst:127
msgid "The field `company_id` must not be defined with `check_company=True`."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel._check_company:3
msgid "names of relational fields to check"
msgstr ""
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel._check_company:0
#: ../../../odoo/odoo/api.py:docstring of odoo.api.Environment.company:0
#: ../../../odoo/odoo/api.py:docstring of odoo.api.Environment.companies:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.create:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.search:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read_group:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.fields_view_get:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.unlink:0
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.ensure_one:0
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form.save:0
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.O2MProxy.edit:0
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.O2MProxy.new:0
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.O2MProxy.remove:0
msgid "Raises"
msgstr ""
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel._check_company:4
msgid "if the `company_id` of the value of any field is not in `[False, self.company_id]` (or `self` if :class:`~odoo.addons.base.models.res_company`)."
msgstr ""
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel._check_company:8
msgid "For :class:`~odoo.addons.base.models.res_users` relational fields, verifies record company is in `company_ids` fields."
msgstr ""
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel._check_company:11
msgid "User with main company A, having access to company A and B, could be assigned or linked to records in company B."
msgid "The `check_company` feature performs a strict check ! It means that if a record has no `company_id` (i.e. the field is not required), it cannot be linked to a record whose `company_id` is set."
msgstr ""
#: ../../content/developer/howtos/company.rst:138
msgid "When no domain is defined on the field and `check_company` is set to `True`, a default domain is added: `['|', '('company_id', '=', False), ('company_id', '=', company_id)]`"
msgstr ""
#: ../../content/developer/howtos/company.rst:144
msgid "Default company"
msgstr ""
#: ../../content/developer/howtos/company.rst:146
msgid "When the field `company_id` is made required on a model, a good practice is to set a default company. It eases the setup flow for the user or even guarantees its validity when the company is hidden from the view. Indeed, the company is usually hidden if the user does not have access to multiple companies (i.e. when the user does not have the group `base.group_multi_company`)."
msgid "As stated in :ref:`above <howto/company/default_company>`, the company is usually hidden from the view if the user does not have access to multiple companies. This is tested with the group `base.group_multi_company`."
msgstr ""
#: ../../content/developer/howtos/company.rst:197
msgid "Security rules"
msgstr ""
#: ../../content/developer/howtos/company.rst:199
msgid "When working with records shared across companies or restricted to a single company, we must take care that a user does not have access to records belonging to other companies."
msgstr ""
#: ../../content/developer/howtos/company.rst:202
msgid "This is achieved with security rules based on `company_ids`, which contains the current companies of the user (the companies the user checked in the multi-company widget)."
msgid "Odoo embeds a profiler of code. This embedded profiler output can be used to generate a graph of calls triggered by the method, number of queries, percentage of time taken in the method itself as well as the time that the method took and its sub-called methods."
msgid "Sending the SIGQUIT signal to an Odoo process (only available on POSIX) makes this process output the current stack trace to log, with info level. When an odoo process seems stuck, sending this signal to the process permit to know what the process is doing, and letting the process continue his job."
msgid "Instead of sending the SIGQUIT signal to an Odoo process often enough, to check where the processes are performing worse than expected, we can use the `py-spy`_ tool to do it for us."
msgid "Welcome to the Getting Started Odoo tutorial! If you reached this page that means you are interested in the development of your own Odoo module. It might also mean that you recently joined the Odoo company for a rather technical position. In any case, your journey to the technical side of Odoo starts here."
msgid "This training is split in two parts. The first part is the 'Core Training': its objective is to give you an insight of the most important parts of the Odoo development framework. The chapters should be followed in their given order since they cover the development of a new Odoo application from scratch in an incremental way. In other words, each chapter depends on the previous one."
msgid "The second part covers a set of 'Advanced' topics. Each topic can be followed independently, but requires the 'Core Training'. Note that some advanced topics cover basic features of an Odoo module, so it's a good idea to give them a quick look."
msgid "All topics are built around a business case we will enhance along the way. The reader is expected to actively take part in the training by writing the solution for each exercise."
msgid "Odoo follows a `multitier architecture`_, meaning that the presentation, the business logic and the data storage are separated. More specifically, it uses a three-tier architecture (image from Wikipedia):"
msgid "The presentation tier is a combination of HTML5, JavaScript and CSS. The logic tier is exclusively written in Python, while the data tier only supports PostgreSQL as an RDBMS."
msgid "Depending on the scope of your module, Odoo development can be done in any of these tiers. Therefore, before going any further, it may be a good idea to refresh your memory if you don't have an intermediate level in these topics."
msgid "In order to go through this tutorial, you will need a very basic knowledge of HTML and an intermediate level of Python. Advanced topics will require more knowledge in the other subjects. There are plenty of tutorials freely accessible, so we cannot recommend one over another since it depends on your background."
msgid "Both server and client extensions are packaged as *modules* which are optionally loaded in a *database*. A module is a collection of functions and data that target a single purpose."
msgid "Odoo modules can either add brand new business logic to an Odoo system or alter and extend existing business logic. One module can be created to add your country's accounting rules to Odoo's generic accounting support, while a different module can add support for real-time visualisation of a bus fleet."
msgid "Terminology: developers group their business features in Odoo *modules*. The main user-facing modules are flagged and exposed as *Apps*, but a majority of the modules aren't Apps. *Modules* may also be referred to as *addons* and the directories where the Odoo server finds them form the ``addons_path``."
msgid "A business object (e.g. an invoice) is declared as a Python class. The fields defined in these classes are automatically mapped to database columns thanks to the :abbr:`ORM (Object-Relational Mapping)` layer."
msgid "None of these elements are mandatory. Some modules may only add data files (e.g. country-specific accounting configuration), while others may only add business objects. During this training, we will create business objects, object views and data files. :ref:`Web controllers <howto/rdtraining/G_website>` and :ref:`static web data <howto/rdtraining/I_jswidget>` are advanced topics."
msgid "When an Odoo module includes business objects (i.e. Python files), they are organized as a `Python package <https://docs.python.org/3/tutorial/modules.html#packages>`_ with a ``__init__.py`` file. This file contains import instructions for various Python files in the module."
msgid "Odoo is available in `two versions`_: Odoo Enterprise (licensed & shared sources) and Odoo Community (open-source). In addition to services such as support or upgrades, the Enterprise version provides extra functionalities to Odoo. From a technical point-of-view, these functionalities are simply new modules installed on top of the modules provided by the Community version."
msgid "Ready to start? Before writing actual code, let's go to the :ref:`next chapter <howto/rdtraining/02_setup>` to review the Odoo installation process. Even if Odoo is already running on your system, we strongly suggest you go through this chapter to make sure we start on the same page during the development of our new application."
msgid "This document attempts to describe the installation options for an internal Odoo R&D developer. We assume that you are installing your development environment on a standard Odoo laptop with Linux Mint installed and up-to-date. At the time of writing, we are using a vanilla Linux Mint 20 (Ubuntu 20.04) as a starting point."
msgid "The very first step of the installation process is to install the `git version control system <https://git-scm.com/>`__ because the Odoo source code is managed on GitHub. Once installed, you can set your name and email:"
msgid "To fetch the sources and contribute to Odoo's development you will need a GitHub account. We recommend using your trigram (xyz) followed by '-odoo' as your username: 'xyz-odoo'. If you prefer, you can also use your personal GitHub account."
msgid "The easiest way to authenticate with GitHub is to use an SSH connection. Using the SSH authentication will allow you to connect to GitHub without supplying your username and password every time."
msgid "The following instructions are based on the official `GitHub documentation <https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`__."
msgid "To contribute to Odoo's development you will need to `fork the repository <https://guides.github.com/activities/forking/>`__, create a branch containing your code in the fork and submit a `Pull Request <https://docs.github.com/en/github/getting-started-with-github/github-glossary#pull-request>`__ to the Odoo repository."
msgid "Change branch: When you change branches, both repositories (odoo and enterprise) must be synchronized, i.e. both need to be in the same branch."
msgid "For libraries using native code, installation of development tools and native dependencies is required before installing the Python dependencies of Odoo."
msgid "wkhtmltopdf is a library to render HTML into PDF. Odoo uses it to create PDF reports. wkhtmltopdf is not installed through pip and must be installed manually in version 0.12.5 to support headers and footers."
msgid "As seen in :ref:`howto/rdtraining/01_architecture`, Odoo uses PostgreSQL as a RDBMS. In the context of a development machine, the easiest approach is to install it locally. Then we can create a PostgreSQL user corresponding to our current user:"
msgid "There are multiple :ref:`command-line arguments <reference/cmdline/server>` that you can use to configure the server. In this training you will only need some of them."
msgid "If this error occurs with more than one module then you may need to re-install all the requirements with `$ pip3 install --upgrade --force-reinstall -r requirements.txt`"
msgid "Open `http://localhost:8069/` on your browser. We recommend you use: `Firefox <https://www.mozilla.org/fr/firefox/new/>`__, `Chrome <https://www.google.com/intl/fr/chrome/>`__ (`Chromium <https://www.chromium.org/Home>`__ the open source equivalent) or any other browser with development tools."
msgid "To activate the developer or debug mode you can follow the steps `here <https://www.odoo.com/documentation/user/general/developer_mode/activate.html>`__."
msgid "If you are working at Odoo, many of your colleagues are using `VSCode`_ (`VSCodium`_ the open source equivalent), `Sublime Text`_, `Atom`_ or `PyCharm`_. However you are free to choose your preferred editor."
msgid "Don't forget to configure your linters correctly. Using a linter can help you by showing syntax and semantic warnings or errors. Odoo source code tries to respect Python and JavaScript standards, but some of them can be ignored."
msgid "You can manage your PostgreSQL databases using the command line as demonstrated earlier or using a GUI application such as `pgAdmin <https://www.pgadmin.org/download/pgadmin-4-apt/>`__ or `DBeaver <https://dbeaver.io/>`__."
msgid "When facing a bug or trying to understand how the code works, simply printing things out can go a long way, but a proper debugger can save a lot of time."
msgid "You can use a classic Python library debugger (`pdb <https://docs.python.org/3/library/pdb.html>`__, `pudb <https://pypi.org/project/pudb/>`__ or `ipdb <https://pypi.org/project/ipdb/>`__) or you can use your editor's debugger. To avoid difficult configurations in the beginning, it is easier if you use a library debugger."
msgid "Execute the current line, stop at the first possible occasion (either in a function that is called or on the next line in the current function)."
msgid "To avoid killing the worker when debugging, you can add these arguments when launching the server: `--limit-time-cpu=9999 --limit-time-real=9999` Another solution is to add them directly in the `~/.odoorc` file:"
msgid "The purpose of this chapter is to lay the foundation for the creation of a completely new Odoo module. We will start from scratch with the minimum needed to have our module recognized by Odoo. In the upcoming chapters, we will progressively add features to build a realistic business case."
msgid "Our new module will cover a business area which is very specific and therefore not included in the standard set of modules: real estate. It is worth noting that before developing a new module, it is good practice to verify that Odoo doesn't already provide a way to answer the specific business case."
msgid "The top area of the form view summarizes important information for the property, such as the name, the property type, the postcode and so on. The first tab contains information describing the property: bedrooms, living area, garage, garden..."
msgid "The second tab lists the offers for the property. We can see here that potential buyers can make offers above or below the expected selling price. It is up to the seller to accept an offer."
msgid "**Goal**: the goal of this section is to have Odoo recognize our new module, which will be an empty shell for now. It will be listed in the Apps:"
msgid "The first step of module creation is to create a new directory. To ease the development, we suggest you first create the directory ``/home/$USER/src/custom``. In this directory we add another directory ``estate``, which is our module."
msgid "A module must contain at least 2 files: the ``__manifest__.py`` file and a ``__init__.py`` file. The ``__init__.py`` file can remain empty for now and we'll come back to it in the next chapter. On the other hand, the ``__manifest__.py`` file must describe our module and cannot remain empty. Its only required field is the ``name``, but it usually contains much more information."
msgid "Take a look at the `CRM file <https://github.com/odoo/odoo/blob/fc92728fb2aa306bf0e01a7f9ae1cfa3c1df0e10/addons/crm/__manifest__.py#L1-L67>`__ as an example. In addition to providing the description of the module (``name``, ``category``, ``summary``, ``website``...), it lists its dependencies (``depends``). A dependency means that the Odoo framework will ensure that these modules are installed before our module is installed. Moreover, if one of these dependencies is uninstalled, then our module and **any other that depends on it will also be uninstalled**. Think about your favorite Linux distribution package manager (``apt``, ``dnf``, ``pacman``...): Odoo works in the same way."
msgid "The ``__manifest__.py`` file should only define the name and the dependencies of our modules. The only necessary framework module for now is ``base``."
msgid "Go to Apps, click on Update Apps List, search for ``estate`` and... tadaaa, your module appears! Did it not appear? Maybe try removing the default 'Apps' filter ;-)"
msgid "At the end of the :ref:`previous chapter <howto/rdtraining/03_newapp>`, we were able to create an Odoo module. However, at this point it is still an empty shell which doesn't allow us to store any data. In our real estate module, we want to store the information related to the properties (name, description, price, living area...) in a database. The Odoo framework provides tools to facilitate database interactions."
msgid "A key component of Odoo is the `ORM`_ layer. This layer avoids having to manually write most `SQL`_ and provides extensibility and security services\\ [#rawsql]_."
msgid "Business objects are declared as Python classes extending :class:`~odoo.models.Model`, which integrates them into the automated persistence system."
msgid "Models can be configured by setting attributes in their definition. The most important attribute is :attr:`~odoo.models.Model._name`, which is required and defines the name for the model in the Odoo system. Here is a minimum definition of a model::"
msgid "This definition is enough for the ORM to generate a database table named ``test_model``. The ``.`` in the model ``_name`` is automatically converted into a ``_`` by the ORM. By convention all models are located in a ``models`` directory and each model is defined in its own Python file."
msgid "The model is defined in the file ``crm/models/crm_recurring_plan.py`` (see `here <https://github.com/odoo/odoo/blob/e80911aaead031e7523173789e946ac1fd27c7dc/addons/crm/models/crm_recurring_plan.py#L1-L9>`__)"
msgid "The file ``crm_recurring_plan.py`` is imported in ``crm/models/__init__.py`` (see `here <https://github.com/odoo/odoo/blob/e80911aaead031e7523173789e946ac1fd27c7dc/addons/crm/models/__init__.py#L15>`__)"
msgid "The folder ``models`` is imported in ``crm/__init__.py`` (see `here <https://github.com/odoo/odoo/blob/e80911aaead031e7523173789e946ac1fd27c7dc/addons/crm/__init__.py#L5>`__)"
msgid "Any modification of the Python files requires a restart of the Odoo server. When we restart the server, we will add the parameters ``-d`` and ``-u``:"
msgid "``-u estate`` means we want to upgrade the ``estate`` module, i.e. the ORM will apply database schema changes. In this case it creates a new table. ``-d rd-demo`` means that the upgrade should be performed on the ``rd-demo`` database. ``-u`` should always be used in combination with ``-d``."
msgid "There are two broad categories of fields: 'simple' fields, which are atomic values stored directly in the model's table, and 'relational' fields, which link records (of the same or different models)."
msgid "Simple field examples are :class:`~odoo.fields.Boolean`, :class:`~odoo.fields.Float`, :class:`~odoo.fields.Char`, :class:`~odoo.fields.Text`, :class:`~odoo.fields.Date` and :class:`~odoo.fields.Selection`."
msgid "The ``garden_orientation`` field must have 4 possible values: 'North', 'South', 'East' and 'West'. The selection list is defined as a list of tuples, see `here <https://github.com/odoo/odoo/blob/b0e0035b585f976e912e97e7f95f66b525bc8e43/addons/crm/report/crm_activity_report.py#L31-L34>`__ for an example."
msgid "Connect to ``psql`` and check the structure of the table ``estate_property``. You'll notice that a couple of extra fields were also added to the table. We will revisit them later."
msgid "You may have noticed your model has a few fields you never defined. Odoo creates a few fields in all models\\ [#autofields]_. These fields are managed by the system and can't be written to, but they can be read if useful or necessary:"
msgid "In the :ref:`previous chapter <howto/rdtraining/04_basicmodel>`, we created our first table intended to store business data. In a business application such as Odoo, one of the first questions to consider is who\\ [#who]_ can access the data. Odoo provides a security mechanism to allow access to the data for specific groups of users."
msgid "The topic of security is covered in more detail in :ref:`howto/rdtraining/B_acl_irrules`. This chapter aims to cover the minimum required for our new module."
msgid "Odoo is a highly data driven system. Although behavior is customized using Python code, part of a module's value is in the data it sets up when loaded. One way to load data is through a CSV file. One example is the `list of country states <https://github.com/odoo/odoo/blob/master/odoo/addons/base/data/res.country.state.csv>`__ which is loaded at installation of the ``base`` module."
msgid "These three fields are `defined <https://github.com/odoo/odoo/blob/2ad2f3d6567b6266fc42c6d2999d11f3066b282c/odoo/addons/base/models/res_country.py#L108-L111>`__ in the ``res.country.state`` model."
msgid "By convention, a file importing data is located in the ``data`` folder of a module. When the data is related to security, it is located in the ``security`` folder. When the data is related to views and actions (we will cover this later), it is located in the ``views`` folder. Additionally, all of these files must be declared in the ``data`` list within the ``__manifest__.py`` file. Our example file is defined `in the manifest of the base module <https://github.com/odoo/odoo/blob/e8697f609372cd61b045c4ee2c7f0fcfb496f58a/odoo/addons/base/__manifest__.py#L29>`__."
msgid "The data files are sequentially loaded following their order in the ``__manifest__.py`` file. This means that if data ``A`` refers to data ``B``, you must make sure that ``B`` is loaded before ``A``."
msgid "In the case of the country states, you will note that the `list of countries <https://github.com/odoo/odoo/blob/e8697f609372cd61b045c4ee2c7f0fcfb496f58a/odoo/addons/base/__manifest__.py#L22>`__ is loaded **before** the `list of country states <https://github.com/odoo/odoo/blob/e8697f609372cd61b045c4ee2c7f0fcfb496f58a/odoo/addons/base/__manifest__.py#L29>`__. This is because the states refer to the countries."
msgid "Why is all this important for security? Because all the security configuration of a model is loaded through data files, as we'll see in the next section."
msgid "Access rights are defined as records of the model ``ir.model.access``. Each access right is associated with a model, a group (or no group for global access) and a set of permissions: create, read, write and unlink\\ [#unlink]_. Such access rights are usually defined in a CSV file named ``ir.model.access.csv``."
msgid "``model_id/id`` refers to the model which the access right applies to. The standard way to refer to the model is ``model_<model_name>``, where ``<model_name>`` is the ``_name`` of the model with the ``.`` replaced by ``_``. Seems cumbersome? Indeed it is..."
msgid "``group_id/id`` refers to the group which the access right applies to. We will cover the concept of groups in the :ref:`advanced topic <howto/rdtraining/N_security>` dedicated to the security."
msgid "Now that we've created our new :ref:`model <howto/rdtraining/04_basicmodel>` and its corresponding :ref:`access rights <howto/rdtraining/05_securityintro>`, it is time to interact with the user interface."
msgid "In :ref:`howto/rdtraining/05_securityintro`, we added data through a CSV file. The CSV format is convenient when the data to load has a simple format. When the format is more complex (e.g. load the structure of a view or an email template), we use the XML format. For example, this `help field <https://github.com/odoo/odoo/blob/09c59012bf80d2ccbafe21c39e604d6cfda72924/addons/crm/views/crm_lost_reason_views.xml#L61-L69>`__ contains HTML tags. While it would be possible to load such data through a CSV file, it is more convenient to use an XML file."
msgid "The XML files must be added to the same folders as the CSV files and defined similarly in the ``__manifest__.py``. The content of the data files is also sequentially loaded when a module is installed or updated, therefore all remarks made for CSV files hold true for XML files. When the data is linked to views, we add them to the ``views`` folder."
msgid "When performance is important, the CSV format is preferred over the XML format. This is the case in Odoo where loading a CSV file is faster than loading an XML file."
msgid "In Odoo, the user interface (actions, menus and views) is largely defined by creating and composing records defined in an XML file. A common pattern is Menu > Action > View. To access records the user navigates through several menu levels; the deepest level is an action which triggers the opening of a list of the records."
msgid "**Goal**: at the end of this section, an action should be loaded in the system. We won't see anything yet in the UI, but the file should be loaded in the log:"
msgid "We will only cover the first case in this chapter. The second case will be covered in a :ref:`later chapter <howto/rdtraining/10_actions>` while the last is the focus of an advanced topic. In our Real Estate example, we would like to link a menu to the ``estate.property`` model, so we are able to create a new record. The action can be viewed as the link between the menu and the model."
msgid "``view_mode`` are the views that will be available; in this case they are the list (tree) and form views. We'll see :ref:`later <howto/rdtraining/15_qwebintro>` that there can be other view modes."
msgid "Examples can be found everywhere in Odoo, but `this <https://github.com/odoo/odoo/blob/09c59012bf80d2ccbafe21c39e604d6cfda72924/addons/crm/views/crm_lost_reason_views.xml#L57-L70>`__ is a good example of a simple action. Pay attention to the structure of the XML data file since you will need it in the following exercise."
msgid "To reduce the complexity in declaring a menu (``ir.ui.menu``) and connecting it to the corresponding action, we can use the ``<menuitem>`` shortcut ."
msgid "The menu ``test_model_menu_action`` is linked to the action ``test_model_action``, and the action is linked to the model ``test.model``. As previously mentioned, the action can be seen as the link between the menu and the model."
msgid "Create the ``estate_menus.xml`` file in the appropriate folder and define it in the ``__manifest__.py`` file. Remember the sequential loading of the data files ;-)"
msgid "Create the three levels of menus for the ``estate.property`` action created in the previous exercise. Refer to the **Goal** of this section for the expected result."
msgid "Restart the server and **refresh the browser**\\ [#refresh]_. You should now see the menus, and you'll even be able to create your first real estate property advertisement!"
msgid "**Goal**: at the end of this section, the selling price should be read-only and the number of bedrooms and the availability date should have default values. Additionally the selling price and availability date values won't be copied when the record is duplicated."
msgid "So far we have only used the generic view for our real estate property advertisements, but in most cases we want to fine tune the view. There are many fine-tunings possible in Odoo, but usually the first step is to make sure that:"
msgid "Before moving further with the view design, let's step back to our model definition. We saw that some attributes, such as ``required=True``, impact the table schema in the database. Other attributes will impact the view or provide default values."
msgid "Restart the server and refresh the browser. You should not be able to set any selling prices. When duplicating a record, the availability date should be empty."
msgid "Any field can be given a default value. In the field definition, add the option ``default=X`` where ``X`` is either a Python literal value (boolean, integer, float, string) or a function taking a model and returning a value::"
msgid "Restart the server, create a new property, then come back to the list view... The property will not be listed! ``active`` is an example of a reserved field with a specific behavior: when a record has ``active=False``, it is automatically removed from any search. To display the created property, you will need to specifically search for inactive records."
msgid "Add a ``state`` field to the ``estate.property`` model. Five values are possible: New, Offer Received, Offer Accepted, Sold and Canceled. It must be required, should not be copied and should have its default value set to 'New'."
msgid "Now that we are able to interact with the UI thanks to the default views, the next step is obvious: we want to define :ref:`our own views <howto/rdtraining/07_basicviews>`."
msgid "We have seen in the :ref:`previous chapter <howto/rdtraining/06_firstui>` that Odoo is able to generate default views for a given model. In practice, the default view is **never** acceptable for a business application. Instead, we should at least organize the various fields in a logical manner."
msgid "in the search view, we must be able to search on more than just the name. Specifically, we want a filter for the 'Available' properties and a shortcut to group by postcode."
msgid "Their root element is ``<tree>``. The most basic version of this view simply lists all the fields to display in the table (where each field is a column):"
msgid "A simple example can be found `here <https://github.com/odoo/odoo/blob/6da14a3aadeb3efc40f145f6c11fc33314b2f15e/addons/crm/views/crm_lost_reason_views.xml#L46-L54>`__."
msgid "Define a list view for the ``estate.property`` model in the appropriate XML file. Check the **Goal** of this section for the fields to display."
msgid "Their root element is ``<form>``. They are composed of high-level structure elements (groups and notebooks) and interactive elements (buttons and fields):"
msgid "It is possible to use regular HTML tags such as ``div`` and ``h1`` as well as the the ``class`` attribute (Odoo provides some built-in classes) to fine-tune the look."
msgid "A simple example can be found `here <https://github.com/odoo/odoo/blob/6da14a3aadeb3efc40f145f6c11fc33314b2f15e/addons/crm/views/crm_lost_reason_views.xml#L16-L44>`__."
msgid "Define a form view for the ``estate.property`` model in the appropriate XML file. Check the **Goal** of this section for the expected final design of the page."
msgid "This might require some trial and error before you get to the expected result ;-) It is advised that you add the fields and the tags one at a time to help understand how it works."
msgid "In order to avoid relaunching the server every time you do a modification to the view, it can be convenient to use the ``--dev xml`` parameter when launching the server:"
msgid "Search views are slightly different from the list and form views since they don't display *content*. Although they apply to a specific model, they are used to filter other views' content (generally aggregated views such as :ref:`reference/views/list`). Beyond the difference in use case, they are defined the same way."
msgid "The default search view generated by Odoo provides a shortcut to filter by ``name``. It is very common to add the fields which the user is likely to filter on in a customized search view."
msgid "Define a search view for the ``estate.property`` model in the appropriate XML file. Check the first image of this section's **Goal** for the list of fields."
msgid "A simple example can be found `here <https://github.com/odoo/odoo/blob/715a24333bf000d5d98b9ede5155d3af32de067c/addons/delivery/views/delivery_view.xml#L30-L44>`__."
msgid "In Odoo, a domain encodes conditions on records: a domain is a list of criteria used to select a subset of a model's records. Each criterion is a triplet with a *field name*, an *operator* and a *value*. A record satisfies a criterion if the specified field meets the condition of the operator applied to the value."
msgid "By default criteria are combined with an implicit AND, meaning *every* criterion needs to be satisfied for a record to match a domain. The logical operators ``&`` (AND), ``|`` (OR) and ``!`` (NOT) can be used to explicitly combine criteria. They are used in prefix position (the operator is inserted before its arguments rather than between). For instance, to select products 'which are services *OR* have a unit price which is *NOT* between 1000 and 2000'::"
msgid "Looking good? At this point we are already able to create models and design a user interface which makes sense business-wise. However, a key component is still missing: the :ref:`link between models <howto/rdtraining/08_relations>`."
msgid "The :ref:`previous chapter <howto/rdtraining/07_basicviews>` covered the creation of custom views for a model containing basic fields. However, in any real business scenario we need more than one model. Moreover, links between models are necessary. One can easily imagine one model containing the customers and another one containing the list of users. You might need to refer to a customer or a user on any existing business model."
msgid "In our real estate module, we want to define the concept of property type. A property type is, for example, a house or an apartment. It is a standard business need to categorize properties according to their type, especially to refine filtering."
msgid "This exercise is a good recap of the previous chapters: you need to create a :ref:`model <howto/rdtraining/04_basicmodel>`, set the :ref:`model <howto/rdtraining/05_securityintro>`, add an :ref:`action and a menu <howto/rdtraining/06_firstui>`, and :ref:`create a view <howto/rdtraining/07_basicviews>`."
msgid "In the real estate module, there are still two missing pieces of information we want on a property: the buyer and the salesperson. The buyer can be any individual, but on the other hand the salesperson must be an employee of the real estate agency (i.e. an Odoo user)."
msgid "``res.users``: the users of the system. Users can be 'internal', i.e. they have access to the Odoo backend. Or they can be 'portal', i.e. they cannot access the backend, only the frontend (e.g. to access their previous orders in eCommerce)."
msgid "Add a buyer and a salesperson to the ``estate.property`` model using the two common models mentioned above. They should be added in a new tab of the form view, as depicted in this section's **Goal**."
msgid "Tip: to get the default value, check the note below or look at an example `here <https://github.com/odoo/odoo/blob/5bb8b927524d062be32f92eb326ef64091301de1/addons/crm/models/crm_lead.py#L92>`__."
msgid "In our real estate module, we want to define the concept of property tags. A property tag is, for example, a property which is 'cozy' or 'renovated'."
msgid "A many2many is a bidirectional multiple relationship: any record on one side can be related to any number of records on the other side. For example, in order to define a link to the ``account.tax`` model on our test model, we can write::"
msgid "By convention, many2many fields have the ``_ids`` suffix. This means that several taxes can be added to our test model. It behaves as a list of records, meaning that accessing the data must be done in a loop::"
msgid "A list of records is known as a *recordset*, i.e. an ordered collection of records. It supports standard Python operations on collections, such as ``len()`` and ``iter()``, plus extra set operations like ``recs1 | recs2``."
msgid "Tip: in the view, use the ``widget=\"many2many_tags\"`` attribute as demonstrated `here <https://github.com/odoo/odoo/blob/5bb8b927524d062be32f92eb326ef64091301de1/addons/crm_iap_lead_website/views/crm_reveal_views.xml#L36>`__. The ``widget`` attribute will be explained in detail in :ref:`a later chapter of the training <howto/rdtraining/12_sprinkles>`. For now, you can try to adding and removing it and see the result ;-)"
msgid "In our real estate module, we want to define the concept of property offers. A property offer is an amount a potential buyer offers to the seller. The offer can be lower or higher than the expected price."
msgid "An offer applies to **one** property, but the same property can have **many** offers. The concept of **many2one** appears once again. However, in this case we want to display the list of offers for a given property so we will use the **one2many** concept."
msgid "A one2many is the inverse of a many2one. For example, we defined on our test model a link to the ``res.partner`` model thanks to the field ``partner_id``. We can define the inverse relation, i.e. the list of test models linked to our partner::"
msgid "By convention, one2many fields have the ``_ids`` suffix. They behave as a list of records, meaning that accessing the data must be done in a loop::"
msgid "Because a :class:`~odoo.fields.One2many` is a virtual relationship, there *must* be a :class:`~odoo.fields.Many2one` field defined in the comodel."
msgid "There are several important things to notice here. First, we don't need an action or a menu for all models. Some models are intended to be accessed only through another model. This is the case in our exercise: an offer is always accessed through a property."
msgid "Second, despite the fact that the ``property_id`` field is required, we did not include it in the views. How does Odoo know which property our offer is linked to? Well that's part of the magic of using the Odoo framework: sometimes things are defined implicitly. When we create a record through a one2many field, the corresponding many2one is populated automatically for convenience."
msgid "Still alive? This chapter is definitely not the easiest one. It introduced a couple of new concepts while relying on everything that was introduced before. The :ref:`next chapter <howto/rdtraining/09_compute_onchange>` will be lighter, don't worry ;-)"
msgid "The :ref:`relations between models <howto/rdtraining/08_relations>` are a key component of any Odoo module. They are necessary for the modelization of any business case. However, we may want links between the fields within a given model. Sometimes the value of one field is determined from the values of other fields and other times we want to help the user with data entry."
msgid "These cases are supported by the concepts of computed fields and onchanges. Although this chapter is not technically complex, the semantics of both concepts is very important. This is also the first time we will write Python logic. Until now we haven't written anything other than class definitions and field declarations."
msgid "In our real estate module, we have defined the living area as well as the garden area. It is then natural to define the total area as the sum of both fields. We will use the concept of a computed field for this, i.e. the value of a given field will be computed from the value of other fields."
msgid "So far fields have been stored directly in and retrieved directly from the database. Fields can also be *computed*. In this case, the field's value is not retrieved from the database but computed on-the-fly by calling a method of the model."
msgid "To create a computed field, create a field and set its attribute :attr:`~odoo.fields.Field.compute` to the name of a method. The computation method should set the value of the computed field for every record in ``self``."
msgid "By convention, :attr:`~odoo.fields.Field.compute` methods are private, meaning that they cannot be called from the presentation tier, only from the business tier (see :ref:`howto/rdtraining/01_architecture`). Private methods have a name starting with an underscore ``_``."
msgid "The value of a computed field usually depends on the values of other fields in the computed record. The ORM expects the developer to specify those dependencies 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::"
msgid "The object ``self`` is a *recordset*, i.e. an ordered collection of records. It supports the standard Python operations on collections, e.g. ``len(self)`` and ``iter(self)``, plus extra set operations such as ``recs1 | recs2``."
msgid "Iterating over ``self`` gives the records one by one, where each record is itself a collection of size 1. You can access/assign fields on single records by using the dot notation, e.g. ``record.name``."
msgid "Many examples of computed fields can be found in Odoo. `Here <https://github.com/odoo/odoo/blob/713dd3777ca0ce9d121d5162a3d63de3237509f4/addons/account/models/account_move.py#L3420-L3423>`__ is a simple one."
msgid "The example is given with a :class:`~odoo.fields.Many2one`, but it is valid for :class:`~odoo.fields.Many2many` or a :class:`~odoo.fields.One2many`. An example can be found `here <https://github.com/odoo/odoo/blob/713dd3777ca0ce9d121d5162a3d63de3237509f4/addons/account/models/account_reconcile_model.py#L248-L251>`__."
msgid "Tip: you might want to try using the :meth:`~odoo.models.BaseModel.mapped` method. See `here <https://github.com/odoo/odoo/blob/f011c9aacf3a3010c436d4e4f408cd9ae265de1b/addons/account/models/account_payment.py#L686>`__ for a simple example."
msgid "In some cases, it might be useful to still be able to set a value directly. In our real estate example, we can define a validity duration for an offer and set a validity date. We would like to be able to set either the duration or the date with one impacting the other."
msgid "An example can be found `here <https://github.com/odoo/odoo/blob/2ccf0bd0dcb2e232ee894f07f24fdc26c51835f7/addons/crm/models/crm_lead.py#L308-L317>`__."
msgid "Where ``date_deadline`` is a computed field which is defined as the sum of two fields from the offer: the ``create_date`` and the ``validity``. Define an appropriate inverse function so that the user can set either the date or the validity."
msgid "Tip: the ``create_date`` is only filled in when the record is created, therefore you will need a fallback to prevent crashing at time of creation."
msgid "Computed fields are **not stored** in the database by default. Therefore it is **not possible** to search on a computed field unless a ``search`` method is defined. This topic is beyond the scope of this training, so we won't cover it. An example can be found `here <https://github.com/odoo/odoo/blob/f011c9aacf3a3010c436d4e4f408cd9ae265de1b/addons/event/models/event_event.py#L188>`__."
msgid "Another solution is to store the field with the ``store=True`` attribute. While this is usually convenient, pay attention to the potential computation load added to your model. Lets re-use our example::"
msgid "Every time the partner ``name`` is changed, the ``description`` is automatically recomputed for **all the records** referring to it! This can quickly become prohibitive to recompute when millions of records need recomputation."
msgid "It is also worth noting that a computed field can depend on another computed field. The ORM is smart enough to correctly recompute all the dependencies in the right order... but sometimes at the cost of degraded performance."
msgid "In general performance must always be kept in mind when defining computed fields. The more complex is your field to compute (e.g. with a lot of dependencies or when a computed field depends on other computed fields), the more time it will take to compute. Always take some time to evaluate the cost of a computed field beforehand. Most of the time it is only when your code reaches a production server that you realize it slows down a whole process. Not cool :-("
msgid "In our real estate module, we also want to help the user with data entry. When the 'garden' field is set, we want to give a default value for the garden area as well as the orientation. Additionally, when the 'garden' field is unset we want the garden area to reset to zero and the orientation to be removed. In this case, the value of a given field modifies the value of other fields."
msgid "The 'onchange' mechanism provides a way for the client interface to update a form without saving anything to the database whenever the user has filled in a field value. To achieve this, we define a method where ``self`` represents the record in the form view and decorate it with :func:`~odoo.api.onchange` to specify which field it is triggered by. Any change you make on ``self`` will be reflected on the form::"
msgid "In this example, changing the partner will also change the name and the description values. It is up to the user whether or not to change the name and description values afterwards. Also note that we do not loop on ``self``, this is because the method is only triggered in a form view, where ``self`` is always a single record."
msgid "Create an ``onchange`` in the ``estate.property`` model in order to set values for the garden area (10) and orientation (North) when garden is set to True. When unset, clear the fields."
msgid "Onchanges methods can also return a non-blocking warning message (`example <https://github.com/odoo/odoo/blob/cd9af815ba591935cda367d33a1d090f248dd18d/addons/payment_authorize/models/payment.py#L34-L36>`__)."
msgid "In many cases, both computed fields and onchanges may be used to achieve the same result. Always prefer computed fields since they are also triggered outside of the context of a form view. Never ever use an onchange to add business logic to your model. This is a **very bad** idea since onchanges are not automatically triggered when creating a record programmatically; they are only triggered in the form view."
msgid "The usual pitfall of computed fields and onchanges is trying to be 'too smart' by adding too much logic. This can have the opposite result of what was expected: the end user is confused from all the automation."
msgid "Computed fields tend to be easier to debug: such a field is set by a given method, so it's easy to track when the value is set. Onchanges, on the other hand, may be confusing: it is very difficult to know the extent of an onchange. Since several onchange methods may set the same fields, it easily becomes difficult to track where a value is coming from."
msgid "When using stored computed fields, pay close attention to the dependencies. When computed fields depend on other computed fields, changing a value can trigger a large number of recomputations. This leads to poor performance."
msgid "So far we have mostly built our module by declaring fields and views. We just introduced business logic in the :ref:`previous chapter <howto/rdtraining/09_compute_onchange>` thanks to computed fields and onchanges. In any real business scenario, we would want to link some business logic to action buttons. In our real estate example, we would like to be able to:"
msgid "One could argue that we can already do these things by changing the state manually, but this is not really convenient. Moreover, we want to add some extra processing: when an offer is accepted we want to set the selling price and the buyer for the property."
msgid "A canceled property cannot be sold and a sold property cannot be canceled. For the sake of clarity, the ``state`` field has been added on the view."
msgid "By assigning ``type=\"object\"`` to our button, the Odoo framework will execute a Python method with ``name=\"action_do_something\"`` on the given model."
msgid "The first important detail to note is that our method name isn't prefixed with an underscore (``_``). This makes our method a **public** method, which can be called directly from the Odoo interface (through an RPC call). Until now, all methods we created (compute, onchange) were called internally, so we used **private** methods prefixed by an underscore. You should always define your methods as private unless they need to be called from the user interface."
msgid "There are hundreds of examples in the Odoo source code. One example is this `button in a view <https://github.com/odoo/odoo/blob/cd9af815ba591935cda367d33a1d090f248dd18d/addons/crm/views/crm_lead_views.xml#L9-L11>`__ and its `corresponding Python method <https://github.com/odoo/odoo/blob/cd9af815ba591935cda367d33a1d090f248dd18d/addons/crm/models/crm_lead.py#L746-L760>`__"
msgid "Add the buttons 'Cancel' and 'Sold' to the ``estate.property`` model. A canceled property cannot be set as sold, and a sold property cannot be canceled."
msgid "Tip: in order to raise an error, you can use the :ref:`UserError<reference/exceptions>` function. There are plenty of examples in the Odoo source code ;-)"
msgid "Tip: to use an icon as a button, have a look `at this example <https://github.com/odoo/odoo/blob/cd9af815ba591935cda367d33a1d090f248dd18d/addons/event/views/event_views.xml#L521>`__."
msgid "In :ref:`howto/rdtraining/06_firstui`, we created an action that was linked to a menu. You may be wondering if it is possible to link an action to a button. Good news, it is! One way to do it is:"
msgid "The :ref:`previous chapter <howto/rdtraining/10_actions>` introduced the ability to add some business logic to our model. We can now link buttons to business code, but how can we prevent users from entering incorrect data? For example, in our real estate module nothing prevents users from setting a negative expected price."
msgid "SQL constraints are defined through the model attribute :attr:`~odoo.models.Model._sql_constraints`. This attribute is assigned a list of triples containing 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."
msgid "You can find a simple example `here <https://github.com/odoo/odoo/blob/24b0b6f07f65b6151d1d06150e376320a44fd20a/addons/analytic/models/analytic_account.py#L20-L23>`__."
msgid "Restart the server with the ``-u estate`` option to see the result. Note that you might have data that prevents a SQL constraint from being set. An error message similar to the following might pop up:"
msgid "For example, if some offers have a price of zero, then the constraint can't be applied. You can delete the problematic data in order to apply the new constraints."
msgid "SQL constraints are an efficient way of ensuring data consistency. However it may be necessary to make more complex checks which require Python code. In this case we need a Python constraint."
msgid "A Python constraint is defined as a method decorated with :func:`~odoo.api.constrains` and is invoked on a recordset. The decorator specifies which fields are involved in the constraint. The constraint is automatically evaluated when any of these fields are modified . The method is expected to raise an exception if its invariant is not satisfied::"
msgid "A simple example can be found `here <https://github.com/odoo/odoo/blob/3783654b87851bdeb11e32da78bb5b62865b869a/addons/account/models/account_payment_term.py#L104-L108>`__."
msgid "Always use the :meth:`~odoo.tools.float_utils.float_compare` and :meth:`~odoo.tools.float_utils.float_is_zero` methods when working with floats!"
msgid "Our real estate module is starting to look good. We added some business logic, and now we make sure the data is consistent. However, the user interface is still a bit rough. Let's see how we can improve it in the :ref:`next chapter <howto/rdtraining/12_sprinkles>`."
msgid "Our real estate module now makes sense from a business perspective. We created :ref:`specific views <howto/rdtraining/07_basicviews>`, added several :ref:`action buttons <howto/rdtraining/10_actions>` and :ref:`constraints <howto/rdtraining/11_constraints>`. However our user interface is still a bit rough. We would like to add some colors to the list views and make some fields and buttons conditionally disappear. For example, the 'Sold' and 'Cancel' buttons should disappear when the property is sold or canceled since it is no longer allowed to change the state at this point."
msgid "This chapter covers a very small subset of what can be done in the views. Do not hesitate to read the reference documentation for a more complete overview."
msgid "The field uses the specific view for ``estate.property.offer``. In some cases we want to define a specific list view which is only used in the context of a form view. For example, we would like to display the list of properties linked to a property type. However, we only want to display 3 fields for clarity: name, expected price and state."
msgid "An example can be found `here <https://github.com/odoo/odoo/blob/0e12fa135882cd5095dbf15fe2f64231c6a84336/addons/event/views/event_tag_views.xml#L27-L33>`__."
msgid "Whenever we've added fields to our models, we've (almost) never had to worry about how these fields would look like in the user interface. For example, a date picker is provided for a ``Date`` field and a ``One2many`` field is automatically displayed as a list. Odoo chooses the right 'widget' depending on the field type."
msgid "However, in some cases, we want a specific representation of a field which can be done thanks to the ``widget`` attribute. We already used it for the ``tag_ids`` field when we used the ``widget=\"many2many_tags\"`` attribute. If we hadn't used it, then the field would have displayed as a list."
msgid "Each field type has a set of widgets which can be used to fine tune its display. Some widgets also take extra options. An exhaustive list can be found in :ref:`reference/js/widgets`."
msgid "Tip: a simple example can be found `here <https://github.com/odoo/odoo/blob/0e12fa135882cd5095dbf15fe2f64231c6a84336/addons/account/views/account_bank_statement_views.xml#L136>`__."
msgid "During the previous exercises, we created several list views. However, at no point did we specify which order the records had to be listed in by default. This is a very important thing for many business cases. For example, in our real estate module we would want to display the highest offers on top of the list."
msgid "Odoo provides several ways to set a default order. The most common way is to define the ``_order`` attribute directly in the model. This way, the retrieved records will follow a deterministic order which will be consistent in all views including when records are searched programmatically. By default there is no order specified, therefore the records will be retrieved in a non-deterministic order depending on PostgreSQL."
msgid "The ``_order`` attribute takes a string containing a list of fields which will be used for sorting. It will be converted to an order_by_ clause in SQL. For example:"
msgid "Ordering is possible at the model level. This has the advantage of a consistent order everywhere a list of records is retrieved. However, it is also possible to define a specific order directly in a view thanks to the ``default_order`` attribute (`example <https://github.com/odoo/odoo/blob/892dd6860733c46caf379fd36f57219082331b66/addons/crm/report/crm_activity_report_views.xml#L30>`__)."
msgid "Both model and view ordering allow flexibility when sorting records, but there is still one case we need to cover: the manual ordering. A user may want to sort records depending on the business logic. For example, in our real estate module we would like to sort the property types manually. It is indeed useful to have the most used types appear at the top of the list. If our real estate agency mainly sells houses, it is more convenient to have 'House' appear before 'Apartment'."
msgid "To do so, a ``sequence`` field is used in combination with the ``handle`` widget. Obviously the ``sequence`` field must be the first field in the ``_order`` attribute."
msgid "Tip: you can find an example here: `model <https://github.com/odoo/odoo/blob/892dd6860733c46caf379fd36f57219082331b66/addons/crm/models/crm_stage.py#L36>`__ and `view <https://github.com/odoo/odoo/blob/892dd6860733c46caf379fd36f57219082331b66/addons/crm/views/crm_stage_views.xml#L23>`__."
msgid "It would be prohibitive to detail all the available features which allow fine tuning of the look of a view. Therefore, we'll stick to the most common ones."
msgid "In our real estate module, we want to modify the behavior of some fields. For example, we don't want to be able to create or edit a property type from the form view. Instead we expect the types to be handled in their appropriate menu. We also want to give tags a color. In order to add these behavior customizations, we can add the ``options`` attribute to several field widgets."
msgid "Add the appropriate option to the ``property_type_id`` field to prevent the creation and the editing of a property type from the property form view. Have a look at the :ref:`Many2one widget documentation <reference/js/widgets>` for more info."
msgid "Then add the appropriate option to the ``tag_ids`` field to add a color picker on the tags. Have a look at the :ref:`FieldMany2ManyTags widget documentation <reference/js/widgets>` for more info."
msgid "In :ref:`howto/rdtraining/06_firstui`, we saw that reserved fields were used for specific behaviors. For example, the ``active`` field is used to automatically filter out inactive records. We added the ``state`` as a reserved field as well. It's now time to use it! A ``state`` field is used in combination with a ``states`` attribute in the view to display buttons conditionally."
msgid "Use the ``states`` attribute to display the header buttons conditionally as depicted in this section's **Goal** (notice how the 'Sold' and 'Cancel' buttons change when the state is modified)."
msgid "More generally, it is possible to make a field ``invisible``, ``readonly`` or ``required`` based on the value of other fields thanks to the ``attrs`` attribute. Note that ``invisible`` can also be applied to other elements of the view such as ``button`` or ``group``."
msgid "The ``attrs`` is a dictionary with the property as a key and a domain as a value. The domain gives the condition in which the property applies. For example:"
msgid "This means that the ``description`` field is invisible when ``is_partner`` is ``False``. It is important to note that a field used in an ``attrs`` **must** be present in the view. If it should not be displayed to the user, we can use the ``invisible`` attribute to hide it."
msgid "Using a (conditional) ``readonly`` attribute in the view can be useful to prevent data entry errors, but keep in mind that it doesn't provide any level of security! There is no check done server-side, therefore it's always possible to write on the field through a RPC call."
msgid "**Goal**: at the end of this section, the property and offer list views should have color decorations. Additionally, offers and tags will be editable directly in the list, and the availability date will be hidden by default."
msgid "When the model only has a few fields, it can be useful to edit records directly through the list view and not have to open the form view. In the real estate example, there is no need to open a form view to add an offer or create a new tag. This can be achieved thanks to the ``editable`` attribute."
msgid "On the other hand, when a model has a lot of fields it can be tempting to add too many fields in the list view and make it unclear. An alternative method is to add the fields, but make them optionally hidden. This can be achieved thanks to the ``optional`` attribute."
msgid "Finally, color codes are useful to visually emphasize records. For example, in the real estate module we would like to display refused offers in red and accepted offers in green. This can be achieved thanks to the ``decoration-{$name}`` attribute (see :ref:`reference/js/widgets` for a complete list):"
msgid "If you want to test the color of the \"Offer Received\" and \"Offer Accepted\" states, add the field in the form view and change it manually (we'll implement the business logic for this later)."
msgid "**Reference**: the documentation related to this section can be found in :ref:`reference/views/search` and :ref:`reference/views/search/defaults`."
msgid "**Goal**: at the end of this section, the available properties will be filtered by default, and searching on the living area returns results where the area is larger than the given number."
msgid "Last but not least, there are some tweaks we would like to apply when searching. First of all, we want to have our 'Available' filter applied by default when we access the properties. To make this happen, we need to use the ``search_default_{$name}`` action context, where ``{$name}`` is the filter name. This means that we can define which filter(s) will be activated by default at the action level."
msgid "Here is an example of an `action <https://github.com/odoo/odoo/blob/6decc32a889b46947db6dd4d42ef995935894a2a/addons/crm/report/crm_opportunity_report_views.xml#L115>`__ with its `corresponding filter <https://github.com/odoo/odoo/blob/6decc32a889b46947db6dd4d42ef995935894a2a/addons/crm/report/crm_opportunity_report_views.xml#L68>`__."
msgid "Another useful improvement in our module would be the ability to search efficiently by living area. In practice, a user will want to search for properties of 'at least' the given area. It is unrealistic to expect users would want to find a property of an exact living area. It is always possible to make a custom search, but that's inconvenient."
msgid "Search view ``<field>`` elements can have a ``filter_domain`` that overrides the domain generated for searching on the given field. In the given domain, ``self`` represents the value entered by the user. In the example below, it is used to search on both ``name`` and ``description`` fields."
msgid "**Goal**: at the end of this section, there will be a stat button on the property type form view which shows the list of all offers related to properties of the given type when it is clicked on."
msgid "If you've already used some functional modules in Odoo, you've probably already encountered a 'stat button'. These buttons are displayed on the top right of a form view and give a quick access to linked documents. In our real estate module, we would like to have a quick link to the offers related to a given property type as depicted in the **Goal** of this section."
msgid "At this point of the tutorial we have already seen most of the concepts to do this. However, there is not a single solution and it can still be confusing if you don't know where to start from. We'll describe a step-by-step solution in the exercise. It can always be useful to find some examples in the Odoo codebase by looking for ``oe_stat_button``."
msgid "The following exercise might be a bit more difficult than the previous ones since it assumes you are able to search for examples in the source code on your own. If you are stuck there is probably someone nearby who can help you ;-)"
msgid "The exercise introduces the concept of :ref:`reference/fields/related`. The easiest way to understand it is to consider it as a specific case of a computed field. The following definition of the ``description`` field:"
msgid "Add the field ``property_type_id`` to ``estate.property.offer``. We can define it as a related field on ``property_id.property_type_id`` and set it as stored."
msgid "Thanks to this field, an offer will be linked to a property type when it's created. You can add the field to the list view of offers to make sure it works."
msgid "Add the field ``offer_count`` to ``estate.property.type``. It is a computed field that counts the number of offers for a given property type (use ``offer_ids`` to do so)."
msgid "At this point, you have all the information necessary to know how many offers are linked to a property type. When in doubt, add ``offer_ids`` and ``offer_count`` directly to the view. The next step is to display the list when clicking on the stat button."
msgid "Create a stat button on ``estate.property.type`` pointing to the ``estate.property.offer`` action. This means you should use the ``type=\"action\"`` attribute (go back to the end of :ref:`howto/rdtraining/10_actions` if you need a refresher)."
msgid "On the ``estate.property.offer`` action, add a domain that defines ``property_type_id`` as equal to the ``active_id`` (= the current record, `here is an example <https://github.com/odoo/odoo/blob/df37ce50e847e3489eb43d1ef6fc1bac6d6af333/addons/event/views/event_views.xml#L162>`__)"
msgid "A powerful aspect of Odoo is its modularity. A module is dedicated to a business need, but modules can also interact with one another. This is useful for extending the functionality of an existing module. For example, in our real estate scenario we want to display the list of a salesperson's properties directly in the regular user view."
msgid "But before going through the specific Odoo module inheritance, let's see how we can alter the behavior of the standard CRUD (Create, Retrieve, Update or Delete) methods."
msgid "In our real estate module, we never had to develop anything specific to be able to do the standard CRUD actions. The Odoo framework provides the necessary tools to do them. In fact, such actions are already included in our model thanks to classical Python inheritance::"
msgid "Our ``class TestModel`` inherits from :class:`~odoo.models.Model` which provides :meth:`~odoo.models.Model.create`, :meth:`~odoo.models.Model.read`, :meth:`~odoo.models.Model.write` and :meth:`~odoo.models.Model.unlink`."
msgid "The decorator :func:`~odoo.api.model` is necessary for the :meth:`~odoo.models.Model.create` method because the content of the recordset ``self`` is not relevant in the context of creation, but it is not necessary for the other CRUD methods."
msgid "In Python 3, ``super()`` is equivalent to ``super(TestModel, self)``. The latter may be necessary when you need to call the parent method with a modified recordset."
msgid "It is very important to **always** call ``super()`` to avoid breaking the flow. There are only a few very specific cases where you don't want to call it."
msgid "Make sure to **always** return data consistent with the parent method. For example, if the parent method returns a ``dict()``, your override must also return a ``dict()``."
msgid "At offer creation, set the property state to 'Offer Received'. Also raise an error if the user tries to create an offer with a lower amount than an existing offer."
msgid "Tip: the ``property_id`` field is available in the ``vals``, but it is an ``int``. To instantiate an ``estate.property`` object, use ``self.env[model_name].browse(value)`` (`example <https://github.com/odoo/odoo/blob/136e4f66cd5cafe7df450514937c7218c7216c93/addons/gamification/models/badge.py#L57>`__)"
msgid "In our real estate module, we would like to display the list of properties linked to a salesperson directly in the Settings / Users & Companies / Users form view. To do this, we need to add a field to the ``res.users`` model and adapt its view to show it."
msgid "The second inheritance mechanism (delegation) allows every record of a model to be linked to a parent model's record and provides transparent access to the fields of this parent record."
msgid "In Odoo, the first mechanism is by far the most used. In our case, we want to add a field to an existing model, which means we will use the first mechanism. For example::"
msgid "A practical example where two fields are added to a model can be found `here <https://github.com/odoo/odoo/blob/60e9410e9aa3be4a9db50f6f7534ba31fea3bc29/addons/account_fleet/models/account_move.py#L39-L47>`__."
msgid "Instead of modifying existing views in place (by overwriting them), Odoo provides view inheritance where children 'extension' views are applied on top of root views. These extension can both add and remove content from their parent view."
msgid "An extension view references its parent using the ``inherit_id`` field. Instead of a single view, its ``arch`` field contains a number of ``xpath`` elements that select and alter the content of their parent view:"
msgid "When matching a single element, the ``position`` attribute can be set directly on the element to be found. Both inheritances below have the same result."
msgid "An example of a view inheritance extension can be found `here <https://github.com/odoo/odoo/blob/691d1f087040f1ec7066e485d19ce3662dfc6501/addons/account_fleet/views/account_move_views.xml#L3-L17>`__."
msgid "Tip: an example an inheritance of the users' view can be found `here <https://github.com/odoo/odoo/blob/691d1f087040f1ec7066e485d19ce3662dfc6501/addons/gamification/views/res_users_views.xml#L5-L14>`__."
msgid "In the :ref:`previous chapter <howto/rdtraining/13_inheritance>`, we used inheritance to modify the behavior of a module. In our real estate scenario, we would like to go a step further and be able to generate invoices for our customers. Odoo provides an Invoicing module, so it would be neat to create an invoice directly from our real estate module, i.e. once a property is set to 'Sold', an invoice is created in the Invoicing application."
msgid "Any time we interact with another module, we need to keep in mind the modularity. If we intend to sell our application to real estate agencies, some may want the invoicing feature but others may not want it."
msgid "The common approach for such use cases is to create a 'link' module. In our case, the module would depend on ``estate`` and ``account`` and would include the invoice creation logic of the estate property. This way the real estate and the accounting modules can be installed independently. When both are installed, the link module provides the new feature."
msgid "When the ``estate_account`` module appears in the list, go ahead and install it! You'll notice that the Invoicing application is installed as well. This is expected since your module depends on it. If you uninstall the Invoicing application, your module will be uninstalled as well."
msgid "It's now time to generate the invoice. We want to add functionality to the ``estate.property`` model, i.e. we want to add some extra logic for when a property is sold. Does that sound familiar? If not, it's a good idea to go back to the :ref:`previous chapter <howto/rdtraining/13_inheritance>` since you might have missed something ;-)"
msgid "As a first step, we need to extend the action called when pressing the :ref:`'Sold' button <howto/rdtraining/10_actions>` on a property. To do so, we need to create a :ref:`model inheritance <howto/rdtraining/13_inheritance>` in the ``estate_account`` module for the ``estate.property`` model. For now, the overridden action will simply return the ``super`` call. Maybe an example will make things clearer::"
msgid "A practical example can be found `here <https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/event_sale/models/account_move.py#L7-L16>`__."
msgid "If the override is working, we can move forward and create the invoice. Unfortunately, there is no easy way to know how to create any given object in Odoo. Most of the time, it is necessary to have a look at its model to find the required fields and provide appropriate values."
msgid "A good way to learn is to look at how other modules already do what you want to do. For example, one of the basic flows of Sales is the creation of an invoice from a sales order. This looks like a good starting point since it does exactly what we want to do. Take some time to read and understand the `_create_invoices <https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/sale/models/sale.py#L610-L717>`__ method. When you are done crying because this simple task looks awfully complex, we can move forward in the tutorial."
msgid "a ``move_type``: it has several `possible values <https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/account/models/account_move.py#L138-L147>`__"
msgid "the ``journal_id`` must be a ``sale`` journal (when in doubt, have a look `here <https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/sale/models/sale.py#L534>`__)"
msgid "Moreover, an invoice line needs to be linked to an invoice. The easiest and most efficient way to link a line to an invoice is to include all lines at invoice creation. To do this, the ``invoice_line_ids`` field is included in the ``account.move`` creation, which is a :class:`~odoo.fields.One2many`. One2many and Many2many use special 'commands' described in :ref:`reference/orm/models/crud`. This format is a list of triplets executed sequentially, where each triplet is a command to execute on the set of records. Here is a simple example to include a One2many field ``line_ids`` at creation of a ``test.model``::"
msgid "This chapter might be one of the most difficult that has been covered so far, but it is the closest to what Odoo development will be in practice. In the :ref:`next chapter <howto/rdtraining/15_qwebintro>`, we will introduce the templating mechanism used in Odoo."
msgid "So far the interface design of our real estate module has been rather limited. Building a list view is straightforward since only the list of fields is necessary. The same holds true for the form view: despite the use of a few tags such as ``<group>`` or ``<page>``, there is very little to do in terms of design."
msgid "However, if we want to give a unique look to our application, it is necessary to go a step further and be able to design new views. Moreover, other features such as PDF reports or website pages need another tool to be created with more flexibility: a templating_ engine."
msgid "You might already be familiar with existing engines such as Jinja (Python), ERB (Ruby) or Twig (PHP). Odoo comes with its own built-in engine: :ref:`reference/qweb`. QWeb is the primary templating engine used by Odoo. It is an XML templating engine and used mostly to generate HTML fragments and pages."
msgid "You probably already have come across the `kanban board`_ in Odoo where the records are displayed in a card-like structure. We will build such a view for our real estate module."
msgid "In our estate application, we would like to add a Kanban view to display our properties. Kanban views are a standard Odoo view (like the form and list views), but their structure is much more flexible. In fact, the structure of each card is a mix of form elements (including basic HTML) and QWeb. The definition of a Kanban view is similar to the definition of the list and form views, except that their root element is ``<kanban>``. In its simplest form, a Kanban view looks like:"
msgid "``<templates>``: defines a list of :ref:`reference/qweb` templates. Kanban views *must* define at least one root template ``kanban-box``, which will be rendered once for each record."
msgid "``<t t-name=\"kanban-box\">``: ``<t>`` is a placeholder element for QWeb directives. In this case, it is used to set the ``name`` of the template to ``kanban-box``"
msgid "Once the Kanban view is working, we can start improving it. If we want to display an element conditionally, we can use the ``t-if`` directive (see :ref:`reference/qweb/conditionals`)."
msgid "``record``: 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 and the latter is the direct value from a :meth:`~odoo.models.Model.read`."
msgid "In the above example, the field ``name`` was added in the ``<templates>`` element, but ``state`` is outside of it. When we need the value of a field but don't want to display it in the view, it is possible to add it outside of the ``<templates>`` element."
msgid "Add the following fields to the Kanban view: expected price, best price, selling price and tags. Pay attention: the best price is only displayed when an offer is received, while the selling price is only displayed when an offer is accepted."
msgid "Let's give the final touch to our view: the properties must be grouped by type by default. You might want to have a look at the various options described in :ref:`reference/views/kanban`."
msgid "Kanban views are a typical example of how it is always a good idea to start from an existing view and fine tune it instead of starting from scratch. There are many options and classes available, so... read and learn!"
msgid "In the previous chapters we saw how to create a fully functional business application. Now we will prepare our code to be shared and learn how to share it."
msgid "Refactor your code to respect the coding guidelines. Don't forget to respect the module structure, the variable names, the method name convention, the model attribute order and the xml ids."
msgid "We will start by creating a git development environment for the 'custom' folder, like we did in the beginning for 'odoo' and 'enterprise'. The PR will target the `odoo/technical-training-sandbox` repository."
msgid "To do this the first step is to `fork <https://guides.github.com/activities/forking/>`__ in GitHub `this repository <https://github.com/odoo/technical-training-sandbox/>`__ to create your own development repository."
msgid "After you successfully created your development repository, we will configure your existing `$HOME/src/custom` folder to be able to commit your work."
msgid "Note that if your work is already in a :ref:`Git and GitHub configured folder <howto/rdtraining/02_setup/development_repository>` the previous steps are not needed. This is the case when you start working in the 'odoo' or 'enterprise' folders."
msgid "Before creating the PR, a new working branch has to be created and used to commit the code. Afterwards the branch will be pushed to the development repository."
msgid "Example: The branch master-sale-fixes-abc on odoo-dev/odoo is a branch containing fixes for the sales app in the odoo/odoo repository, to be deployed in master and done by ABC."
msgid "Open a browser in your development repository `https://github.com/xyz-odoo/technical-training-sandbox`. There will be a button to create a new pull request."
msgid "You will notice that your commit message is used as the pull request message. This occurs if you have only 1 commit. If you have multiple commits, you can either make a summary of the commits as the PR message or if there aren't that many commits you can just copy/paste your commit messages as the PR message."
msgid "Our `welcome <https://github.com/odoo/enterprise/wiki/Welcome>`__ page has extra info about working at Odoo as well as additional `tutorials <https://github.com/odoo/enterprise/wiki/Welcome#3-technical-training>`__ that are both language and Odoo specific."
msgid "Once you are ready to start doing tasks, it is important to note that Odoo follows a `rebasing workflow instead of merging <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>`__ for your PRs. `This cheatsheet <https://github.com/odoo/enterprise/wiki/GIT-Cheatsheet#pull-request-flow>`__ describes how to do this flow. If you want to become more of a rebasing master, then `this tutorial <https://www.atlassian.com/git/tutorials/rewriting-history>`__ is extra useful."
msgid "Odoo has its own :abbr:`CI (Continuous integration)` server named `runbot <https://runbot.odoo.com/>`__. All commits, branches and PR will be tested to avoid regressions or breaking of the stable versions. All the runs that pass the tests are deployed on their own server with demo data."
msgid "Feel free to go to the runbot website and open the last stable version of Odoo to check out all the available applications and functionalities."
msgid "To follow the exercise, it is recommended that you fetch the branch 14.0-core from the repository XXX, it contains a version of the module created during the core training we can use as a starting point."
msgid "So far we have mostly concerned ourselves with implementing useful features. However in most business scenarios *security* quickly becomes a concern: currently,"
msgid "If ``estate_account`` is installed then only agents allowed to interact with invoicing can confirm sales as that's necessary to :ref:`create an invoice <howto/rdtraining/14_other_module/create>`."
msgid "Not all our employees may be real-estate agents (e.g. administrative personnel, property managers, ...), we don't want non-agents to see the available properties."
msgid "All real-estate agents should be able to confirm the sale of a property they can manage, but we do not want them to be able to validate or mark as paid any invoice in the system."
msgid "Because it's easier for users to disable unnecessary security rules than it is to create them from nothing, it's better to err on the side of caution and limiting access: users can relax that access if necessary or convenient."
msgid "It would not be practical to attach individual security rules to employees any time we need a change so *groups* link security rules and users. They correspond to roles that can be assigned to employees."
msgid "For most Odoo applications [#app]_ a good baseline is to have *user* and *manager* (or administrator) roles: the manager can change the configuration of the application and oversee the entirety of its use while the user can well, use the application [#appuser]_."
msgid "In keeping with Odoo's data-driven nature, a group is no more than a record of the ``res.groups`` model. They are normally part of a module's :ref:`master data <howto/rdtraining/C_data>`, defined in one of the module's data files."
msgid "As simple example `can be found here <https://github.com/odoo/odoo/blob/532c083cbbe0ee6e7a940e2bdc9c677bd56b62fa/addons/hr/security/hr_security.xml#L9-L14>`_."
msgid "``category_id`` a *module category*, it is automatically generated from the :ref:`category defined in module manifest files <howto/rdtraining/03_newapp>`."
msgid "Add a record creating a group with the id ``estate_group_user``, the name \"Agent\" and the category ``base.module_category_real_estate_brokerage``."
msgid "Below that, add a record creating a group with the id ``estate_group_manager``, the name \"Manager\" and the category ``base.module_category_real_estate_brokerage``. The ``estate_group_manager`` group needs to imply ``estate_group_user``."
msgid "Via the web interface, create a new user with only the \"real estate agent\" access. The user should not have any Invoicing or Administration access."
msgid "Use a private tab or window to log in with the new user (remember to set a password), as the real-estate agent you should only see the real estate application, and possibly the Discuss (chat) application:"
msgid "Access rights are a way to give users access to models *via* groups: associate an access right to a group, then all users with that group will have the access."
msgid "For instance we don't want real-estate agents to be able to modify what property types are available, so we would not link that access to the \"user\" group."
msgid "Access rights can only give access, they can't remove it: when access is checked, the system looks to see if *any* access right associated with the user (via any group) grants that access."
msgid "A user with the groups A and C will be able to do anything but delete the object while one with B and C will be able to read or update, but not search or read."
msgid "The group of an access right can be omitted, this means the ACL applies to *every user*, this is a useful but risky fallback as depending on the applications installed it can grant even non-users access to the model."
msgid "If a menu item points to a model to which a user doesn't have access and has no submenus which the user can see, the menu will not be displayed."
msgid "Check that your agent user is not able to alter types or tags, or to delete properties, but that they can otherwise create or update properties."
msgid "Since the \"demo\" user was not made a real-estate agent or manager, they should not even be able to see the real-estate application. Use a private tab or window to check for this (the \"demo\" user has the password \"demo\")."
msgid "At the end of this section, agents will not be able to see the properties exclusive to their colleagues; but managers will still be able to see everything."
msgid "Access rights can grant access to an entire model but often we need to be more specific: while an agent can interact with properties in general we may not want them to update or even see properties managed by one of their colleagues."
msgid "Only applies to the \"create\", \"update\" (write) and \"delete\" (unlink) operations: here we want every employee to be able to see other users' records but only the author / assignee can update a record."
msgid "Allows the operation if the current user (``user.id``) is set (e.g. created, or is assigned) on the record, or if the record has no associated user at all."
msgid "If no rule is defined or applies to a model and operation, then the operation is allowed (*default-allow*), this can have odd effects if access rights are not set up correctly (are too permissive)."
msgid "Define a rule which limits agents to only being able to see or modify properties which have no salesperson, or for which they are the salesperson."
msgid "This happens because ``estate_account`` tries to create an invoice during the process, but creating an invoice requires the right to all invoice management."
msgid "We want agents to be able to confirm a sale without them having full invoicing access, which means we need to *bypass* the normal security checks of Odoo in order to create an invoice *despite* the current user not having the right to do so."
msgid "The ``sudo()`` method will create a new recordset in \"sudo mode\", this ignores all access rights and record rules (although hard-coded group and user checks may still apply)."
msgid "These features should generally be avoided, and only used with extreme care, after having checked that the current user and operation should be able to bypass normal access rights validation."
msgid "Operations performed in such modes should also rely on user input as little as possible, and should validate it to the maximum extent they can."
msgid "In Odoo, access rights and record rules are only checked *when performing data access via the ORM* e.g. creating, reading, searching, writing, or unlinking a record via ORM methods. Other methods do *not* necessarily check against any sort of access rights."
msgid "In the previous section, we bypassed the record rules when creating the invoice in ``action_sold``. This bypass can be reached by any user without any access right being checked:"
msgid "Add a print to ``action_sold`` in ``estate_account`` before the creation of the invoice (as creating the invoice accesses the property, therefore triggers an ACL check) e.g.::"
msgid "Execute ``bypass.py`` in ``estate_account``, giving it the name of your database, and the name of your version of ``action_sold`` (unless you named it ``action_sold`` then it's fine)"
msgid "*Currently* the accesses are implicitly checked by accessing data on ``self`` as well as calling ``super()`` (which does the same and *updates* ``self``), triggering access errors and cancelling the transaction \"uncreating\" our invoice."
msgid "*However* if this changes in the future, or we add side-effects to the method (e.g. reporting the sale to a government agency), or bugs are introduced in ``estate``, ... it would be possible for non-agents to trigger operations they should not have access to."
msgid "Therefore when performing non-CRUD operations, or legitimately bypassing the ORM or security, or when triggering other side-effects, it is extremely important to perform *explicit security checks*."
msgid "Calling ``check_access_rule(operations)`` on a non-empty recorset, this verifies that the current user is allowed to perform the operation on *every* record of the set."
msgid "Checking access rights and checking record rules are separate operations, if you're checking record rules you usually want to also check access rights beforehand."
msgid "Before creating the invoice, use ``check_access_rights`` and ``check_access_rule`` to ensure that the current user can update properties in general, and this specific property in particular."
msgid ":ref:`reference/howtos/company` for an overview of multi-company facilities in general, and :ref:`multi-company security rules <howto/company/security>` this in particular."
msgid "For one reason or an other we might need to manage our real-estate business as multiple companies e.g. we might have largely autonomous agencies, or a franchise setup, or multiple brands (possibly from having acquired other real-estate businesses) which remain legally or financially separate from one another."
msgid "Odoo can be used to manage multiple companies inside the same system, however the actual handling is up to individual modules: Odoo itself provides the tools to manage the issue like company-dependent fields and *multi-company rules*, which is what we're going to concern ourselves with."
msgid "We want different agencies to be \"siloed\" from one another, with properties belonging to a given agency and users (whether agents or managers) only able to see properties linked to their agency."
msgid "As before, because this is based on non-trivial records it's easier for a user to relax rules than to tighten them so it makes sense to default to a relatively stronger security model."
msgid "Multi-company rules are usually :ref:`global <reference/security/rules/global>`, otherwise there is a high risk that additional rules would allow bypassing the muti-company rules."
msgid "Add a ``company_id`` field to ``estate.property``, it should be required (we don't want agency-less properties), and should default to the current user's current company."
msgid "Create a few properties in each company (either use the company selector as the manager or use the agents). Unset the default salesman to avoid triggering *that* rule."
msgid "At the end of this section, real-estate agents should not see the Settings menu of the rea-estate application, but should still be able to set the property type or tags."
msgid "Specific Odoo models can be associated directly with groups (or companies, or users). It is important to figure out whether this association is a *security* or a *visibility* feature before using it:"
msgid "*Visibility* features mean a user can still access the model or record otherwise, either through an other part of the interface or by :doc:`perform operations remotely using RPC <../../misc/api/odoo>`, things might just not be visible in the web interface in some contexts."
msgid "Groups on *model fields* (in Python) are a security feature, users outside the group will not be able to retrieve the field, or even know it exists."
msgid "Example: in server actions, `only system users can see or update Python code <https://github.com/odoo/odoo/blob/7058e338a980268df1c502b8b2860bdd8be9f727/odoo/addons/base/models/ir_actions.py#L414-L417>`_."
msgid "Groups on *view elements* (in XML) are a visibility feature, users outside the group will not be able to see the element or its content in the form but they will otherwise be able to interact with the object (including that field)."
msgid "Example: `only managers have an immediate filter to see their teams' leaves <https://github.com/odoo/odoo/blob/8e19904bcaff8300803a7b596c02ec45fcf36ae6/addons/hr_holidays/report/hr_leave_reports.xml#L16>`_."
msgid "Groups on menus and actions are visibility features, the menu or action will not be shown in the interface but that doesn't prevent directly interacting with the underlying object."
msgid "Example: `only system administrators can see the elearning settings menu <https://github.com/odoo/odoo/blob/ff828a3e0c5386dc54e6a46fd71de9272ef3b691/addons/website_slides/views/website_slides_menu_views.xml#L64-L69>`_."
msgid "Despite not having access to the Property Types and Property Tags menus anymore, agents can still access the underlying objects since they can still select tags or a type to set on their properties."
msgid "An Odoo Application is a group of related modules covering a business area or field, usually composed of a base module and a number of expansions on that base to add optional or specific features, or link to other business areas."
msgid "For applications which would be used by most or every employees, the \"application user\" role might be done away with and its abilities granted to all employees directly e.g. generally all employees can submit expenses or take time off."
msgid "Master data is usually part of the technical or business requirements for the module. In other words, such data is often necessary for the module to work properly. This data will always be installed when installing the module."
msgid "We already met technical data previously since we have defined :ref:`security rules<howto/rdtraining/N_security>`, :ref:`views<reference/views>` and :ref:`actions<reference/actions>`. Those are one kind of master data."
msgid "On top of technical data, business data can be defined: countries, currencies, units of measure but also complete country localization (legal reports, tax definitions, chart of account), and much more..."
msgid "Have a set of working data for developers to test the new features and see what it looks like with something they might not have created without it."
msgid "Demo data is automatically loaded when you start the server if you didn't say explicitly you don't want it. This can be done in the database manager or with the command line."
msgid "The keys to use in the manifest to add new data are ``data`` for the master data and ``demo`` for the demo data. Both values should be a list of strings representing the relative path to the files declaring the data."
msgid "Usually, the demo data is set in a ``demo`` folder, the views and actions are put in a ``views`` folder, the security related data is put in a ``security`` folder, and the other data is set in a ``data`` folder."
msgid "The easiest way to declare simple data is by using the CSV format. This is however limited in terms of features: use it for long lists of simple models, but prefer XML in the other cases."
msgid "Add some standard Real Estate Property Types for the `estate` module: Residential, Commercial, Industrial and Land. These should always be installed."
msgid "During the Core Training, we saw in the :ref:`howto/rdtraining/13_inheritance` chapter we could inherit (extend) an existing view. This was a special case of data extension: any data can be extended in a module."
msgid "When you are adding new fields to an existing model in a new module, you might want to populate those fields on the records created in the modules you are depending on. This is done by giving the `xml_id` of the record you want to extend. It won't replace it, in this case we will set the ``field_c`` to the given value for both records."
msgid "Related fields can be set using the ``ref`` key. The value of that key is the ``xml_id`` of the record you want to link. Remember the ``xml_id`` is composed of the name of the module where the data is first declared, followed by a dot, followed by the ``id`` of the record (just the ``id`` works too if you are in the module declaring it)."
msgid "The value to assign to a field is not always a simple string and you might need to compute it. It can also be used to optimize the insertion of related values, or because a constraint forces you to add the related values in batch. See ::ref:`Add X2many fields <howto/rdtraining/C_data/x2m>`."
msgid "In python code, you can use the ``env.ref(self, xml_id, raise_if_not_found=True)`` method. It returns the recordset linked to the ``xml_id`` you specify."
msgid "It will call the ref method, and store the id of the record returned on the field ``related_id`` of the record of type ``tutorial.example`` with id ``id1``."
msgid "Because we don't want a column ``xml_id`` in every single SQL table of the database, we need a mechanism to store it. This is done with the ``ir.model.data`` model."
msgid "The records created with the ``noupdate`` flag won't be updated when upgrading the module that created them, but it will be created if it didn't exist yet."
msgid "In some cases, it makes sense to do the import directly in SQL. This is however discouraged as it bypasses all the features of the ORM, computed fields (including metadata) and python constraints."
msgid "It can help to speed the import time by a lot `with huge files <https://github.com/odoo/enterprise/blob/d46cceef8c594b9056d0115edb7169e207a5986f/product_unspsc/hooks.py#L19>`__."
msgid "For more complex imports like for the `translations <https://github.com/odoo/odoo/blob/e1f8d549895cd9c459e6350430f30d541d02838a/odoo/addons/base/models/ir_translation.py#L24>`__."
msgid "It can be necessary to `initialize the database <https://github.com/odoo/odoo/blob/e1f8d549895cd9c459e6350430f30d541d02838a/odoo/addons/base/data/base_data.sql>`__."
msgid "**Reference**: `Odoo's Test Framework: Learn Best Practices <https://www.youtube.com/watch?v=JEIscps0OOQ>`__ (Odoo Experience 2020) on Youtube."
msgid "This section is only for Odoo employees and people that are contributing to `github.com/odoo`. We highly recommend having your own CI if it is not the case."
msgid "When a test is written, it is important to make sure it always passes when modifications are applied to the source code. To automate this task, we use a development practice called Continuous Integration (CI). This is why we have some bots running all the tests at different moments. Whether you are working at Odoo or not, if you are trying to merge something inside `odoo/odoo`, `odoo/enterprise`, `odoo/upgrade` or on odoo.sh, you will have to go through the CI. If you are working on another project, you should think of adding your own CI."
msgid "A **batch** is a set of builds, depending on the parameters of the bundle. A batch is green (i.e. passes the tests) if all the builds are green."
msgid "A **build** is when we launch a server. It can be divided in sub-builds. Usually there are builds for the community version, the enterprise version (only if there is an enterprise branch but you can force the build), and the migration of the branch. A build is green if every sub-build is green."
msgid "A **sub-build** only does some parts of what a full build does. It is used to speed up the CI process. Generally it is used to split the post install tests in 4 parallel instances. A sub-build is green if all the tests are passing and there are no errors/warnings logged."
msgid "All tests are run whatever the modifications done. Correcting a typo in an error message or refactoring a whole module triggers the same tests. It will install all the modules. This means something might not work if Runbot green but your changes depend on something you don't depend on."
msgid "The localization modules (i.e. country-specific modules) are not installed on Runbot (except the generic one), some modules with external dependencies can be excluded also."
msgid "There is a nightly build running additional tests, like module operations, localization, single module installs, multi-builds for nondeterministic bugs, etc. These are not kept in the standard CI to shorten the time of execution."
msgid "You can also login on a build built by Runbot. There are 3 users usable: `admin`, `demo` and `portal`. The password is the same as the login. This is useful to quickly test things on different versions without having to build it locally. The full logs are also available; these are used for monitoring."
msgid "Robodoo is the guy spamming the CI status as tags on your PRs, but he is also the guy that kindly integrates your commits on the main repositories."
msgid "When the last batch is green, the reviewer can ask robodoo to merge your PR (actually it is more a `rebase` than a `merge`). It will then go to the mergebot."
msgid "It will take the commits in your branch not yet present on the target, stage it and rerun the tests one more time, including the enterprise version even if you are only changing something in community."
msgid "a nondeterministic bug that is already on the target. If you are an Odoo employee, you can check those here: https://runbot.odoo.com/runbot/errors"
msgid "Always check that the issue does not come from you before asking the merge bot to retry: rebase your branch on the target and rerun the tests locally."
msgid "Because Odoo is modular, the tests need to be modular also. This means the modules are defined in the module that adds the functionality you add; and that tests cannot depend on functionality coming from modules your module doesn't depend on."
msgid "If the behavior you want to test can be changed by the installation of another module, you need to ensure that the tag `at_install` is set; otherwise you can use the tag `post_install` to speed up the CI, and ensure it is not changed if it shouldn't."
msgid "**Reference**: the documentation related to this topic can be found in `Python unittest <https://docs.python.org/3/library/unittest.html>`__. and :ref:`Testing Odoo<reference/testing>`."
msgid "Tests should not impact the database by leaving/changing residual data. This is usually done by the test framework by doing a rollback. This is why you must never call ``cr.commit`` in a test (nor anywhere else in the business code)."
msgid "Don't test something that is already tested elsewhere; you can trust the ORM. Most of the tests in business modules should only test the business flows."
msgid "Remember that ``onchange`` only applies in the Form views, not by changing the attributes in python. This also applies in the tests. If you want to emulate a Form view, you can use ``odoo.tests.common.Form``."
msgid "The tests should be located in a ``tests`` folder in the root of your module. Each test file name should start with `test_` and be imported in the ``__init__.py`` of the test folder. You shouldn't import the test folder/module in the ``__init__.py`` of the module."
msgid "Some older tests are extending ``odoo.tests.common.TransactionCase``, but they are less scalable. The difference is that the setup is done per test method and not per test class. The data changed are rollbacked between each test in `SavepointCase` to have the same behavior as in `TransactionCase`."
msgid "All the tests should extend ``odoo.tests.common.SavepointCase``. You usually define a ``setUpClass``, and the tests. After doing the `setUpClass`, you have an `env` available on the class and can start interacting with the ORM."
msgid "For more readability, split your tests into multiple files depending on the scope of the tests. You can also have a Common class that most of the tests should inherit from; that common class can define the whole set up for the module. For instance in `account <https://github.com/odoo/odoo/blob/14.0/addons/account/tests/common.py>`__."
msgid "This tutorial assumes you have completed the :ref:`Core Training <howto/rdtraining>` and have installed :ref:`wkhtmltopdf <howto/rdtraining/02_setup/install-wkhtmltopdf>`."
msgid "We were previously :ref:`introduced to QWeb <howto/rdtraining/15_qwebintro>` in the Core Training where it was used to build a kanban view. Now we will expand on one of QWeb's other main uses: creating PDF reports. A common business requirement is the ability to create documents to send to customers and to use internally. These reports can be used to summarize and display information in an organized template to support the business in different ways. Odoo can additionally add our company's header and footer to our reports with minimal extra effort."
msgid "The documentation related to this topic can be found in :ref:`reference/qweb`, :ref:`reference/reports/report` and the :ref:`reference/actions/report` section of the Actions reference."
msgid "The bulk of a PDF report is its QWeb template. It also typically needs a corresponding ``ir.actions.report`` to include the report within a module's business logic. There is no strict rule for the file names or where they are located, but these two parts are typically stored in 2 separate files within a ``report`` folder in the top level of your module's directory. If a module has many or multiple long report templates, then they are often organized in a logical manner across different files named after the report(s) they contain. All actions for the reports are usually stored in the same file ending with ``_report_views.xml`` regardless of the number of reports it contains."
msgid "Note that you will often see other non-QWeb and non-XML files containing \"report\" in their name also within the report folder. These are unrelated to the reports covered in this tutorial and are covered in :ref:`another advanced topic <howto/rdtraining/K_dashboard>`. For now you can think of them as customized views that use direct SQL queries (sometimes referred to as SQL Views)."
msgid "Don't forget to add whatever files your template and action view will be located in to your ``__manifest__.py``. In this case you will want to add the files to the ``data`` list and remember that the files listed in a manifest are loaded sequentially!"
msgid "In our real estate example there are many useful reports that we could create. One simple report we can create is one that displays all of a property's offers."
msgid "Before we do anything we first need some data to populate our reports or else this tutorial won't be very interesting. When creating reports, you will need some data to test your report code and check that the resulting look is as expected. It is a good idea to test with data that will cover most or all of your expected use cases. A good representation set for our simple report is:"
msgid "Complete :ref:`howto/rdtraining/C_data` (if you haven't done so already) and add the extra cases to your demo data (you may need to create a new database to load in the demo data)."
msgid "Copy this `data file <https://github.com/odoo/technical-training-solutions/blob/14.0-J_reports/estate/data/estate_demo.xml>`__ into a new directory (data) in your estate module and copy `these lines <https://github.com/odoo/technical-training-solutions/blob/14.0-J_reports/estate/__manifest__.py#L21-L23>`__ into your __manifest__.py file (you may need to create a new database to load in the demo data)."
msgid "Before continuing, click through your data in your database and make sure your data is as expected. Of course you can add the data after you write your report code, but then you will not be able to incrementally test portions of your code as you write it. This can make checking for mistakes and debugging your code more difficult in the long run for complicated reports."
msgid "A minimal viable template is viewable under the \"Minimal viable template\" section of the :ref:`reference/reports/templates` documentation. We can modify this example to build our minimal property offers template file:"
msgid "Most of the Odoo specific (i.e. non-HTML) items in our file are explained in the minimal viable template section. Some additional features in our template are:"
msgid "The use of the ``class=\"table\"`` attribute so our table has some nice formatting. Twitter Bootstrap (we're using its table class in this case) and FontAwesome (useful for adding icons) classes can be used in your report template."
msgid "If you are already familiar with website templating engines, then the QWeb directives (i.e. the `t-` commands) probably don't need much explanation and you can just look at its :ref:`documentation <reference/qweb>` and skip ahead to the next subsection."
msgid "Otherwise you are encouraged to read more about them ( `Wikipedia <https://en.wikipedia.org/wiki/Template_processor>`__ has a good high level description), but the general idea is that QWeb provides the ability to dynamically generate web code based on Odoo data and simple commands. I.e. QWeb can access recordset data (and methods) and process simple programming operations such as setting and accessing temporary variables. For example, in the above example:"
msgid "``t-set`` creates a temporary variable called \"offers\" that has its value set by ``t-value`` to the current ``estate.property`` recordset's ``offer_ids``."
msgid "Now that we have a template, we need to make it accessible in our app via a ``ir.actions.report``. A practical example of ``ir.actions.report`` is `here <https://github.com/odoo/odoo/blob/0e12fa135882cd5095dbf15fe2f64231c6a84336/addons/event/report/event_event_reports.xml#L20-L30>`__ corresponding to `this template <https://github.com/odoo/odoo/blob/0e12fa135882cd5095dbf15fe2f64231c6a84336/addons/event/report/event_event_templates.xml#L5>`__. Its contents are all explained in :ref:`the documentation <reference/actions/report>`."
msgid "An ``ir.actions.report`` is primarily used via the Print menu of a model's view. In the practical example, the ``binding_model_id`` specifies which model's views the report should show in and Odoo will auto-magically add it for you. Another common use case of the report action is to link it to a button like we learned in :ref:`howto/rdtraining/10_actions`. This is handy for reports that only make sense under specific conditions. For example, if we wanted to make a \"Final Sale\" report, then we can link it to a \"Print Sale Info\" button that appears in the form view only when the property is \"Sold\"."
msgid "You may have noticed or are wondered why our report template loops through a recordset. When our template is passed more than one record, it can produce one PDF report for all of the records. Using the Print menu in the list view with multiple records selected will demonstrate this."
msgid "Improve the report by adding more data. Refer to the **Goal** of this section to see what additional data you can add and feel free to add even more."
msgid "Bonus: Make an extra flexible report by adding in some logic so that when there are no offers on a property then we don't create a table and instead write something about how there are no offers yet. Hint: you will need to use ``t-if`` and ``t-else``."
msgid "There are two main reasons for using sub-templates. One is to make the code easier to read when working with extra long or complicated templates. The other is to reuse code where possible. Our simple property offers report is useful, but listing property offers information can be useful for more than just one report template. One example is a report that lists all of a salesman's properties' offers."
msgid "See if you can understand how to call a sub-template by reading the :ref:`documentation <reference/qweb/sub-templates>` on it and/or by looking at an `example <https://github.com/odoo/odoo/blob/0e12fa135882cd5095dbf15fe2f64231c6a84336/addons/portal/static/src/xml/portal_chatter.xml#L147-L160>`__ (remember QWeb uses the same control flows regardless if it is for a report or a view in Odoo.)"
msgid "Add a new report for ``res.users`` that allows you to print all of the Real Estate Properties that are visible in their form view (i.e. in the \"Settings\" app). Include the offers for each of those saleman's properties in the same report. Hint: since the ``binding_model_id`` in this case will not be within the estate module, you will need to use ``ref=\"base.model_res_users\"``."
msgid "Inheritance in QWeb uses the same ``xpath`` elements as :ref:`views inheritance <reference/views/inheritance>`. A QWeb template refers to its parent template in a different way though. It is even easier to do by just adding the ``inherit_id`` attribute to the ``template`` element and setting it equal to the *module.parent_template_id*."
msgid "We didn't add any new fields to any of the estate models in `estate_account`, but we can still add information to our existing property report. For example, we know that any \"Sold\" properties will already have an invoice created for them, so we can add this information to our report."
msgid "Extend the property report to include some information about the invoice. You can look at the **Goal** of this section for inspiration (i.e. print a line when the property is Done, otherwise print nothing)."
msgid "All of the following extra features are described further in the :ref:`reference/reports/report` documentation, including how to implement each of them."
msgid "We all know Odoo is used in multiple languages thanks to automated and manual translating. QWeb reports are no exception! Note that sometimes the translations do not work properly if there are unnecessary spaces in your template's text content so try to avoid them when possible (especially leading spaces)."
msgid "You probably are tired of hearing that QWeb creates HTML, but we're saying it again! One of the neat features about reports being written in QWeb is they can be viewed within the web browser. This can be useful if you want to embed a hyperlink that leads to a specific report. Note that the usual security checks will still apply to prevent unauthorized users from accessing the reports."
msgid "Odoo has a built-in barcode image creator that allows for barcodes to be embedded in your reports. Check out the corresponding `code <https://github.com/odoo/odoo/blob/0e12fa135882cd5095dbf15fe2f64231c6a84336/addons/web/controllers/main.py#L2044-L2046>`__ to see all the supported barcode types."
msgid "The term \"Dashboard\" is used in Odoo for objects that display data, but involves different implementations. This tutorial will only focus on the Enterprise view that is used to provide aggregated data visualization. They can be added as a ``view_mode`` to an existing model (i.e. a view you can switch to via the view buttons in the top right of a view), but they are also often used as a view for to a special model customized for data visualization. You may hear these special views referred to as SQL views."
msgid "It is useful to note there is a \"Dashboard\" app in Odoo Community. This app allows users to create their own customized view of data, but the customization is only visible to each user and can only be viewed within the \"Dashboard\" app. Technically it is possible to make global dashboards using this ``board`` module, but it is much easier to do as an Enterprise view. Plus it looks nicer and has extra features not available in ``board``. Some other dashboards within Odoo also exist, but they are custom made and are beyond the scope of this tutorial."
msgid "You probably have already guessed that since dashboard views are an Enterprise view, they must have a dependency on an Enterprise module. The Enterprise module is ``web_dashboard``. Don't forget to add it to your manifest file! It is standard to add dashboards intended to be used as a ``view_mode`` for one of your module's models (in the ``model`` folder``) to the views directory (i.e. the same file that contains the other views for the same model)."
msgid "It is standard to create a separate Enterprise module to add extra Enterprise views and features to a Community module. This is done in a similar manner as the module link technique covered within :ref:`howto/rdtraining/14_other_module`. The difference is that instead of linking 2 different modules, we are extending our `estate` module. We do this by creating a new module and adding both the Community module and its necessary Enterprise module dependencies to its manifest. You will commonly see \"enterprise\" in the module's directory name. To keep this tutorial simple, we will add dashboards to our existing ``estate`` module."
msgid "SQL Views have 2 parts: their xml file (don't forget to add it to your manifest file) and their Python file (don't forget to add it to the appropriate ``__init.py__`` files). The former is the same format as the ``view_mode`` xml while the latter contains a custom model and SQL code to populate its fields. It is standard to add SQL view files to the ``report/`` directory. It is also common to include \"report\" in the name of the SQL view's files. You may be wondering why do we put the files in a report directory? We saw earlier that the dashboard is for data visualization, therefore it is not editable. You can think of dashboards as interactive reports where you can click on statistics, graphs, and charts to see the specific data contributing to them. Note it is also standard to store the xml code for :ref:`PDF report templates <howto/rdtraining/J_reports>` in the report directory."
msgid "There are many useful statistics and visuals we can provide for our real estate example using these options. A full example to reference while doing the exercises in this section is `viewable here <https://github.com/odoo/enterprise/blob/6fd3244ae168dc73c348a9c1870796e89d8ef594/crm_enterprise/views/crm_lead_views.xml#L106-L133>`__ (restricted github repository link)."
msgid "To fully enjoy our dashboard view, we will need good test data to populate it. Test data will allow us to check that the resulting look and statistics are correct. It is a good idea to test with data that will cover most or all of your expected use cases, but is also easy to verify with that your statistics are correct. In our goal's case we are looking at count, sum, average, minimum, and maximum statistics, therefore a good representation set for our dashboard is:"
msgid "Copy this `data file <https://github.com/odoo/technical-training-solutions/blob/14.0-K_dashboard/estate/data/estate_demo.xml>`__ into a new directory called ``data`` in your estate module and copy `these lines <https://github.com/odoo/technical-training-solutions/blob/14.0-K_dashboard/estate/__manifest__.py#L21-L23>`__ into your __manifest__.py file (you may need to create a new database to load in the demo data)."
msgid "Click through your database data and make sure it is what you expect. Of course you can add the data after you write your dashboard code and then test that your view is working as expected."
msgid "Building a dashboard view is very similar to what you have previously done in :ref:`howto/rdtraining/07_basicviews`. For the dashboard view, we use the `dashboard` root element and choose from its possible tags (see all the possibilities and their attributes in the :ref:`reference/views/dashboard` documentation). So a simple dashboard example is:"
msgid "In this example, ``<group>`` adds styling and ``<aggregate>`` declares an aggregation. We indicate which ``field`` we want to aggregate, what ``string`` to display with the value, and how to aggregate it with the `group_operator` attribute. The `group_operator` can use any valid PostgreSQL aggregate function plus the special Odoo defined ``count_distinct``."
msgid "Hopefully you remember how to add views to a window action `view_mode` (hint, it was covered in :ref:`howto/rdtraining/06_firstui`). Now let's make some dashboards!"
msgid "Create a dashboard of aggregated values for the ``estate.property`` model. You can look at the **Goal** of this section for some inspiration. Remember to check that your statistics are calculating as you expect and note that the calculated values take into consideration any applied view filters!"
msgid "Bonus: Add in some aggregations that need a `domain` to make sense (remember domains were also covered in :ref:`howto/rdtraining/07_basicviews`)."
msgid "In this example, we indicate that we're using the `pie_chart` widget with the `name` attribute, the ``title`` for the pie chart, and that we're grouping it by property type."
msgid "Add the pie charts from the **Goal** of this section to your dashboard. Hint: you will need to add `'measure': selling_price` to your pie chart `attrs` if you want to show selling prices grouped by property type."
msgid "Bonus: Add a domain to your selling price pie chart to only include \"sold\" properties (i.e. not \"offer_accepted\" ones). Note that the `'` will need to be escaped since it is declared as part of the `attrs`."
msgid "Similar to how we can use the list view within the form view (we saw this automatically happen for One2many relationships in :ref:`howto/rdtraining/08_relations`), we can add other views within our dashboard view. The most commonly added are the pivot and graph views, but the cohort view is also an option. These views are covered in more depth in :ref:`howto/rdtraining/H_adv_views`. For this topic you are only required to know their names. A dashboard with only subviews is:"
msgid "The `ref` attribute can be added to `<view>` elements to use a specific xml id for that view. If no xml id is provided for a graph or pivot view then the default view will be used. The cohort view will not work in the dashboard without a specific xml id. If you have already created some of these views then you are welcome to add them to your dashboard! Sample graph and pivot views are included in the `solution code <https://github.com/odoo/technical-training-solutions/blob/14.0-K_dashboard/estate/views/estate_property_views.xml#L169-L191>`__ that you are welcome to use as well."
msgid "Add in a graph and a pivot view to your dashboard. Try playing around with the layout of your subviews in relation to your pie charts and aggregated values and refer to the **Goal** of this section for an often used layout. Remember to check that your subviews are displaying your data as expected (and yes, they are also affected by the filters!)."
msgid "This section expects you to have a basic knowledge of SQL. If you have little to no SQL knowledge then `this is a good tutorial to start with <https://selectstarsql.com/>`__ and these `exercises <https://www.pgexercises.com/>`__ are good for those who need a refresher or extra practice."
msgid "Occasionally we want to show data that goes beyond what our model already has in it. We could add a lot of stored computed or related fields (non-stored fields cannot be aggregated or displayed in pie charts), but it would be impractical to store a bunch of fields only for this purpose. We can instead add a custom SQL view to minimize the computational load and keep our model clean of unnecessary fields."
msgid "We will start with the more difficult part: our special report model. This file starts the same as any other model except that we add 2 attributes ``_auto`` and ``_rec_name``::"
msgid "``_auto = False`` indicates that we do not want to store the model in the database and we will create a custom table by overriding the ``BaseModel.init()`` method. ``_rec_name`` indicates which of the model's fields represents a record's name (i.e. the name that will be used in the navigation breadcrumb when opening a record's form view). In this case I left it as 'id' because our property offers don't have a name. We will need the `tools` import later (i.e. ``odoo/odoo/tools``, which is full of all sort of useful helper methods you will probably use in the future). Note that it is standard to include ``report`` in the model name."
msgid "Then we define the fields we need for our dashboard the same way as any other model (like you learned in :ref:`howto/rdtraining/04_basicmodel`), except that every field is ``readonly=True``. After all, our model is for readonly purposes only."
msgid "We use ``tools.drop_view_if_exists`` to ensure that we don't create a conflicting view and then execute the SQL query. It is standard to separate the different parts of the query to allow for easier model extension. Exactly how the query is split up across methods is not standardized, but you will often see at minimum ``_select`` and ``_from`` methods [or something similar] and of course all of these methods will return strings. The columns from the SELECT will populate our model's fields so ensure that your column names match your field names or use alias names that match."
msgid "You won't be able to check if your model is correct until we create a view for it, but you are welcome to check your query directly in your database to see if the results are as you expect. If you struggle with this exercise, then `here is an example <https://github.com/odoo/odoo/blob/7417d8fc138b9de550bc631435bcc08628c29bed/addons/crm/report/crm_activity_report.py>`__ to reference."
msgid "Now that we have our model, we can make its dashboard view. There is no difference to how its made except that its file is located in the ``report`` folder. Since it is a new model not linked to any other model, we will also have to add a new menuitem to view our dashboard. Typically SQL views are added under a first level menu called ``Reporting` (because it's a report, surprise!). Do you remember how to add a ``menuitem``? If not, revisit :ref:`howto/rdtraining/06_firstui`) again."
msgid "Recreate the dashboard in the **Goal** of this section. Hint: it uses the ``formula`` element, which we did not need for our previous dashboard."
msgid "Bonus: Create ``list`` and ``form`` views for your new report model so we don't have to see the ugly defaults when you click on your pie charts."
msgid "**Tip 1** A common mistake in SQL views is to not take into account the duplication of certain data due to table JOINs. For example, in our **Goal** we have a pie chart of the offers' property types. We may be tempted to add a similar pie chart with a domain to only include canceled properties, so we think we are only counting the number of canceled properties by property type. In reality we are still looking at all the offers per property so any property with more than 1 offer will be counted per offer. This example is easily double checked by clicking on the pie chart to see its list view:"
msgid "But for cases such as average aggregations or using a subview such as the pivot view, it is easy to miss this mistake. It is also easy to miss this mistake when you have insufficient test data. In order to add a number of properties canceled by property type pie chart to this report, we would either have to do a hack (too advanced for this tutorial) or simply exclude it from this report."
msgid "**Tip 2** If you have a field that you do not want as a measure (i.e. in your pivot or graph views), then you can add ``store=False`` to it and it will not show."
msgid "This tutorial provides a great overview of what you can do creating an Odoo theme. It is however incomplete. We are currently working on a new detailed theme tutorial, come back here soon to unleash the true power of Odoo themes!"
msgstr ""
#: ../../content/developer/howtos/themes.rst:15
msgid "Odoo celebrates freedom. Freedom for the designer to go further and freedom for the user to customize everything according to their needs."
msgstr ""
#: ../../content/developer/howtos/themes.rst:18
msgid "Ready to create your own theme? Great. Here are some things you should know before you begin. This tutorial is a guide to creating an Odoo theme."
msgstr ""
#: ../../content/developer/howtos/themes.rst:24
msgid "An introduction for web designers"
msgstr ""
#: ../../content/developer/howtos/themes.rst:26
msgid "If you are a web designer using Odoo for the first time, you are in the right place. This introduction will outline the basics of Odoo theme creation. Odoo’s team has created a framework that’s powerful and easy to use."
msgstr ""
#: ../../content/developer/howtos/themes.rst:30
msgid "From common CMS to Odoo"
msgstr ""
#: ../../content/developer/howtos/themes.rst:34
msgid "If you always think and work in the same way, you’ll probably get the same results. If you want something completely new, then try something different."
msgstr ""
#: ../../content/developer/howtos/themes.rst:38
msgid "Where is my header.php file?"
msgstr ""
#: ../../content/developer/howtos/themes.rst:40
msgid "This is usually the first question from a web designer used to working with Wordpress or Joomla and coming to Odoo for the first time."
msgstr ""
#: ../../content/developer/howtos/themes.rst:50
msgid "Indeed, when using common CMSs, you have to code several files (like header.php, page.php, post.php, etc.) in order to create a basic structure for your website. With those systems, this base structure acts as a design foundation that you have to update over time to ensure compatibility within your CMS. So, even after you have spent hours coding the files, you have not even started on the design yet."
msgstr ""
#: ../../content/developer/howtos/themes.rst:52
msgid "This **does not** apply to creating Odoo themes."
msgstr ""
#: ../../content/developer/howtos/themes.rst:56
msgid "We think that theme design should be simple (and powerful). When we created our Website Builder, we decided to start from scratch instead of relying on what already existed. This approach gave us the freedom to focus on the things that are really important for designers: styles, content and the logic behind them. No more struggling with technical stuff."
msgstr ""
#: ../../content/developer/howtos/themes.rst:59
msgid "Odoo default theme structure"
msgstr ""
#: ../../content/developer/howtos/themes.rst:65
msgid "Odoo comes with a default website structure. It is a very basic “theme” that provides minimal structure and layout. When you create a new theme, you are actually **extending** this. Indeed it’s always enabled in your setup and it acts exactly like the CMS’s base structure we mentioned above, except that you don’t have to create or maintain it. It will upgrade automatically within your Odoo installation and, since it is included in the Website Builder module, everything is smoothly integrated by default."
msgstr ""
#: ../../content/developer/howtos/themes.rst:70
msgid "As a result, you are totally free to focus on design while this structure does the job of providing integrations and functionality."
msgstr ""
#: ../../content/developer/howtos/themes.rst:80
msgid "**Main features:**"
msgstr ""
#: ../../content/developer/howtos/themes.rst:82
msgid "Basic layouts for pages, blog, eCommerce and much more"
msgstr ""
#: ../../content/developer/howtos/themes.rst:83
msgid "Website Builder integration"
msgstr ""
#: ../../content/developer/howtos/themes.rst:84
msgid "Basic Snippets"
msgstr ""
#: ../../content/developer/howtos/themes.rst:85
msgid "Automatic Sass compiling"
msgstr ""
#: ../../content/developer/howtos/themes.rst:86
msgid "Automatic Js and CSS minification and combination"
msgstr ""
#: ../../content/developer/howtos/themes.rst:90
msgid "**Main technologies:**"
msgstr ""
#: ../../content/developer/howtos/themes.rst:92
msgid "Twitter Bootstrap"
msgstr ""
#: ../../content/developer/howtos/themes.rst:93
msgid "jQuery"
msgstr ""
#: ../../content/developer/howtos/themes.rst:94
msgid "jQuery UI"
msgstr ""
#: ../../content/developer/howtos/themes.rst:95
msgid "underscore.js"
msgstr ""
#: ../../content/developer/howtos/themes.rst:98
msgid "Thinking \"modular\""
msgstr ""
#: ../../content/developer/howtos/themes.rst:100
msgid "An Odoo theme is not a folder containing HTML or PHP files, it’s a modular framework written in XML. Never worked with XML files before? Don’t worry, after following the tutorial, you’ll be able to create your first theme with only basic knowledge of HTML."
msgstr ""
#: ../../content/developer/howtos/themes.rst:102
msgid "Using classical web design workflows, you usually code the layout of the entire page. The result of this is a “static” web page. You can update the content, of course, but your client will need you to work on making even basic changes."
msgstr ""
#: ../../content/developer/howtos/themes.rst:104
msgid "Creating themes for Odoo is a total change of perspective. Instead of defining the complete layout for a page, you can create blocks (snippets) and let the user choose where to “drag&drop” them, creating the page layout on their own. We call this modular design."
msgstr ""
#: ../../content/developer/howtos/themes.rst:107
msgid "Imagine an Odoo theme as a “list” of elements and options that you have to create or extend. As a designer, your goal is to style these elements in order to achieve a wonderful result, regardless of where the end user chooses to place them."
msgstr ""
#: ../../content/developer/howtos/themes.rst:110
msgid "Let’s take a tour of our “list” elements:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:117
msgid "Snippets (or building-blocks)"
msgstr ""
#: ../../content/developer/howtos/themes.rst:119
msgid "A piece of HTML code. The user will drag&drop, modify and combine them using our built-in Website Builder interface. You can define sets of options and styles for each snippet. The user will choose from them according to their needs."
msgstr ""
#: ../../content/developer/howtos/themes.rst:124
msgid "Pages"
msgstr ""
#: ../../content/developer/howtos/themes.rst:126
msgid "These are normal web pages, except that they will be editable by the final user and that you can define an empty area that the user can “fill” by dragging snippets into it."
msgstr ""
#: ../../content/developer/howtos/themes.rst:137
msgid "Styles"
msgstr ""
#: ../../content/developer/howtos/themes.rst:139
msgid "Styles are defined using SCSS files (or you can use standard CSS files). You can define a style as **default** or **optional**. The default styles are always active in your theme, the optional styles can be enabled or disabled by the user."
msgstr ""
#: ../../content/developer/howtos/themes.rst:144
msgid "Functionalities"
msgstr ""
#: ../../content/developer/howtos/themes.rst:146
msgid "Thanks to Odoo’s modularity, everything can be personalized even more. This means there are endless possibilities for your creativity. Adding functionalities is easy and it’s simple to provide the end user with customizable options."
msgstr ""
#: ../../content/developer/howtos/themes.rst:150
msgid "Odoo's XML files, an overview"
msgstr ""
#: ../../content/developer/howtos/themes.rst:152
msgid "Any Odoo XML file starts with encoding specifications. After that, you have to write your code inside a ``<odoo>`` tag."
msgstr ""
#: ../../content/developer/howtos/themes.rst:165
msgid "Almost every element and option that you create has to be placed inside a ``<template>`` tag, like in this example."
msgstr ""
#: ../../content/developer/howtos/themes.rst:177
msgid "don't misunderstand what ``template`` means. A template tag only defines a piece of html code or options - but it does not necessarily coincide with a visual arrangement of elements."
msgstr ""
#: ../../content/developer/howtos/themes.rst:181
msgid "The previous code defines a title, but it will not be displayed anywhere because that *template* is not associated with any part of the **Odoo default structure**. In order to do that you can use **xpath**, **qWeb** or a combination of both."
msgstr ""
#: ../../content/developer/howtos/themes.rst:186
msgid "Keep reading the tutorial to learn to how properly extend it with your own code."
msgstr ""
#: ../../content/developer/howtos/themes.rst:190
msgid "Create a theme module"
msgstr ""
#: ../../content/developer/howtos/themes.rst:192
msgid "Odoo’s themes are packaged like modules. Even if you are designing a very simple website for your company or client, you need to package the theme like an Odoo module."
msgstr ""
#: ../../content/developer/howtos/themes.rst:196
msgid "``main folder``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:195
msgid "Create a folder and name it like this: ``theme_`` followed by your theme's name."
msgstr ""
#: ../../content/developer/howtos/themes.rst:201
msgid "``__manifest__.py``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:199
msgid "Create an empty document and save it to your folder as ``__manifest__.py``. This will contain the configuration info for your theme."
msgstr ""
#: ../../content/developer/howtos/themes.rst:205
msgid "``__init__.py``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:204
msgid "Create another empty file and name it ``__init__.py``. It's a mandatory system file. Create and leave it blank."
msgstr ""
#: ../../content/developer/howtos/themes.rst:211
msgid "``views`` and ``static`` folders"
msgstr ""
#: ../../content/developer/howtos/themes.rst:208
msgid "Create them in the main folder. In ``views`` you'll place your xml files that define your snippets, your pages and your options. ``static`` folder is the right place for your style , images and custom js code."
msgstr ""
#: ../../content/developer/howtos/themes.rst:215
msgid "Use two underscore characters at the beginning and two at the end of odoo and init file names."
msgstr ""
#: ../../content/developer/howtos/themes.rst:218
msgid "The final result should be like this:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:223
msgid "Edit ``__manifest__.py``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:225
msgid "Open the ``__manifest__.py`` you created and copy/paste the following:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:241
msgid "Replace the first four property’s values with anything you like. These values will be used to identify your new theme in Odoo’s backend."
msgstr ""
#: ../../content/developer/howtos/themes.rst:244
msgid "``category`` defines your module category (always “Theme”) and, after a slash, the subcategory. You can use one subcategory from the Odoo Apps categories list. (https://www.odoo.com/apps/themes)"
msgstr ""
#: ../../content/developer/howtos/themes.rst:246
msgid "``depends`` specifies the modules needed by our theme to work properly. For our tutorial theme, we only need website and website_theme_install to install/update. If you need blogging or eCommerce features as well, you have to add those modules too. If you plan to offer your theme to the majority of users, it is however recommended that you only depend on website and website_theme_install for the base of your theme. You can then create a second theme, which is an extension of the first one and another Odoo feature like the eCommerce."
msgstr ""
#: ../../content/developer/howtos/themes.rst:254
msgid "The ``data`` property will contain the xml files list. Right now it’s empty, but we will add any new files created."
msgstr ""
#: ../../content/developer/howtos/themes.rst:258
msgid "Installing your theme"
msgstr ""
#: ../../content/developer/howtos/themes.rst:260
msgid "To install your theme, you just place your theme folder inside addons in your Odoo installation."
msgstr ""
#: ../../content/developer/howtos/themes.rst:262
msgid "After that, navigate to the Odoo **Website** module, go to :menuselection:`Configuration --> Settings`."
msgstr ""
#: ../../content/developer/howtos/themes.rst:265
msgid "Under **Website** section click the **Pick a Theme** button, then hover over your theme and click **Use this theme**."
msgstr ""
#: ../../content/developer/howtos/themes.rst:269
#: ../../content/developer/howtos/themes.rst:523
#: ../../content/developer/howtos/themes.rst:697
#: ../../content/developer/howtos/themes.rst:982
msgid "Update your theme"
msgstr ""
#: ../../content/developer/howtos/themes.rst:271
msgid "Since XML files are only loaded when you install the theme, you will have to force reloading every time you make changes on an xml file."
msgstr ""
#: ../../content/developer/howtos/themes.rst:273
msgid "To do that, click on the Upgrade button in the theme selection screen."
msgstr ""
#: ../../content/developer/howtos/themes.rst:278
msgid "Structure of an Odoo page"
msgstr ""
#: ../../content/developer/howtos/themes.rst:280
msgid "An Odoo page is the visual result of a combination of 2 kind of elements, **cross-pages** and **unique**. By default, Odoo provides you with a **Header** and a **Footer** (cross-pages) and a unique main element that contains the content that makes your page unique."
msgstr ""
#: ../../content/developer/howtos/themes.rst:285
msgid "Cross-pages elements will be the same on every page. Unique elements are related to a specific page only."
msgstr ""
#: ../../content/developer/howtos/themes.rst:289
msgid "To inspect the default layout, simply create a new page using the Website Builder. Click on :menuselection:`New --> New Page` and add a page name. Inspect the page using your browser."
msgid "The most important feature or your theme should be the style it provides. Odoo includes Bootstrap by default. This means that you can take advantage of all Bootstrap styles and layout functionalities out of the box."
msgstr ""
#: ../../content/developer/howtos/themes.rst:311
msgid "Of course Bootstrap is not enough if you want to provide a unique design. The following steps will guide you through how to add custom styles to your theme. The final result won't be pretty, but will provide you with enough information to build upon on your own."
msgstr ""
#: ../../content/developer/howtos/themes.rst:314
msgid "Let’s start by creating an empty file called **style.scss** and place it in a folder called **scss** in your static folder. Let's add an example rule which adds a top border on the footer. Copy and paste it, then save the file."
msgstr ""
#: ../../content/developer/howtos/themes.rst:323
msgid "Our file is ready but it is not included in our theme yet."
msgstr ""
#: ../../content/developer/howtos/themes.rst:325
msgid "Let’s navigate to the view folder and create an XML file called *assets.xml*. Add the default Odoo xml markup as seen before then copy/paste the following code between the Odoo tags. Remember to replace ``theme_tutorial`` with your theme’s main folder name."
msgstr ""
#: ../../content/developer/howtos/themes.rst:338
msgid "We just created a template specifying our scss file. As you can see, our template has a special attribute called ``inherit_id``. This attribute tells Odoo that our template is referring to another one in order to operate."
msgstr ""
#: ../../content/developer/howtos/themes.rst:343
msgid "In this case, we are referring to ``assets_frontend`` template, located in the ``website`` module. ``assets_frontend`` specifies the list of assets loaded by the website builder and our goal is to add our scss file to this list."
msgstr ""
#: ../../content/developer/howtos/themes.rst:348
msgid "This can be achieved using xpath with the attributes ``expr=\"link[last()]\"`` and ``position=\"after\"``, which means \"*take my style file and place it after the last link in the list of assets*\"."
msgstr ""
#: ../../content/developer/howtos/themes.rst:353
msgid "Placing it after the last one, we ensure that our file will be loaded at the end and takes priority."
msgstr ""
#: ../../content/developer/howtos/themes.rst:356
msgid "Finally add **assets.xml** in your **__manifest__.py** file in the data section."
msgstr ""
#: ../../content/developer/howtos/themes.rst:358
msgid "Update your theme."
msgstr ""
#: ../../content/developer/howtos/themes.rst:363
msgid "Our scss file is now included in our theme, it will be automatically compiled, minified and combined with all Odoo’s assets."
msgstr ""
#: ../../content/developer/howtos/themes.rst:365
msgid "You can now see the beautiful footer border on the website."
msgstr ""
#: ../../content/developer/howtos/themes.rst:369
msgid "Advanced tips for styling"
msgstr ""
#: ../../content/developer/howtos/themes.rst:371
msgid "In the introduction, we saw how to add a basic file of CSS rules into the system to extend the website. This is actually the last step you should need to add style to your theme."
msgstr ""
#: ../../content/developer/howtos/themes.rst:375
msgid "The Odoo website builder already allows the user to create pages by adding a large variety of default well-designed blocks. It also allows a large set of customization possibilities. What may not be straightforward for the user is to combine all of those options to make something really beautiful. This is where your theme can shine. First try to construct the spirit of your theme by enabling a nice set of Odoo default options. This also allows you to ensure two things:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:383
msgid "You do not re-invent something which already exists. If Odoo provides an option to have a border on the footer, don't recode it yourself. Enable it, then extend it if needed."
msgstr ""
#: ../../content/developer/howtos/themes.rst:387
msgid "You ensure that the user can still use all of Odoo features with your theme. Again, if Odoo provides an option to have a border on the footer and that you recode it yourself, you may break the default option or make it useless, making the user have a bad experience. Your option might also not work as well with all the other Odoo features relying on it."
msgstr ""
#: ../../content/developer/howtos/themes.rst:393
msgid "So here are the steps to create a robust and consistent style for your theme:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:395
msgid "\\(1) Set the values for Odoo-provided SCSS variables"
msgstr ""
#: ../../content/developer/howtos/themes.rst:397
msgid "Odoo declares many CSS rules, most being entirely customizable by overriding the related SCSS variables. First, create a new file called primary_variables.scss and add it the same way as the style.scss file. The only difference it that you won't add it in the ``assets_frontend`` template but in the ``_assets_primary_variables`` template."
msgstr ""
#: ../../content/developer/howtos/themes.rst:414
msgid "That file must only contain definition and overrides of SCSS variables and mixins."
msgstr ""
#: ../../content/developer/howtos/themes.rst:417
msgid "Add those:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:438
msgid "This defines two color palettes for the user to choose from. Odoo relies on five named colors to be used by the website builder. By defining those in your theme, you ensure a consistent colored Odoo theme. Starting with Odoo 14.0, a lot more variable are there for you to customize."
msgstr ""
#: ../../content/developer/howtos/themes.rst:445
msgid "All variables defined through those \"palettes\" SCSS maps can later be customized by the users themselves."
msgstr ""
#: ../../content/developer/howtos/themes.rst:448
msgid "\\(2) Set the values for Bootstrap variables that Odoo do not surcharge"
msgstr ""
#: ../../content/developer/howtos/themes.rst:450
msgid "If Odoo does not provide the variable you are looking for, then try to find a Bootstrap variable which allows it. Indeed all Odoo layouts respect Bootstrap structures and use Bootstrap components or extensions of them. So if you customize a bootstrap variable, you add a generic style for the whole user website."
msgstr ""
#: ../../content/developer/howtos/themes.rst:456
msgid "Bootstrap values **must** not be overridden in the primary_variables.scss file but in another dedicated file, extending the ``_assets_frontend_helpers`` template."
msgstr ""
#: ../../content/developer/howtos/themes.rst:467
msgid "With for example:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:475
msgid "Make sure to not override Bootstrap variables which depend on Odoo variables of step (1). Otherwise, you might break the possibility for the user to customize them using the Odoo website builder."
msgstr ""
#: ../../content/developer/howtos/themes.rst:479
msgid "\\(3) Add your own CSS rules as seen in the introduction"
msgstr ""
#: ../../content/developer/howtos/themes.rst:481
msgid "You may also want to design your snippet first, as we will see in a later section of this tutorial."
msgstr ""
#: ../../content/developer/howtos/themes.rst:486
msgid "Extend Odoo Layout"
msgstr ""
#: ../../content/developer/howtos/themes.rst:488
msgid "By default, Odoo header contains a responsive navigation menu and the company’s logo. You can easily add new elements or style the existing one."
msgstr ""
#: ../../content/developer/howtos/themes.rst:490
msgid "To do so, create a **layout.xml** file in your **views** folder and add the default Odoo xml markup."
msgstr ""
#: ../../content/developer/howtos/themes.rst:492
msgid "Then copy-pasting the following code."
msgstr ""
#: ../../content/developer/howtos/themes.rst:508
msgid "This xpath will add a welcome message just before the page content. You can do a lot more of thing with xpath and qweb, check the related doc for more details."
msgstr ""
#: ../../content/developer/howtos/themes.rst:513
msgid "Be careful replacing default elements attributes. As your theme will extend the default one, your changes will take priority in any future Odoo’s update."
msgstr ""
#: ../../content/developer/howtos/themes.rst:516
msgid "The last step is to add layout.xml to the list of xml files used by the theme. To do that, edit your ``__manifest__.py`` file like this"
msgstr ""
#: ../../content/developer/howtos/themes.rst:527
msgid "Great! We successfully added an id to the header and an element after the navigation menu. These changes will be applied to each page of the website."
msgstr ""
#: ../../content/developer/howtos/themes.rst:535
msgid "Create a specific page layout"
msgstr ""
#: ../../content/developer/howtos/themes.rst:537
msgid "Imagine that we want to create a specific layout for a Services page. For this page, we need to add a list of services to the top and give the client the possibility of setting the rest of the page’s layout using snippets."
msgstr ""
#: ../../content/developer/howtos/themes.rst:540
msgid "Inside your *views* folder, create a **pages.xml** file and add the default Odoo markup. Inside ``<odoo>``, instead of defining a ``<template>``, we will create a *page* object."
msgstr ""
#: ../../content/developer/howtos/themes.rst:570
msgid "As you can see, pages come with many additional properties like the *name* or the *url* where it is reachable."
msgstr ""
#: ../../content/developer/howtos/themes.rst:573
msgid "We successfully created a new page layout, but we haven't told the system **how to use it**. To do that, we can use **QWeb**. Wrap the html code into a ``<t>`` tag, like in this example."
msgstr ""
#: ../../content/developer/howtos/themes.rst:604
msgid "Using ``<t t-call=\"website.layout\">`` we will use the Odoo default page layout with our code."
msgstr ""
#: ../../content/developer/howtos/themes.rst:607
msgid "As you can see, we wrapped our code into two ``<div>``, one with ID ``wrap`` and the other one with class ``container``. This is to provide a minimal layout."
msgstr ""
#: ../../content/developer/howtos/themes.rst:609
msgid "The next step is to add an empty area that the user can fill with snippets. To achieve this, just create a ``div`` with ``oe_structure`` class just before closing the ``div#wrap`` element."
msgstr ""
#: ../../content/developer/howtos/themes.rst:649
msgid "You can create as many snippet areas as you like and place them anywhere in your pages."
msgstr ""
#: ../../content/developer/howtos/themes.rst:651
msgid "It is worth mentioning there is an alternative to create pages using the ``<template>`` directive we saw before."
msgstr ""
#: ../../content/developer/howtos/themes.rst:686
msgid "This would allow your page content to be further customized using ``<xpath>``."
msgstr ""
#: ../../content/developer/howtos/themes.rst:688
msgid "Our page is almost ready. Now all we have to do is add **pages.xml** in our **__manifest__.py** file"
msgstr ""
#: ../../content/developer/howtos/themes.rst:701
msgid "Great, our Services page is ready and you’ll be able to access it by navigating to ``<yourwebsite>/services`` (the URL we chose above)."
msgstr ""
#: ../../content/developer/howtos/themes.rst:703
msgid "You will notice that it's possible to drag/drop snippets underneath the *Our Services* list."
msgstr ""
#: ../../content/developer/howtos/themes.rst:709
msgid "Now let's go back to our *pages.xml* and, after our page template, copy/paste the following code."
msgstr ""
#: ../../content/developer/howtos/themes.rst:721
msgid "This code will add a link to the main menu, referring to the page we created."
msgstr ""
#: ../../content/developer/howtos/themes.rst:726
msgid "The **sequence** attribute defines the link’s position in the top menu. In our example, we set the value to ``99`` in order to place it last. I you want to place it in a particular position, you have to replace the value according to your needs."
msgstr ""
#: ../../content/developer/howtos/themes.rst:729
msgid "As you can see inspecting the *data.xml* file in the ``website`` module, the **Home** link is set to ``10`` and the **Contact** us one is set to ``60`` by default. If, for example, you want to place your link in the **middle**, you can set your link’s sequence value to ``40``."
msgstr ""
#: ../../content/developer/howtos/themes.rst:733
msgid "Create Snippets"
msgstr ""
#: ../../content/developer/howtos/themes.rst:735
msgid "Since snippets are how users design and layout pages, they are the most important XML elements of your design. Let’s create a snippet for our Service page. The snippet will display three testimonials and it will be editable by the end user using the Website Builder UI. Navigate to the view folder and create an XML file called **snippets.xml**. Add the default Odoo xml markup and copy/paste the following code. The template contains the HTML markup that will be displayed by the snippet."
msgstr ""
#: ../../content/developer/howtos/themes.rst:767
msgid "As you can see, we used Bootstrap default classes for our three columns. It’s not just about layout, these classes **will be triggered by the Website Builder to make them resizable by the user**."
msgstr ""
#: ../../content/developer/howtos/themes.rst:769
msgid "The previous code will create the snippet’s content, but we still need to place it into the editor bar, so the user will be able to drag&drop it into the page. Copy/paste this template in your **snippets.xml** file."
msgstr ""
#: ../../content/developer/howtos/themes.rst:782
msgid "Using xpath, we are targeting a particular element with id ``snippet_structure``. This means that the snippet will appear in the Structure tab. If you want to change the destination tab, you have just to replace the ``id`` value in the xpath expression."
msgid "The ``<t>`` tag will call our snippet's template and will assign a thumbnail placed in the img folder. You can now drag your snippet from the snippet bar, drop it in your page and see the result."
msgstr ""
#: ../../content/developer/howtos/themes.rst:809
msgid "Snippet options"
msgstr ""
#: ../../content/developer/howtos/themes.rst:811
msgid "Options allow publishers to edit a snippet’s appearance using the Website Builder’s UI. Using Website Builder functionalities, you can create snippet options easily and automatically add them to the UI."
msgstr ""
#: ../../content/developer/howtos/themes.rst:815
msgid "Options group properties"
msgstr ""
#: ../../content/developer/howtos/themes.rst:817
msgid "Options are wrapped in groups. Groups can have properties that define how the included options will interact with the user interface."
msgstr ""
#: ../../content/developer/howtos/themes.rst:819
msgid "``data-selector=\"[css selector(s)]\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:820
msgid "Bind all the options included into the group to a particular element."
msgstr ""
#: ../../content/developer/howtos/themes.rst:821
msgid "``data-js=\" custom method name \"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:822
msgid "Is used to bind custom Javascript methods."
msgstr ""
#: ../../content/developer/howtos/themes.rst:823
msgid "``data-drop-in=\"[css selector(s)]\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:824
msgid "Defines the list of elements where the snippet can be dropped into."
msgstr ""
#: ../../content/developer/howtos/themes.rst:826
msgid "``data-drop-near=\"[css selector(s)]\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:826
msgid "Defines the list of elements that the snippet can be dropped beside."
msgstr ""
#: ../../content/developer/howtos/themes.rst:829
msgid "Default option methods"
msgstr ""
#: ../../content/developer/howtos/themes.rst:831
msgid "Options apply standard CSS classes to the snippet. Depending on the method that you choose, the UI will behave differently."
msgstr ""
#: ../../content/developer/howtos/themes.rst:834
msgid "``data-select-class=\"[class name]\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:834
msgid "More data-select-class in the same group defines a list of classes that the user can choose to apply. Only one option can be enabled at a time."
msgstr ""
#: ../../content/developer/howtos/themes.rst:837
msgid "``data-toggle-class=\"[class name]\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:837
msgid "The data-toggle-class is used to apply one or more CSS classes from the list to a snippet. Multiple selections can be applied at once."
msgstr ""
#: ../../content/developer/howtos/themes.rst:839
msgid "Let's demonstrate how default options work with a basic example."
msgstr ""
#: ../../content/developer/howtos/themes.rst:841
msgid "We start by adding a new file in our views folder - name it **options.xml** and add the default Odoo XML markup. Create a new template copy/pasting the following"
msgstr ""
#: ../../content/developer/howtos/themes.rst:863
msgid "The previous template will inherit the default **snippet_options template** adding our options after the **background** options (xpath expr attribute). To place your options in a particular order, inspect the **snippet_options template** from the **website module** and add your options before/after the desired position."
msgstr ""
#: ../../content/developer/howtos/themes.rst:866
msgid "As you can see, we wrapped all our options inside a DIV tag that will group our options and that will target them to the right selector (``data-selector=\".s_testimonial\"``)."
msgstr ""
#: ../../content/developer/howtos/themes.rst:870
msgid "To define our options we applied ``data-select-class`` attributes to the ``li`` elements. When the user selects an option, the class contained in the attribute will automatically be applied to the element."
msgstr ""
#: ../../content/developer/howtos/themes.rst:874
msgid "Since ``selectClass`` method avoids multiple selections, the last \"empty\" option will reset the snippet to default."
msgstr ""
#: ../../content/developer/howtos/themes.rst:877
msgid "Add **options.xml** to ``__manifest__.py`` and update your theme."
msgstr ""
#: ../../content/developer/howtos/themes.rst:881
msgid "Dropping our snippet onto the page, you will notice that our new options are automatically added to the customize menu. Inspecting the page, you will also notice that the class will be applied to the element when selecting an option."
msgstr ""
#: ../../content/developer/howtos/themes.rst:885
msgid "Let’s create some css rules in order to provide a visual feedback for our options. Open our **style.scss** file and add the following"
msgstr ""
#: ../../content/developer/howtos/themes.rst:907
msgid "Great! We successfully created options for our snippet."
msgstr ""
#: ../../content/developer/howtos/themes.rst:909
msgid "Any time the publisher clicks on an option, the system will add the class specified in the data-select-class attribute."
msgstr ""
#: ../../content/developer/howtos/themes.rst:911
msgid "By replacing ``data-select-class`` with ``data-toggle-class`` you will be able to select more classes at the same time."
msgstr ""
#: ../../content/developer/howtos/themes.rst:916
msgid "Javascript Options"
msgstr ""
#: ../../content/developer/howtos/themes.rst:918
msgid "``data-select-class`` and ``data-toggle-class`` are great if you need to perform simple class change operations. But what if your snippet’s customization needs something more?"
msgstr ""
#: ../../content/developer/howtos/themes.rst:921
msgid "As we said before, ``data-js`` propriety can be assigned to an options group in order to define a custom method. Let’s create one for our *testimonials snippet* by adding a ``data-js`` attribute to the option’s group div that we created earlier."
msgstr ""
#: ../../content/developer/howtos/themes.rst:929
msgid "Done. From now on, the Website Builder will look for a ``s_testimonial_options`` JS option each time the publisher enters in edit mode."
msgstr ""
#: ../../content/developer/howtos/themes.rst:933
msgid "Let's go one step further by creating a javascript file, name it **tutorial_editor.js** and place it into the **static** folder. Copy/paste the following code"
msgstr ""
#: ../../content/developer/howtos/themes.rst:943
msgid "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 ``s_testimonial_options`` name that we used before."
msgstr ""
#: ../../content/developer/howtos/themes.rst:956
msgid "As you will notice, we used a method called ``onFocus`` to trigger our function. The Website Builder provides several events you can use to trigger your custom functions."
msgid "Fires when the publisher selects the snippet for the first time in an editing session or when the snippet is drag-dropped into the page"
msgstr ""
#: ../../content/developer/howtos/themes.rst:962
msgid "``onFocus``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:962
msgid "Fires each time the snippet is selected by the user or when the snippet is drag-dropped into the page."
msgstr ""
#: ../../content/developer/howtos/themes.rst:963
msgid "``onBlur``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:963
msgid "This event occurs when a snippet loses focus."
msgstr ""
#: ../../content/developer/howtos/themes.rst:964
msgid "``onClone``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:964
msgid "Fires just after a snippet is duplicated."
msgstr ""
#: ../../content/developer/howtos/themes.rst:965
msgid "``onRemove``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:965
msgid "It occurs just before that the snippet is removed."
msgstr ""
#: ../../content/developer/howtos/themes.rst:966
msgid "``onBuilt``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:966
msgid "Fires just after that the snippet is drag and dropped into a drop zone. When this event is triggered, the content is already inserted in the page."
msgstr ""
#: ../../content/developer/howtos/themes.rst:967
msgid "``cleanForSave``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:967
msgid "It trigger before the publisher saves the page."
msgstr ""
#: ../../content/developer/howtos/themes.rst:970
msgid "Let’s add our new javascript files to the editor assets list. Go back to **assets.xml** and create a new template like the previous one. This time we have to inherit ``assets_editor`` instead of ``assets_frontend``."
msgstr ""
#: ../../content/developer/howtos/themes.rst:987
msgid "Let’s test our new javascript function. Enter in Edit mode and drop into the page. You should now see the javascript alert that we bound on the ``onFocus`` event. If you close it, then click outside of your snippet and then click in it again, the event will trigger again."
msgstr ""
#: ../../content/developer/howtos/themes.rst:997
msgid "Editing Reference Guide"
msgstr ""
#: ../../content/developer/howtos/themes.rst:999
msgid "Basically all the elements in a page can be edited by the publisher. Besides that, some element types and css classes will trigger special Website Builder functionalities when edited."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1003
msgid "Layout"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1006
msgid "``<section />``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1006
msgid "Any section element can be edited like a block of content. The publisher can move or duplicate it. It’s also possible to set a background image or color. Section is the standard main container of any snippet."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1009
msgid "``.row > .col-lg-*``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1009
msgid "Any large bootstrap columns directly descending from a .row element (respecting Bootstrap structure), will be resizable by the publisher."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1012
msgid "``contenteditable=\"False\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1012
msgid "This attribute will prevent editing to the element and all its children."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1015
msgid "``contenteditable=\"True\"``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1015
msgid "Apply it to an element inside a contenteditable=\"False\" element in order to create an exception and make the element and its children editable."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1018
msgid "``<a href=”#” />``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1018
msgid "In Edit Mode, any link can be edited and styled. Using the “Link Modal” it’s also possible to replace it with a button."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1021
msgid "Media"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1024
msgid "``<span class=”fa” />``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1024
msgid "Pictogram elements. Editing this element will open the Pictogram library to replace the icon. It’s also possible to transform the elements using CSS."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1027
msgid "``<img />``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1027
msgid "Once clicked, the Image Library will open and you can replace images. Transformation is also possible for this kind of element."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1037
msgid "This html structure will create an ``<iframe>`` element editable by the publisher."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1041
msgid "SEO best practice"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1044
msgid "Facilitate content insertion"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1046
msgid "Modern search engine algorithms increasingly focus on content, which means there is less focus on **keyword saturation** and more focus on whether or not the content is **actually relevant to the keywords**."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1048
msgid "As content is so important for SEO, you should concentrate on giving publishers the tools to easily insert it. It is important that your snippets are “content-responsive”, meaning that they should fit the publisher’s content regardless of size."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1050
msgid "Let’s have a look to this example of a classic two column snippet, implemented in two different ways."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1060
msgid "**Bad**"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1062
msgid "Using fixed image, the publisher will be forced to limit the text in order to follow the layout."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1072
msgid "**Good**"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1074
msgid "Using background images that fit the column height, the publisher will be free to add the content regardless of the image’s height."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1079
msgid "Page segmentation"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1081
msgid "Basically, page segmentation means that a page is divided into several separate parts and these parts are treated as separate entries by search engines. When you design pages or snippets, you should be sure to use the right tags in order to facilitate search engine indexing."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1085
msgid "``<article>``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1085
msgid "Specifies an independent block of content. Within it should be a piece of self-contained content that should make sense on its own. You can nest ``<article>`` elements within one another. In this case, it’s implied that the nested elements are related to the outer ``<article>`` element."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1088
msgid "``<header>``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1088
msgid "Indicates the header section of a self-contained block of content (an ``<article>``)."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1091
msgid "``<section>``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1091
msgid "Is the snippet default tag and it specifies a subsection of a block of content. It can be used to split ``<article>`` content into several parts. It’s advisable to use a heading element (``<h1>`` – ``<h6>``) to define the section’s topic."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1101
msgid "``<hgroup>``"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1094
msgid "Is used to wrap a section of headings (``<h1>`` - ``<h6>``). A great example would be an article with both a headline and sub-headline at the top:"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1104
msgid "Describe your page"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1107
msgid "Define keywords"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1108
msgid "You should use appropriate, relevant keywords and synonyms for those keywords. You can define them for each page using the built-in “Promote” function found in the bar at the top."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1111
msgid "Define a title and a description"
msgstr ""
#: ../../content/developer/howtos/themes.rst:1113
msgid "Define them using the “Promote” function. Keep your page titles short and include the main keyword phrase for the page. Good titles evoke an emotional response, ask a question or promise something."
msgstr ""
#: ../../content/developer/howtos/themes.rst:1116
msgid "Descriptions, while not important to search engine rankings, are extremely important in gaining user click-through. These are an opportunity to advertise content and to let people searching know exactly whether the given page contains the information they're looking for. It is important that titles and descriptions on each page are unique."
msgstr ""
#: ../../content/developer/howtos/web.rst:5
msgid "Customizing the web client"
msgstr ""
#: ../../content/developer/howtos/web.rst:9
msgid "this section is really really out of date. It will be updated someday, but meanwhile, this tutorial will probably be frustrating to follow, since it was written a long time ago."
msgstr ""
#: ../../content/developer/howtos/web.rst:18
msgid "This guide is about creating modules for Odoo's web client."
msgstr ""
#: ../../content/developer/howtos/web.rst:20
msgid "To create websites with Odoo, see :doc:`website`; to add business capabilities or extend existing business systems of Odoo, see :doc:`backend`."
msgstr ""
#: ../../content/developer/howtos/web.rst:25
msgid "This guide assumes knowledge of:"
msgstr ""
#: ../../content/developer/howtos/web.rst:27
msgid "Javascript basics and good practices"
msgstr ""
#: ../../content/developer/howtos/web.rst:28
msgid "jQuery_"
msgstr ""
#: ../../content/developer/howtos/web.rst:29
msgid "`Underscore.js`_"
msgstr ""
#: ../../content/developer/howtos/web.rst:31
msgid "It also requires :ref:`an installed Odoo <setup/install>`, and Git_."
msgstr ""
#: ../../content/developer/howtos/web.rst:35
msgid "A Simple Module"
msgstr ""
#: ../../content/developer/howtos/web.rst:37
msgid "Let's start with a simple Odoo module holding basic web component configuration and letting us test the web framework."
msgstr ""
#: ../../content/developer/howtos/web.rst:40
msgid "The example module is available online and can be downloaded using the following command:"
msgstr ""
#: ../../content/developer/howtos/web.rst:47
msgid "This will create a ``petstore`` folder wherever you executed the command. You then need to add that folder to Odoo's :option:`addons path <odoo-bin --addons-path>`, create a new database and install the ``oepetstore`` module."
msgstr ""
#: ../../content/developer/howtos/web.rst:52
msgid "If you browse the ``petstore`` folder, you should see the following content:"
msgstr ""
#: ../../content/developer/howtos/web.rst:78
msgid "The module already holds various server customizations. We'll come back to these later, for now let's focus on the web-related content, in the ``static`` folder."
msgstr ""
#: ../../content/developer/howtos/web.rst:82
msgid "Files used in the \"web\" side of an Odoo module must be placed in a ``static`` folder so they are available to a web browser, files outside that folder can not be fetched by browsers. The ``src/css``, ``src/js`` and ``src/xml`` sub-folders are conventional and not strictly necessary."
msgstr ""
#: ../../content/developer/howtos/web.rst:87
msgid "``oepetstore/static/css/petstore.css``"
msgstr ""
#: ../../content/developer/howtos/web.rst:88
msgid "Currently empty, will hold the CSS_ for pet store content"
msgstr ""
#: ../../content/developer/howtos/web.rst:89
msgid "``oepetstore/static/xml/petstore.xml``"
msgstr ""
#: ../../content/developer/howtos/web.rst:90
msgid "Mostly empty, will hold :ref:`reference/qweb` templates"
msgstr ""
#: ../../content/developer/howtos/web.rst:109
msgid "``oepetstore/static/js/petstore.js``"
msgstr ""
#: ../../content/developer/howtos/web.rst:92
msgid "The most important (and interesting) part, contains the logic of the application (or at least its web-browser side) as javascript. It should currently look like::"
msgstr ""
#: ../../content/developer/howtos/web.rst:111
msgid "Which only prints a small message in the browser's console."
msgstr ""
#: ../../content/developer/howtos/web.rst:113
msgid "The files in the ``static`` folder, need to be defined within the module in order for them to be loaded correctly. Everything in ``src/xml`` is defined in ``__manifest__.py`` while the contents of ``src/css`` and ``src/js`` are defined in ``petstore.xml``, or a similar file."
msgstr ""
#: ../../content/developer/howtos/web.rst:117
msgid "All JavaScript files are concatenated and :term:`minified` to improve application load time."
msgstr ""
#: ../../content/developer/howtos/web.rst:120
msgid "One of the drawback is debugging becomes more difficult as individual files disappear and the code is made significantly less readable. It is possible to disable this process by enabling the \"developer mode\": log into your Odoo instance (user *admin* password *admin* by default) open the user menu (in the top-right corner of the Odoo screen) and select :guilabel:`About Odoo` then :guilabel:`Activate the developer mode`:"
msgstr ""
#: ../../content/developer/howtos/web.rst:134
msgid "This will reload the web client with optimizations disabled, making development and debugging significantly more comfortable."
msgstr ""
#: ../../content/developer/howtos/web.rst:137
msgid "qweb files hooked via __manifest__.py, but js and CSS use bundles"
msgstr ""
#: ../../content/developer/howtos/web.rst:140
msgid "Odoo JavaScript Module"
msgstr ""
#: ../../content/developer/howtos/web.rst:142
msgid "Javascript doesn't have built-in modules. As a result variables defined in different files are all mashed together and may conflict. This has given rise to various module patterns used to build clean namespaces and limit risks of naming conflicts."
msgstr ""
#: ../../content/developer/howtos/web.rst:147
msgid "The Odoo framework uses one such pattern to define modules within web addons, in order to both namespace code and correctly order its loading."
msgstr ""
#: ../../content/developer/howtos/web.rst:150
msgid "``oepetstore/static/js/petstore.js`` contains a module declaration::"
msgstr ""
#: ../../content/developer/howtos/web.rst:156
msgid "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."
msgstr ""
#: ../../content/developer/howtos/web.rst:160
msgid "When the web client loads your module it will call the root function and provide two parameters:"
msgstr ""
#: ../../content/developer/howtos/web.rst:163
msgid "the first parameter is the current instance of the Odoo web client, it gives access to various capabilities defined by the Odoo (translations, network services) as well as objects defined by the core or by other modules."
msgstr ""
#: ../../content/developer/howtos/web.rst:167
msgid "the second parameter is your own local namespace automatically created by the web client. Objects and variables which should be accessible from outside your module (either because the Odoo web client needs to call them or because others may want to customize them) should be set inside that namespace."
msgstr ""
#: ../../content/developer/howtos/web.rst:174
msgid "Classes"
msgstr ""
#: ../../content/developer/howtos/web.rst:176
msgid "Much as modules, and contrary to most object-oriented languages, javascript does not build in *classes*\\ [#classes]_ although it provides roughly equivalent (if lower-level and more verbose) mechanisms."
msgstr ""
#: ../../content/developer/howtos/web.rst:180
msgid "For simplicity and developer-friendliness Odoo web provides a class system based on John Resig's `Simple JavaScript Inheritance`_."
msgstr ""
#: ../../content/developer/howtos/web.rst:183
msgid "New classes are defined by calling the :func:`~odoo.web.Class.extend` method of :class:`odoo.web.Class`::"
msgstr ""
#: ../../content/developer/howtos/web.rst:192
msgid "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."
msgstr ""
#: ../../content/developer/howtos/web.rst:196
msgid "Classes are instantiated using the ``new`` operator::"
msgstr ""
#: ../../content/developer/howtos/web.rst:202
msgid "And attributes of the instance can be accessed via ``this``::"
msgstr ""
#: ../../content/developer/howtos/web.rst:215
msgid "Classes can provide an initializer to perform the initial setup of the instance, by defining an ``init()`` method. The initializer receives the parameters passed when using the ``new`` operator::"
msgstr ""
#: ../../content/developer/howtos/web.rst:232
msgid "It is also possible to create subclasses from existing (used-defined) classes by calling :func:`~odoo.web.Class.extend` on the parent class, as is done to subclass :class:`~odoo.web.Class`::"
msgstr ""
#: ../../content/developer/howtos/web.rst:246
msgid "When overriding a method using inheritance, you can use ``this._super()`` to call the original method::"
msgstr ""
#: ../../content/developer/howtos/web.rst:262
msgid "``_super`` is not a standard method, it is set on-the-fly to the next method in the current inheritance chain, if any. It is only defined during the *synchronous* part of a method call, for use in asynchronous handlers (after network calls or in ``setTimeout`` callbacks) a reference to its value should be retained, it should not be accessed via ``this``::"
msgstr ""
#: ../../content/developer/howtos/web.rst:285
msgid "Widgets Basics"
msgstr ""
#: ../../content/developer/howtos/web.rst:287
msgid "The Odoo web client bundles jQuery_ for easy DOM manipulation. It is useful and provides a better API than standard `W3C DOM`_\\ [#dombugs]_, but insufficient to structure complex applications leading to difficult maintenance."
msgstr ""
#: ../../content/developer/howtos/web.rst:292
msgid "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:`~odoo.Widget` class, a component specialized in handling a page section and displaying information for the user."
msgstr ""
#: ../../content/developer/howtos/web.rst:299
msgid "Your First Widget"
msgstr ""
#: ../../content/developer/howtos/web.rst:301
msgid "The initial demonstration module already provides a basic widget::"
msgstr ""
#: ../../content/developer/howtos/web.rst:309
msgid "It extends :class:`~odoo.Widget` and overrides the standard method :func:`~odoo.Widget.start`, which — much like the previous ``MyClass`` — does little for now."
msgstr ""
#: ../../content/developer/howtos/web.rst:313
msgid "This line at the end of the file::"
msgstr ""
#: ../../content/developer/howtos/web.rst:318
msgid "registers our basic widget as a client action. Client actions will be explained later, for now this is just what allows our widget to be called and displayed when we select the :menuselection:`Pet Store --> Pet Store --> Home Page` menu."
msgstr ""
#: ../../content/developer/howtos/web.rst:325
msgid "because the widget will be called from outside our module, the web client needs its \"fully qualified\" name, not the local version."
msgstr ""
#: ../../content/developer/howtos/web.rst:329
msgid "Display Content"
msgstr ""
#: ../../content/developer/howtos/web.rst:331
msgid "Widgets have a number of methods and features, but the basics are simple:"
msgstr ""
#: ../../content/developer/howtos/web.rst:333
msgid "set up a widget"
msgstr ""
#: ../../content/developer/howtos/web.rst:334
msgid "format the widget's data"
msgstr ""
#: ../../content/developer/howtos/web.rst:335
msgid "display the widget"
msgstr ""
#: ../../content/developer/howtos/web.rst:337
msgid "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."
msgstr ""
#: ../../content/developer/howtos/web.rst:342
msgid "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:`~odoo.Widget.$el` is an empty ``<div>`` element."
msgstr ""
#: ../../content/developer/howtos/web.rst:347
msgid "A ``<div>`` element is usually invisible to the user if it has no content (or without specific styles giving it a size) which is why nothing is displayed on the page when ``HomePage`` is launched."
msgstr ""
#: ../../content/developer/howtos/web.rst:351
msgid "Let's add some content to the widget's root element, using jQuery::"
msgstr ""
#: ../../content/developer/howtos/web.rst:359
msgid "That message will now appear when you open :menuselection:`Pet Store --> Pet Store --> Home Page`"
msgstr ""
#: ../../content/developer/howtos/web.rst:364
msgid "to refresh the javascript code loaded in Odoo Web, you will need to reload the page. There is no need to restart the Odoo server."
msgstr ""
#: ../../content/developer/howtos/web.rst:367
msgid "The ``HomePage`` widget is used by Odoo Web and managed automatically. To learn how to use a widget \"from scratch\" let's create a new one::"
msgstr ""
#: ../../content/developer/howtos/web.rst:376
msgid "We can now add our ``GreetingsWidget`` to the ``HomePage`` by using the ``GreetingsWidget``'s :func:`~odoo.Widget.appendTo` method::"
msgstr ""
#: ../../content/developer/howtos/web.rst:387
msgid "``HomePage`` first adds its own content to its DOM root"
msgstr ""
#: ../../content/developer/howtos/web.rst:388
msgid "``HomePage`` then instantiates ``GreetingsWidget``"
msgstr ""
#: ../../content/developer/howtos/web.rst:389
msgid "Finally it tells ``GreetingsWidget`` where to insert itself, delegating part of its :attr:`~odoo.Widget.$el` to the ``GreetingsWidget``."
msgstr ""
#: ../../content/developer/howtos/web.rst:392
msgid "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:`~odoo.Widget.start` method will be called during the call to :func:`~odoo.Widget.appendTo`."
msgstr ""
#: ../../content/developer/howtos/web.rst:397
msgid "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 <odoo.Widget.className>`::"
msgstr ""
#: ../../content/developer/howtos/web.rst:411
msgid "If you can find the relevant section of the DOM (right-click on the text then :guilabel:`Inspect Element`), it should look like this:"
msgstr ""
#: ../../content/developer/howtos/web.rst:423
msgid "Which clearly shows the two ``<div>`` elements automatically created by :class:`~odoo.Widget`, because we added some classes on them."
msgstr ""
#: ../../content/developer/howtos/web.rst:426
msgid "We can also see the two message-holding divs we added ourselves"
msgstr ""
#: ../../content/developer/howtos/web.rst:428
msgid "Finally, note the ``<div class=\"oe_petstore_greetings\">`` element which represents the ``GreetingsWidget`` instance is *inside* the ``<div class=\"oe_petstore_homepage\">`` which represents the ``HomePage`` instance, since we appended"
msgstr ""
#: ../../content/developer/howtos/web.rst:434
msgid "Widget Parents and Children"
msgstr ""
#: ../../content/developer/howtos/web.rst:436
msgid "In the previous part, we instantiated a widget using this syntax::"
msgstr ""
#: ../../content/developer/howtos/web.rst:440
msgid "The first argument is ``this``, which in that case was a ``HomePage`` instance. This tells the widget being created which other widget is its *parent*."
msgstr ""
#: ../../content/developer/howtos/web.rst:444
msgid "As we've seen, widgets are usually inserted in the DOM by another widget and *inside* that other widget's root element. This means most widgets are \"part\" of another widget, and exist on behalf of it. We call the container the *parent*, and the contained widget the *child*."
msgstr ""
#: ../../content/developer/howtos/web.rst:449
msgid "Due to multiple technical and conceptual reasons, it is necessary for a widget to know who is its parent and who are its children."
msgstr ""
#: ../../content/developer/howtos/web.rst:460
msgid ":func:`~odoo.Widget.getParent`"
msgstr ""
#: ../../content/developer/howtos/web.rst:453
msgid "can be used to get the parent of a widget::"
msgstr ""
#: ../../content/developer/howtos/web.rst:472
msgid ":func:`~odoo.Widget.getChildren`"
msgstr ""
#: ../../content/developer/howtos/web.rst:463
msgid "can be used to get a list of its children::"
msgstr ""
#: ../../content/developer/howtos/web.rst:474
msgid "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::"
msgstr ""
#: ../../content/developer/howtos/web.rst:485
msgid "Finally, if a widget does not have a parent (e.g. because it's the root widget of the application), ``null`` can be provided as parent::"
msgstr ""
#: ../../content/developer/howtos/web.rst:491
msgid "Destroying Widgets"
msgstr ""
#: ../../content/developer/howtos/web.rst:493
msgid "If you can display content to your users, you should also be able to erase it. This is done via the :func:`~odoo.Widget.destroy` method::"
msgstr ""
#: ../../content/developer/howtos/web.rst:498
msgid "When a widget is destroyed it will first call :func:`~odoo.Widget.destroy` on all its children. Then it erases itself from the DOM. If you have set up permanent structures in :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:`~odoo.Widget.destroy`."
msgstr ""
#: ../../content/developer/howtos/web.rst:507
msgid "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"
msgstr ""
#: ../../content/developer/howtos/web.rst:513
msgid "The QWeb Template Engine"
msgstr ""
#: ../../content/developer/howtos/web.rst:515
msgid "In the previous section we added content to our widgets by directly manipulating (and adding to) their DOM::"
msgstr ""
#: ../../content/developer/howtos/web.rst:520
msgid "This allows generating and displaying any type of content, but gets unwieldy when generating significant amounts of DOM (lots of duplication, quoting issues, ...)"
msgstr ""
#: ../../content/developer/howtos/web.rst:524
msgid "As many other environments, Odoo's solution is to use a `template engine`_. Odoo's template engine is called :ref:`reference/qweb`."
msgstr ""
#: ../../content/developer/howtos/web.rst:527
msgid "QWeb is an XML-based templating language, similar to `Genshi <http://en.wikipedia.org/wiki/Genshi_(templating_language)>`_, `Thymeleaf <http://en.wikipedia.org/wiki/Thymeleaf>`_ or `Facelets <http://en.wikipedia.org/wiki/Facelets>`_. It has the following characteristics:"
msgstr ""
#: ../../content/developer/howtos/web.rst:533
msgid "It's implemented fully in JavaScript and rendered in the browser"
msgid "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:`~odoo.Widget` without relying on QWeb)"
msgstr ""
#: ../../content/developer/howtos/web.rst:541
msgid "The rationale behind using QWeb instead of existing javascript template engines is the extensibility of pre-existing (third-party) templates, much like Odoo :ref:`views <reference/views>`."
msgstr ""
#: ../../content/developer/howtos/web.rst:545
msgid "Most javascript template engines are text-based which precludes easy structural extensibility where an XML-based templating engine can be generically altered using e.g. XPath or CSS and a tree-alteration DSL (or even just XSLT). This flexibility and extensibility is a core characteristic of Odoo, and losing it was considered unacceptable."
msgstr ""
#: ../../content/developer/howtos/web.rst:552
msgid "Using QWeb"
msgstr ""
#: ../../content/developer/howtos/web.rst:554
msgid "First let's define a simple QWeb template in the almost-empty ``oepetstore/static/src/xml/petstore.xml`` file:"
msgstr ""
#: ../../content/developer/howtos/web.rst:566
msgid "Now we can use this template inside of the ``HomePage`` widget. Using the ``QWeb`` loader variable defined at the top of the page, we can call to the template defined in the XML file::"
msgstr ""
#: ../../content/developer/howtos/web.rst:576
msgid ":func:`QWeb.render` looks for the specified template, renders it to a string and returns the result."
msgstr ""
#: ../../content/developer/howtos/web.rst:579
msgid "However, because :class:`~odoo.Widget` has special integration for QWeb the template can be set directly on the widget via its :attr:`~odoo.Widget.template` attribute::"
msgstr ""
#: ../../content/developer/howtos/web.rst:590
msgid "Although the result looks similar, there are two differences between these usages:"
msgstr ""
#: ../../content/developer/howtos/web.rst:593
msgid "with the second version, the template is rendered right before :func:`~odoo.Widget.start` is called"
msgstr ""
#: ../../content/developer/howtos/web.rst:595
msgid "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\" sub-widget also gets a red background"
msgstr ""
#: ../../content/developer/howtos/web.rst:602
msgid "templates should have a single non-``t`` root element, especially if 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)"
msgstr ""
#: ../../content/developer/howtos/web.rst:608
msgid "QWeb Context"
msgstr ""
#: ../../content/developer/howtos/web.rst:610
msgid "QWeb templates can be given data and can contain basic display logic."
msgstr ""
#: ../../content/developer/howtos/web.rst:612
msgid "For explicit calls to :func:`QWeb.render`, the template data is passed as second parameter::"
msgstr ""
#: ../../content/developer/howtos/web.rst:617
msgid "with the template modified to:"
msgstr ""
#: ../../content/developer/howtos/web.rst:625
msgid "will result in:"
msgstr ""
#: ../../content/developer/howtos/web.rst:631
msgid "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:`~odoo.Widget.start` is called (the widget's state will essentially be that set up by :func:`~odoo.Widget.init`):"
msgstr ""
#: ../../content/developer/howtos/web.rst:655
#: ../../content/developer/misc/api/odoo.rst:210
#: ../../content/developer/misc/api/odoo.rst:296
#: ../../content/developer/misc/api/odoo.rst:338
#: ../../content/developer/misc/api/odoo.rst:377
#: ../../content/developer/misc/api/odoo.rst:417
#: ../../content/developer/misc/api/odoo.rst:481
#: ../../content/developer/misc/api/odoo.rst:514
#: ../../content/developer/misc/api/odoo.rst:562
#: ../../content/developer/misc/api/odoo.rst:645
#: ../../content/developer/misc/api/odoo.rst:716
#: ../../content/developer/misc/api/odoo.rst:785
#: ../../content/developer/misc/api/odoo.rst:834
#: ../../content/developer/misc/api/odoo.rst:946
#: ../../content/developer/misc/api/odoo.rst:1111
msgid "Result:"
msgstr ""
#: ../../content/developer/howtos/web.rst:662
msgid "Template Declaration"
msgstr ""
#: ../../content/developer/howtos/web.rst:664
msgid "We've seen how to *render* QWeb templates, let's now see the syntax of the templates themselves."
msgstr ""
#: ../../content/developer/howtos/web.rst:667
msgid "A QWeb template is composed of regular XML mixed with QWeb *directives*. A QWeb directive is declared with XML attributes starting with ``t-``."
msgstr ""
#: ../../content/developer/howtos/web.rst:670
msgid "The most basic directive is ``t-name``, used to declare new templates in a template file:"
msgstr ""
#: ../../content/developer/howtos/web.rst:681
msgid "``t-name`` takes the name of the template being defined, and declares that it can be called using :func:`QWeb.render`. It can only be used at the top-level of a template file."
msgstr ""
#: ../../content/developer/howtos/web.rst:686
msgid "Escaping"
msgstr ""
#: ../../content/developer/howtos/web.rst:688
msgid "The ``t-esc`` directive can be used to output text:"
msgstr ""
#: ../../content/developer/howtos/web.rst:694
msgid "It takes a Javascript expression which is evaluated, the result of the expression is then HTML-escaped and inserted in the document. Since it's an expression it's possible to provide just a variable name as above, or a more complex expression like a computation:"
msgstr ""
#: ../../content/developer/howtos/web.rst:703
msgid "or method calls:"
msgstr ""
#: ../../content/developer/howtos/web.rst:710
msgid "Outputting HTML"
msgstr ""
#: ../../content/developer/howtos/web.rst:712
msgid "To inject HTML in the page being rendered, use ``t-raw``. Like ``t-esc`` it takes an arbitrary Javascript expression as parameter, but it does not perform an HTML-escape step."
msgstr ""
#: ../../content/developer/howtos/web.rst:722
msgid "``t-raw`` *must not* be used on any data which may contain non-escaped user-provided content as this leads to `cross-site scripting`_ vulnerabilities"
msgid "QWeb can have conditional blocks using ``t-if``. The directive takes an arbitrary expression, if the expression is falsy (``false``, ``null``, ``0`` or an empty string) the whole block is suppressed, otherwise it is displayed."
msgstr ""
#: ../../content/developer/howtos/web.rst:746
msgid "QWeb doesn't have an \"else\" structure, use a second ``t-if`` with the original condition inverted. You may want to store the condition in a local variable if it's a complex or expensive expression."
msgstr ""
#: ../../content/developer/howtos/web.rst:751
msgid "Iteration"
msgstr ""
#: ../../content/developer/howtos/web.rst:753
msgid "To iterate on a list, use ``t-foreach`` and ``t-as``. ``t-foreach`` takes an expression returning a list to iterate on ``t-as`` takes a variable name to bind to each item during iteration."
msgstr ""
#: ../../content/developer/howtos/web.rst:767
msgid "``t-foreach`` can also be used with numbers and objects (dictionaries)"
msgstr ""
#: ../../content/developer/howtos/web.rst:771
msgid "Defining attributes"
msgstr ""
#: ../../content/developer/howtos/web.rst:773
msgid "QWeb provides two related directives to define computed attributes: :samp:`t-att-{name}` and :samp:`t-attf-{name}`. In either case, *name* is the name of the attribute to create (e.g. ``t-att-id`` defines the attribute ``id`` after rendering)."
msgstr ""
#: ../../content/developer/howtos/web.rst:778
msgid "``t-att-`` takes a javascript expression whose result is set as the attribute's value, it is most useful if all of the attribute's value is computed:"
msgstr ""
#: ../../content/developer/howtos/web.rst:789
msgid "``t-attf-`` takes a *format string*. A format string is literal text with interpolation blocks inside, an interpolation block is a javascript expression between ``{{`` and ``}}``, which will be replaced by the result of the expression. It is most useful for attributes which are partially literal and partially computed such as a class:"
msgstr ""
#: ../../content/developer/howtos/web.rst:802
msgid "Calling other templates"
msgstr ""
#: ../../content/developer/howtos/web.rst:804
msgid "Templates can be split into sub-templates (for simplicity, maintainability, reusability or to avoid excessive markup nesting)."
msgstr ""
#: ../../content/developer/howtos/web.rst:807
msgid "This is done using the ``t-call`` directive, which takes the name of the template to render:"
msgstr ""
#: ../../content/developer/howtos/web.rst:821
msgid "rendering the ``A`` template will result in:"
msgstr ""
#: ../../content/developer/howtos/web.rst:829
msgid "Sub-templates inherit the rendering context of their caller."
msgstr ""
#: ../../content/developer/howtos/web.rst:832
msgid "To Learn More About QWeb"
msgstr ""
#: ../../content/developer/howtos/web.rst:834
msgid "For a QWeb reference, see :ref:`reference/qweb`."
msgstr ""
#: ../../content/developer/howtos/web.rst:837
#: ../../content/developer/howtos/web.rst:1103
msgid "Exercise"
msgstr ""
#: ../../content/developer/howtos/web.rst:839
msgid "Usage of QWeb in Widgets"
msgstr ""
#: ../../content/developer/howtos/web.rst:841
msgid "Create a widget whose constructor takes two parameters aside from ``parent``: ``product_names`` and ``color``."
msgstr ""
#: ../../content/developer/howtos/web.rst:844
msgid "``product_names`` should an array of strings, each one the name of a product"
msgstr ""
#: ../../content/developer/howtos/web.rst:846
msgid "``color`` is a string containing a color in CSS color format (ie: ``#000000`` for black)."
msgstr ""
#: ../../content/developer/howtos/web.rst:849
msgid "The widget should display the given product names one under the other, each one in a separate box with a background color with the value of ``color`` and a border. You should use QWeb to render the HTML. Any necessary CSS should be in ``oepetstore/static/src/css/petstore.css``."
msgstr ""
#: ../../content/developer/howtos/web.rst:854
msgid "Use the widget in ``HomePage`` with half a dozen products."
msgstr ""
#: ../../content/developer/howtos/web.rst:918
msgid "Widget Helpers"
msgstr ""
#: ../../content/developer/howtos/web.rst:921
msgid "``Widget``'s jQuery Selector"
msgstr ""
#: ../../content/developer/howtos/web.rst:923
msgid "Selecting DOM elements within a widget can be performed by calling the ``find()`` method on the widget's DOM root::"
msgstr ""
#: ../../content/developer/howtos/web.rst:928
msgid "But because it's a common operation, :class:`~odoo.Widget` provides an equivalent shortcut through the :func:`~odoo.Widget.$` method::"
msgstr ""
#: ../../content/developer/howtos/web.rst:939
msgid "The global jQuery function ``$()`` should *never* be used unless it is absolutely necessary: selection on a widget's root are scoped to the widget and local to it, but selections with ``$()`` are global to the page/application and may match parts of other widgets and views, leading to odd or dangerous side-effects. Since a widget should generally act only on the DOM section it owns, there is no cause for global selection."
msgstr ""
#: ../../content/developer/howtos/web.rst:947
msgid "Easier DOM Events Binding"
msgstr ""
#: ../../content/developer/howtos/web.rst:949
msgid "We have previously bound DOM events using normal jQuery event handlers (e.g. ``.click()`` or ``.change()``) on widget elements::"
msgstr ""
#: ../../content/developer/howtos/web.rst:964
msgid "While this works it has a few issues:"
msgstr ""
#: ../../content/developer/howtos/web.rst:966
msgid "it is rather verbose"
msgstr ""
#: ../../content/developer/howtos/web.rst:967
msgid "it does not support replacing the widget's root element at runtime as the binding is only performed when ``start()`` is run (during widget initialization)"
msgstr ""
#: ../../content/developer/howtos/web.rst:970
msgid "it requires dealing with ``this``-binding issues"
msgstr ""
#: ../../content/developer/howtos/web.rst:972
msgid "Widgets thus provide a shortcut to DOM event binding via :attr:`~odoo.Widget.events`::"
msgstr ""
#: ../../content/developer/howtos/web.rst:984
msgid ":attr:`~odoo.Widget.events` is an object (mapping) of an event to the function or method to call when the event is triggered:"
msgstr ""
#: ../../content/developer/howtos/web.rst:987
msgid "the key is an event name, possibly refined with a CSS selector in which case only if the event happens on a selected sub-element will the function or method run: ``click`` will handle all clicks within the widget, but ``click .my_button`` will only handle clicks in elements bearing the ``my_button`` class"
msgstr ""
#: ../../content/developer/howtos/web.rst:992
msgid "the value is the action to perform when the event is triggered"
msgstr ""
#: ../../content/developer/howtos/web.rst:994
msgid "It can be either a function::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1000
msgid "or the name of a method on the object (see example above)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1002
msgid "In either case, the ``this`` is the widget instance and the handler is given a single parameter, the `jQuery event object`_ for the event."
msgstr ""
#: ../../content/developer/howtos/web.rst:1006
msgid "Widget Events and Properties"
msgstr ""
#: ../../content/developer/howtos/web.rst:1009
msgid "Events"
msgstr ""
#: ../../content/developer/howtos/web.rst:1011
msgid "Widgets provide an event system (separate from the DOM/jQuery event system described above): a widget can fire events on itself, and other widgets (or itself) can bind themselves and listen for these events::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1031
msgid "This widget acts as a facade, transforming user input (through DOM events) into a documentable internal event to which parent widgets can bind themselves."
msgstr ""
#: ../../content/developer/howtos/web.rst:1035
msgid ":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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1039
msgid "We can then set up a parent event instantiating our generic widget and listening to the ``user_chose`` event using :func:`~odoo.Widget.on`::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1057
msgid ":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:`~odoo.Widget.trigger` if it has any. Example::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1076
msgid "Triggering events on an other widget is generally a bad idea. The main 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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1082
msgid "Properties"
msgstr ""
#: ../../content/developer/howtos/web.rst:1084
msgid "Properties are very similar to normal object attributes in that they allow storing data on a widget instance, however they have the additional feature that they trigger events when set::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1097
msgid ":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:`~odoo.Widget.set`) and ``change``"
msgstr ""
#: ../../content/developer/howtos/web.rst:1100
msgid ":func:`~odoo.Widget.get` retrieves the value of a property."
msgstr ""
#: ../../content/developer/howtos/web.rst:1105
msgid "Widget Properties and Events"
msgstr ""
#: ../../content/developer/howtos/web.rst:1107
msgid "Create a widget ``ColorInputWidget`` that will display 3 ``<input type=\"text\">``. Each of these ``<input>`` is dedicated to type a hexadecimal number from 00 to FF. When any of these ``<input>`` is modified by the user the widget must query the content of the three ``<input>``, concatenate their values to have a complete CSS color code (ie: ``#00FF00``) and put the result in a property named ``color``. Please note the jQuery ``change()`` event that you can bind on any HTML ``<input>`` element and the ``val()`` method that can query the current value of that ``<input>`` could be useful to you for this exercise."
msgstr ""
#: ../../content/developer/howtos/web.rst:1117
msgid "Then, modify the ``HomePage`` widget to instantiate ``ColorInputWidget`` and display it. The ``HomePage`` widget should also display an empty rectangle. That rectangle must always, at any moment, have the same background color as the color in the ``color`` property of the ``ColorInputWidget`` instance."
msgstr ""
#: ../../content/developer/howtos/web.rst:1123
msgid "Use QWeb to generate all HTML."
msgstr ""
#: ../../content/developer/howtos/web.rst:1196
msgid "Modify existing widgets and classes"
msgstr ""
#: ../../content/developer/howtos/web.rst:1198
msgid "The class system of the Odoo web framework allows direct modification of existing classes using the :func:`~odoo.web.Class.include` method::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1216
msgid "This system is similar to the inheritance mechanism, except it will alter the target class in-place instead of creating a new class."
msgstr ""
#: ../../content/developer/howtos/web.rst:1219
msgid "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:`~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:`~odoo.Widget.include`."
msgstr ""
#: ../../content/developer/howtos/web.rst:1229
msgid "The process to translate text in Python and JavaScript code is very similar. You could have noticed these lines at the beginning of the ``petstore.js`` file::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1236
msgid "These lines are simply used to import the translation functions in the current JavaScript module. They are used thus::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1241
msgid "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:`~odoo.web._t` (and also :func:`~odoo.web._lt`)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1247
msgid "``_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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1252
msgid "To inject user-provided values in translatable strings, it is recommended to use `_.str.sprintf <http://gabceb.github.io/underscore.string.site/#sprintf>`_ with named arguments *after* the translation::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1262
msgid "This makes translatable strings more readable to translators, and gives them more flexibility to reorder or ignore parameters."
msgstr ""
#: ../../content/developer/howtos/web.rst:1265
msgid ":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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1269
msgid "It is used to define translatable terms before the translations system is initialized, for class attributes for instance (as modules are loaded before the user's language is configured and translations are downloaded)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1274
msgid "Communication with the Odoo Server"
msgstr ""
#: ../../content/developer/howtos/web.rst:1277
msgid "Contacting Models"
msgstr ""
#: ../../content/developer/howtos/web.rst:1279
msgid "Most operations with Odoo involve communicating with *models* implementing business concern, these models will then (potentially) interact with some storage engine (usually PostgreSQL_)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1283
msgid "Although jQuery_ provides a `$.ajax`_ function for network interactions, communicating with Odoo requires additional metadata whose setup before every call would be verbose and error-prone. As a result, Odoo web provides higher-level communication primitives."
msgstr ""
#: ../../content/developer/howtos/web.rst:1288
msgid "To demonstrate this, the file ``petstore.py`` already contains a small model with a sample method:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1303
msgid "This declares a model with two fields, and a method ``my_method()`` which returns a literal dictionary."
msgstr ""
#: ../../content/developer/howtos/web.rst:1306
msgid "Here is a sample widget that calls ``my_method()`` and displays the result::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1319
msgid "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)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1323
msgid ":func:`~odoo.web.Model.call` can be used to call any (public) method of an Odoo model. It takes the following positional arguments:"
msgid "an array of `positional arguments`_ to provide to the method. Because the example has no positional argument to provide, the ``args`` parameter is not provided."
msgstr ""
#: ../../content/developer/howtos/web.rst:1333
msgid "Here is an other example with positional arguments:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1357
msgid "``kwargs``"
msgstr ""
#: ../../content/developer/howtos/web.rst:1346
msgid "a mapping of `keyword arguments`_ to pass. The example provides a single named argument ``context``."
msgstr ""
#: ../../content/developer/howtos/web.rst:1359
msgid ":func:`~odoo.Widget.call` returns a deferred resolved with the value returned by the model's method as first argument."
msgstr ""
#: ../../content/developer/howtos/web.rst:1363
msgid "CompoundContext"
msgstr ""
#: ../../content/developer/howtos/web.rst:1365
msgid "The previous section used a ``context`` argument which was not explained in the method call::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1370
msgid "The context is like a \"magic\" argument that the web client will always give to the server when calling a method. The context is a dictionary containing multiple keys. One of the most important key is the language of the user, used by the server to translate all the messages of the application. Another one is the time zone of the user, used to compute correctly dates and times if Odoo is used by people in different countries."
msgstr ""
#: ../../content/developer/howtos/web.rst:1377
msgid "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:`odoo.web.CompoundContext`."
msgstr ""
#: ../../content/developer/howtos/web.rst:1382
msgid ":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:`~odoo.web.CompoundContext` instances. It will merge all those contexts before sending them to the server."
msgstr ""
#: ../../content/developer/howtos/web.rst:1400
msgid "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:`~odoo.web.CompoundContext`."
msgstr ""
#: ../../content/developer/howtos/web.rst:1406
msgid "Queries"
msgstr ""
#: ../../content/developer/howtos/web.rst:1408
msgid "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:`~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::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1423
msgid "versus::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1433
msgid ":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:`odoo.web.Query` which can be further customized before being executed"
msgstr ""
#: ../../content/developer/howtos/web.rst:1437
msgid ":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:`~odoo.web.Query` for its customization options."
msgstr ""
#: ../../content/developer/howtos/web.rst:1442
msgid "When the query is set up as desired, simply call :func:`~odoo.web.Query.all` to execute it and return a deferred to its result. The result is the same as :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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1449
msgid "Exercises"
msgstr ""
#: ../../content/developer/howtos/web.rst:1451
msgid "Message of the Day"
msgstr ""
#: ../../content/developer/howtos/web.rst:1453
msgid "Create a ``MessageOfTheDay`` widget displaying the last record of the ``oepetstore.message_of_the_day`` model. The widget should fetch its record as soon as it is displayed."
msgstr ""
#: ../../content/developer/howtos/web.rst:1457
msgid "Display the widget in the Pet Store home page."
msgstr ""
#: ../../content/developer/howtos/web.rst:1517
msgid "Pet Toys List"
msgstr ""
#: ../../content/developer/howtos/web.rst:1519
msgid "Create a ``PetToysList`` widget displaying 5 toys (using their name and their images)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1522
msgid "The pet toys are not stored in a new model, instead they're stored in ``product.product`` using a special category *Pet Toys*. You can see the pre-generated toys and add new ones by going to :menuselection:`Pet Store --> Pet Store --> Pet Toys`. You will probably need to explore ``product.product`` to create the right domain to select just pet toys."
msgstr ""
#: ../../content/developer/howtos/web.rst:1529
msgid "In Odoo, images are generally stored in regular fields encoded as base64_, HTML supports displaying images straight from base64 with :samp:`<img src=\"data:{mime_type};base64,{base64_image_data}\"/>`"
msgstr ""
#: ../../content/developer/howtos/web.rst:1533
msgid "The ``PetToysList`` widget should be displayed on the home page on the right of the ``MessageOfTheDay`` widget. You will need to make some layout with CSS to achieve this."
msgstr ""
#: ../../content/developer/howtos/web.rst:1653
msgid "Existing web components"
msgstr ""
#: ../../content/developer/howtos/web.rst:1656
msgid "The Action Manager"
msgstr ""
#: ../../content/developer/howtos/web.rst:1658
msgid "In Odoo, many operations start from an :ref:`action <reference/actions>`: opening a menu item (to a view), printing a report, ..."
msgstr ""
#: ../../content/developer/howtos/web.rst:1661
msgid "Actions are pieces of data describing how a client should react to the activation of a piece of content. Actions can be stored (and read through a model) or they can be generated on-the fly (locally to the client by javascript code, or remotely by a method of a model)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1666
msgid "In Odoo Web, the component responsible for handling and reacting to these actions is the *Action Manager*."
msgstr ""
#: ../../content/developer/howtos/web.rst:1670
msgid "Using the Action Manager"
msgstr ""
#: ../../content/developer/howtos/web.rst:1672
msgid "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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1676
msgid ":func:`~odoo.Widget.do_action` is a shortcut of :class:`~odoo.Widget` looking up the \"current\" action manager and executing the action::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1692
msgid "The most common action ``type`` is ``ir.actions.act_window`` which provides views to a model (displays a model in various manners), its most common attributes are:"
msgid "Lists the views available through the action. A list of ``[view_id, view_type]``, ``view_id`` can either be the database identifier of a view of the right type, or ``false`` to use the view by default for the specified type. View types can not be present multiple times. The action will open the first view of the list by default."
msgid "Either ``current`` (the default) which replaces the \"content\" section of the web client by the action, or ``new`` to open the action in a dialog box."
msgstr ""
#: ../../content/developer/howtos/web.rst:1710
msgid "Additional context data to use within the action."
msgstr ""
#: ../../content/developer/howtos/web.rst:1712
msgid "Jump to Product"
msgstr ""
#: ../../content/developer/howtos/web.rst:1714
msgid "Modify the ``PetToysList`` component so clicking on a toy replaces the homepage by the toy's form view."
msgstr ""
#: ../../content/developer/howtos/web.rst:1761
msgid "Client Actions"
msgstr ""
#: ../../content/developer/howtos/web.rst:1763
msgid "Throughout this guide, we used a simple ``HomePage`` widget which the web client automatically starts when we select the right menu item. But how did the Odoo web know to start this widget? Because the widget is registered as a *client action*."
msgstr ""
#: ../../content/developer/howtos/web.rst:1768
msgid "A client action is (as its name implies) an action type defined almost entirely in the client, in javascript for Odoo web. The server simply sends an action tag (an arbitrary name), and optionally adds a few parameters, but beyond that *everything* is handled by custom client code."
msgstr ""
#: ../../content/developer/howtos/web.rst:1773
msgid "Our widget is registered as the handler for the client action through this::"
msgstr ""
#: ../../content/developer/howtos/web.rst:1778
msgid "``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:`~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."
msgstr ""
#: ../../content/developer/howtos/web.rst:1784
msgid "When a client action must be executed, the action manager looks up its tag in the registry, walks the specified path and displays the widget it finds at the end."
msgstr ""
#: ../../content/developer/howtos/web.rst:1788
msgid "a client action handler can also be a regular function, in which case it'll be called and its result (if any) will be interpreted as the next action to execute."
msgstr ""
#: ../../content/developer/howtos/web.rst:1792
msgid "On the server side, we had simply defined an ``ir.actions.client`` action:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1800
msgid "and a menu opening the action:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1808
msgid "Architecture of the Views"
msgstr ""
#: ../../content/developer/howtos/web.rst:1810
msgid "Much of Odoo web's usefulness (and complexity) resides in views. Each view type is a way of displaying a model in the client."
msgstr ""
#: ../../content/developer/howtos/web.rst:1814
msgid "The View Manager"
msgstr ""
#: ../../content/developer/howtos/web.rst:1816
msgid "When an ``ActionManager`` instance receive an action of type ``ir.actions.act_window``, it delegates the synchronization and handling of the views themselves to a *view manager*, which will then set up one or multiple views depending on the original action's requirements:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1826
msgid "The Views"
msgstr ""
#: ../../content/developer/howtos/web.rst:1828
msgid "Most :ref:`Odoo views <reference/views>` are implemented through a subclass of :class:`odoo.web.View` which provides a bit of generic basic structure for handling events and displaying model information."
msgstr ""
#: ../../content/developer/howtos/web.rst:1832
msgid "The *search view* is considered a view type by the main Odoo framework, but 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)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1836
msgid "A view is responsible for loading its own description XML (using :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:`~odoo.web.View.view_id` attribute."
msgstr ""
#: ../../content/developer/howtos/web.rst:1841
msgid "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)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1845
msgid "Views may also want to handle search queries by overriding :func:`~odoo.web.View.do_search`, and updating their :class:`~odoo.web.DataSet` as necessary."
msgstr ""
#: ../../content/developer/howtos/web.rst:1850
msgid "The Form View Fields"
msgstr ""
#: ../../content/developer/howtos/web.rst:1852
msgid "A common need is the extension of the web form view to add new ways of displaying fields."
msgstr ""
#: ../../content/developer/howtos/web.rst:1855
msgid "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:`~odoo.fields.Char` fields which should contain email addresses and display them as email links)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1862
msgid "To explicitly specify which form widget should be used to display a field, simply use the ``widget`` attribute in the view's XML description:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1871
msgid "the same widget is used in both \"view\" (read-only) and \"edit\" modes of a form view, it's not possible to use a widget in one and an other widget in the other"
msgstr ""
#: ../../content/developer/howtos/web.rst:1874
msgid "and a given field (name) can not be used multiple times in the same form"
msgstr ""
#: ../../content/developer/howtos/web.rst:1875
msgid "a widget may ignore the current mode of the form view and remain the same in both view and edit modes"
msgstr ""
#: ../../content/developer/howtos/web.rst:1878
msgid "most of this should probably move to an advanced form view guide"
msgstr ""
#: ../../content/developer/howtos/web.rst:1880
msgid "Fields are instantiated by the form view after it has read its XML description and constructed the corresponding HTML representing that description. After that, the form view will communicate with the field objects using some methods. These methods are defined by the ``FieldInterface`` interface. Almost all fields inherit the ``AbstractField`` abstract class. That class defines some default mechanisms that need to be implemented by most fields."
msgstr ""
#: ../../content/developer/howtos/web.rst:1888
msgid "Here are some of the responsibilities of a field class:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1890
msgid "The field class must display and allow the user to edit the value of the field."
msgstr ""
#: ../../content/developer/howtos/web.rst:1891
msgid "It must correctly implement the 3 field attributes available in all fields of Odoo. The ``AbstractField`` class already implements an algorithm that dynamically calculates the value of these attributes (they can change at any moment because their value change according to the value of other fields). Their values are stored in *Widget Properties* (the widget properties were explained earlier in this guide). It is the responsibility of each field class to check these widget properties and dynamically adapt depending of their values. Here is a description of each of these attributes:"
msgstr ""
#: ../../content/developer/howtos/web.rst:1901
msgid "``required``: The field must have a value before saving. If ``required`` is ``true`` and the field doesn't have a value, the method ``is_valid()`` of the field must return ``false``."
msgstr ""
#: ../../content/developer/howtos/web.rst:1904
msgid "``invisible``: When this is ``true``, the field must be invisible. The ``AbstractField`` class already has a basic implementation of this behavior that fits most fields."
msgstr ""
#: ../../content/developer/howtos/web.rst:1907
msgid "``readonly``: When ``true``, the field must not be editable by the user. Most fields in Odoo have a completely different behavior depending on the value of ``readonly``. As example, the ``FieldChar`` displays an HTML ``<input>`` when it is editable and simply displays the text when it is read-only. This also means it has much more code it would need to implement only one behavior, but this is necessary to ensure a good user experience."
msgstr ""
#: ../../content/developer/howtos/web.rst:1915
msgid "Fields have two methods, ``set_value()`` and ``get_value()``, which are called by the form view to give it the value to display and get back the new value entered by the user. These methods must be able to handle the value as given by the Odoo server when a ``read()`` is performed on a model and give back a valid value for a ``write()``. Remember that the JavaScript/Python data types used to represent the values given by ``read()`` and given to ``write()`` is not necessarily the same in Odoo. As example, when you read a many2one, it is always a tuple whose first value is the id of the pointed record and the second one is the name get (ie: ``(15, \"Agrolait\")``). But when you write a many2one it must be a single integer, not a tuple anymore. ``AbstractField`` has a default implementation of these methods that works well for simple data type and set a widget property named ``value``."
msgstr ""
#: ../../content/developer/howtos/web.rst:1929
msgid "Please note that, to better understand how to implement fields, you are strongly encouraged to look at the definition of the ``FieldInterface`` interface and the ``AbstractField`` class directly in the code of the Odoo web client."
msgstr ""
#: ../../content/developer/howtos/web.rst:1935
msgid "Creating a New Type of Field"
msgstr ""
#: ../../content/developer/howtos/web.rst:1937
msgid "In this part we will explain how to create a new type of field. The example here will be to re-implement the ``FieldChar`` class and progressively explain each part."
msgstr ""
#: ../../content/developer/howtos/web.rst:1942
msgid "Simple Read-Only Field"
msgstr ""
#: ../../content/developer/howtos/web.rst:1944
msgid "Here is a first implementation that will only display text. The user will not be able to modify the content of the field."
msgstr ""
#: ../../content/developer/howtos/web.rst:1961
msgid "In this example, we declare a class named ``FieldChar2`` inheriting from ``AbstractField``. We also register this class in the registry ``instance.web.form.widgets`` under the key ``char2``. That will allow us to use this new field in any form view by specifying ``widget=\"char2\"`` in the ``<field/>`` tag in the XML declaration of the view."
msgstr ""
#: ../../content/developer/howtos/web.rst:1967
msgid "In this example, we define a single method: ``render_value()``. All it does is display the widget property ``value``. Those are two tools defined by the ``AbstractField`` class. As explained before, the form view will call the method ``set_value()`` of the field to set the value to display. This method already has a default implementation in ``AbstractField`` which simply sets the widget property ``value``. ``AbstractField`` also watch the ``change:value`` event on itself and calls the ``render_value()`` when it occurs. So, ``render_value()`` is a convenience method to implement in child classes to perform some operation each time the value of the field changes."
msgstr ""
#: ../../content/developer/howtos/web.rst:1977
msgid "In the ``init()`` method, we also define the default value of the field if none is specified by the form view (here we assume the default value of a ``char`` field should be an empty string)."
msgstr ""
#: ../../content/developer/howtos/web.rst:1982
msgid "Read-Write Field"
msgstr ""
#: ../../content/developer/howtos/web.rst:1984
msgid "Read-only fields, which only display content and don't allow the user to modify it can be useful, but most fields in Odoo also allow editing. This makes the field classes more complicated, mostly because fields are supposed to handle both editable and non-editable mode, those modes are often completely different (for design and usability purpose) and the fields must be able to switch between modes at any moment."
msgstr ""
#: ../../content/developer/howtos/web.rst:1991
msgid "To know in which mode the current field should be, the ``AbstractField`` class sets a widget property named ``effective_readonly``. The field should watch for changes in that widget property and display the correct mode accordingly. Example::"
msgstr ""
#: ../../content/developer/howtos/web.rst:2039
msgid "In the ``start()`` method (which is called immediately after a widget has been appended to the DOM), we bind on the event ``change:effective_readonly``. That allows us to redisplay the field each time the widget property ``effective_readonly`` changes. This event handler will call ``display_field()``, which is also called directly in ``start()``. This ``display_field()`` was created specifically for this field, it's not a method defined in ``AbstractField`` or any other class. We can use this method to display the content of the field depending on the current mode."
msgstr ""
#: ../../content/developer/howtos/web.rst:2048
msgid "From now on the conception of this field is typical, except there is a lot of verifications to know the state of the ``effective_readonly`` property:"
msgstr ""
#: ../../content/developer/howtos/web.rst:2051
msgid "In the QWeb template used to display the content of the widget, it displays an ``<input type=\"text\" />`` if we are in read-write mode and nothing in particular in read-only mode."
msgstr ""
#: ../../content/developer/howtos/web.rst:2054
msgid "In the ``display_field()`` method, we have to bind on the ``change`` event of the ``<input type=\"text\" />`` to know when the user has changed the value. When it happens, we call the ``internal_set_value()`` method with the new value of the field. This is a convenience method provided by the ``AbstractField`` class. That method will set a new value in the ``value`` property but will not trigger a call to ``render_value()`` (which is not necessary since the ``<input type=\"text\" />`` already contains the correct value)."
msgstr ""
#: ../../content/developer/howtos/web.rst:2062
msgid "In ``render_value()``, we use a completely different code to display the value of the field depending if we are in read-only or in read-write mode."
msgstr ""
#: ../../content/developer/howtos/web.rst:2065
msgid "Create a Color Field"
msgstr ""
#: ../../content/developer/howtos/web.rst:2067
msgid "Create a ``FieldColor`` class. The value of this field should be a string containing a color code like those used in CSS (example: ``#FF0000`` for red). In read-only mode, this color field should display a little block whose color corresponds to the value of the field. In read-write mode, you should display an ``<input type=\"color\" />``. That type of ``<input />`` is an HTML5 component that doesn't work in all browsers but works well in Google Chrome. So it's OK to use as an exercise."
msgstr ""
#: ../../content/developer/howtos/web.rst:2075
msgid "You can use that widget in the form view of the ``message_of_the_day`` model for its field named ``color``. As a bonus, you can change the ``MessageOfTheDay`` widget created in the previous part of this guide to display the message of the day with the background color indicated in the ``color`` field."
msgstr ""
#: ../../content/developer/howtos/web.rst:2140
msgid "The Form View Custom Widgets"
msgstr ""
#: ../../content/developer/howtos/web.rst:2142
msgid "Form fields are used to edit a single field, and are intrinsically linked to a field. Because this may be limiting, it is also possible to create *form widgets* which are not so restricted and have less ties to a specific lifecycle."
msgstr ""
#: ../../content/developer/howtos/web.rst:2147
msgid "Custom form widgets can be added to a form view through the ``widget`` tag:"
msgstr ""
#: ../../content/developer/howtos/web.rst:2153
msgid "This type of widget will simply be created by the form view during the creation of the HTML according to the XML definition. They have properties in common with the fields (like the ``effective_readonly`` property) but they are not assigned a precise field. And so they don't have methods like ``get_value()`` and ``set_value()``. They must inherit from the ``FormWidget`` abstract class."
msgstr ""
#: ../../content/developer/howtos/web.rst:2160
msgid "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:`~odoo.web.form.FormWidget.field_manager` attribute::"
msgstr ""
#: ../../content/developer/howtos/web.rst:2180
msgid ":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:"
msgstr ""
#: ../../content/developer/howtos/web.rst:2185
msgid ":func:`~odoo.web.form.FieldManagerMixin.get_field_value(field_name)` which returns the value of a field."
msgstr ""
#: ../../content/developer/howtos/web.rst:2187
msgid ":func:`~odoo.web.form.FieldManagerMixin.set_values(values)` sets multiple field values, takes a mapping of ``{field_name: value_to_set}``"
msgstr ""
#: ../../content/developer/howtos/web.rst:2189
msgid "An event :samp:`field_changed:{field_name}` is triggered any time the value of the field called ``field_name`` is changed"
msgstr ""
#: ../../content/developer/howtos/web.rst:2192
msgid "Show Coordinates on Google Map"
msgstr ""
#: ../../content/developer/howtos/web.rst:2194
msgid "Add two fields to ``product.product`` storing a latitude and a longitude, then create a new form widget to display the latitude and longitude of a product's origin on a map"
msgstr ""
#: ../../content/developer/howtos/web.rst:2198
msgid "To display the map, use Google Map's embedding:"
msgstr ""
#: ../../content/developer/howtos/web.rst:2205
msgid "where ``XXX`` should be replaced by the latitude and ``YYY`` by the longitude."
msgstr ""
#: ../../content/developer/howtos/web.rst:2208
msgid "Display the two position fields and a map widget using them in a new notebook page of the product's form view."
msgstr ""
#: ../../content/developer/howtos/web.rst:2240
msgid "Get the Current Coordinate"
msgstr ""
#: ../../content/developer/howtos/web.rst:2242
msgid "Add a button resetting the product's coordinates to the location of the user, you can get these coordinates using the `javascript geolocation API`_."
msgstr ""
#: ../../content/developer/howtos/web.rst:2246
msgid "Now we would like to display an additional button to automatically set the coordinates to the location of the current user."
msgstr ""
#: ../../content/developer/howtos/web.rst:2249
msgid "To get the coordinates of the user, an easy way is to use the geolocation JavaScript API. `See the online documentation to know how to use it`_."
msgstr ""
#: ../../content/developer/howtos/web.rst:2254
msgid "Please also note that the user should not be able to click on that button when the form view is in read-only mode. So, this custom widget should handle correctly the ``effective_readonly`` property just like any field. One way to do this would be to make the button disappear when ``effective_readonly`` is true."
msgstr ""
#: ../../content/developer/howtos/web.rst:2305
msgid "as a separate concept from instances. In many languages classes are full-fledged objects and themselves instance (of metaclasses) but there remains two fairly separate hierarchies between classes and instances"
msgstr ""
#: ../../content/developer/howtos/web.rst:2309
msgid "as well as papering over cross-browser differences, although this has become less necessary over time"
msgstr ""
#: ../../content/developer/howtos/website.rst:3
msgid "Building a Website"
msgstr ""
#: ../../content/developer/howtos/website.rst:7
msgid "This guide assumes `basic knowledge of Python <http://docs.python.org/2/tutorial/>`_"
msgid "In Odoo, tasks are performed by creating modules."
msgstr ""
#: ../../content/developer/howtos/website.rst:16
msgid "Modules customize the behavior of an Odoo installation, either by adding new behaviors or by altering existing ones (including behaviors added by other modules)."
msgstr ""
#: ../../content/developer/howtos/website.rst:20
msgid ":ref:`Odoo's scaffolding <reference/cmdline/scaffold>` can setup a basic module. To quickly get started simply invoke:"
msgstr ""
#: ../../content/developer/howtos/website.rst:27
msgid "This will automatically create a ``my-modules`` *module directory* with an ``academy`` module inside. The directory can be an existing module directory if you want, but the module name must be unique within the directory."
msgstr ""
#: ../../content/developer/howtos/website.rst:32
msgid "A demonstration module"
msgstr ""
#: ../../content/developer/howtos/website.rst:34
msgid "We have a \"complete\" module ready for installation."
msgstr ""
#: ../../content/developer/howtos/website.rst:36
msgid "Although it does absolutely nothing we can install it:"
msgstr ""
#: ../../content/developer/howtos/website.rst:38
msgid "start the Odoo server"
msgstr ""
#: ../../content/developer/howtos/website.rst:44
msgid "go to http://localhost:8069"
msgstr ""
#: ../../content/developer/howtos/website.rst:45
msgid "create a new database including demonstration data"
msgstr ""
#: ../../content/developer/howtos/website.rst:46
msgid "to go :menuselection:`Settings --> Modules --> Modules`"
msgstr ""
#: ../../content/developer/howtos/website.rst:47
msgid "in the top-right corner remove the *Installed* filter and search for *academy*"
msgstr ""
#: ../../content/developer/howtos/website.rst:49
msgid "click the :guilabel:`Install` button for the *Academy* module"
msgstr ""
#: ../../content/developer/howtos/website.rst:52
msgid "To the browser"
msgstr ""
#: ../../content/developer/howtos/website.rst:54
msgid ":ref:`Controllers <reference/controllers>` interpret browser requests and send data back."
msgstr ""
#: ../../content/developer/howtos/website.rst:57
msgid "Add a simple controller and ensure it is imported by ``__init__.py`` (so Odoo can find it):"
msgstr ""
#: ../../content/developer/howtos/website.rst:60
#: ../../content/developer/howtos/website.rst:96
#: ../../content/developer/howtos/website.rst:243
#: ../../content/developer/howtos/website.rst:301
#: ../../content/developer/howtos/website.rst:369
#: ../../content/developer/howtos/website.rst:384
#: ../../content/developer/howtos/website.rst:401
msgid "``academy/controllers.py``"
msgstr ""
#: ../../content/developer/howtos/website.rst:72
msgid "Shut down your server (:kbd:`^C`) then restart it:"
msgstr ""
#: ../../content/developer/howtos/website.rst:78
msgid "and open a page to http://localhost:8069/academy/academy/, you should see your \"page\" appear:"
msgstr ""
#: ../../content/developer/howtos/website.rst:84
msgid "Templates"
msgstr ""
#: ../../content/developer/howtos/website.rst:86
msgid "Generating HTML in Python isn't very pleasant."
msgstr ""
#: ../../content/developer/howtos/website.rst:88
msgid "The usual solution is templates_, pseudo-documents with placeholders and display logic. Odoo allows any Python templating system, but provides its own :ref:`QWeb <reference/qweb>` templating system which integrates with other features."
msgstr ""
#: ../../content/developer/howtos/website.rst:93
msgid "Create a template and ensure the template file is registered in the ``__manifest__.py`` manifest, and alter the controller to use our template:"
msgstr ""
#: ../../content/developer/howtos/website.rst:107
#: ../../content/developer/howtos/website.rst:255
#: ../../content/developer/howtos/website.rst:313
#: ../../content/developer/howtos/website.rst:410
#: ../../content/developer/howtos/website.rst:429
#: ../../content/developer/howtos/website.rst:470
#: ../../content/developer/howtos/website.rst:497
#: ../../content/developer/howtos/website.rst:518
#: ../../content/developer/howtos/website.rst:532
#: ../../content/developer/howtos/website.rst:545
#: ../../content/developer/howtos/website.rst:969
#: ../../content/developer/howtos/website.rst:992
msgid "``academy/templates.xml``"
msgstr ""
#: ../../content/developer/howtos/website.rst:121
msgid "The templates iterates (``t-foreach``) on all the teachers (passed through the *template context*), and prints each teacher in its own paragraph."
msgstr ""
#: ../../content/developer/howtos/website.rst:124
msgid "Finally restart Odoo and update the module's data (to install the template) by going to :menuselection:`Settings --> Modules --> Modules --> Academy` and clicking :guilabel:`Upgrade`."
msgstr ""
#: ../../content/developer/howtos/website.rst:130
msgid "Alternatively, Odoo can be restarted :option:`and update modules at the same time<odoo-bin -u>`:"
msgstr ""
#: ../../content/developer/howtos/website.rst:137
msgid "Going to http://localhost:8069/academy/academy/ should now result in:"
msgstr ""
#: ../../content/developer/howtos/website.rst:142
msgid "Storing data in Odoo"
msgstr ""
#: ../../content/developer/howtos/website.rst:144
msgid ":ref:`Odoo models <reference/orm/model>` map to database tables."
msgstr ""
#: ../../content/developer/howtos/website.rst:146
msgid "In the previous section we just displayed a list of string entered statically in the Python code. This doesn't allow modifications or persistent storage so we'll now move our data to the database."
msgstr ""
#: ../../content/developer/howtos/website.rst:151
msgid "Defining the data model"
msgstr ""
#: ../../content/developer/howtos/website.rst:153
msgid "Define a teacher model, and ensure it is imported from ``__init__.py`` so it is correctly loaded:"
msgstr ""
#: ../../content/developer/howtos/website.rst:156
#: ../../content/developer/howtos/website.rst:461
#: ../../content/developer/howtos/website.rst:656
#: ../../content/developer/howtos/website.rst:730
#: ../../content/developer/howtos/website.rst:796
#: ../../content/developer/howtos/website.rst:913
msgid "``academy/models.py``"
msgstr ""
#: ../../content/developer/howtos/website.rst:166
msgid "Then setup :ref:`basic access control <reference/security/acl>` for the model and add them to the manifest:"
msgstr ""
#: ../../content/developer/howtos/website.rst:169
#: ../../content/developer/howtos/website.rst:290
#: ../../content/developer/howtos/website.rst:586
#: ../../content/developer/howtos/website.rst:785
#: ../../content/developer/howtos/website.rst:846
#: ../../content/developer/howtos/website.rst:863
msgid "``academy/__manifest__.py``"
msgstr ""
#: ../../content/developer/howtos/website.rst:178
#: ../../content/developer/howtos/website.rst:665
msgid "``academy/security/ir.model.access.csv``"
msgstr ""
#: ../../content/developer/howtos/website.rst:184
msgid "this simply gives read access (``perm_read``) to all users (``group_id:id`` left empty)."
msgstr ""
#: ../../content/developer/howtos/website.rst:189
msgid ":ref:`Data files <reference/data>` (XML or CSV) must be added to the module manifest, Python files (models or controllers) don't but have to be imported from ``__init__.py`` (directly or indirectly)"
msgstr ""
#: ../../content/developer/howtos/website.rst:195
msgid "the administrator user bypasses access control, they have access to all models even if not given access"
msgstr ""
#: ../../content/developer/howtos/website.rst:199
msgid "Demonstration data"
msgstr ""
#: ../../content/developer/howtos/website.rst:201
msgid "The second step is to add some demonstration data to the system so it's possible to test it easily. This is done by adding a ``demo`` :ref:`data file <reference/data>`, which must be linked from the manifest:"
msgstr ""
#: ../../content/developer/howtos/website.rst:205
#: ../../content/developer/howtos/website.rst:884
msgid "``academy/demo.xml``"
msgstr ""
#: ../../content/developer/howtos/website.rst:224
msgid ":ref:`Data files <reference/data>` can be used for demo and non-demo data. Demo data are only loaded in \"demonstration mode\" and can be used for flow testing and demonstration, non-demo data are always loaded and used as initial system setup."
msgstr ""
#: ../../content/developer/howtos/website.rst:229
msgid "In this case we're using demonstration data because an actual user of the system would want to input or import their own teachers list, this list is only useful for testing."
msgstr ""
#: ../../content/developer/howtos/website.rst:236
msgid "The last step is to alter model and template to use our demonstration data:"
msgstr ""
#: ../../content/developer/howtos/website.rst:238
msgid "fetch the records from the database instead of having a static list"
msgstr ""
#: ../../content/developer/howtos/website.rst:239
msgid "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``"
msgstr ""
#: ../../content/developer/howtos/website.rst:269
msgid "Restart the server and update the module (in order to update the manifest and templates and load the demo file) then navigate to http://localhost:8069/academy/academy/. The page should look slightly different: names should simply be prefixed by a number (the database identifier for the teacher)."
msgstr ""
#: ../../content/developer/howtos/website.rst:276
msgid "Website support"
msgstr ""
#: ../../content/developer/howtos/website.rst:278
msgid "Odoo bundles a module dedicated to building websites."
msgstr ""
#: ../../content/developer/howtos/website.rst:280
msgid "So far we've used controllers fairly directly, but Odoo 8 added deeper integration and a few other services (e.g. default styling, theming) via the ``website`` module."
msgstr ""
#: ../../content/developer/howtos/website.rst:284
msgid "first, add ``website`` as a dependency to ``academy``"
msgstr ""
#: ../../content/developer/howtos/website.rst:285
msgid "then add the ``website=True`` flag on the controller, this sets up a few new variables on :ref:`the request object <reference/http/request>` and allows using the website layout in our template"
msgstr ""
#: ../../content/developer/howtos/website.rst:288
msgid "use the website layout in the template"
msgstr ""
#: ../../content/developer/howtos/website.rst:333
msgid "After restarting the server while updating the module (in order to update the manifest and template) access http://localhost:8069/academy/academy/ should yield a nicer looking page with branding and a number of built-in page elements (top-level menu, footer, …)"
msgstr ""
#: ../../content/developer/howtos/website.rst:340
msgid "The website layout also provides support for editing tools: click :guilabel:`Sign In` (in the top-right), fill the credentials in (``admin`` / ``admin`` by default) then click :guilabel:`Log In`."
msgstr ""
#: ../../content/developer/howtos/website.rst:344
msgid "You're now in Odoo \"proper\": the administrative interface. For now click on the :guilabel:`Website` menu item (top-left corner."
msgstr ""
#: ../../content/developer/howtos/website.rst:347
msgid "We're back in the website but as an administrator, with access to advanced editing features provided by the *website* support:"
msgstr ""
#: ../../content/developer/howtos/website.rst:350
msgid "a template code editor (:menuselection:`Customize --> HTML Editor`) where you can see and edit all templates used for the current page"
msgstr ""
#: ../../content/developer/howtos/website.rst:352
msgid "the :guilabel:`Edit` button in the top-left switches to \"editing mode\" where blocks (snippets) and rich text editing are available"
msgstr ""
#: ../../content/developer/howtos/website.rst:354
msgid "a number of other features such as mobile preview or :abbr:`SEO (Search Engine Optimization)`"
msgstr ""
#: ../../content/developer/howtos/website.rst:358
msgid "URLs and routing"
msgstr ""
#: ../../content/developer/howtos/website.rst:360
msgid "Controller methods are associated with *routes* via the :func:`~odoo.http.route` decorator which takes a routing string and a number of attributes to customise its behavior or security."
msgstr ""
#: ../../content/developer/howtos/website.rst:364
msgid "We've seen a \"literal\" routing string, which matches a URL section exactly, but routing strings can also use `converter patterns`_ which match bits of URLs and make those available as local variables. For instance we can create a new controller method which takes a bit of URL and prints it out:"
msgstr ""
#: ../../content/developer/howtos/website.rst:377
msgid "restart Odoo, access http://localhost:8069/academy/Alice/ and http://localhost:8069/academy/Bob/ and see the difference."
msgstr ""
#: ../../content/developer/howtos/website.rst:380
msgid "As the name indicates, `converter patterns`_ don't just do extraction, they also do *validation* and *conversion*, so we can change the new controller to only accept integers:"
msgstr ""
#: ../../content/developer/howtos/website.rst:391
msgid "Restart Odoo, access http://localhost:8069/academy/2, note how the old value was a string, but the new one was converted to an integers. Try accessing http://localhost:8069/academy/Carol/ and note that the page was not found: since \"Carol\" is not an integer, the route was ignored and no route could be found."
msgstr ""
#: ../../content/developer/howtos/website.rst:397
msgid "Odoo provides an additional converter called ``model`` which provides records directly when given their id. Let's use this to create a generic page for teacher biographies:"
msgstr ""
#: ../../content/developer/howtos/website.rst:426
msgid "then change the list of model to link to our new controller:"
msgstr ""
#: ../../content/developer/howtos/website.rst:448
msgid "Restart Odoo and upgrade the module, then you can visit each teacher's page. As an exercise, try adding blocks to a teacher's page to write a biography, then go to another teacher's page and so forth. You will discover, that your biography is shared between all teachers, because blocks are added to the *template*, and the *biography* template is shared between all teachers, when one page is edited they're all edited at the same time."
msgstr ""
#: ../../content/developer/howtos/website.rst:456
msgid "Field editing"
msgstr ""
#: ../../content/developer/howtos/website.rst:458
msgid "Data which is specific to a record should be saved on that record, so let us add a new biography field to our teachers:"
msgstr ""
#: ../../content/developer/howtos/website.rst:487
msgid "Restart Odoo and update the views, reload the teacher's page and… the field is invisible since it contains nothing."
msgstr ""
#: ../../content/developer/howtos/website.rst:490
msgid "the view has been set to noupdate because modified previously, force via ``-i`` or do something else?"
msgstr ""
#: ../../content/developer/howtos/website.rst:493
msgid "For record fields, templates can use a special ``t-field`` directive which allows editing the field content from the website using field-specific interfaces. Change the *person* template to use ``t-field``:"
msgstr ""
#: ../../content/developer/howtos/website.rst:507
msgid "Restart Odoo and upgrade the module, there is now a placeholder under the teacher's name and a new zone for blocks in :guilabel:`Edit` mode. Content dropped there is stored in the corresponding teacher's ``biography`` field, and thus specific to that teacher."
msgstr ""
#: ../../content/developer/howtos/website.rst:512
msgid "The teacher's name is also editable, and when saved the change is visible on the index page."
msgstr ""
#: ../../content/developer/howtos/website.rst:515
msgid "``t-field`` can also take formatting options which depend on the exact field. For instance if we display the modification date for a teacher's record:"
msgstr ""
#: ../../content/developer/howtos/website.rst:529
msgid "it is displayed in a very \"computery\" manner and hard to read, but we could ask for a human-readable version:"
msgstr ""
#: ../../content/developer/howtos/website.rst:543
msgid "or a relative display:"
msgstr ""
#: ../../content/developer/howtos/website.rst:557
msgid "Administration and ERP integration"
msgstr ""
#: ../../content/developer/howtos/website.rst:560
msgid "A brief and incomplete introduction to the Odoo administration"
msgstr ""
#: ../../content/developer/howtos/website.rst:562
msgid "The Odoo administration was briefly seen during the `website support`_ section. We can go back to it using :menuselection:`Administrator --> Administrator` in the menu (or :guilabel:`Sign In` if you're signed out)."
msgstr ""
#: ../../content/developer/howtos/website.rst:566
msgid "The conceptual structure of the Odoo backend is simple:"
msgstr ""
#: ../../content/developer/howtos/website.rst:568
msgid "first are menus, a tree (menus can have sub-menus) of records. Menus without children map to…"
msgstr ""
#: ../../content/developer/howtos/website.rst:570
msgid "actions. Actions have various types: links, reports, code which Odoo should execute or data display. Data display actions are called *window actions*, and tell Odoo to display a given *model* according to a set of views…"
msgstr ""
#: ../../content/developer/howtos/website.rst:573
msgid "a view has a type, a broad category to which it corresponds (a list, a graph, a calendar) and an *architecture* which customises the way the model is displayed inside the view."
msgstr ""
#: ../../content/developer/howtos/website.rst:578
msgid "Editing in the Odoo administration"
msgstr ""
#: ../../content/developer/howtos/website.rst:580
msgid "By default, an Odoo model is essentially invisible to a user. To make it visible it must be available through an action, which itself needs to be reachable, generally through a menu."
msgstr ""
#: ../../content/developer/howtos/website.rst:584
msgid "Let's create a menu for our model:"
msgstr ""
#: ../../content/developer/howtos/website.rst:596
#: ../../content/developer/howtos/website.rst:627
#: ../../content/developer/howtos/website.rst:675
#: ../../content/developer/howtos/website.rst:747
#: ../../content/developer/howtos/website.rst:806
msgid "``academy/views.xml``"
msgstr ""
#: ../../content/developer/howtos/website.rst:613
msgid "then accessing http://localhost:8069/web/ in the top left should be a menu :guilabel:`Academy`, which is selected by default, as it is the first menu, and having opened a listing of teachers. From the listing it is possible to :guilabel:`Create` new teacher records, and to switch to the \"form\" by-record view."
msgstr ""
#: ../../content/developer/howtos/website.rst:619
msgid "If there is no definition of how to present records (a :ref:`view <reference/views>`) Odoo will automatically create a basic one on-the-fly. In our case it works for the \"list\" view for now (only displays the teacher's name) but in the \"form\" view the HTML ``biography`` field is displayed side-by-side with the ``name`` field and not given enough space. Let's define a custom form view to make viewing and editing teacher records a better experience:"
msgstr ""
#: ../../content/developer/howtos/website.rst:646
msgid "We have seen a pair of \"basic\" fields stored directly in the record. There are :ref:`a number of basic fields <reference/fields/basic>`. The second broad categories of fields are :ref:`relational <reference/fields/relational>` and used to link records to one another (within a model or across models)."
msgstr ""
#: ../../content/developer/howtos/website.rst:652
msgid "For demonstration, let's create a *courses* model. Each course should have a ``teacher`` field, linking to a single teacher record, but each teacher can teach many courses:"
msgstr ""
#: ../../content/developer/howtos/website.rst:672
msgid "let's also add views so we can see and edit a course's teacher:"
msgstr ""
#: ../../content/developer/howtos/website.rst:725
msgid "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 <odoo.fields.One2many>` to the *teachers* model:"
msgstr ""
#: ../../content/developer/howtos/website.rst:769
msgid "Discussions and notifications"
msgstr ""
#: ../../content/developer/howtos/website.rst:771
msgid "Odoo provides technical models, which don't directly fulfill business needs but which add capabilities to business objects without having to build them by hand."
msgstr ""
#: ../../content/developer/howtos/website.rst:775
msgid "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:`~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."
msgstr ""
#: ../../content/developer/howtos/website.rst:781
msgid "For our academy, it makes sense to allow discussing courses to handle e.g. scheduling changes or discussions between teachers and assistants:"
msgstr ""
#: ../../content/developer/howtos/website.rst:826
msgid "At the bottom of each course form, there is now a discussion thread and the possibility for users of the system to leave messages and follow or unfollow discussions linked to specific courses."
msgstr ""
#: ../../content/developer/howtos/website.rst:831
msgid "Selling courses"
msgstr ""
#: ../../content/developer/howtos/website.rst:833
msgid "Odoo also provides business models which allow using or opting in business needs more directly. For instance the ``website_sale`` module sets up an e-commerce site based on the products in the Odoo system. We can easily make course subscriptions sellable by making our courses specific kinds of products."
msgstr ""
#: ../../content/developer/howtos/website.rst:839
msgid "Rather than the previous classical inheritance, this means replacing our *course* model by the *product* model, and extending products in-place (to add anything we need to it)."
msgstr ""
#: ../../content/developer/howtos/website.rst:843
msgid "First of all we need to add a dependency on ``website_sale`` so we get both products (via ``sale``) and the ecommerce interface:"
msgstr ""
#: ../../content/developer/howtos/website.rst:857
msgid "restart Odoo, update your module, there is now a :guilabel:`Shop` section in the website, listing a number of pre-filled (via demonstration data) products."
msgstr ""
#: ../../content/developer/howtos/website.rst:860
msgid "The second step is to replace the *courses* model by ``product.template``, and add a new category of product for courses:"
msgstr ""
#: ../../content/developer/howtos/website.rst:874
msgid "``academy/data.xml``"
msgstr ""
#: ../../content/developer/howtos/website.rst:923
msgid "With this installed, a few courses are now available in the :guilabel:`Shop`, though they may have to be looked for."
msgstr ""
#: ../../content/developer/howtos/website.rst:928
msgid "to extend a model in-place, it's :attr:`inherited <odoo.models.Model._inherit>` without giving it a new :attr:`~odoo.models.Model._name`"
msgstr ""
#: ../../content/developer/howtos/website.rst:931
msgid "``product.template`` already uses the discussions system, so we can remove it from our extension model"
msgstr ""
#: ../../content/developer/howtos/website.rst:933
msgid "we're creating our courses as *published* by default so they can be seen without having to log in"
msgstr ""
#: ../../content/developer/howtos/website.rst:937
msgid "Altering existing views"
msgstr ""
#: ../../content/developer/howtos/website.rst:939
msgid "So far, we have briefly seen:"
msgstr ""
#: ../../content/developer/howtos/website.rst:941
msgid "the creation of new models"
msgstr ""
#: ../../content/developer/howtos/website.rst:942
msgid "the creation of new views"
msgstr ""
#: ../../content/developer/howtos/website.rst:943
msgid "the creation of new records"
msgstr ""
#: ../../content/developer/howtos/website.rst:944
msgid "the alteration of existing models"
msgstr ""
#: ../../content/developer/howtos/website.rst:946
msgid "We're left with the alteration of existing records and the alteration of existing views. We'll do both on the :guilabel:`Shop` pages."
msgstr ""
#: ../../content/developer/howtos/website.rst:949
msgid "View alteration is done by creating *extension* views, which are applied on top of the original view and alter it. These alteration views can be added or removed without modifying the original, making it easier to try things out and roll changes back."
msgstr ""
#: ../../content/developer/howtos/website.rst:954
msgid "Since our courses are free, there is no reason to display their price on the shop page, so we're going to alter the view and hide the price if it's 0. The first task is finding out which view displays the price, this can be done via :menuselection:`Customize --> HTML Editor` which lets us read the various templates involved in rendering a page. Going through a few of them, \"Product item\" looks a likely culprit."
msgstr ""
#: ../../content/developer/howtos/website.rst:961
msgid "Altering view architectures is done in 3 steps:"
msgstr ""
#: ../../content/developer/howtos/website.rst:963
msgid "Create a new view"
msgstr ""
#: ../../content/developer/howtos/website.rst:964
msgid "Extend the view to modify by setting the new view's ``inherit_id`` to the modified view's external id"
msgstr ""
#: ../../content/developer/howtos/website.rst:966
msgid "In the architecture, use the ``xpath`` tag to select and alter elements from the modified view"
msgstr ""
#: ../../content/developer/howtos/website.rst:978
msgid "The second thing we will change is making the product categories sidebar visible by default: :menuselection:`Customize --> Product Categories` lets you toggle a tree of product categories (used to filter the main display) on and off."
msgstr ""
#: ../../content/developer/howtos/website.rst:983
msgid "This is done via the ``customize_show`` and ``active`` fields of extension templates: an extension template (such as the one we've just created) can be *customize_show=True*. This choice will display the view in the :guilabel:`Customize` menu with a check box, allowing administrators to activate or disable them (and easily customize their website pages)."
msgstr ""
#: ../../content/developer/howtos/website.rst:989
msgid "We simply need to modify the *Product Categories* record and set its default to *active=\"True\"*:"
msgstr ""
#: ../../content/developer/howtos/website.rst:999
msgid "With this, the *Product Categories* sidebar will automatically be enabled when the *Academy* module is installed."
msgid "Odoo provides a service allowing you to automate the processing of your invoices. The service scans your document using an Optical Character Recognition (OCR) engine and then uses AI-based algorithms to extract the fields of interest such as the total, the due date, or the invoice lines. More functional information can be found on the `demo page <https://www.odoo.com/page/invoice-automation>`_."
msgid "This service is a paid service. Each invoice processing will cost you one credit. Three different sized packs can be bought on `iap.odoo.com <https://iap.odoo.com/iap/in-app-services/259?sortby=date>`_."
msgid "You can either use this service directly in the Odoo Accounting App or through the API. The Extract API which is detailed in the next section allows you to integrate our service directly into your own projects."
msgid "Call :ref:`webservices/extract_api/invoice_parse` to submit your invoices (one call for each invoice). On success, you receive a `document_id` in the response."
msgid "Once the result received, you can validate it by calling :ref:`webservices/extract_api/invoice_validate` and sending the expected values. This step is optional but greatly helps the system to improve."
msgid "These 3 routes are detailed in this :ref:`section <webservices/extract_api/routes>`. The HTTP POST method should be used for all of them. A python implementation of the full flow can be found :download:`here <extract_api/implementation.py>` and a token for integration testing is provided in the :ref:`integration testing section <webservices/extract_api/integration_testing>`."
msgid "An identifier established by the client. It allows the client to keep track of which response goes with which request. This makes asynchronous calls easier."
msgid "The version will determine the format of your requests and the format of the server response. Some results can be unavailable in older versions. For the current version 1.2.0, send ‘120’. If not specified, the latest version will be used."
msgid "The invoice must be provided as a string in the ASCII encoding. The list should contain only one string. If multiple strings are provided only the first string corresponding to a pdf will be processed. If no pdf is found, the first string will be processed. This field is a list only for legacy reasons. The supported extensions are *pdf*, *png*, *jpg* and *bmp*."
msgid "Information concerning the person to whom the invoice is intended. This information is not required in order for the service to work but it greatly improves the quality of the result."
msgid "Request the results of the documents ids obtained with the :ref:`/parse <webservices/extract_api/invoice_parse>` route. Can either return the results or a \"request pending\" message."
msgid "Each field of interest we want to extract from the invoice such as the total or the due date are also called features. An exhaustive list of all the extracted features can be found in the table below."
msgid "``[center_x, center_y, width, height, rotation_angle]``. The position and dimensions are relative to the size of the page and are therefore between 0 and 1. The angle is a clockwise rotation measured in degrees."
msgid "It follows a more specific structure. It is basically a list of dictionaries where each dictionary represents an invoice line. Each value follows a :ref:`webservices/extract_api/invoice_get_results/feature_result` structure."
msgid "Route that validates the different features of an invoice. The validation step is an optional step but is strongly recommended. By telling the system if it were right or wrong for each feature you give an important feedback. It has no direct impact but it helps the system to greatly improve its prediction accuracy for the invoices you will send in the future."
msgid "You don't have to validate all the features in order for the validation to succeed. However :ref:`/validate <webservices/extract_api/invoice_validate>` can't be called multiple times for a same invoice. Therefore you should validate all the features you want to validate at once."
msgid "A **validation** for a given feature is a dictionary containing the textual representation of the expected value for this given feature. This format apply for all the features except for ``global_taxes`` and ``invoice_lines`` which have more complex validation format."
msgid "Indicates if the ``tax_amount`` is a percentage or a fixed value. The type must be specified using the literal string \"fixed\" or \"percent\"."
msgid "You can test your integration by using *integration_token* as ``account_token`` in the :ref:`/parse <webservices/extract_api/invoice_parse>` request."
msgid "Using this token put you in test mode and allows you to simulate the entire flow without really parsing a document and without being billed one credit for each successful invoice parsing."
msgid "The only technical differences in test mode is that the document you send is not parsed by the system and that the response you get from :ref:`/get_results <webservices/extract_api/invoice_get_results>` is a hard-coded one."
msgid "A python implementation of the full flow can be found :download:`here <extract_api/implementation.py>`."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:6
msgid "In-App Purchase"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:8
msgid "In-App Purchase (IAP) allows providers of ongoing services through Odoo apps to be compensated for ongoing service use rather than — and possibly instead of — a sole initial purchase."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:12
msgid "In that context, Odoo acts mostly as a *broker* between a client and an Odoo App Developer:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:15
msgid "Users purchase service tokens from Odoo."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:16
msgid "Service providers draw tokens from the user's Odoo account when service is requested."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:21
msgid "This document is intended for *service providers* and presents the latter, which can be done either via direct JSON-RPC2_ or if you are using Odoo using the convenience helpers it provides."
msgid "The Service Provider is (probably) you the reader, you will be providing value to the client in the form of a service paid per-use."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:35
msgid "The Client installed your Odoo App, and from there will request services."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:36
msgid "Odoo brokers crediting, the Client adds credit to their account, and you can draw credits from there to provide services."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:38
msgid "The External Service is an optional player: *you* can either provide a service directly, or you can delegate the actual service acting as a bridge/translator between an Odoo system and the actual service."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:46
msgid "The Credits"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:48
msgid "The credits went from integer to float value starting **October 2018**. Integer values are still supported."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:51
msgid "Every service provided through the IAP platform can be used by the clients with tokens or *credits*. The credits are an float unit and their monetary value depends on the service and is decided by the provider. This could be:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:56
msgid "for an sms service: 1 credit = 1 sms;"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:57
msgid "for an ad service: 1 credit = 1 ad; or"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:58
msgid "for a postage service: 1 credit = 1 post stamp."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:60
msgid "A credit can also simply be associated with a fixed amount of money to palliate the variations of price (e.g. the prices of sms and stamps may vary following the countries)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:64
msgid "The value of the credits is fixed with the help of prepaid credit packs that the clients can buy on https://iap.odoo.com (see :ref:`Packs <iap-packages>`)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:67
msgid "In the following explanations we will ignore the External Service, they are just a detail of the service you provide."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:73
msgid "'Normal' service flow"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:75
msgid "If everything goes well, the normal flow is the following:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:77
msgid "The Client requests a service of some sort."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:78
msgid "The Service Provider asks Odoo if there are enough credits for the service in the Client's account, and creates a transaction over that amount."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:81
msgid "The Service Provider provides the service (either on their own or calling to External Services)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:83
msgid "The Service Provider goes back to Odoo to capture (if the service could be provided) or cancel (if the service could not be provided) the transaction created at step 2."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:86
msgid "Finally, the Service Provider notifies the Client that the service has been rendered, possibly (depending on the service) displaying or storing its results in the client's system."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:93
msgid "Insufficient credits"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:95
msgid "However, if the Client's account lacks credits for the service, the flow will be as follows:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:97
msgid "The Client requests a service as previously."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:98
msgid "The Service Provider asks Odoo if there are enough credits on the Client's account and gets a negative reply."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:100
msgid "This is signaled back to the Client."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:101
msgid "Who is redirected to their Odoo account to credit it and re-try."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:105
msgid "Building your service"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:107
msgid "For this example, the service we will provide is ~~mining dogecoins~~ burning 10 seconds of CPU for a credit. For your own services, you could, for example:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:110
msgid "provide an online service yourself (e.g. convert quotations to faxes for business in Japan);"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:112
msgid "provide an *offline* service yourself (e.g. provide accountancy service); or"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:113
msgid "act as intermediary to an other service provider (e.g. bridge to an MMS gateway)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:119
msgid "Register the service on Odoo"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:121
msgid "complete this part with screenshots"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:123
msgid "The first step is to register your service on the IAP endpoint (production and/or test) before you can actually query user accounts. To create a service, go to your *Portal Account* on the IAP endpoint (https://iap.odoo.com for production, https://iap-sandbox.odoo.com for testing, the endpoints are *independent* and *not synchronized*). Alternatively, you can go to your portal on Odoo (https://iap.odoo.com/my/home) and select *In-App Services*."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:132
msgid "On production, there is a manual validation step before the service can be used to manage real transactions. This step is automatically passed when on sandbox to ease the tests."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:136
msgid "Log in then go to :menuselection:`My Account --> Your In-App Services`, click Create and provide the information of your service."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:140
msgid "The service has *seven* important fields:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:142
msgid ":samp:`name` - :class:`ServiceName`: This is the string you will need to provide inside the client's :ref:`app <iap-odoo-app>` when requesting a transaction from Odoo. (e.g. :class:`self.env['iap.account].get(name)`). As good practice, this should match the technical name of your app."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:147
msgid ":samp:`label` - :class:`Label`: The name displayed on the shopping portal for the client."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:152
msgid "Both the :class:`ServiceName` and :class:`Label` are unique. As good practice, the :class:`ServiceName` should usually match the name of your Odoo Client App."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:155
msgid ":samp:`icon` - :class:`Icon`: A generic icon that will serve as default for your :ref:`packs <iap-packages>`."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:158
msgid ":samp:`key` - :class:`ServiceKey`: The developer key that identifies you in IAP (see :ref:`your service <iap-service>`) and allows to draw credits from the client's account. It will be shown only once upon creation of the service and can be regenerated at will."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:164
msgid "Your :class:`ServiceKey` *is a secret*, leaking your service key allows other application developers to draw credits bought for your service(s)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:168
msgid ":samp:`trial credits` - :class:`Float`: This corresponds to the credits you are ready to offer upon first use to your app users. Note that such service will only be available to clients that have an active enterprise contract."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:172
msgid ":samp:`privacy policy` - :class:`PrivacyPolicy`: This is an url to the privacy policy of your service. This should explicitly mention the **information you collect**, how you **use it, its relevance** to make your service work and inform the client on how they can **access, update or delete their personal information**."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:189
msgid "You can then create *credit packs* which clients can purchase in order to use your service."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:195
msgid "Packs"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:197
msgid "A credit pack is essentially a product with five characteristics:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:199
msgid "Name: name of the pack,"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:200
msgid "Icon: specific icon for the pack (if not provided, it will fallback on the service icon),"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:201
msgid "Description: details on the pack that will appear on the shop page as well as the invoice,"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:203
msgid "Amount: amount of credits the client is entitled to when buying the pack,"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:204
msgid "Price: price in EUR (for the time being, USD support is planned)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:208
msgid "Odoo takes a 25% commission on all pack sales. Adjust your selling price accordingly."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:213
msgid "Depending on the strategy, the price per credit may vary from one pack to another."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:223
msgid "Odoo App"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:225
msgid "does this actually require apps?"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:227
msgid "The second step is to develop an `Odoo App`_ which clients can install in their Odoo instance and through which they can *request* the services you provide. Our app will just add a button to the Partners form which lets a user request burning some CPU time on the server."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:232
msgid "First, we will create an *odoo module* depending on ``iap``. IAP is a standard V11 module and the dependency ensures a local account is properly set up and we will have access to some necessary views and useful helpers."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:236
#: ../../content/developer/misc/api/iap.rst:251
msgid "`coalroller/__manifest__.py`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:246
msgid "Second, the \"local\" side of the integration. Here we will only be adding an action button to the partners view, but you can of course provide significant local value via your application and additional parts via a remote service."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:264
msgid "`coalroller/views/res_partner_views.xml`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:289
msgid "We can now implement the action method/callback. This will *call our own server*."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:292
msgid "There are no requirements when it comes to the server or the communication protocol between the app and our server, but ``iap`` provides a :func:`~odoo.addons.iap.tools.iap_tools.iap_jsonrpc` helper to call a JSON-RPC2_ endpoint on an other Odoo instance and transparently re-raise relevant Odoo exceptions (:class:`~odoo.addons.iap.tools.iap_tools.InsufficientCreditError`, :class:`odoo.exceptions.AccessError` and :class:`odoo.exceptions.UserError`)."
msgid "the :class:`token <UserToken>` of the current client that is provided by the ``iap.account`` model's ``account_token`` field. You can retrieve the account for your service by calling :samp:`env['iap.account'].get({service_name})` where :class:`service_name <ServiceName>` is the name of the service registered on IAP endpoint."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:308
msgid "`coalroller/models/res_partner.py`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:336
msgid "``iap`` automatically handles :class:`~odoo.addons.iap.tools.iap_tools.InsufficientCreditError` coming from the action and prompts the user to add credits to their account."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:340
msgid ":func:`~odoo.addons.iap.tools.iap_tools.iap_jsonrpc` takes care of re-raising :class:`~odoo.addons.iap.models.iap.InsufficientCreditError` for you."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:345
msgid "If you are not using :func:`~odoo.addons.iap.tools.iap_tools.iap_jsonrpc` you *must* be careful to re-raise :class:`~odoo.addons.iap.tools.iap_tools.InsufficientCreditError` in your handler otherwise the user will not be prompted to credit their account, and the next call will fail the same way."
msgid "Though that is not *required*, since ``iap`` provides both a client helper for JSON-RPC2_ calls (:func:`~odoo.addons.iap.tools.iap_tools.iap_jsonrpc`) and a service helper for transactions (:class:`~odoo.addons.iap.tools.iap_tools.iap_charge`) we will also be implementing the service side as an Odoo module:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:361
#: ../../content/developer/misc/api/iap.rst:449
msgid "`coalroller_service/__manifest__.py`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:371
msgid "Since the query from the client comes as JSON-RPC2_ we will need the corresponding controller which can call :class:`~odoo.addons.iap.tools.iap_tools.iap_charge` and perform the service within:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:375
#: ../../content/developer/misc/api/iap.rst:462
msgid "`coalroller_service/controllers/main.py`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:407
msgid "for the actual IAP will the \"portal\" page be on odoo.com or iap.odoo.com?"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:409
msgid "\"My Account\" > \"Your InApp Services\"?"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:412
msgid "The :class:`~odoo.addons.iap.tools.iap_tools.iap_charge` helper will:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:414
msgid "authorize (create) a transaction with the specified number of credits, if the account does not have enough credits it will raise the relevant error"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:417
msgid "execute the body of the ``with`` statement"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:418
msgid "if the body of the ``with`` executes successfully, update the price of the transaction if needed"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:420
msgid "capture (confirm) the transaction"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:421
msgid "otherwise, if an error is raised from the body of the ``with``, cancel the transaction (and release the hold on the credits)"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:426
msgid "By default, :class:`~odoo.addons.iap.tools.iap_tools.iap_charge` contacts the *production* IAP endpoint, https://iap.odoo.com. While developing and testing your service you may want to point it towards the *development* IAP endpoint https://iap-sandbox.odoo.com."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:431
msgid "To do so, set the ``iap.endpoint`` config parameter in your service Odoo: in debug/developer mode, :menuselection:`Setting --> Technical --> Parameters --> System Parameters`, just define an entry for the key ``iap.endpoint`` if none already exists)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:436
msgid "The :class:`~odoo.addons.iap.tools.iap_tools.iap_charge` helper has two additional optional parameters we can use to make things clearer to the end-user."
msgid "is a message which will be associated with the transaction and will be displayed in the user's dashboard, it is useful to remind the user why the charge exists."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:447
msgid "``credit_template``"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:444
msgid "is the name of a :ref:`reference/qweb` template which will be rendered and shown to the user if their account has less credit available than the service provider is requesting, its purpose is to tell your users why they should be interested in your IAP offers."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:487
msgid "`coalroller_service/views/no-credit.xml`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:510
msgid "how do you test your service?"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:513
msgid "JSON-RPC2_ Transaction API"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:518
msgid "The IAP transaction API does not require using Odoo when implementing your server gateway, calls are standard JSON-RPC2_."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:520
msgid "Calls use different *endpoints* but the same *method* on all endpoints (``call``)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:522
msgid "Exceptions are returned as JSON-RPC2_ errors, the formal exception name is available on ``data.name`` for programmatic manipulation."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:525
msgid "`iap.odoo.com documentation`_ for additional information."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:528
#: ../../content/developer/misc/api/iap.rst:770
msgid "Authorize"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:532
msgid "Verifies that the user's account has at least as ``credit`` available *and creates a hold (pending transaction) on that amount*."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:535
msgid "Any amount currently on hold by a pending transaction is considered unavailable to further authorize calls."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:538
msgid "Returns a :class:`TransactionToken` identifying the pending transaction which can be used to capture (confirm) or cancel said transaction (`iap.odoo.com documentation`_)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:544
msgid "optional, helps users identify the reason for charges on their account"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:546
msgid "optional, allows the user to benefit from trial credits if his database is eligible (see :ref:`Service registration <register-service>`)"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:0
#: ../../../odoo/odoo/http.py:docstring of odoo.http.WebRequest.csrf_token:0
msgid ":class:`TransactionToken` if the authorization succeeded"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:0
#: ../../content/developer/misc/api/iap.rst:0
#: ../../content/developer/misc/api/iap.rst:0
#: ../../content/developer/misc/api/iap.rst:0
#: ../../content/developer/misc/api/iap.rst:0
msgid "raises"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:549
msgid ":class:`~odoo.exceptions.AccessError` if the service token is invalid"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:550
msgid ":class:`~odoo.addons.iap.models.iap.InsufficientCreditError` if the account does not have enough credits"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:551
msgid "``TypeError`` if the ``credit`` value is not an integer or a float"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:573
#: ../../content/developer/misc/api/iap.rst:849
msgid "Capture"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:577
msgid "Confirms the specified transaction, transferring the reserved credits from the user's account to the service provider's."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:580
msgid "Capture calls are idempotent: performing capture calls on an already captured transaction has no further effect."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:585
msgid "optional parameter to capture a smaller amount of credits than authorized"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:586
#: ../../content/developer/misc/api/iap.rst:618
msgid ":class:`~odoo.exceptions.AccessError`"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:606
#: ../../content/developer/misc/api/iap.rst:811
msgid "Cancel"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:610
msgid "Cancels the specified transaction, releasing the hold on the user's credits."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:613
msgid "Cancel calls are idempotent: performing capture calls on an already cancelled transaction has no further effect."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:638
msgid "Exceptions aside, these are *abstract types* used for clarity, you should not care how they are implemented."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:643
msgid "String identifying your service on https://iap.odoo.com (production) as well as the account related to your service in the client's database."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:648
msgid "Identifier generated for the provider's service. Each key (and service) matches a token of a fixed value, as generated by the service provide."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:651
msgid "Multiple types of tokens correspond to multiple services. As an exampe, SMS and MMS could either be the same service (with an MMS being 'worth' multiple SMS) or could be separate services at separate price points."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:655
msgid "Your service key *is a secret*, leaking your service key allows other application developers to draw credits bought for your service(s)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:661
msgid "Identifier for a user account."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:665
msgid "Transaction identifier, returned by the authorization process and consumed by either capturing or cancelling the transaction."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:670
msgid "Raised during transaction authorization if the credits requested are not currently available on the account (either not enough credits or too many pending transactions/existing holds)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:677
msgid "Raised by:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:679
msgid "any operation to which a service token is required, if the service token is invalid; or"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:680
msgid "any failure in an inter-server call. (typically, in :func:`~odoo.addons.iap.tools.iap_tools.iap_jsonrpc`)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:685
msgid "Raised by any unexpected behaviour at the discretion of the App developer (*you*)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:689
msgid "Test the API"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:691
msgid "In order to test the developed app, we propose a sandbox platform that allows you to:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:693
msgid "Test the whole flow from the client's point of view - Actual services and transactions that can be consulted. (again this requires to change the endpoint, see the danger note in :ref:`Service <iap-service>`)."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:696
msgid "Test the API."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:698
msgid "The latter consists in specific tokens that will work on **IAP-Sandbox only**."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:700
msgid "Token ``000000``: Represents a non-existing account. Returns an :class:`~odoo.addons.iap.tools.iap_tools.InsufficientCreditError` on authorize attempt."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:702
msgid "Token ``000111``: Represents an account without sufficient credits to perform any service. Returns an :class:`~odoo.addons.iap.tools.iap_tools.InsufficientCreditError` on authorize attempt."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:704
msgid "Token ``111111``: Represents an account with enough credits to perform any service. An authorize attempt will return a dummy transaction token that is processed by the capture and cancel routes."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:710
msgid "Those tokens are only active on the IAP-Sanbox server."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:711
msgid "The service key is completely ignored with this flow, If you want to run a robust test of your service, you should ignore these tokens."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:715
msgid "Odoo Helpers"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:717
msgid "For convenience, if you are implementing your service using Odoo the ``iap`` module provides a few helpers to make IAP flow even simpler."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:723
msgid "Charging"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:727
msgid "A *context manager* for authorizing and automatically capturing or cancelling transactions for use in the backend/proxy."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:730
msgid "Works much like e.g. a cursor context manager:"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:732
msgid "immediately authorizes a transaction with the specified parameters;"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:733
msgid "executes the ``with`` body;"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:734
msgid "if the body executes in full without error, captures the transaction;"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:735
msgid "otherwise cancels it."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:737
#: ../../content/developer/misc/api/iap.rst:776
#: ../../content/developer/misc/api/iap.rst:817
#: ../../content/developer/misc/api/iap.rst:855
msgid "used to retrieve the ``iap.endpoint`` configuration key"
msgstr ""
#: ../../content/developer/misc/api/iap.rst:774
msgid "Will authorize everything."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:815
msgid "Will cancel an authorized transaction."
msgstr ""
#: ../../content/developer/misc/api/iap.rst:853
msgid "Will capture the amount ``credit`` on the given transaction."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:3
msgid "External API"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:5
msgid "Odoo is usually extended internally via modules, but many of its features and all of its data are also available from the outside for external analysis or integration with various tools. Part of the :ref:`reference/orm/model` API is easily available over XML-RPC_ and accessible from a variety of languages."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:11
msgid "Connection"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:14
msgid "Configuration"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:16
msgid "If you already have an Odoo server installed, you can just use its parameters."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:20
msgid "For Odoo Online instances (<domain>.odoo.com), users are created without a *local* password (as a person you are logged in via the Odoo Online authentication system, not by the instance itself). To use XML-RPC on Odoo Online instances, you will need to set a password on the user account you want to use:"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:26
msgid "Log in your instance with an administrator account."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:27
msgid "Go to :menuselection:`Settings --> Users & Companies --> Users`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:28
msgid "Click on the user you want to use for XML-RPC access."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:29
msgid "Click on :guilabel:`Action` and select :guilabel:`Change Password`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:30
msgid "Set a :guilabel:`New Password` value then click :guilabel:`Change Password`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:32
msgid "The *server url* is the instance's domain (e.g. *https://mycompany.odoo.com*), the *database name* is the name of the instance (e.g. *mycompany*). The *username* is the configured user's login as shown by the *Change Password* screen."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:68
msgid "API Keys"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:72
msgid "Odoo has support for **api keys** and (depending on modules or settings) may **require** these keys to perform webservice operations."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:75
msgid "The way to use API Keys in your scripts is to simply replace your **password** by the key. The login remains in-use. You should store the API Key as carefully as the password as they essentially provide the same access to your user account (although they can not be used to log-in via the interface)."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:80
msgid "In order to add a key to your account, simply go to your :guilabel:`Preferences` (or :guilabel:`My Profile`):"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:86
msgid "then open the :guilabel:`Account Security` tab, and click :guilabel:`New API Key`:"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:92
msgid "Input a description for the key, **this description should be as clear and complete as possible**: it is the only way you will have to identify your keys later and know whether you should remove them or keep them around."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:96
msgid "Click :guilabel:`Generate Key`, then copy the key provided. **Store this key carefully**: it is equivalent to your password, and just like your password the system will not be able to retrieve or show the key again later on. If you lose this key, you will have to create a new one (and probably delete the one you lost)."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:102
msgid "Once you have keys configured on your account, they will appear above the :guilabel:`New API Key` button, and you will be able to delete them:"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:108
msgid "**A deleted API key can not be undeleted or re-set**. You will have to generate a new key and update all the places where you used the old one."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:112
msgid "Test database"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:114
msgid "To make exploration simpler, you can also ask https://demo.odoo.com for a test database:"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:131
msgid "PHP"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:140
msgid "These examples use the `Ripcord <https://code.google.com/p/ripcord/>`_ library, which provides a simple XML-RPC API. Ripcord requires that `XML-RPC support be enabled <https://php.net/manual/en/xmlrpc.installation.php>`_ in your PHP installation."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:146
msgid "Since calls are performed over `HTTPS <https://en.wikipedia.org/wiki/HTTP_Secure>`_, it also requires that the `OpenSSL extension <https://php.net/manual/en/openssl.installation.php>`_ be enabled."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:151
msgid "Java"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:168
msgid "These examples use the `Apache XML-RPC library <https://ws.apache.org/xmlrpc/>`_."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:170
msgid "The examples do not include imports as these imports couldn't be pasted in the code."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:174
msgid "Logging in"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:176
msgid "Odoo requires users of the API to be authenticated before they can query most data."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:179
msgid "The ``xmlrpc/2/common`` endpoint provides meta-calls which don't require authentication, such as the authentication itself or fetching version information. To verify if the connection information is correct before trying to authenticate, the simplest call is to ask for the server's version. The authentication itself is done through the ``authenticate`` function and returns a user identifier (``uid``) used in authenticated calls instead of the login."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:243
msgid "Calling methods"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:245
msgid "The second endpoint is ``xmlrpc/2/object``. It is used to call methods of odoo models via the ``execute_kw`` RPC function."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:248
msgid "Each call to ``execute_kw`` takes the following parameters:"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:250
msgid "the database to use, a string"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:251
msgid "the user id (retrieved through ``authenticate``), an integer"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:252
msgid "the user's password, a string"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:253
msgid "the model name, a string"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:254
msgid "the method name, a string"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:255
msgid "an array/list of parameters passed by position"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:256
msgid "a mapping/dict of parameters to pass by keyword (optional)"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:260
msgid "For instance, to see if we can read the ``res.partner`` model, we can call ``check_access_rights`` with ``operation`` passed by position and ``raise_exception`` passed by keyword (in order to get a true/false result rather than true/error):"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:303
msgid "List records"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:305
msgid "Records can be listed and filtered via :meth:`~odoo.models.Model.search`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:307
msgid ":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."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:313
msgid "To list customer companies, for instance:"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:345
msgid "Pagination"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:347
msgid "By default a search will return the ids of all records matching the condition, which may be a huge number. ``offset`` and ``limit`` parameters are available to only retrieve a subset of all matched records."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:384
msgid "Count records"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:386
msgid "Rather than retrieve a possibly gigantic list of records and count them, :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:`~odoo.models.Model.search` and no other parameter."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:424
msgid "Calling ``search`` then ``search_count`` (or the other way around) may not yield coherent results if other users are using the server: stored data could have changed between the calls."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:429
msgid "Read records"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:431
msgid "Record data are accessible via the :meth:`~odoo.models.Model.read` method, which takes a list of ids (as returned by :meth:`~odoo.models.Model.search`), and optionally a list of fields to fetch. By default, it fetches all the fields the current user can read, which tends to be a huge amount."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:487
msgid "Conversely, picking only three fields deemed interesting."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:521
msgid "Even if the ``id`` field is not requested, it is always returned."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:524
msgid "List record fields"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:526
msgid ":meth:`~odoo.models.Model.fields_get` can be used to inspect a model's fields and check which ones seem to be of interest."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:529
msgid "Because it returns a large amount of meta-information (it is also used by client programs) it should be filtered before printing, the most interesting items for a human user are ``string`` (the field's label), ``help`` (a help text if available) and ``type`` (to know which values to expect, or to send when updating a record)."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:604
msgid "Search and read"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:606
msgid "Because it is a very common task, Odoo provides a :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."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:612
msgid "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)."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:683
msgid "Create records"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:685
msgid "Records of a model are created using :meth:`~odoo.models.Model.create`. The method creates a single record and returns its database identifier."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:688
msgid ":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."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:723
msgid "While most value types are what would expect (integer for :class:`~odoo.fields.Integer`, string for :class:`~odoo.fields.Char` or :class:`~odoo.fields.Text`),"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:727
msgid ":class:`~odoo.fields.Date`, :class:`~odoo.fields.Datetime` and :class:`~odoo.fields.Binary` fields use string values"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:729
msgid ":class:`~odoo.fields.One2many` and :class:`~odoo.fields.Many2many` use a special command protocol detailed in :meth:`the documentation to the write method <odoo.models.Model.write>`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:734
msgid "Update records"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:736
msgid "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:`~odoo.models.Model.create`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:740
msgid "Multiple records can be updated simultaneously, but they will all get the same values for the fields being set. It is not possible to perform \"computed\" updates (where the value being set depends on an existing value of a record)."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:792
msgid "Delete records"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:794
msgid "Records can be deleted in bulk by providing their ids to :meth:`~odoo.models.Model.unlink`."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:841
msgid "Inspection and introspection"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:843
msgid "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 XML-RPC."
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:852
msgid "``ir.model``"
msgstr ""
#: ../../content/developer/misc/api/odoo.rst:854
msgid "Provides information about Odoo models via its various fields."
msgid "When installing the ``accounting`` module, the localization module corresponding to the country code of the company is installed automatically. In case of no country code set or no localization module found, the ``l10n_generic_coa`` (US) localization module is installed by default."
msgid "First of all, before I proceed, we need to talk about the templates. A template is a record that allows replica of itself. This mechanism is needed when working in multi-companies. For example, the creation of a new account is done using the ``account.account.template`` model. However, each company using this chart of accounts will be linked to a replica having ``account.account`` as model. So, the templates are never used directly by the company."
msgid "Then, when a chart of accounts needs to be installed, all templates dependent of this one will create a replica and link this newly generated record to the company's user. It means all such templates must be linked to the chart of accounts in some way. To do so, each one must reference the desired chart of accounts using the ``chart_template_id`` field. For this reason, we need to define an instance of the ``account.chart.template`` model before creating its templates."
msgid "Now that the chart of accounts is created, we can focus on the creation of the templates. As said previously, each record must reference this record through the ``chart_template_id`` field. If not, the template will be ignored. The following sections show in details how to create these templates."
msgid "It's time to create our accounts. It consists to creating records of ``account.account.template`` type. Each ``account.account.template`` is able to create an ``account.account`` for each company."
msgid "The ``user_type_id`` field requires a value of type ``account.account.type``. Although some additional types could be created in a localization module, we encourage the usage of the existing types in the `account/data/data_account_type.xml <https://github.com/odoo/odoo/blob/14.0/addons/account/data/data_account_type.xml>`_ file. The usage of these generic types ensures the generic reports working correctly in addition to those that you could create in your localization module."
msgid "Avoid the usage of liquidity ``account.account.type``! Indeed, the bank & cash accounts are created directly at the installation of the localization module and then, are linked to an ``account.journal``."
msgid "Although the ``tag_ids`` field is optional, this one remains a very powerful feature. Indeed, this one allows you to define some tags for your accounts to spread them correctly on your reports. For example, suppose you want to create a financial report having multiple lines but you have no way to find a rule to dispatch the accounts according their ``code`` or ``name``. The solution is the usage of tags, one for each report line, to spread and aggregate your accounts like you want."
msgid "To create a new tax record, you just need to follow the same process as the creation of accounts. The only difference being that you must use the ``account.tax.template`` model."
msgid "If you need more information about what is a fiscal position and how it works in Odoo, please refer to :doc:`/applications/finance/accounting/taxation/taxes/fiscal_positions`."
msgid "When the whole accounts are generated, you have the possibility to override the newly generated chart of accounts by adding some properties that correspond to default accounts used in certain situations. This must be done after the creation of accounts before each one must be linked to the chart of accounts."
msgid "Since ``V10``, a new feature is available in the bank statement reconciliation widget: the bank operation model. This allows the user to pre-fill some accounting entries with a single click. The creation of an ``account.reconcile.model.template`` record is quite easy:"
msgid "If you need to add some reports on your localization, you need to create a new module named **l10n_xx_reports**. Furthermore, this additional module must be present in the ``enterprise`` repository and must have at least two dependencies, one to bring all the stuff for your localization module and one more, ``account_reports``, to design dynamic reports."
msgid "Once it's done, you can start the creation of your report statements. The documentation is available in the following `slides <https://www.odoo.com/slides/slide/how-to-create-custom-accounting-report-415>`_."
msgid "If you want to contribute to the translation of Odoo itself, please refer to the `Odoo Wiki page <https://github.com/odoo/odoo/wiki/Translations>`_."
msgid "A number of terms in your modules are \"implicitly translatable\" as a result, even if you haven't done any specific work towards translation you can export your module's translatable terms and may find content to work with."
msgid "Translations export is performed via the administration interface by logging into the backend interface and opening :menuselection:`Settings --> Translations --> Import / Export --> Export Translations`"
msgid "This gives you a file called :file:`{yourmodule}.pot` which should be moved to the :file:`{yourmodule}/i18n/` directory. The file is a *PO Template* which simply lists translatable strings and from which actual translations (PO files) can be created. PO files can be created using msginit_, with a dedicated translation tool like POEdit_ or by simply copying the template to a new file called :file:`{language}.po`. Translation files should be put in :file:`{yourmodule}/i18n/`, next to :file:`{yourmodule}.pot`, and will be automatically loaded by Odoo when the corresponding language is installed (via :menuselection:`Settings --> Translations --> Languages`)"
msgid "in non-QWeb views, all text nodes are exported as well as the content of the ``string``, ``help``, ``sum``, ``confirm`` and ``placeholder`` attributes"
msgid "QWeb templates (both server-side and client-side), all text nodes are exported except inside ``t-translation=\"off\"`` blocks, the content of the ``title``, ``alt``, ``label`` and ``placeholder`` attributes are also exported"
msgid "When it comes to more \"imperative\" situations in Python code or Javascript 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."
msgid "Only literal strings can be marked for exports, not expressions or variables. For situations where strings are formatted, this means the format string must be marked, not the formatted string"
msgid "The lazy version of `_` and `_t` is :func:`odoo._lt` in python and :js:func:`odoo.web._lt` in javascript. The translation lookup is executed only at rendering and can be used to declare translatable properties in class methods of global variables."
msgid "Translations of a module are **not** exposed to the front end by default and thus are not accessible from JavaScript. In order to achieve that, the module name has to be either prefixed with `website` (just like `website_sale`, `website_event` etc.) or explicitly register by implementing :func:`_get_translation_frontend_modules_name` for the `ir.http` model."
msgid "**Do** set the dynamic variables as a parameter of the translation lookup (this will fallback on source in case of missing placeholder in the translation)::"
msgid "**Do** in the case where the translation lookup is done when the JS file is *read*, use `_lt` instead of `_t` to translate the term when it is *used*::"
msgid "The CLI :dfn:`command-line interface` offers several functionalities related to Odoo. You can use it to :ref:`run the server <reference/cmdline/server>`, :ref:`launch Odoo as a Python console environment <reference/cmdline/shell>`, :ref:`scaffold an Odoo module <reference/cmdline/scaffold>`, :ref:`populate a database <reference/cmdline/populate>`, or :ref:`count the number of lines of code <reference/cmdline/cloc>`."
msgid "The command to use to call the CLI depends on how you installed Odoo. In the examples below, we assume that you are :ref:`running Odoo from source <setup/install/source>` with the :file:`odoo-bin` file. If you installed Odoo :ref:`from a distribution package <setup/install/packaged>` or :ref:`with Docker <setup/install/docker>`, you must adapt the command."
msgid "When Odoo was installed, an executable named `odoo` was added to your user's PATH. Replace all occurrences of :command:`odoo-bin` with :command:`odoo` in the examples below."
msgid "saves the server configuration to the current configuration file (:file:`{$HOME}/.odoorc` by default, and can be overridden using :option:`-c`)."
msgid "The tag will match tags added on a class with a :func:`~odoo.tests.common.tagged` decorator (all :ref:`test classes <reference/testing>` have `standard` and `at_install` tags until explicitly removed, see the decorator documentation)."
msgid "Filtering and executing the tests happens twice: right after each module installation/update and at the end of the modules loading. At each stage tests are filtered by `--test-tags` specs and additionally by dynamic specs `at_install` and `post_install` correspondingly."
msgid "Specify directory where to write screenshots when an HttpCase.browser_js test fails. It defaults to :file:`/tmp/odoo_tests/{db_name}/screenshots`"
msgid "Enable screencasts and specify directory where to write screencasts files. The ``ffmpeg`` utility needs to be installed to encode frames into a video file. Otherwise frames will be kept instead of the video file."
msgid "``%d`` is replaced by the subdomain the request is made on, with the exception of ``www`` (so domain ``odoo.com`` and ``www.odoo.com`` both match the database ``odoo``)."
msgid "These operations are case sensitive. Add option ``(?i)`` to match all databases (so domain ``odoo.com`` using ``(?i)%d`` matches the database ``Odoo``)."
msgid "Since version 11, it's also possible to restrict access to a given database listen by using the --database parameter and specifying a comma-separated list of databases"
msgid "When combining the two parameters, db-filter supersedes the comma-separated database list for restricting database list, while the comma-separated list is used for performing requested operations like upgrade of modules."
msgid "Restrict access to only two databases, 11firstdatabase and 11seconddatabase, and update base module on one database: 11firstdatabase. If database 11seconddatabase doesn't exist, the database is created and base modules is installed"
msgid "Restrict access to databases whose name starts with 11, and update base module on one database: 11firstdatabase. If database 11seconddatabase doesn't exist, the database is created and base modules is installed"
msgid "Path to the PostgreSQL binaries that are used by the database manager to dump and restore databases. You have to specify this option only if these binaries are located in a non-standard directory."
msgid "Control the SSL security of the connection between Odoo and PostgreSQL. Value should be one of 'disable', 'allow', 'prefer', 'require', 'verify-ca' or 'verify-full' Default value is 'prefer'"
msgid "Use these options to translate Odoo to another language. See i18n section of the user manual. Option '-d' is mandatory. Option '-l' is mandatory in case of importation"
msgid "``xml``: read template qweb from xml file directly instead of database. Once a template has been modified in database, it will be not be read from the xml file until the next update/init."
msgid "By default, Odoo displays all logging of level_ ``info`` except for workflow logging (``warning`` only), and log output is sent to ``stdout``. Various options are available to redirect logging to other destinations and to customize the amount of logging output."
msgid "sends logging output to the specified file instead of stdout. On Unix, the file `can be managed by external log rotation programs <https://docs.python.org/3/library/logging.handlers.html#watchedfilehandler>`_ and will automatically be reopened when replaced"
msgid "logs to the system's event logger: `syslog on unices <https://docs.python.org/3/library/logging.handlers.html#sysloghandler>`_ and `the Event Log on Windows <https://docs.python.org/3/library/logging.handlers.html#nteventloghandler>`_."
msgid "logs to the ``ir.logging`` model (``ir_logging`` table) of the specified database. The database can be the name of a database in the \"current\" PostgreSQL, or `a PostgreSQL URI`_ for e.g. log aggregation."
msgid ":samp:`{LOGGER}:{LEVEL}`, enables ``LOGGER`` at the provided ``LEVEL`` e.g. ``odoo.models:DEBUG`` will enable all logging messages at or above ``DEBUG`` level in the models."
msgid "Shortcut to more easily set predefined levels on specific loggers. \"real\" levels (``critical``, ``error``, ``warn``, ``debug``) are set on the ``odoo`` and ``werkzeug`` loggers (except for ``debug`` which is only set on ``odoo``)."
msgid "if ``count`` is not 0 (the default), enables multiprocessing and sets up the specified number of HTTP workers (sub-processes processing HTTP and RPC requests)."
msgid "Hard limit on virtual memory, any worker exceeding the limit will be immediately killed without waiting for the end of the current request processing."
msgid "number of workers dedicated to :ref:`cron <reference/actions/cron>` jobs. Defaults to *2*. The workers are threads in multi-threading mode and processes in multi-processing mode."
msgid "Most of the command-line options can also be specified via a configuration file. Most of the time, they use similar names with the prefix ``-`` removed and other ``-`` are replaced by ``_`` e.g. :option:`--db-template` becomes ``db_template``."
msgid "logging presets (all options starting with ``--log-`` except for :option:`--log-handler` and :option:`--log-db`) just add content to ``log_handler``, use that directly in the configuration file"
msgid "The default configuration file is :file:`{$HOME}/.odoorc` which can be overridden using :option:`--config <odoo-bin -c>`. Specifying :option:`--save <odoo-bin -s>` will save the current configuration state back to that file. The configuration items relative to the command-line are to be specified in the section ``[options]``."
msgid "Odoo command-line also allows to launch odoo as a python console environment. This enables direct interaction with the :ref:`orm <reference/orm>` and its functionalities."
msgid "Scaffolding is the automated creation of a skeleton structure to simplify bootstrapping (of new modules, in the case of Odoo). While not necessary it avoids the tedium of setting up basic structures and looking up what all starting requirements are."
msgid "Odoo CLI supports database population features. If the feature is :ref:`implemented on a given model <reference/testing/populate/methods>`, it allows automatic data generation of the model's records to test your modules in databases containing non-trivial amounts of records."
msgid "population size, the actual records number depends on the model's `_populate_sizes` attribute. The generated records content is specified by the :meth:`~odoo.models._populate_factories` method of a given model (cf. the :file:`populate` folder of modules for further details)."
msgid "Odoo Cloc is a tool to count the number of relevant lines written in Python, Javascript or XML. This can be used as a rough metric for pricing maintenance of extra modules."
msgid "Process the code of all extra modules installed on the provided database, and of all server actions and computed fields manually created in the provided database."
msgid "If combined with :option:`--path`, the count will be that of the sum of both options' results (with possible overlaps). At least one of these two options is required to specify which code to process."
msgid "If combined with :option:`--database`, the count will be that of the sum of both options' results (with possible overlaps). At least one of these two options is required to specify which code to process."
msgid "Odoo Cloc counts the lines in each file of extra installed modules in a given database. In addition, it counts the Python lines of server actions and custom computed fields that have been directly created in the database or imported."
msgid "For special cases, a list of files that should be ignored by Odoo Cloc can be defined per module. This is specified by the ``cloc_exclude`` entry of the manifest:"
msgid "This method works the same as with the :ref:`--database option <reference/cmdline/cloc/database-option>` if a manifest file is present in the given folder. Otherwise, it counts all files."
msgid "To distinguish between standard and extra modules, Odoo Cloc uses the following heuristic: modules that are located (real file system path, after following symbolic links) in the same parent directory as the ``base``, ``web`` or ``web_enterprise`` standard modules are considered standard. Other modules are treated as extra modules."
msgid "Odoo Cloc cannot count the lines of code of a Python file with a syntax problem. If an extra module contains such files, they should be fixed to allow the module to load. If the module works despite the presence of those files, they are probably not loaded and should therefore be removed from the module, or at least excluded in the manifest via ``cloc_exclude``."
msgid "This page introduces the Odoo Coding Guidelines. Those aim to improve the quality of Odoo Apps code. Indeed proper code improves readability, eases maintenance, helps debugging, lowers complexity and promotes reliability. These guidelines should be applied to every new module and to all new development."
msgid "When modifying existing files in **stable version** the original file style strictly supersedes any other style guidelines. In other words please never modify existing files in order to apply these guidelines. It avoids disrupting the revision history of code lines. Diff should be kept minimal. For more details, see our `pull request guide <https://odoo.com/submit-pr>`_."
msgid "When modifying existing files in **master (development) version** apply those guidelines to existing code only for modified code or if most of the file is under revision. In other words modify existing files structure only if it is going under major changes. In that case first do a **move** commit then apply the changes related to the feature."
msgid "A module is organized in important directories. Those contain the business logic; having a look at them should make you understand the purpose of the module."
msgid "File naming is important to quickly find information through all odoo addons. This section explains how to name files in a standard odoo module. As an example we use a `plant nursery <https://github.com/tivisse/odoodays-2018/tree/master/plant_nursery>`_ application. It holds two main models *plant.nursery* and *plant.order*."
msgid "Concerning *models*, split the business logic by sets of models belonging to a same main model. Each set lies in a given file named based on its main model. If there is only one model, its name is the same as the module name. Each inherited model should be in its own file to help understanding of impacted models."
msgid "Concerning *views*, backend views should be split like models and suffixed by ``_views.xml``. Backend views are list, form, kanban, activity, graph, pivot, .. views. To ease split by model in views main menus not linked to specific actions may be extracted into an optional ``<module>_menus.xml`` file. Templates (QWeb pages used notably for portal / website display) and bundles (import of JS and CSS assets) are put in separate files. Those are respectively ``<model>_templates.xml`` and ``assets.xml`` files."
msgid "Concerning *data*, split them by purpose (demo or data) and main model. Filenames will be the main_model name suffixed by ``_demo.xml`` or ``_data.xml``. For instance for an application having demo and data for its main model as well as subtypes, activities and mail templates all related to mail module:"
msgid "Concerning *controllers*, generally all controllers belong to a single controller contained in a file named ``<module_name>.py``. An old convention in Odoo is to name this file ``main.py`` but it is considered as outdated. If you need to inherit an existing controller from another module do it in ``<inherited_module_name>.py``. For example adding portal controller in an application is done in ``portal.py``."
msgid "Concerning *static files*, Javascript files follow globally the same logic as python models. Each component should be in its own file with a meaningful name. For instance, the activity widgets are located in ``activity.js`` of mail module. Subdirectories can also be created to structure the 'package' (see web module for more details). The same logic should be applied for the templates of JS widgets (static XML files) and for their styles (scss files). Don't link data (image, libraries) outside Odoo: do not use an URL to an image but copy it in the codebase instead."
msgid "Concerning *wizards*, naming convention is the same of for python models: ``<transient>.py`` and ``<transient>_views.xml``. Both are put in the wizard directory. This naming comes from old odoo applications using the wizard keyword for transient models."
msgid "For field declaration, ``name`` attribute is first. Then place the *value* either in the ``field`` tag, either in the ``eval`` attribute, and finally other attributes (widget, options, ...) ordered by importance."
msgid "The tag *<data>* is only used to set not-updatable data with ``noupdate=1``. If there is only not-updatable data in the file, the ``noupdate=1`` can be set on the ``<odoo>`` tag and do not set a ``<data>`` tag."
msgid "For an action: the main action respects :samp:`{<model_name>}_action`. Others are suffixed with :samp:`_{<detail>}`, where *detail* is a lowercase string briefly explaining the action. This is used only if multiple actions are declared for the model."
msgid "For a rule: :samp:`{<model_name>}_rule_{<concerned_group>}` where *concerned_group* is the short name of the concerned group ('user' for the 'model_name_group_user', 'public' for public user, 'company' for multi-company rules, ...)."
msgid "Xml Ids of inheriting views should use the same ID as the original record. It helps finding all inheritance at a glance. As final Xml Ids are prefixed by the module that creates them there is no overlap."
msgid "Using a linter can help show syntax and semantic warnings or errors. Odoo source code tries to respect Python standard, but some of them can be ignored."
msgid "Useless variable : Temporary variables can make the code clearer by giving names to objects, but that doesn't mean you should create temporary variables all the time:"
msgid "Learn list comprehensions : Use list comprehension, dict comprehension, and basic manipulation using ``map``, ``filter``, ``sum``, ... They make the code easier to read."
msgid "Collections are booleans too : In python, many objects have \"boolean-ish\" value when evaluated in a boolean context (such as an if). Among these are collections (lists, dicts, sets, ...) which are \"falsy\" when empty and \"truthy\" when containing items:"
msgid "In additions to these guidelines, you may also find the following link interesting: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html (a little bit outdated, but quite relevant)"
msgid "For performance issue, when developing a 'stat button' (for instance), do not perform a ``search`` or a ``search_count`` in a loop. It is recommended to use ``read_group`` method, to compute all value in only one request."
msgid "The context is a ``frozendict`` that cannot be modified. To call a method with a different context, the ``with_context`` method should be used :"
msgid "Since the values are propagated automatically, some unexpected behavior may appear. Calling ``create()`` method of a model with *default_my_field* key in context will set the default value of *my_field* for the concerned model. But if during this creation, other objects (such as sale.order.line, on sale.order creation) having a field name *my_field* are created, their default value will be set too."
msgid "If you need to create a key context influencing the behavior of some object, choice a good name, and eventually prefix it by the name of the module to isolate its impact. A good example are the keys of ``mail`` module : *mail_create_nosubscribe*, *mail_notrack*, *mail_notify_user_signature*, ..."
msgid "Functions and methods should not contain too much logic: having a lot of small and simple methods is more advisable than having few large and complex methods. A good rule of thumb is to split a method as soon as it has more than one responsibility (see http://en.wikipedia.org/wiki/Single_responsibility_principle)."
msgid "Also, name your functions accordingly: small and properly named functions are the starting point of readable/maintainable code and tighter documentation."
msgid "The Odoo framework is in charge of providing the transactional context for all RPC calls. The principle is that a new database cursor is opened at the beginning of each RPC call, and committed when the call has returned, just before transmitting the answer to the RPC client, approximately like this:"
msgid "Similarly, the system also provides a dedicated transaction during the execution of tests suites, so it can be rolled back or not depending on the server startup options."
msgid "The consequence is that if you manually call ``cr.commit()`` anywhere there is a very high chance that you will break the system in various ways, because you will cause partial commits, and thus partial and unclean rollbacks, causing among others:"
msgid "tests that can't be rolled back cleanly, and will start polluting the database, and triggering error (this is true even if no error occurs during the transaction)"
msgid "You should **NEVER** call ``cr.commit()`` yourself, **UNLESS** you have created your own database cursor explicitly! And the situations where you need to do that are exceptional!"
msgid "And by the way if you did create your own cursor, then you need to handle error cases and proper rollback, as well as properly close the cursor when you're done with it."
msgid "And contrary to popular belief, you do not even need to call ``cr.commit()`` in the following situations: - in the ``_auto_init()`` method of an *models.Model* object: this is taken care of by the addons initialization method, or by the ORM transaction when creating custom models - in reports: the ``commit()`` is handled by the framework too, so you can update the database even from within a report - within *models.Transient* methods: these methods are called exactly like regular *models.Model* ones, within a transaction and with the corresponding ``cr.commit()/rollback()`` at the end - etc. (see general rule above if you have in doubt!)"
msgid "All ``cr.commit()`` calls outside of the server framework from now on must have an **explicit comment** explaining why they are absolutely necessary, why they are indeed correct, and why they do not break the transactions. Otherwise they can and will be removed !"
msgid "Odoo uses a GetText-like method named \"underscore\" ``_( )`` to indicate that a static string used in the code needs to be translated at runtime using the language of the context. This pseudo-method is accessed within your code by importing as follows:"
msgid "Basically, this method should only be used for static strings written manually in the code, it will not work to translate field values, such as Product names, etc. This must be done instead using the translate flag on the corresponding field."
msgid "The method accepts optional positional or named parameter The rule is very simple: calls to the underscore method should always be in the form ``_('literal string')`` and nothing else:"
msgid "Also, keep in mind that translators will have to work with the literal values that are passed to the underscore function, so please try to make them easy to understand and keep spurious characters and formatting to a minimum. Translators must be aware that formatting patterns such as ``%s`` or ``%d``, newlines, etc. need to be preserved, but it's important to use these in a sensible and obvious manner:"
msgid "In general in Odoo, when manipulating strings, prefer ``%`` over ``.format()`` (when only one variable to replace in a string), and prefer ``%(varname)`` instead of position (when multiple variables have to be replaced). This makes the translation easier for the community translators."
msgid "When defining an Odoo Transient (wizard) : use ``<related_base_model>.<action>`` where *related_base_model* is the base model (defined in *models/*) related to the transient, and *action* is the short name of what the transient do. Avoid the *wizard* word. For instance : ``account.invoice.make``, ``project.task.delegate.batch``, ..."
msgid "suffix your variable name with *_id* or *_ids* if it contains a record id or list of id. Don't use ``partner_id`` to contain a record of res.partner"
msgid "Action method : an object action method is prefix with *action_*. Since it uses only one record, add ``self.ensure_one()`` at the beginning of the method."
msgid "Odoo addons have some conventions on how to structure various files. We explain here in more details how web assets are supposed to be organized."
msgid "The first thing to know is that the Odoo server will serve (statically) all files located in a *static/* folder, but prefixed with the addon name. So, for example, if a file is located in *addons/web/static/src/js/some_file.js*, then it will be statically available at the url *your-odoo-server.com/web/static/src/js/some_file.js*"
msgid "*static/lib*: this is the place where js libs should be located, in a sub folder. So, for example, all files from the *jquery* library are in *addons/web/static/lib/jquery*"
msgid "More precise JS guidelines are detailed in the `github wiki <https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines>`_. You may also have a look at existing API in Javascript by looking Javascript References."
msgid "Prefix all your classes with *o_<module_name>* where *module_name* is the technical name of the module ('sale', 'im_chat', ...) or the main route reserved by the module (for website module mainly, i.e. : 'o_forum' for *website_forum* module). The only exception for this rule is the webclient: it simply uses *o_* prefix."
msgid "Commit message has four parts: tag, module, short description and full description. Try to follow the preferred structure for your commit messages"
msgid "**[MOV]** for moving files: use git move and do not change content of moved file otherwise Git may loose track and history of the file; also used when moving code from one file to another;"
msgid "After tag comes the modified module name. Use the technical name as functional name may change with time. If several modules are modified, list them or use various to tell it is cross-modules. Unless really required or easier avoid modifying code across several modules in the same commit. Understanding module history may become difficult."
msgid "After tag and module name comes a meaningful commit message header. It should be self explanatory and include the reason behind the change. Do not use single words like \"bugfix\" or \"improvements\". Try to limit the header length to about 50 characters for readability."
msgid "Commit message header should make a valid sentence once concatenated with ``if applied, this commit will <header>``. For example ``[IMP] base: prevent to archive users linked to active partners`` is correct as it makes a valid sentence ``if applied, this commit will prevent users to archive...``."
msgid "In the message description specify the part of the code impacted by your changes (module name, lib, transversal object, ...) and a description of the changes."
msgid "First explain WHY you are modifying code. What is important if someone goes back to your commit in about 4 decades (or 3 days) is why you did it. It is the purpose of the change."
msgid "What you did can be found in the commit itself. If there was some technical choices involved it is a good idea to explain it also in the commit message after the why. For Odoo R&D developers \"PO team asked me to do it\" is not a valid why, by the way."
msgid "Please avoid commits which simultaneously impact multiple modules. Try to split into different commits where impacted modules are different. It will be helpful if we need to revert changes in a given module separately."
msgid "Don't hesitate to be a bit verbose. Most people will only see your commit message and judge everything you did in your life just based on those few sentences. No pressure at all."
msgid "**You spend several hours, days or weeks working on meaningful features. Take some time to calm down and write clear and understandable commit messages.**"
msgid "If you are an Odoo R&D developer the WHY should be the purpose of the task you are working on. Full specifications make the core of the commit message. **If you are working on a task that lacks purpose and specifications please consider making them clear before continuing.**"
msgid "IoT Drivers allow any Odoo module to communicate in real-time with any device connected to the IoT Box. Communication with the IoT Box goes both ways, so the Odoo client can send commands to and receive information from any of the supported devices."
msgid "At each boot, the IoT Box will load all of the Interfaces and Drivers that can be located on the connected Odoo instance. Each module can contain an `iot_handlers` directory that will be copied to the IoT Box. The structure of this directory is the following"
msgid "Devices connected to the IoT Box are detected through `Interfaces`. There is an Interface for each supported connection type (USB, Bluetooth, Video, Printers, Serial, etc.). The interface maintains a list of detected devices and associates them with the right Driver."
msgid "Supported devices will appear both on the IoT Box Homepage that you can access through its IP address and in the IoT module of the connected Odoo instance."
msgid "Implementing the `get_devices` method, that should return a dictionary containing data about each detected device. This data will be given as argument to the constructors and `supported` method of the Drivers."
msgid "Once the interface has retrieved the list of detected devices, it will loop through all of the Drivers that have the same `connection_type` attribute and test their respective `supported` method on all detected devices. If the supported method of a Driver returns `True`, an instance of this Driver will be created for the corresponding device."
msgid "`supported` methods of drivers are given a priority order. The `supported` method of a child class will always be tested before the one of its parent. This priority can be adjusted by modifying the `priority` attribute of the Driver."
msgid "Once your new device is detected and appears in the IoT module, the next step is to communicate with it. Since the box only has a local IP address, it can only be reached from the same local network. Communication, therefore, needs to happen on the browser-side, in JavaScript."
msgid "The process depends on the direction of the communication: - From the browser to the box, through `Actions`_ - From the box to the browser, through `Longpolling`_"
msgid "Both channels are accessed from the same JS object, the `DeviceProxy`, which is instantiated using the IP of the IoT Box and the device identifier."
msgid "It must be noted that no “answer” will be sent by the box on this route, only the request status. The answer to the action, if any, has to be retrieved via the longpolling."
msgid "In your driver, define an `action` method that will be executed when called from an Odoo module. It takes the data given during the call as argument."
msgid "When any module in Odoo wants to read data from a specific device, it creates a listener identified by the IP/domain of the box and the device identifier and passes it a callback function to be called every time the device status changes. The callback is called with the new data as argument."
msgid "In the Driver, an event is released by calling the `device_changed` function from the `event_manager`. All callbacks set on the listener will then be called with `self.data` as argument."
msgid "Aside from their two mandatory attributes, all actions also share *optional* attributes used to present an action in an arbitrary model's contextual menu:"
msgid "a comma-separated list of view types for which the action appears in the contextual menu, mostly \"list\" and / or \"form\". Defaults to ``list,form`` (both list and form )"
msgid "The most common action type, used to present visualisations of a model through :ref:`views <reference/views>`: a window action defines a set of view types (and possibly specific views) for a model (and possibly specific record of the model)."
msgid "a list of ``(view_id, view_type)`` pairs. The second element of each pair is the category of the view (tree, form, graph, ...) and the first is 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:`~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"
msgid "``(id, name)`` pair, ``id`` is the database identifier of a specific search view to load for the action. Defaults to fetching the default search view for the model"
msgid "whether the views should be open in the main content area (``current``), in full screen mode (``fullscreen``) or in a dialog/popup (``new``). Use ``main`` instead of ``current`` to clear the breadcrumbs. Defaults to ``current``."
msgid "comma-separated list of view types as a string (/!\\\\ No spaces /!\\\\). All of these types will be present in the generated ``views`` list (with at least a ``False`` view_id)"
msgid "specific view added to the ``views`` list in case its type is part of the ``view_mode`` list and not already filled by one of the views in ``view_ids``"
#: ../../../odoo/odoo/addons/base/models/ir_actions.py:docstring of odoo.addons.base.models.ir_actions.IrActionsServer:1
msgid "Server actions model. Server action work on a base model and offer various type of actions that can be executed automatically, for example using base action rules, of manually, by adding the action in the 'More' contextual menu."
#: ../../../odoo/odoo/addons/base/models/ir_actions.py:docstring of odoo.addons.base.models.ir_actions.IrActionsServer:6
msgid "Since Odoo 8.0 a button 'Create Menu Action' button is available on the action form view. It creates an entry in the More menu of the base model. This allows to create server actions and run them in mass mode easily through the interface."
msgid "In-database records are significantly richer and can perform a number of specific or generic actions based on their ``state``. Some fields (and corresponding behaviors) are shared between states:"
msgid "many2one to ``ir.model.fields``, specifies the current record's m2o field on which the newly created record should be set (models should match)"
msgid "If ``value``, the ``value`` field is interpreted as a literal value (possibly converted), if ``equation`` the ``value`` field is interpreted as a Python expression and evaluated"
msgid "Specify the multiple sub-actions (``ir.actions.server``) to enact in state multi. If sub-actions themselves return actions, the last one will be returned to the client as the multi's own next action"
msgid "If you define your report through a `<record>` instead of a `<report>` tag and want the action to show up in the Print menu of the model's views, you will also need to specify ``binding_model_id`` from :ref:`reference/bindings`. It's not necessary to set ``binding_type`` to ``report``, since ``ir.actions.report`` will implicitly default to that."
msgid "used as the file name if ``print_report_name`` is not specified. Otherwise, only useful as a mnemonic/description of the report when looking for one in a list of some sort"
msgid "if set to ``True``, the report is only generated once the first time it is requested, and re-printed from the stored report afterwards instead of being re-generated every time."
msgid "whether the client action should be open in the main content area (``current``), in full screen mode (``fullscreen``) or in a dialog/popup (``new``). Use ``main`` instead of ``current`` to clear the breadcrumbs. Defaults to ``current``."
msgid "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), security (access rights and record rules), reports and plain data are all defined via records."
msgid "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."
msgid "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)."
msgid "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."
msgid "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`"
msgid "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."
msgid "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."
msgid "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"
msgid "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."
msgid "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``)"
msgid "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."
msgid "Parameters can be provided using ``eval`` (should evaluate to a sequence of parameters to call the method with) or ``value`` elements (see ``list`` values)."
msgid "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>`:"
msgid "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"
msgid "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"
msgid "``enabled`` or ``disabled``, whether the view can be disabled (in the website interface) and its default status. If unset, the view is always enabled."
msgid "Controllers need to provide extensibility, much like :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)."
msgid "Controllers are created by :ref:`inheriting <python:tut-inheritance>` from :class:`~odoo.http.Controller`. Routes are defined through methods decorated with :func:`~odoo.http.route`::"
msgid "To *override* a controller, :ref:`inherit <python:tut-inheritance>` from its class and override relevant methods, re-exposing them if necessary::"
msgid "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\""
msgid "the decorators of all methods are combined, if the overriding method's decorator has no argument all previous ones will be kept, any provided argument will override previously defined ones e.g.::"
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:4
msgid "string or array. The route part that will determine which http requests will match the decorated method. Can be a single string or an array of strings. See werkzeug's routing documentation for the format of route expression ( http://werkzeug.pocoo.org/docs/routing/ )."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:10
msgid "The type of authentication method, can on of the following: * ``user``: The user must be authenticated and the current request will perform using the rights of the user. * ``public``: The user may or may not be authenticated. If she isn't, the current request will perform using the shared Public user. * ``none``: The method is always active, even if there is no database. Mainly used by the framework and authentication modules. There request code will not have any facilities to access the database nor have any configuration indicating the current database nor the current user."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:16
msgid "``none``: The method is always active, even if there is no database. Mainly used by the framework and authentication modules. There request code will not have any facilities to access the database nor have any configuration indicating the current database nor the current user."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:39
msgid "CSRF protection is enabled by default and applies to *UNSAFE* HTTP methods as defined by :rfc:`7231` (all methods other than ``GET``, ``HEAD``, ``TRACE`` and ``OPTIONS``)."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:43
msgid "CSRF protection is implemented by checking requests using unsafe methods for a value called ``csrf_token`` as part of the request's form data. That value is removed from the form as part of the validation and does not have to be taken in account by your own form processing."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:52
msgid "if the form is generated in Python, a csrf token is available via :meth:`request.csrf_token() <odoo.http.WebRequest.csrf_token`, the :data:`~odoo.http.request` object is available by default in QWeb (python) templates, it may have to be added explicitly if you are not using QWeb."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:59
msgid "if the form is generated in Javascript, the CSRF token is added by default to the QWeb (js) rendering context as ``csrf_token`` and is otherwise available as ``csrf_token`` on the ``web.core`` module:"
#: ../../../odoo/odoo/http.py:docstring of odoo.http.route:68
msgid "if the endpoint can be called by external parties (not from Odoo) as e.g. it is a REST API or a `webhook <https://en.wikipedia.org/wiki/Webhook>`_, CSRF protection must be disabled on the endpoint. If possible, you may want to implement other methods of request validation (to ensure it is not called by an unrelated third-party)."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.WebRequest:1
msgid "Parent class for all Odoo Web request types, mostly deals with initialization and setup of the request object (the dispatching itself has to be handled by the subclasses)"
#: ../../../odoo/odoo/http.py:docstring of odoo.http.WebRequest:15
msgid ":class:`~collections.Mapping` of request parameters, not generally useful as they're provided directly to the handler method as keyword arguments"
#: ../../../odoo/odoo/http.py:docstring of odoo.http.HttpRequest.make_response:4
msgid "While handlers can just return the HTML markup of a page they want to send as a string if non-HTML data is returned they need to create a complete response object, or the returned data will not be correctly interpreted by the clients."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.HttpRequest.render:3
msgid "The actual rendering of the given template will occur at then end of the dispatching. Meanwhile, the template and/or qcontext can be altered or even replaced by a static response."
#: ../../../odoo/odoo/http.py:docstring of odoo.http.JsonRequest:7
msgid "the handler method's result is returned as JSON-RPC ``result`` and wrapped in the `JSON-RPC Response <http://www.jsonrpc.org/specification#response_object>`_"
#: ../../../odoo/odoo/http.py:docstring of odoo.http.Response:3
msgid "In addition to the :class:`werkzeug.wrappers.Response` parameters, this class's constructor can take the following additional parameters for QWeb Lazy Rendering."
msgid "Odoo implements some useful classes and mixins that make it easy for you to add often-used behaviours on your objects. This guide will details most of them, with examples and use cases."
msgid "Integrating messaging features to your model is extremely easy. Simply inheriting the ``mail.thread`` model and adding the messaging fields (and their appropriate widgets) to your form view will get you up and running in no time."
msgid "Let's create a simplistic model representing a business trip. Since organizing this kind of trip usually involves a lot of people and a lot of discussion, let's add support for message exchange on the model."
msgid "Once you've added chatter support on your model, users can easily add messages or internal notes on any record of your model; every one of those will send a notification (to all followers for messages, to employee (*base.group_user*) users for internal notes). If your mail gateway and catchall address are correctly configured, these notifications will be sent by e-mail and can be replied-to directly from your mail client; the automatic routing system will route the answer to the correct thread."
msgid "Helper method to send a mail / post a message using a view_id to render using the ir.qweb engine. This method is stand alone, because there is nothing in template and composer that allows to handle views in batch. This method will probably disappear when templates handle ir ui views."
msgid "These methods are called when a new e-mail is processed by the mail gateway. These e-mails can either be new thread (if they arrive via an :ref:`alias <reference/mixins/mail/alias>`) or simply replies from an existing thread. Overriding them allows you to set values on the thread's record depending on some values from the email itself (i.e. update a date or an e-mail address, add CC's addresses as followers, etc.)."
msgid "The default behavior is to create a new record of the corresponding model (based on some very basic info extracted from the message). Additional behavior may be implemented by overriding this method."
msgid "optional dictionary of additional field values to pass to create() when creating the new thread record; be careful, these values may override any other values coming from the message"
msgid "Called by ``message_process`` when a new message is received for an existing thread. The default behavior is to update the record with ``update_vals`` taken from the incoming email."
msgid "The ``mail`` module adds a powerful tracking system on fields, allowing you to log changes to specific fields in the record's chatter. To add tracking to a field, simple set the tracking attribute to True."
msgid "From now on, every change to a trip's name or responsible will log a note on the record. The ``name`` field will be displayed in the notification as well to give more context about the notification (even if the name did not change)."
msgid "Subtypes give you more granular control over messages. Subtypes act as a classification system for notifications, allowing subscribers to a document to customize the subtype of notifications they wish to receive."
msgid "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"
msgid "Interfacing subtypes with field tracking allows to subscribe to different kind of notifications depending on what might interest users. To do this, you can override the ``_track_subtype()`` function:"
msgid "Then, we need to override the ``track_subtype()`` function. This function is called by the tracking system to know which subtype should be used depending on the change currently being applied. In our case, we want to use our shiny new subtype when the ``state`` field changes from *draft* to *confirmed*:"
msgid "When sending notifications to followers, it can be quite useful to add buttons in the template to allow quick actions directly from the e-mail. Even a simple button to link directly to the record's form view can be useful; however in most cases you don't want to display these buttons to portal users."
msgid "Display *Access Buttons*: these buttons are visible at the top of the notification e-mail and allow the recipient to directly access the form view of the record"
msgid "Display *Custom Action Buttons*: these buttons are calls to specific routes and allow you to make some useful actions directly available from the e-mail (i.e. converting a lead to an opportunity, validating an expense sheet for an Expense Manager, etc.)"
msgid "list of tuple of the form (group_name, group_func,group_data) where: group_name is an identifier used only to be able to override and manipulate groups. Default groups are ``user`` (recipients linked to an employee user), ``portal`` (recipients linked to a portal user) and ``customer`` (recipients not linked to any user). An example of override use would be to add a group linked to a res.groups like Hr Officers to set specific action buttons to them. group_func is a function pointer taking a partner record as parameter. This method will be applied on recipients to know whether they belong to a given group or not. Only first matching group is kept. Evaluation order is the list order. group_data is a dict containing parameters for the notification email with the following possible keys - values: - has_button_access whether to display Access <Document> in email. True by default for new groups, False for portal / customer. - button_access dict with url and title of the button - has_button_follow whether to display Follow in email (if recipient is not currently following the thread). True by default for new groups, False for portal / customer. - button_follow dict with url and title of the button - has_button_unfollow whether to display Unfollow in email (if recipient is currently following the thread). True by default for new groups, False for portal / customer. - button_unfollow dict with url and title of the button - actions list of action buttons to display in the notification email. Each action is a dict containing url and title of the button."
msgid "is an identifier used only to be able to override and manipulate groups. Default groups are ``user`` (recipients linked to an employee user), ``portal`` (recipients linked to a portal user) and ``customer`` (recipients not linked to any user). An example of override use would be to add a group linked to a res.groups like Hr Officers to set specific action buttons to them."
msgid "is a function pointer taking a partner record as parameter. This method will be applied on recipients to know whether they belong to a given group or not. Only first matching group is kept. Evaluation order is the list order."
msgid "whether to display Follow in email (if recipient is not currently following the thread). True by default for new groups, False for portal / customer."
msgid "whether to display Unfollow in email (if recipient is currently following the thread). True by default for new groups, False for portal / customer."
msgid "link type to be generated; can be any of these values: ``view`` link to form view of the record ``assign`` assign the logged user to the ``user_id`` field of the record (if it exists) ``follow`` self-explanatory ``unfollow`` self-explanatory ``method`` call a method on the record; the method's name should be provided as the kwarg ``method`` ``new`` open an empty form view for a new record; you can specify a specific action by providing its id (database id or fully resolved external id) in the kwarg ``action_id``"
msgid "open an empty form view for a new record; you can specify a specific action by providing its id (database id or fully resolved external id) in the kwarg ``action_id``"
msgid "Let's add a custom button to the Business Trip state change notification; this button will reset the state to Draft and will be only visible to a member of the (imaginary) group Travel Manager (``business.group_trip_manager``)"
msgid "Note that that I could have defined my evaluation function outside of this method and define a global function to do it instead of a lambda, but for the sake of being more brief and less verbose in these documentation files that can sometimes be boring, I choose the former instead of the latter."
msgid "These context keys can be used to somewhat control ``mail.thread`` features like auto-subscription or field tracking during calls to ``create()`` or ``write()`` (or any other method where it may be useful)."
msgid "Aliases are configurable email addresses that are linked to a specific record (which usually inherits the ``mail.alias.mixin`` model) that will create new records when contacted via e-mail. They are an easy way to make your system accessible from the outside, allowing users or customers to quickly create records in your database without needing to connect to Odoo directly."
msgid "Some people use the Incoming Mail Gateway for this same purpose. You still need a correctly configured mail gateway to use aliases, however a single catchall domain will be sufficient since all routing will be done inside Odoo. Aliases have several advantages over Mail Gateways:"
msgid "A single incoming gateway can be used by many aliases; this avoids having to configure multiple emails on your domain name (all configuration is done inside Odoo)"
msgid "Mixin model is built to be extended from the start, allowing you to extract useful data from incoming e-mails more easily than with a mail gateway."
msgid "Aliases are usually configured on a parent model which will then create specific record when contacted by e-mail. For example, Project have aliases to create tasks or issues, Sales Team have aliases to generate Leads."
msgid "Alias support is added by inheriting ``mail.alias.mixin``; this mixin will generate a new ``mail.alias`` record for each record of the parent class that gets created (for example, every ``project.project`` record having its ``mail.alias`` record initialized on creation)."
msgid "Aliases can also be created manually and supported by a simple :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."
msgid "Unlike ``mail.thread`` inheritance, the ``mail.alias.mixin`` **requires** some specific overrides to work correctly. These overrides will specify the values of the created alias, like the kind of record it must create and possibly some default values these records may have depending on the parent object:"
msgid "Return the model name for the alias. Incoming emails that are not replies to existing records will cause the creation of a new record of this alias model. The value may depend on ``vals``, the dict of values passed to ``create`` when a record of this model is created."
msgid "Return values to create an alias, or to write on the alias after its creation. While not completely mandatory, it is usually required to make sure that newly created records will be linked to the alias' parent (i.e. tasks getting created in the right project) by setting a dictionary of default values in the alias' ``alias_defaults`` field."
msgid "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:"
msgid "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"
msgid "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"
msgid "Note that aliases make use of :ref:`delegation inheritance <reference/orm/inheritance>`, which means that while the alias is stored in another table, you have access to all these fields directly from your parent object. This allows you to make your alias easily configurable from the record's form view."
msgid "Activities are actions users have to take on a document like making a phone call or organizing a meeting. Activities come with the mail module as they are integrated in the Chatter but are *not bundled with mail.thread*. Activities are records of the ``mail.activity`` class, which have a type (``mail.activity.type``), name, description, scheduled time (among others). Pending activities are visible above the message history in the chatter widget."
msgid "You can integrate activities using the ``mail.activity.mixin`` class on your object and the specific widgets to display them (via the field ``activity_ids``) in the form view and kanban view of your records (``mail_activity`` and ``kanban_activity`` widgets, respectively)."
msgid "Organizing a business trip is a tedious process and tracking needed activities like ordering plane tickets or a cab for the airport could be useful. To do so, we will add the activities mixin on our model and display the next planned activities in the message history of our trip."
msgid "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:"
msgid "Once a customer visits your website with these parameters set in the url (i.e. https://www.odoo.com/?campaign_id=mixin_talk&source_id=www.odoo.com&medium_id=website), three cookies are set in the visitor's website for these parameters. Once a object that inherits the utm.mixin is created from the website (i.e. lead form, job application, etc.), the utm.mixin code kicks in and fetches the values from the cookies to set them in the new record. Once this is done, you can then use the campaign/source/medium fields as any other field when defining reports and views (group by, etc.)."
msgid "To extend this behaviour, simply add a relational field to a simple model (the model should support the *quick create* (i.e. call to ``create()`` with a single ``name`` value) and extend the function ``tracking_fields()``:"
msgid "This will tell the system to create a cookie named *odoo_utm_my_field* with the value found in the url parameter ``my_field``; once a new record of this model is created by a call from a website form, the generic override of the ``create()`` method of ``utm.mixin`` will fetch the default values for this field from the cookie (and the ``my_module.my_track`` record will be creatwed on the fly if it does not exist yet)."
msgid "You can quite easily add a website visibility toggle on any of your record. While this mixin is quite easy to implement manually, it is the most often-used after the ``mail.thread`` inheritance; a testament to its usefulness. The typical use case for this mixin is any object that has a frontend-page; being able to control the visibility of the page allows you to take your time while editing the page and only publish it when you're satisfied."
msgid "Once the mechanism is in place, you just have to adapt your frontend and backend views to make it accessible. In the backend, adding a button in the button box is usually the way to go:"
msgid "Note that you must pass your object as the variable ``object`` to the template; in this example, the ``blog.post`` record was passed as the ``blog_post`` variable to the ``qweb`` rendering engine, it is necessary to specify this to the publish management template. The ``publish_edit`` variable allow the frontend button to link to the backend (allowing you to switch from frontend to backend and vice-versa easily); if set, you must specify the full external id of the action you want to call in the backend in the ``action`` variable (note that a Form View must exist for the model)."
msgid "The action ``website_publish_button`` is defined in the mixin and adapts its behaviour to your object: if the class has a valid ``website_url`` compute function, the user is redirected to the frontend when he clicks on the button; the user can then publish the page directly from the frontend. This ensures that no online publication can happen by accident. If there is not compute function, the boolean ``website_published`` is simply triggered."
msgid "``website_meta_description``: :class:`~odoo.fields.Char` field that contains a short description of the page (sometimes used in search engines results)"
msgid "``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"
msgid "These fields are editable in the frontend using the \"Promote\" tool from the Editor toolbar. Setting these fields can help search engines to better index your pages. Note that search engines do not base their results only on these metadata; the best SEO practice should still be to get referenced by reliable sources."
msgid "The rating mixin allows sending email to ask for customer rating, automatic transitioning in a kanban processes and aggregating statistics on your ratings."
msgid "The ``rating.rating`` record will be linked to the partner of the ``user_id`` field of your model (if the field is present) (i.e. the partner who is rated)"
msgid "this behaviour can be overridden with the function ``rating_get_rated_partner_id()`` if you use another field than ``user_id`` (note that the function must return a ``res.partner``, for ``user_id`` the system automatically fetches the partner of the user)"
msgid "If you wish to send emails to request a rating, simply generate an e-mail with links to the rating object. A very basic email template could look like this:"
msgid "Your customer will then receive an e-mail with links to a simple webpage allowing them to provide a feedback on their interaction with your users (including a free-text feedback message)."
msgid "Although using `existing categories`_ is recommended, the field is freeform and unknown categories are created on-the-fly. Category hierarchies can be created using the separator ``/`` e.g. ``Foo / Bar`` will create a category ``Foo``, a category ``Bar`` as child category of ``Foo``, and will set ``Bar`` as the module's category."
msgid "Odoo modules which must be loaded before this one, either because this module uses features they create or because it alters resources they define."
msgid "Module `base` is always installed in any Odoo instance. But you still need to specify it as dependency to make sure your module is updated when `base` is updated."
msgid "For instance ``sale_crm`` depends on both ``sale`` and ``crm`` and is set to ``auto_install``. When both ``sale`` and ``crm`` are installed, it automatically adds CRM campaigns tracking to sale orders without either ``sale`` or ``crm`` being aware of one another."
msgid "If it is a list, it must contain a subset of the dependencies. This module will automatically be installed as soon as all the dependencies in the subset are installed. The remaining dependencies will be automatically installed as well. If the list is empty, this module will always be automatically installed regardless of its dependencies and these will be installed as well."
msgid "For python dependencies, the ``python`` key must be defined for this dictionary and a list of python modules to be imported should be assigned to it."
msgid "The module won't be installed if either the python module is not installed in the host machine or the binary executable is not found within the host machine's PATH environment variable."
msgid "Whether the module should be considered as a fully-fledged application (``True``) or is just a technical module (``False``) that provides some extra functionality to an existing application module."
msgid "Hooks for module installation/uninstallation, their value should be a string representing the name of a function defined inside the module's ``__init__.py``."
msgid "By default, the field's label (user-visible name) is a capitalized version of the field name, this can be overridden with the ``string`` parameter. ::"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel:13
msgid "The system automatically instantiates every model once per database. Those instances represent the available models on each database, and depend on which modules are installed on that database. The actual class of each instance is built from the Python classes that create and inherit from the corresponding model."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel:19
msgid "Every model instance is a \"recordset\", i.e., an ordered collection of records of the model. Recordsets are returned by methods like :meth:`~.browse`, :meth:`~.search`, or field accesses. Records have no explicit representation: a record is represented as a recordset of one record."
#: ../../docstring of odoo.models.BaseModel._inherits:1
msgid "dictionary {'parent_model': 'm2o_field'} mapping the _name of the parent business objects to the names of the corresponding foreign key fields to use::"
#: ../../docstring of odoo.models.BaseModel._inherits:9
msgid "implements composition-based inheritance: the new model exposes all the fields of the inherited models but stores none of them: the values themselves remain stored on the linked record."
#: ../../docstring of odoo.models.BaseModel._inherits:15
msgid "if multiple fields with the same name are defined in the :attr:`~odoo.models.Model._inherits`-ed models, the inherited field will correspond to the last one (in the inherits list order)."
#: ../../docstring of odoo.models.BaseModel._check_company_auto:1
msgid "On write and create, call ``_check_company`` to ensure companies consistency on the relational fields having ``check_company=True`` as attribute."
#: ../../docstring of odoo.models.BaseModel._parent_store:3
msgid "Alongside a :attr:`~.parent_path` field, sets up an indexed storage of the tree structure of records, to enable faster hierarchical queries on the records of the current model using the ``child_of`` and ``parent_of`` domain operators."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.TransientModel:4
msgid "A TransientModel has a simplified access rights management, all users can create new records, and may only access the records they created. The superuser has unrestricted access to all TransientModel records."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:1
msgid "The field descriptor contains the field definition, and manages accesses and assignments of the corresponding field on records. The following attributes may be provided when instanciating a field:"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:12
msgid "whether the field is readonly (default: ``False``) This only has an impact on the UI. Any field assignation in code will work (if the field is a stored field or an inversable one)."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:22
msgid "the default value for the field; this is either a static value, or a function taking a recordset and returning a value; use ``default=None`` to discard default values for the field"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:27
msgid "a dictionary mapping state values to lists of UI attribute-value pairs; possible attributes are: ``readonly``, ``required``, ``invisible``. .. warning:: Any state-based condition requires the ``state`` field value to be available on the client-side UI. This is typically done by including it in the relevant views, possibly made invisible if not relevant for the end-user."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:30
msgid "Any state-based condition requires the ``state`` field value to be available on the client-side UI. This is typically done by including it in the relevant views, possibly made invisible if not relevant for the end-user."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:38
msgid "whether the field value is dependent of the current company; The value isn't stored on the model table. It is registered as `ir.property`. When the value of the company_dependent field is needed, an `ir.property` is searched, linked to the current company (and current record if one property exists). If the value is changed on the record, it either modifies the existing property for the current record (if one exists), or creates a new one for the current company and res_id. If the value is changed on the company side, it will impact all records on which the value hasn't been changed."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:40
msgid "The value isn't stored on the model table. It is registered as `ir.property`. When the value of the company_dependent field is needed, an `ir.property` is searched, linked to the current company (and current record if one property exists)."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:45
msgid "If the value is changed on the record, it either modifies the existing property for the current record (if one exists), or creates a new one for the current company and res_id."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:52
msgid "whether the field value should be copied when the record is duplicated (default: ``True`` for normal fields, ``False`` for ``one2many`` and computed fields, including property fields and related fields)"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:60
msgid "aggregate function used by :meth:`~odoo.models.Model.read_group` when grouping on this field. Supported aggregate functions are: * ``array_agg`` : values, including nulls, concatenated into an array * ``count`` : number of rows * ``count_distinct`` : number of distinct rows * ``bool_and`` : true if all values are true, otherwise false * ``bool_or`` : true if at least one value is true, otherwise false * ``max`` : maximum value of all values * ``min`` : minimum value of all values * ``avg`` : the average (arithmetic mean) of all values * ``sum`` : sum of all values"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:75
msgid "function used to expand read_group results when grouping on the current field. .. code-block:: python @api.model def _read_group_selection_field(self, values, domain, order): return ['choice1', 'choice2', ...] # available selection choices. @api.model def _read_group_many2one_field(self, records, domain, order): return records + self.search([custom_domain])"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Field:94
msgid "whether the field should be recomputed as superuser to bypass access rights (by default ``True`` for stored fields, ``False`` for non stored fields)"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Char:9
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Text:4
msgid "enable the translation of the field's values; use ``translate=True`` to translate field values as a whole; ``translate`` may also be a callable such that ``translate(callback, value)`` translates ``value`` by using ``callback(term)`` to retrieve the translation of terms."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Float:9
msgid "When a float is a quantity associated with an unit of measure, it is important to use the right tool to compare or round values with the correct precision."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Float:14
msgid ":func:`~odoo.fields.Float.round()` to round a float with the given precision. :func:`~odoo.fields.Float.is_zero()` to check if a float equals zero at the given precision. :func:`~odoo.fields.Float.compare()` to compare two floats at the given precision."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Float:35
msgid "if result == 0, the first and second floats are equal if result < 0, the first float is lower than the second if result > 0, the first float is greater than the second"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Image:3
msgid "If image size is greater than the ``max_width``/``max_height`` limit of pixels, the image will be resized to the limit by keeping aspect ratio."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Image:8
msgid "whether the image resolution should be verified to ensure it doesn't go over the maximum image resolution (default: ``True``). See :class:`odoo.tools.image.ImageProcess` for maximum image resolution (default: ``45e6``)."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Image:14
msgid "If no ``max_width``/``max_height`` is specified (or is set to 0) and ``verify_resolution`` is False, the field content won't be verified at all and a :class:`Binary` field should be used."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Monetary:6
msgid "name of the :class:`Many2one` field holding the :class:`res_currency <odoo.addons.base.models.res_currency.Currency>` this monetary field is expressed in (default: `'currency_id'`)"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Selection:8
msgid "provides an extension of the selection in the case of an overridden field. It is a list of pairs ``(value, label)`` or singletons ``(value,)``, where singleton values must appear in the overridden selection. The new values are inserted in an order that is consistent with the overridden selection and this list:: selection = [('a', 'A'), ('b', 'B')] selection_add = [('c', 'C'), ('b',)] > result = [('a', 'A'), ('c', 'C'), ('b', 'B')]"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Selection:8
msgid "provides an extension of the selection in the case of an overridden field. It is a list of pairs ``(value, label)`` or singletons ``(value,)``, where singleton values must appear in the overridden selection. The new values are inserted in an order that is consistent with the overridden selection and this list::"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Selection:19
msgid "provides a fallback mechanism for any overridden field with a selection_add. It is a dict that maps every option from the selection_add to a fallback action. This fallback action will be applied to all records whose selection_add option maps to it. The actions can be any of the following: - 'set null' -- the default, all records with this option will have their selection value set to False. - 'cascade' -- all records with this option will be deleted along with the option itself. - 'set default' -- all records with this option will be set to the default of the field definition - <callable> -- a callable whose first and only argument will be the set of records containing the specified Selection option, for custom processing"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Selection:19
msgid "provides a fallback mechanism for any overridden field with a selection_add. It is a dict that maps every option from the selection_add to a fallback action."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Selection:33
msgid "<callable> -- a callable whose first and only argument will be the set of records containing the specified Selection option, for custom processing"
msgid ":class:`Dates <odoo.fields.Date>` and :class:`Datetimes <odoo.fields.Datetime>` are very important fields in any kind of business application. Their misuse can create invisible yet painful bugs, this section aims to provide Odoo developers with the knowledge required to avoid misusing these fields."
msgid "Strings representing dates and datetimes can be compared between each other, however the result may not be the expected result, as a datetime string will always be greater than a date string, therefore this practice is **heavily** discouraged."
msgid "Common operations with dates and datetimes such as addition, subtraction or fetching the start/end of a period are exposed through both :class:`~odoo.fields.Date` and :class:`~odoo.fields.Datetime`. These helpers are also available by importing `odoo.tools.date_utils`."
msgid "Datetime fields are stored as `timestamp without timezone` columns in the database and are stored in the UTC timezone. This is by design, as it makes the Odoo database independent from the timezone of the hosting server system. Timezone conversion is managed entirely by the client side."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Date.to_date:5
msgid "If a datetime object is given as value, it will be converted to a date object and all datetime-specific information will be lost (HMS, TZ, ...)."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Date.to_string:4
msgid "a string representing ``value`` in the server's date format, if ``value`` is of type :class:`datetime`, the hours, minute, seconds, tzinfo will be truncated."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Datetime.context_timestamp:3
msgid "This method is *not* meant for use as a default initializer, because datetime fields are automatically converted upon display on client side. For default values, :meth:`now` should be used instead."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Datetime.to_string:5
msgid "a string representing ``value`` in the server's datetime format, if ``value`` is of type :class:`date`, the time portion will be midnight (00:00:00)."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.One2many:1
msgid "One2many field; the value of such a field is the recordset of all the records in ``comodel_name`` such that the field ``inverse_name`` is equal to the current record."
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Many2many:15
msgid "The attributes ``relation``, ``column1`` and ``column2`` are optional. If not given, names are automatically generated from model names, provided ``model_name`` and ``comodel_name`` are different!"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Many2many:19
msgid "Note that having several fields with implicit relation parameters on a given model with the same comodel is not accepted by the ORM, since those field would use the same table. The ORM prevents two many2many fields to use the same relation parameters, except if"
#: ../../../odoo/odoo/fields.py:docstring of odoo.fields.Many2oneReference:5
msgid "Contrary to :class:`Reference` fields, the model has to be specified in a :class:`Char` field, whose name has to be specified in the `model_field` attribute for the current :class:`Many2oneReference` field."
msgid "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:`~odoo.api.depends`. ::"
msgid "computed fields are not stored by default, they are computed and returned when requested. Setting ``store=True`` will store them in the database and automatically enable searching."
msgid "searching on a computed field can also be enabled by setting the ``search`` parameter. The value is a method name returning a :ref:`reference/orm/domains`. ::"
msgid "The search method is invoked when processing domains before doing an actual search on the model. It must return a domain equivalent to the condition: ``field operator value``."
msgid "Computed fields are readonly by default. To allow *setting* values on a computed field, use the ``inverse`` parameter. It is the name of a function reversing the computation and setting the relevant fields::"
msgid "During the computation of the inverse, **all** fields that use said inverse are protected, meaning that they can't be computed, even if their value is not in the cache."
msgid "If any of those fields is accessed and its value is not in cache, the ORM will simply return a default value of `False` for these fields. This means that the value of the inverse fields (other than the one triggering the inverse method) may not give their correct value and this will probably break the expected behavior of the inverse method."
msgid "A special case of computed fields are *related* (proxy) fields, which provide the value of a sub-field on the current record. They are defined by setting the ``related`` parameter and like regular computed fields they can be stored::"
msgid "The value of a related field is given by following a sequence of relational fields and reading a field on the reached model. The complete sequence of fields to traverse is specified by the ``related`` attribute."
msgid "Some field attributes are automatically copied from the source field if they are not redefined: ``string``, ``help``, ``required`` (only if all fields in the sequence are required), ``groups``, ``digits``, ``size``, ``translate``, ``sanitize``, ``selection``, ``comodel_name``, ``domain``, ``context``. All semantic-free attributes are copied from the source field."
msgid "Add the attribute ``store=True`` to make it stored, just like computed fields. Related fields are automatically recomputed when their dependencies are modified."
msgid "``related`` can be used to refer to a :class:`~odoo.fields.One2many` or :class:`~odoo.fields.Many2many` field on another model on the condition that it's done through a ``Many2one`` relation on the current model. ``One2many`` and ``Many2many`` are not supported and the results will not be aggregated correctly::"
msgid "These fields are automatically set and updated if :attr:`~odoo.models.BaseModel._log_access` is enabled. It can be disabled to avoid creating or updating those fields on tables for which they are not useful."
msgid "A few field names are reserved for pre-defined behaviors beyond that of automated fields. They should be defined on a model when the related behavior is desired:"
msgid "default_value of :attr:`~._parent_name`, used to organize records in a tree structure and enables the ``child_of`` and ``parent_of`` operators in domains."
msgid "When :attr:`~._parent_store` is set to True, used to store a value reflecting the tree structure of :attr:`~._parent_name`, and to optimize the operators ``child_of`` and ``parent_of`` in search domains. It must be declared with ``index=True`` for proper operation."
msgid "Used by `:meth:~odoo.models._check_company` to check multi company consistency. Defines whether a record is shared between companies (no value) or only accessible by the users of a given company."
msgid "Iterating on a recordset will yield new sets of *a single record* (\"singletons\"), much like iterating on a Python string yields strings of a single characters::"
msgid "Field values can also be accessed like dict items, which is more elegant and safer than ``getattr()`` for dynamic field names. Setting a field's value triggers an update to the database::"
msgid "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."
msgid "Odoo maintains a cache for the fields of the records, so that not every field access issues a database request, which would be terrible for performance. The following example queries the database only for the first statement::"
msgid "To avoid reading one field on one record at a time, Odoo *prefetches* records and fields following some heuristics to get good performance. Once a field must be read on a given record, the ORM actually reads that field on a larger recordset, and stores the returned values in cache for later use. The prefetched recordset is usually the recordset from which the record comes by iteration. Moreover, all simple stored fields (boolean, integer, float, char, text, date, datetime, selection, many2one) are fetched altogether; they correspond to the columns of the model's table, and are fetched efficiently in the same query."
msgid "Consider the following example, where ``partners`` is a recordset of 1000 records. Without prefetching, the loop would make 2000 queries to the database. With prefetching, only one query is made::"
msgid "The prefetching also works on *secondary records*: when relational fields are read, their values (which are records) are subscribed for future prefetching. Accessing one of those secondary records prefetches all secondary records from the same model. This makes the following example generate only two queries, one for partners and one for countries::"
#: ../../../odoo/odoo/api.py:docstring of odoo.api.autovacuum:1
msgid "Decorate a method so that it is called by the daily vacuum cron job (model ``ir.autovacuum``). This is typically used for garbage-collection-like tasks that do not deserve a specific cron job."
#: ../../../odoo/odoo/api.py:docstring of odoo.api.constrains:18
msgid "``@constrains`` only supports simple field names, dotted names (fields of relational fields e.g. ``partner_id.customer``) are not supported and will be ignored."
#: ../../../odoo/odoo/api.py:docstring of odoo.api.constrains:22
msgid "``@constrains`` will be triggered only if the declared fields in the decorated method are included in the ``create`` or ``write`` call. It implies that fields not present in a view will not trigger a call during a record creation. A override of ``create`` is necessary to make sure a constraint will always be triggered (e.g. to test the absence of value)."
#: ../../../odoo/odoo/api.py:docstring of odoo.api.depends:1
msgid "Return a decorator that specifies the field dependencies of a \"compute\" method (for new-style function fields). Each argument must be a string that consists in a dot-separated sequence of field names::"
#: ../../../odoo/odoo/api.py:docstring of odoo.api.depends_context:1
msgid "Return a decorator that specifies the context dependencies of a non-stored \"compute\" method. Each argument is a key in the context's dictionary::"
#: ../../../odoo/odoo/api.py:docstring of odoo.api.model_create_multi:1
msgid "Decorate a method that takes a list of dictionaries and creates multiple records. The method may be called with either a single dict or a list of dicts::"
#: ../../../odoo/odoo/api.py:docstring of odoo.api.onchange:3
msgid "In the form views where the field appears, the method will be called when one of the given fields is modified. The method is invoked on a pseudo-record that contains the values present in the form. Field assignments on that record are automatically sent back to the client."
#: ../../../odoo/odoo/api.py:docstring of odoo.api.onchange:25
msgid "``@onchange`` only supports simple field names, dotted names (fields of relational fields e.g. ``partner_id.tz``) are not supported and will be ignored"
#: ../../../odoo/odoo/api.py:docstring of odoo.api.onchange:31
msgid "Since ``@onchange`` returns a recordset of pseudo-records, calling any one of the CRUD methods (:meth:`create`, :meth:`read`, :meth:`write`, :meth:`unlink`) on the aforementioned recordset is undefined behaviour, as they potentially do not exist in the database yet."
#: ../../../odoo/odoo/api.py:docstring of odoo.api.onchange:42
msgid "It is not possible for a ``one2many`` or ``many2many`` field to modify itself via onchange. This is a webclient limitation - see `#2693 <https://github.com/odoo/odoo/issues/2693>`_."
#: ../../../odoo/odoo/api.py:docstring of odoo.api.returns:14
msgid "The decorator adapts the method output to the api style: ``id``, ``ids`` or ``False`` for the traditional style, and recordset for the record style::"
#: ../../../odoo/odoo/api.py:docstring of odoo.api.returns:30
msgid "Those decorators are automatically *inherited*: a method that overrides a decorated existing method will be decorated with the same ``@returns(model)``."
msgid "will not trigger any interface update when the field is edited by the user, even if there are function fields or explicit onchange depending on that field."
msgid "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."
msgid "When creating a recordset from an other recordset, the environment is inherited. The environment can be used to get an empty recordset in an other model, and query that model::"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.with_context:4
msgid "The extended context is either the provided ``context`` in which ``overrides`` are merged or the *current* context in which ``overrides`` are merged e.g.::"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.with_user:1
msgid "Return a new version of this recordset attached to the given user, in non-superuser mode, unless `user` is the superuser (by convention, the superuser is always in superuser mode.)"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.with_company:11
msgid "When using an unauthorized company for current user, accessing the company(ies) on the environment may trigger an AccessError if not done in a sudoed environment."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.with_env:7
msgid "The new environment will not benefit from the current environment's data cache, so later data access may incur extra delays while re-fetching from the database. The returned recordset has the same prefetch object as ``self``."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.sudo:1
msgid "Returns a new version of this recordset with superuser mode enabled or disabled, depending on `flag`. The superuser mode does not change the current user, and simply bypasses access rights checks."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.sudo:7
msgid "Using ``sudo`` could cause data access to cross the boundaries of record rules, possibly mixing records that are meant to be isolated (e.g. records from different companies in multi-company environments)."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.sudo:12
msgid "It may lead to un-intuitive results in methods which select one record among many - for example getting the default company, or selecting a Bill of Materials."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.sudo:18
msgid "Because the record rules and access control will have to be re-evaluated, the new recordset will not benefit from the current environment's data cache, so later data access may incur extra delays while re-fetching from the database. The returned recordset has the same prefetch object as ``self``."
msgid "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::"
msgid "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)."
msgid "Executing raw SQL bypasses the ORM, and by consequent, Odoo security rules. Please make sure your queries are sanitized when using user input and prefer using ORM utilities if you don't really need to use SQL queries."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.create:6
msgid "values for the model's fields, as a list of dictionaries:: [{'field_name': field_value, ...}, ...] For backward compatibility, ``vals_list`` may be a dictionary. It is treated as a singleton list ``[vals]``, and a single record is returned. see :meth:`~.write` for details"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.name_create:4
msgid "The new record will be initialized with any default values applicable to this model, or provided through the context. The usual behavior of :meth:`~.create` applies."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:3
msgid "fields to update and the value to set on them e.g:: {'foo': 1, 'bar': \"Qux\"} will set the field ``foo`` to ``1`` and the field ``bar`` to ``\"Qux\"`` if those are valid (otherwise it will trigger an error)."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:20
msgid "For :class:`~odoo.fields.Selection`, the value should match the selection values (generally :class:`python:str`, sometimes :class:`python:int`)"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:29
msgid "for historical and compatibility reasons, :class:`~odoo.fields.Date` and :class:`~odoo.fields.Datetime` fields use strings as values (written and read) rather than :class:`~python:datetime.date` or :class:`~python:datetime.datetime`. These date strings are UTC-only and formatted according to :const:`odoo.tools.misc.DEFAULT_SERVER_DATE_FORMAT` and :const:`odoo.tools.misc.DEFAULT_SERVER_DATETIME_FORMAT`"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:39
msgid ":class:`~odoo.fields.One2many` and :class:`~odoo.fields.Many2many` use a special \"commands\" format to manipulate the set of records stored in/associated with the field."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:43
msgid "This format is a list of triplets executed sequentially, where each triplet is a command to execute on the set of records. Not all commands apply in all situations. Possible commands are:"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.write:66
msgid "replaces all existing records in the set by the ``ids`` list, equivalent to using the command ``5`` followed by a command ``4`` for each ``id`` in ``ids``."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.name_search:1
msgid "Search for records that have a display name matching the given ``name`` pattern when compared with the given ``operator``, while also matching the optional search domain (``args``)."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.name_search:5
msgid "This is used for example to provide suggestions based on a partial value for a relational field. Sometimes be seen as the inverse function of :meth:`~.name_get`, but it is not guaranteed to be."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.name_search:9
msgid "This method is equivalent to calling :meth:`~.search` with a search domain based on ``display_name`` and then :meth:`~.name_get` on the result of the search."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read_group:5
msgid "list of fields present in the list view specified on the object. Each element is either 'field' (field name, using the default aggregation), or 'field:agg' (aggregate field with aggregation function 'agg'), or 'name:agg(field)' (aggregate field with 'agg' and return it as 'name'). The possible aggregation functions are the ones provided by PostgreSQL (https://www.postgresql.org/docs/current/static/functions-aggregate.html) and 'count_distinct', with the expected meaning."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read_group:12
msgid "list of groupby descriptions by which the records will be grouped. A groupby description is either a field (then it will be grouped by that field) or a string 'field:groupby_function'. Right now, the only functions supported are 'day', 'week', 'month', 'quarter' or 'year', and they only make sense for date/datetime fields."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read_group:19
msgid "optional ``order by`` specification, for overriding the natural sort ordering of the groups, see also :py:meth:`~osv.osv.osv.search` (supported only for many2one fields currently)"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read_group:23
msgid "if true, the results are only grouped by the first groupby and the remaining groupbys are put in the __context key. If false, all the groupbys are done in one call."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.read_group:26
msgid "list of dictionaries(one dictionary for each record) containing: * the values of fields grouped by the fields in ``groupby`` argument * __domain: list of tuples specifying the search criteria * __context: dictionary with argument like ``groupby``"
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.fields_get:3
msgid "The returned value is a dictionary (indexed by field name) of dictionaries. The _inherits'd fields are included. The string, help, and selection (if present) attributes are translated."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.fields_view_get:9
msgid "* if the inherited view has unknown position to work with other than 'before', 'after', 'inside', 'replace' * if some tag other than 'position' is found in parent view"
msgid "a field name of the current model, or a relationship traversal through a :class:`~odoo.fields.Many2one` using dot-notation e.g. ``'street'`` or ``'partner_id.country'``"
msgid "matches ``field_name`` against the ``value`` pattern. An underscore ``_`` in the pattern stands for (matches) any single character; a percent sign ``%`` matches any string of zero or more characters."
msgid "Mostly to negate combinations of criteria Individual criterion generally have a negative form (e.g. ``=`` -> ``!=``, ``<`` -> ``>=``) which is simpler than negating the positive."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.get_metadata:4
msgid "list of dictionaries with the following keys: * id: object id * create_uid: user who created the record * create_date: date when the record was created * write_uid: last user who changed the record * write_date: date of the last change to the record * xmlid: XML ID to use to refer to this record (if there is one), in format ``module.name`` * noupdate: A boolean telling if the record will be updated or not"
msgid "``record in set`` returns whether ``record`` (which must be a 1-element recordset) is present in ``set``. ``record not in set`` is the inverse operation"
msgid "Recordsets are iterable so the usual Python tools are available for transformation (:func:`python:map`, :func:`python:sorted`, :func:`~python:itertools.ifilter`, ...) however these return either a :class:`python:list` or an :term:`python:iterator`, removing the ability to call methods on their result, or to use set operations."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.mapped:1
msgid "Apply ``func`` on all records in ``self``, and return the result as a list or a recordset (if ``func`` return recordsets). In the latter case, the order of the returned recordset is arbitrary."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel.sorted:3
msgid "either a function of one argument that returns a comparison key for each record, or a field name, or ``None``, in which case records are ordered according the default model's order"
msgid "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:`~odoo.models.Model._inherit`) as a base. The new model gets all the fields, methods and meta-information (defaults & al) from its base."
msgid "the second model has inherited from the first model's ``check`` method and its ``name`` field, but overridden the ``call`` method, as when using standard :ref:`Python inheritance <python:tut-inheritance>`."
msgid "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)::"
msgid "The third inheritance mechanism provides more flexibility (it can be altered 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:`~odoo.fields.Reference` fields automatically set up on the parent model."
msgid "The main difference is in the meaning. When using Delegation, the model **has one** instead of **is one**, turning the relationship in a composition instead of inheritance::"
msgid "A field is defined as class attribute on a model class. If the model is extended, one can also extend the field definition by redefining a field with the same name and same type on the subclass. In that case, the attributes of the field are taken from the parent class and overridden by the ones given in subclasses."
#: ../../../odoo/odoo/exceptions.py:docstring of odoo.exceptions.UserError:3
msgid "Typically when the user tries to do something that has no sense given the current state of a record. Semantically comparable to the generic 400 HTTP status codes."
msgid "Reports are written in HTML/QWeb, like website views in Odoo. You can use the usual :ref:`QWeb control flow tools <reference/qweb>`. The PDF rendering itself is performed by wkhtmltopdf_."
msgid "Calling ``external_layout`` will add the default header and footer on your report. The PDF body will be the content inside the ``<div class=\"page\">``. The template's ``id`` must be the name specified in the report declaration; for example ``account.report_invoice`` for the above report. Since this is a QWeb template, you can access all the fields of the ``docs`` objects received by the template."
msgid "If you wish to access other records/models in the template, you will need :ref:`a custom report <reference/reports/custom_reports>`, however in that case you will have to provide the items above if you need them."
msgid "You can then call the translatable document from your main template with the attribute ``t-lang`` set to a language code (for example ``fr`` or ``en_US``) or to a record field. You will also need to re-browse the related records with the proper context if you use fields that are translatable (like country names, sales conditions, etc.)"
msgid "If your report template does not use translatable record fields, re-browsing the record in another language is *not* necessary and will impact performances."
msgid "The main template calls the translatable template with ``doc.partner_id.lang`` as a ``t-lang`` parameter, so it will be rendered in the language of the partner. This way, each Sale Order will be printed in the language of the corresponding customer. If you wish to translate only the body of the document, but keep the header and footer in a default language, you could call the report's external layout this way::"
msgid "Please take note that this works only when calling external templates, you will not be able to translate part of a document by setting a ``t-lang`` attribute on an xml node other than ``t-call``. If you wish to translate part of a template, you can create an external template with this partial template and call it from the main one with the ``t-lang`` attribute."
msgid "Barcodes are images returned by a controller and can easily be embedded in reports thanks to the QWeb syntax (e.g. see :ref:`reference/qweb/attributes`):"
msgid "If it appears that your PDF report is missing the styles, please check :ref:`these instructions <reference/backend/reporting/printed-reports/pdf-without-styles>`."
msgid "either a predefined format (A0 to A9, B0 to B10, Legal, Letter, Tabloid,...) or ``custom``; A4 by default. You cannot use a non-custom format if you define the page dimensions."
msgid "However, it will first look for a model named :samp:`report.{module.report_name}` and call that model's ``_get_report_values(doc_ids, data)`` in order to prepare the rendering data for the template."
msgid "When using a custom report, the \"default\" document-related items (``doc_ids``, ``doc_model`` and ``docs``) will *not* be included. If you want them, you will need to include them yourself."
msgid "If you want to use custom fonts you will need to add your custom font and the related less/CSS to the ``web.reports_assets_common`` assets bundle. Adding your custom font(s) to ``web.assets_common`` or ``web.assets_backend`` will not make your font available in QWeb reports."
msgid "You will need to define your ``@font-face`` within this less file, even if you've used in another assets bundle (other than ``web.reports_assets_common``)."
msgid "it does not matter what timezone the :class:`python:datetime` object is actually in (including no timezone), its timezone will unconditionally be *set* to UTC before being adjusted to the user's"
msgid "Both mechanisms are linked to specific users through *groups*: a user belongs to any number of groups, and security mechanisms are associated to groups, thus applying security mechanisms to users."
msgid "The *module category*, serves to associate groups with an Odoo App (~a set of related business models) and convert them into an exclusive selection in the user form."
msgid "Other groups to set on the user alongside this one. This is a convenience pseudo-inheritance relationship: it's possible to explicitly remove implied groups from a user without removing the implier."
msgid "*Grants* access to an entire model for a given set of operations. If no access rights matches an operation on a model for a user (through their group), the user doesn't have access."
msgid "Access rights are additive, a user's accesses are the union of the accesses they get through all their groups e.g. given a user who is part of group A granting read and create access and a group B granting update access, the user will have all three of create, read, and update."
msgid "The :class:`res.groups` to which the accesses are granted, an empty :attr:`group_id` means the ACL is granted to *every user* (non-employees e.g. portal or public users)."
msgid "Record rules are *conditions* which must be satisfied in order for an operation to be allowed. Record rules are evaluated record-by-record, following access rights."
msgid "Record rules are default-allow: if access rights grant access and no rule applies to the operation and model for the user, the access is granted."
msgid "The :class:`res.groups` to which access is granted (or not). Multiple groups can be specified. If no group is specified, the rule is *global* which is treated differently than \"group\" rules (see below)."
msgid "A predicate specified as a :ref:`domain <reference/orm/domains>`, the rule allows the selected operations if the domain matches the record, and forbids it otherwise."
msgid "All the companies to which the current user has access as a list of company ids (not a recordset), see :ref:`howto/company/security` for more details."
msgid "The :samp:`perm_{method}` have completely different semantics than for :class:`ir.model.access`: for rules, they specify which operation the rules applies *for*. If an operation is not selected, then the rule is not checked for it, as if the rule did not exist."
msgid "Global rules *intersect*, if two global rules apply then *both* must be satisfied for the access to be granted, this means adding global rules always restricts access further."
msgid "Group rules *unify*, if two group rules apply then *either* can be satisfied for the access to be granted. This means adding group rules can expand access, but not beyond the bounds defined by global rules."
msgid "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`)."
msgid "Any public method can be executed via a :ref:`RPC call <api/odoo/calling_methods>` with the chosen parameters. The methods starting with a ``_`` are not callable from an action button or external API."
msgid "On public methods, the record on which a method is executed and the parameters can not be trusted, ACL being only verified during CRUD operations."
msgid "You should never use the database cursor directly when the ORM can do the same thing! By doing so you are bypassing all the ORM features, possibly the automated behaviours like translations, invalidation of fields, ``active``, access rights and so on."
msgid "Care must be taken not to introduce SQL injections vulnerabilities when using manual SQL queries. The vulnerability is present when user input is either incorrectly filtered or badly quoted, allowing an attacker to introduce undesirable clauses to a SQL query (such as circumventing filters or executing ``UPDATE`` or ``DELETE`` commands)."
msgid "The best way to be safe is to never, NEVER use Python string concatenation (+) or string parameters interpolation (%) to pass variables to a SQL query string."
msgid "The second reason, which is almost as important, is that it is the job of the database abstraction layer (psycopg2) to decide how to format query parameters, not your job! For example psycopg2 knows that when you pass a list of values it needs to format them as a comma-separated list, enclosed in parentheses !"
msgid "Here is a memorable example to help you remember what the issue is about (but do not copy the code there). Before continuing, please be sure to read the online documentation of pyscopg2 to learn of to use it properly:"
msgid "When rendering content using JavaScript and XML, one may be tempted to use a ``t-raw`` to display rich-text content. This should be avoided as a frequent `XSS <https://en.wikipedia.org/wiki/Cross-site_scripting>`_ vector."
msgid "It is very hard to control the integrity of the data from the computation until the final integration in the browser DOM. A ``t-raw`` that is correctly escaped at the time of introduction may no longer be safe at the next bugfix or refactoring."
msgid "The above code may feel safe as the message content is controlled but is a bad practice that may lead to unexpected security vulnerabilities once this code evolves in the future."
msgid "**Escaping** converts *TEXT* to *CODE*. It is absolutely mandatory to do it every time you mix *DATA/TEXT* with *CODE* (e.g. generating HTML or python code to be evaluated inside a `safe_eval`), because *CODE* always requires *TEXT* to be encoded. It is critical for security, but it's also a question of correctness. Even when there is no security risk (because the text is 100% guarantee to be safe or trusted), it is still required (e.g. to avoid breaking the layout in generated HTML)."
msgid "**Sanitizing** converts *CODE* to *SAFER CODE* (but not necessary *safe* code). It does not work on *TEXT*. Sanitizing is only necessary when *CODE* is untrusted, because it comes in full or in part from some user-provided data. If the user-provided data is in the form of *TEXT* (e.g. the content from a form filled by a user), and if that data was correctly escaped before putting it in *CODE*, then sanitizing is useless (but can still be done). If however, the user-provided data was **not escaped**, then sanitizing will **not** work as expected."
msgid "Sanitizing can break features, depending on whether the *CODE* is expected to contain patterns that are not safe. That's why `fields.Html` and `tools.html_sanitize()` have options to fine-tune the level of sanitization for styles, etc. Those options have to be carefully considered depending on where the data comes from, and the desired features. The sanitization safety is balanced against sanitization breakages: the safer the sanitisation the more likely it is to break things."
msgid "Some may want to ``eval`` to parse user provided content. Using ``eval`` should be avoided at all cost. A safer, sandboxed, method :class:`~odoo.tools.safe_eval` can be used instead but still gives tremendous capabilities to the user running it and must be reserved for trusted privileged users only as it breaks the barrier between code and data."
msgid "Tours (see `Integration Testing`_): tours simulate a real situation. They ensures that the python and the javascript parts properly talk to each other."
msgid "To write tests, simply define a ``tests`` sub-package in your module, it will be automatically inspected for test modules. Test modules should have a name starting with ``test_`` and should be imported from ``tests/__init__.py``, e.g."
msgid "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):"
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.TransactionCase:1
msgid "TestCase in which each test method is run in its own transaction, and with its own cursor. The transaction is rolled back and the cursor is closed after each test."
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.SingleTransactionCase:1
msgid "TestCase in which all test methods are run in the same transaction, the transaction is started with the first test method and rolled back at the end of the last."
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.SavepointCase:1
msgid "Similar to :class:`SingleTransactionCase` in that all test methods are run in a single transaction *but* each test case is run inside a rollbacked savepoint (sub-transaction)."
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.SavepointCase:5
msgid "Useful for test cases containing fast tests but with significant database setup common to all cases (complex in-db test data): :meth:`~.setUpClass` can be used to generate db test data once, then all test cases use the same data without influencing one another but without having to recreate the test data either."
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.HttpCaseCommon.browser_js:1
msgid "Test js code running in the browser - optionnally log as 'login' - load page given by url_path - wait for ready object to be available - eval(code) inside the page"
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.tagged:1
msgid "A decorator to tag BaseCase objects. Tags are stored in a set that can be accessed from a 'test_tags' attribute. A tag prefixed by '-' will remove the tag e.g. to remove the 'standard' tag. By default, all Test classes from odoo.tests.common have a test_tags attribute that defaults to 'standard' and 'at_install'. When using class inheritance, the tags are NOT inherited."
msgid "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::"
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form:3
msgid "Implements much of the \"form view\" manipulation flow, such that server-side tests can more properly reflect the behaviour which would be observed when manipulating the interface:"
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form:28
msgid "For :class:`~odoo.fields.Many2many` fields, the field itself is a :class:`~odoo.tests.common.M2MProxy` and can be altered by adding or removing records::"
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form:39
msgid "Because the :class:`~odoo.fields.One2many` only exists through its parent, it is manipulated more directly by creating \"sub-forms\" with the :meth:`~odoo.tests.common.O2MProxy.new` and :meth:`~odoo.tests.common.O2MProxy.edit` methods. These would normally be used as context managers since they get saved in the parent record::"
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form:60
msgid "empty or singleton recordset. An empty recordset will put the view in \"creation\" mode and trigger calls to default_get and on-load onchanges, a singleton will put it in \"edit\" mode and only load the view's data."
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form:65
msgid "the id, xmlid or actual view object to use for onchanges and view constraints. If none is provided, simply loads the default view for the model."
#: ../../../odoo/odoo/tests/common.py:docstring of odoo.tests.common.Form.save:4
msgid "does not save unmodified fields (during edition) — any assignment or onchange return marks the field as modified, even if set to its current value"
msgid "Tests are automatically run when installing or updating modules if :option:`--test-enable <odoo-bin --test-enable>` was enabled when starting the Odoo server."
msgid "Subclasses of :class:`odoo.tests.common.BaseCase` (usually through :class:`~odoo.tests.common.TransactionCase`, :class:`~odoo.tests.common.SavepointCase` or :class:`~odoo.tests.common.HttpCase`) are automatically tagged with ``standard`` and ``at_install`` by default."
msgid ":option:`--test-tags <odoo-bin --test-tags>` can be used to select/filter tests to run on the command-line. It implies :option:`--test-enable <odoo-bin --test-enable>`, so it's not necessary to specify :option:`--test-enable <odoo-bin --test-enable>` when using :option:`--test-tags <odoo-bin --test-tags>`."
msgid "This option defaults to ``+standard`` meaning tests tagged ``standard`` (explicitly or implicitly) will be run by default when starting Odoo with :option:`--test-enable <odoo-bin --test-enable>`."
msgid "Tags can be prefixed with the minus (``-``) sign, to *remove* them instead of add or select them e.g. if you don't want your test to be executed by default you can remove the ``standard`` tag:"
msgid "Note that only the tests tagged ``nice`` are going to be executed. To run *both* ``nice`` and ``standard`` tests, provide multiple values to :option:`--test-tags <odoo-bin --test-tags>`: on the command-line, values are *additive* (you're selecting all tests with *any* of the specified tags)"
msgid "The config switch parameter also accepts the ``+`` and ``-`` prefixes. The ``+`` prefix is implied and therefore, totally optional. The ``-`` (minus) prefix is made to deselect tests tagged with the prefixed tags, even if they are selected by other specified tags e.g. if there are ``standard`` tests which are also tagged as ``slow`` you can run all standard tests *except* the slow ones:"
msgid "When you write a test that does not inherit from the :class:`~odoo.tests.common.BaseCase`, this test will not have the default tags, you have to add them explicitly to have the test included in the default test suite. This is a common issue when using a simple ``unittest.TestCase`` as they're not going to get run:"
msgid "Besides tags you can also specify specific modules, classes or functions to test. The full syntax of the format accepted by :option:`--test-tags <odoo-bin --test-tags>` is:"
msgid "if the name of the test is unambiguous. Multiple modules, classes and functions can be specified at once separated by a `,` like with regular tags."
msgid "``standard``: All Odoo tests that inherit from :class:`~odoo.tests.common.BaseCase` are implicitly tagged standard. :option:`--test-tags <odoo-bin --test-tags>` also defaults to ``standard``."
msgid "``at_install``: Means that the test will be executed right after the module installation and before other modules are installed. This is a default implicit tag."
msgid "``post_install``: Means that the test will be executed after all the modules are installed. This is what you want for HttpCase tests most of the time."
msgid "Note that this is *not exclusive* with ``at_install``, however since you will generally not want both ``post_install`` is usually paired with ``-at_install`` when tagging a test class."
msgid "Tests will be executed only in installed modules. If you're starting from a clean database, you'll need to install the modules with the :option:`-i <odoo-bin -i>` switch at least once. After that it's no longer needed, unless you need to upgrade the module, in which case :option:`-u <odoo-bin -u>` can be used. For simplicity, those switches are not specified in the examples below."
msgid "Testing a complex system is an important safeguard to prevent regressions and to guarantee that some basic functionality still works. Since Odoo has a non trivial codebase in Javascript, it is necessary to test it. In this section, we will discuss the practice of testing JS code in isolation: these tests stay in the browser, and are not supposed to reach the server."
msgid "The Odoo framework uses the QUnit_ library testing framework as a test runner. QUnit defines the concepts of *tests* and *modules* (a set of related tests), and gives us a web based interface to execute the tests."
msgid "The main way to run the test suite is to have a running Odoo server, then navigate a web browser to ``/web/tests``. The test suite will then be executed by the web browser Javascript engine."
msgid "The web UI has many useful features: it can run only some submodules, or filter tests that match a string. It can show every assertions, failed or passed, rerun specific tests, ..."
msgid "there is an asset bundle named `web.qunit_suite`_. This bundle contains the main code (assets common + assets backend), some libraries, the QUnit test runner and the test bundles listed below."
msgid "a bundle named `web.tests_assets`_ includes most of the assets and utils required by the test suite: custom QUnit asserts, test helpers, lazy loaded assets, etc."
msgid "to execute the tests, one can simply point its browser to the route */web/tests*. In that case, the browser will download all assets, and QUnit will take over."
msgid "we want the runbot to also run these tests, so there is a test (in `test_js.py`_) which simply spawns a browser and points it to the *web/tests* url. Note that the browser_js method spawns a Chrome headless instance."
msgid "With the way Odoo is designed, any addon can modify the behaviour of other parts of the system. For example, the *voip* addon can modify the *FieldPhone* widget to use extra features. This is not really good from the perspective of the testing system, since this means that a test in the addon web will fail whenever the voip addon is installed (note that the runbot runs the tests with all addons installed)."
msgid "At the same time, our testing system is good, because it can detect whenever another module breaks some core functionality. There is no complete solution to this issue. For now, we solve this on a case by case basis."
msgid "Usually, it is not a good idea to modify some other behaviour. For our voip example, it is certainly cleaner to add a new *FieldVOIPPhone* widget and modify the few views that needs it. This way, the *FieldPhone* widget is not impacted, and both can be tested."
msgid "Let us assume that we are maintaining an addon *my_addon*, and that we want to add a test for some javascript code (for example, some utility function myFunction, located in *my_addon.utils*). The process to add a new test case is the following:"
msgid "Without help, it is quite difficult to test some parts of Odoo. In particular, views are tricky, because they communicate with the server and may perform many rpcs, which needs to be mocked. This is why we developed some specialized helper functions, located in `test_utils.js`_."
msgid "Mock test functions: these functions help setting up a test environment. The most important use case is mocking the answers given by the Odoo server. These functions use a `mock server`_. This is a javascript class that simulates answers to the most common model methods: read, search_read, nameget, ..."
msgid "DOM helpers: useful to simulate events/actions on some specific target. For example, testUtils.dom.click performs a click on a target. Note that it is safer than doing it manually, because it also checks that the target exists, and is visible."
msgid "create helpers: they are probably the most important functions exported by `test_utils.js`_. These helpers are useful to create a widget, with a mock environment, and a lot of small detail to simulate as much as possible the real conditions. The most important is certainly `createView`_."
msgid "`qunit assertions`_: QUnit can be extended with specialized assertions. For Odoo, we frequently test some DOM properties. This is why we made some assertions to help with that. For example, the *containsOnce* assertion takes a widget/jQuery/HtmlElement and a selector, then checks if the target contains exactly one match for the css selector."
msgid "Notice the use of the testUtils.createView helper and of the containsOnce assertion. Also, the form controller was properly destroyed at the end of the test."
msgid "no need to have full and complete code coverage. But adding a few tests helps a lot: it makes sure that your code is not completely broken, and whenever a bug is fixed, it is really much easier to add a test to an existing test suite."
msgid "if you want to check some negative assertion (for example, that a HtmlElement does not have a specific css class), then try to add the positive assertion in the same test (for example, by doing an action that changes the state). This will help avoid the test to become dead in the future (for example, if the css class is changed)."
msgid "running only one test: you can (temporarily!) change the *QUnit.test(...)* definition into *QUnit.only(...)*. This is useful to make sure that QUnit only runs this specific test."
msgid "debug flag: most create utility functions have a debug mode (activated by the debug: true parameter). In that case, the target widget will be put in the DOM instead of the hidden qunit specific fixture, and more information will be logged. For example, all mocked network communications will be available in the console."
msgid "when working on a failing test, it is common to add the debug flag, then comment the end of the test (in particular, the destroy call). With this, it is possible to see the state of the widget directly, and even better, to manipulate the widget by clicking/interacting with it."
msgid "Testing Python code and JS code separately is very useful, but it does not prove that the web client and the server work together. In order to do that, we can write another kind of test: tours. A tour is a mini scenario of some interesting business flow. It explains a sequence of steps that should be followed. The test runner will then create a PhantomJs browser, point it to the proper url and simulate the click and inputs, according to the scenario."
msgid "Every step contains at least a trigger. You can either use the `predefined steps <https://github.com/odoo/odoo/blob/14.0/addons/web_tour/static/src/js/tour_step_utils.js>`_ or write your own personalized step."
msgid "**extra-trigger**: optional selector/element/jQuery that needs to be present before the next step begins. This is especially useful when the tour needs to wait for a wizard to open, a line added to a list view..."
msgid "**run**: optional action to run, defaults either to `click` or `text Test` if you are triggering an input. A multitude of actions are possible. Here are some of them: `click`, `dbclick`, `tripleclick`, `text Example`, `drag_and_drop selector1 selector2`..."
msgid "Sometimes, a step will be different in enterprise or in community. You can then write two steps, one for the enterprise edition and one for the community one."
msgid "First, activate the :doc:`developer mode </applications/general/developer_mode>` with `?debug=tests`. Then, open your debug menu and click on **Start Tour**. You can now launch your tour from there with the button `Test`."
msgid "Be aware that when running the tour, any data added to the setup of your python test won't be present in the tour unless you launched the test calling the tour with a breakpoint."
msgid "When running tests that use HttpCase.browser_js from the command line, the Chrome browser is used in headless mode. By default, if a test fails, a PNG screenshot is taken at the moment of the failure and written in"
msgid "Two new command line arguments were added since Odoo 13.0 to control this behavior: :option:`--screenshots <odoo-bin --screenshots>` and :option:`--screencasts <odoo-bin --screencasts>`"
msgid "One of the ways to test performance is to measure database queries. Manually, this can be tested with the `--log-sql` CLI parameter. If you want to establish the maximum number of queries for an operation, you can use the :meth:`~odoo.tests.common.BaseCase.assertQueryCount` method, integrated in Odoo test classes."
msgid "Instead of the tedious manual, or programmatic, specification of test data, one can use this feature to fill a database on demand with the desired number of test data. This can be used to detect diverse bugs or performance issues in tested flows."
#: ../../docstring of odoo.models.Model._populate_sizes:1
msgid "Return a dict mapping symbolic sizes (``'small'``, ``'medium'``, ``'large'``) to integers, giving the minimal number of records that :meth:`_populate` should create."
#: ../../../odoo/odoo/models.py:docstring of odoo.models.BaseModel._populate_factories:19
msgid "It is the responsibility of the generator to handle the field_name correctly. The generator could generate values for multiple fields together. In this case, the field_name should be more a \"field_group\" (should be begin by a \"_\"), covering the different fields updated by the generator (e.g. \"_address\" for a generator updating multiple address fields)."
msgid "You have to define at least :meth:`~odoo.models.Model._populate` or :meth:`~odoo.models.Model._populate_factories` on the model to enable database population."
#: ../../../odoo/odoo/tools/populate.py:docstring of odoo.tools.populate.compute:1
msgid "Return a factory for an iterator of values dicts that computes the field value as ``function(values, counter, random)``, where ``values`` is the other field values, ``counter`` is an integer, and ``random`` is a pseudo-random number generator."
#: ../../../odoo/odoo/tools/populate.py:docstring of odoo.tools.populate.iterate:1
msgid "Return a factory for an iterator of values dicts that picks a value among ``vals`` for each input. Once all ``vals`` have been used once, resume as ``then`` or as a ``randomize`` generator."
msgid "Views are what define how records should be displayed to end-users. They are specified in XML which means that they can be edited independently from the models that they represent. They are flexible and allow a high level of customization of the screens that they control. There exist various types of views. Each of them represents a mode of visualization: *form*, *list*, *kanban*, etc."
msgid "When a view is requested by ``(model, type)``, the view matching the model and the type, with the lowest priority will be returned (it is the default view)."
msgid "If the view extends an existing view, the extension will only be applied for a given user if the user has access to the provided ``groups_id``."
msgid "The different view types have a wide variety of attributes allowing customizations of the generic behaviors. Some main attributes will be explained here. They do not all have an impact on all view types."
msgid "Supported values differ for the two view types. The Gantt view only supports ``success``, ``info``, ``warning``, ``danger`` and ``secondary`` displays. The list view supports ``bf``, ``it``, ``success``, ``info``, ``warning``, ``danger``, ``muted`` and ``primary`` displays."
msgid "These fake records will have heuristics for certain field names/models. For example, a field 'display_name' on the model 'res.users' will be populated with sample people names while an 'email' field will be in the form 'firstname.lastname@sample.demo'."
msgid "The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)"
msgid "If this attribute is set, the :ref:`controller route url<reference/controllers>` will be fetched and displayed above the view. The json response from the controller should contain an \"html\" key."
msgid "To interact with the backend you can use <a type=\"action\"> tags. Please take a look at the documentation of the _onActionClicked method of AbstractController (*addons/web/static/src/js/views/abstract_controller.js*) for more details."
msgid "Only views extending AbstractView and AbstractController can use this attribute, like :ref:`reference/views/form`, :ref:`reference/views/kanban`, :ref:`reference/views/list`, ..."
msgid "An example of where you would want to override ``mode`` while using ``inherit_id`` is delegation inheritance. In that case your derived model will be separate from its parent and views matching with one won't match with the other. Suppose you inherit from a view associated with the parent model and want to customize the derived view to show data from the derived model. The ``mode`` of the derived view needs to be set to ``primary``, because it's the base (and maybe only) view for that derived model. Otherwise the :ref:`view matching <reference/views/inheritance/view-matching>` rules won't apply."
msgid "the current view's children with mode ``extension`` are looked up and their inheritance specs are applied depth-first (a child view is applied, then its children, then its siblings)"
msgid "Inheritance specs are comprised of an element locator, to match the inherited element in the parent view, and children element that will be used to modify the inherited element."
msgid "An ``xpath`` element with an ``expr`` attribute. ``expr`` is an XPath_ expression\\ [#hasclass]_ applied to the current ``arch``, the first node it finds is the match"
msgid "a ``field`` element with a ``name`` attribute, matches the first ``field`` with the same ``name``. All other attributes are ignored during matching"
msgid "the content of the inheritance spec replaces the matched node. Any text node containing only ``$0`` within the contents of the spec will be replaced by a complete copy of the matched node, effectively wrapping the matched node."
msgid "if the ``attribute`` element has a body, a new attributed named after its ``name`` is created on the matched node with the ``attribute`` element's text as value"
msgid "if the ``attribute`` element has no body, the attribute named after its ``name`` is removed from the matched node. If no such attribute exists, an error is raised"
msgid "can be used as a direct child of a inheritance spec with a ``inside``, ``replace``, ``after`` or ``before`` ``position`` attribute to move a node."
msgid "an extension function is added for simpler matching in QWeb views: ``hasclass(*classes)`` matches if the context node has all the specified classes"
msgid "The Activity view is used to display the activities linked to the records. The data are displayed in a chart with the records forming the rows and the activity types the columns. The first cell of each row displays a (customizable, see ``templates``, quite similarly to :ref:`reference/views/kanban`) card representing the corresponding record. When clicking on others cells, a detailed description of all activities of the same type for the record is displayed."
msgid "defines the :ref:`reference/qweb` templates. Cards definition may be split into multiple templates for clarity, but activity views *must* define at least one root template ``activity-box``, which will be rendered once for each record."
msgid "The activity view uses mostly-standard :ref:`javascript qweb <reference/qweb/javascript>` and provides the following context variables (see :ref:`reference/views/kanban` for more details):"
msgid "the current :js:class:`ActivityRecord`, can be used to fetch some meta-information. These methods are also available directly in the template context and don't need to be accessed via ``widget``"
msgid "Calendar views display records as events in a daily, weekly, monthly or yearly calendar. Their root element is ``<calendar>``. Available attributes on the calendar view are:"
msgid "name of the record's field holding the end date for the event, if ``date_stop`` is provided records become movable (via drag and drop) directly in the calendar"
msgid "name of a record field to use for *color segmentation*. Records in the same color segment are allocated the same highlight color in the calendar, colors are allocated semi-randomly. Displayed the display_name/avatar of the visible record in the sidebar"
msgid "view to open when the user create or edit an event. Note that if this attribute is not set, the calendar view will fall back to the id of the form view in the current action, if any."
msgid "If the option 'event_open_popup' is set to true, then the calendar view will open events (or records) in a FormViewDialog. Otherwise, it will open events in a new form view (with a do_action)"
msgid "enables quick-event creation on click: only asks the user for a ``name`` and tries to create a new event with just that and the clicked event time. Falls back to a full form dialog if the quick creation fails"
msgid "The cohort view is used to display and understand the way some data changes over a period of time. For example, imagine that for a given business, clients can subscribe to some service. The cohort view can then display the total number of subscriptions each month, and study the rate at which client leave the service (churn). When clicking on a cell, the cohort view will redirect you to a new action in which you will only see the records contained in the cell's time interval; this action contains a list view and a form view."
msgid "By default the cohort view will use the same list and form views as those defined on the action. You can pass a list view and a form view to the context of the action in order to set/override the views that will be used (the context keys to use being `form_view_id` and `list_view_id`)"
msgid "A valid date or datetime field. This field is understood by the view as the end date of a record. This is the field that will determine the churn."
msgid "A string to describe the mode. It should be either 'churn' or 'retention' (default). Churn mode will start at 0% and accumulate over time whereas retention will start at 100% and decrease over time."
msgid "A string to describe the timeline. It should be either 'backward' or 'forward' (default). Forward timeline will display data from date_start to date_stop, whereas backward timeline will display data from date_stop to date_start (when the date_start is in future / greater than date_stop)."
msgid "A field that can be aggregated. This field will be used to compute the values for each cell. If not set, the cohort view will count the number of occurrences."
msgid "allows to specify a particular field in order to manage it from the available measures, it's main use is for hiding a field from the selectable measures:"
msgid "if true, the field will not appear either in the active measures nor in the selectable measures (useful for fields that do not make sense aggregated, such as fields in different units, e.g. € and $)."
msgid "Like pivot and graph view, The dashboard view is used to display aggregate data. However, the dashboard can embed sub views, which makes it possible to have a more complete and interesting look on a given dataset."
msgid "The dashboard view can display sub views, aggregates for some fields (over a domain), or even *formulas* (expressions which involves one or more aggregates). For example, here is a very simple dashboard:"
msgid "When the user clicks on an aggregate with a domain, it will be added to the search view as a facet. The string displayed for this facet can be customized with this attribute."
msgid "A valid postgreSQL aggregate function identifier to use when aggregating values (see https://www.postgresql.org/docs/9.5/static/functions-aggregate.html). If not provided, By default, the group_operator from the field definition is used. Note that no aggregation of field values is achieved if the group_operator value is \"\"."
msgid "This attribute is the name of a field describing the measure that has to be used in the graph and pivot views when clicking on the aggregate. The special value __count__ can be used to use the count measure."
msgid "A boolean indicating if this aggregate should be clickable or not (default to true). Clicking on a clickable aggregate will change the measures used by the subviews and add the value of the domain attribute (if any) to the search view."
msgid "A string expression that will be evaluated, with the builtin python evaluator (in the web client). Every aggregate can be used in the context, in the ``record`` variable. For example, ``record.price_total / record.order_id``."
msgid "Form views are used to display the data from a single record. Their root element is ``<form>``. They are composed of regular HTML_ with additional structural and semantic components."
msgid "used to define column layouts in forms. By default, groups define 2 columns and most direct children of groups take a single column. ``field`` direct children of groups display a label by default, and the label and the field itself have a colspan of 1 each."
msgid "The number of columns in a ``group`` can be customized using the ``col`` attribute, the number of columns taken by an element can be customized using ``colspan``."
msgid "only useful within ``group`` elements, ends the current row early and immediately switches to a new row (without filling any remaining column beforehand)"
msgid "call into the Odoo system, similar to :ref:`list view buttons <reference/views/list/button>`. In addition, the following attribute can be specified:"
msgid "renders (and allow editing of, possibly) a single field of the current record. Using several times a field in a form view is supported and the fields can receive different values for modifiers 'invisible' and 'readonly'. However, the behavior is not guaranteed when several fields exist with different values for modifier 'required'. Possible attributes of the field node are:"
msgid "the node id. Useful when there are several occurrences of the same field in the view (see ``label`` component below). Default is the field name."
msgid "fields have a default rendering based on their type (e.g. :class:`~odoo.fields.Char`, :class:`~odoo.fields.Many2one`). The ``widget`` attributes allows using a different rendering method and context."
msgid "help message to display in *empty* fields. Can replace field labels in complex forms. *Should not* be an example of data as users are liable to confuse placeholder text with filled fields"
msgid "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)"
msgid "when a ``field`` component isn't placed directly inside a ``group``, or when its ``nolabel`` attribute is set, the field's label isn't automatically displayed alongside its value. The ``label`` component is the manual alternative of displaying the label of a field. Possible attributes are:"
msgid "the reference to the field associated with the label. Can be either the name of a field, or its id (``id`` attribute set on the ``field``). When there are several occurrences of the same field in the view, and there are several ``label`` components associated with these ``field`` nodes, those labels must have unique ``for`` attributes (in this case referencing the ``id`` attribute of the corresponding ``field`` nodes)."
msgid "dictionary with the \"group by\" field as key and the maximum consolidation value that can be reached before displaying the cell in red (e.g. ``{\"user_id\": 100}``)"
msgid "name of the field that describes if the task has to be excluded from the consolidation if set to true it displays a striped zone in the consolidation line"
msgid "``cell_create``: If enabled and ``create`` enabled, a \"**+**\" button will be displayed while hovering on a time slot cell to create a new record on that slot."
msgid "``plan``: If enabled and ``edit`` enabled, a \"magnifying glass\" button will be displayed on time slots to plan unassigned records into that time slot."
msgid "When you do not want to create records on the gantt view and the beginning and end dates are required on the model, the planning feature should be disabled because no record will ever be found."
msgid "Depending on the scale, the number of units to add to today to compute the default period. Examples: An offset of +1 in default_scale week will open the gantt view for next week, and an offset of -2 in default_scale month will open the gantt view of 2 months ago."
msgid "boolean to control whether it is possible to collapse each row if grouped by one field. (default: ``false``, the collapse starts when grouping by two fields)"
msgid "boolean to mark the dates returned by the ``gantt_unavailability`` function of the model as available inside the gantt view. Records can still be scheduled in them, but their unavailability is visually displayed. (default: ``false``)"
msgid "comma-separated list of allowed scales for this view. By default, all scales are allowed. For possible scale values to use in this list, see ``default_scale``."
msgid "the current :js:class:`GanttRow`, can be used to fetch some meta-information. The ``getColor`` method to convert in a color integer is also available directly in the template context without using ``widget``."
msgid "``on_create`` If specified when clicking the add button on the view, instead of opening a generic dialog, launch a client action. this should hold the xmlid of the action (eg: ``on_create=\"%(my_module.my_wizard)d\"``"
msgid "view to open when the user create or edit a record. Note that if this attribute is not set, the gantt view will fall back to the id of the form view in the current action, if any."
msgid "This allows to display a thumbnail next to groups name if the group is a relationnal field. This expects a python dict which keys are the name of the field on the active model. Values are the names of the field holding the thumbnail on the related model."
msgid "The graph view is used to visualize aggregations over a number of records or record groups. Its root element is ``<graph>`` which can take the following attributes:"
msgid "if set, x-axis values will be sorted by default according their measure with respect to the given order (``asc`` or ``desc``). Only used for ``bar`` and ``pie`` charts."
msgid "on date and datetime fields, groups by the specified interval (``day``, ``week``, ``month``, ``quarter`` or ``year``) instead of grouping on the specific datetime (fixed second resolution) or date (fixed day resolution)."
msgid "The measures are automatically generated from the model fields; only the aggregatable fields are used. Those measures are also alphabetically sorted on the string of the field."
msgid "The kanban view is a `kanban board`_ visualisation: it displays records as \"cards\", halfway between a :ref:`list view <reference/views/list>` and a non-editable :ref:`form view <reference/views/form>`. Records may be grouped in columns for use in workflow visualisation or manipulation (e.g. tasks or work-progress management), or ungrouped (used simply to visualize records)."
msgid "whether the kanban view should be grouped if no grouping is specified via the action or the current search. Should be the name of the field to group by when no grouping is otherwise specified"
msgid "if set to a key in the `KanbanExamplesRegistry`_, examples on column setups will be available in the grouped kanban view. `Here <https://github.com/odoo/odoo/blob/99821fdcf89aa66ac9561a972c6823135ebf65c0/addons/project/static/src/js/project_task_kanban_examples.js#L27>`_ is an example of how to define those setups."
msgid "whether it should be possible to create records without switching to the form view. By default, ``quick_create`` is enabled when the Kanban view is grouped by many2one, selection, char or boolean fields, and disabled when not."
msgid "the name of the field whose column's records' values will be summed and displayed next to the progressbar (if omitted, displays the total number of records)"
msgid "defines a list of :ref:`reference/qweb` templates. Cards definition may be split into multiple templates for clarity, but kanban views *must* define at least one root template ``kanban-box``, which will be rendered once for each record."
msgid "the current :js:class:`KanbanRecord`, can be used to fetch some meta-information. These methods are also available directly in the template context and don't need to be accessed via ``widget``"
msgid "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:`~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>`_)"
msgid "While most of the Kanban templates are standard :ref:`reference/qweb`, the Kanban view processes ``field``, ``button`` and ``a`` elements specially:"
msgid "by default fields are replaced by their formatted value, unless the ``widget`` attribute is specified, in which case their rendering and behavior depends on the corresponding widget. Possible values are (among others):"
msgid "buttons and links with a ``type`` attribute become perform Odoo-related operations rather than their standard HTML function. Possible types are:"
msgid "Calendar views display records as events in a daily, weekly or monthly calendar. Their root element is ``<calendar>``. Available attributes on the calendar view are:"
msgid "by default, selecting a list view's row opens the corresponding :ref:`form view <reference/views/form>`. The ``editable`` attributes makes the list view itself editable in-place."
msgid "The architecture for the inline :ref:`form view <reference/views/form>` is derived from the list view. Most attributes valid on a :ref:`form view <reference/views/form>`'s fields and buttons are thus accepted by list views although they may not have any meaning if the list view is non-editable"
msgid "overrides the ordering of the view, replacing the model's order (:attr:`~odoo.models.BaseModel._order` model attribute). The value is a comma-separated list of fields, postfixed by ``desc`` to sort in reverse order:"
msgid "``{$name}`` can be ``bf`` (``font-weight: bold``), ``it`` (``font-style: italic``), or any `bootstrap contextual color`_ (``danger``, ``info``, ``muted``, ``primary``, ``success`` or ``warning``)."
msgid "call a method on the list's model. The button's ``name`` is the method, which is called with the current row's record id and the current context."
msgid "load an execute an ``ir.actions``, the button's ``name`` is the database id of the action. The context is expanded with the list's model (as ``active_model``), the current row's record (``active_id``) and all the records currently loaded in the list (``active_ids``, may be just a subset of the database records matching the current search)"
msgid "A mapping of attributes to domains, domains are evaluated in the context of the current row's record, if ``True`` the corresponding attribute is set on the cell."
msgid "shorthand for ``invisible`` ``attrs``: a list of states, comma separated, requires that the model has a ``state`` field and that it is used in the view."
msgid "fetches and stores the field, but doesn't display the column in the table. Necessary for fields which shouldn't be displayed but are used by e.g. ``@colors``"
msgid "for ``sequence`` (or ``integer``) fields by which records are sorted, instead of displaying the field's value just displays a drag&drop icon to reorder records."
msgid "displays the corresponding aggregate at the bottom of the column. The aggregation is only computed on *currently displayed* records. The aggregation operation must match the corresponding field's ``group_operator``"
msgid "dynamic attributes based on record values. Only effects the current field, so e.g. ``invisible`` will hide the field but leave the same field of other records visible, it will not hide the column itself"
msgid "when there is no data in the list, the width of a column can be forced by setting this attribute. The value can be an absolute width (e.g. '100px'), or a relative weight (e.g. '3', meaning that this column will be 3 times larger than the others). Note that when there are records in the list, we let the browser automatically adapt the column's widths according to their content, and this attribute is thus ignored."
msgid "if the list view is ``editable``, any field attribute from the :ref:`form view <reference/views/form>` is also valid and will be used when setting up the inline form view."
msgid "In case of list sub-views (One2many/Many2many display in a form view), The attribute ``column_invisible`` can be useful to hide a column depending on the parent object."
msgid "When a list view is grouped, numeric fields are aggregated and displayed for each group. Also, if there are too many records in a group, a pager will appear on the right of the group row. For this reason, it is not a good practice to have a numeric field in the last column, when the list view is in a situation where it can be grouped (it is however fine for x2manys field in a form view: they cannot be grouped)."
msgid "defines custom headers (with buttons) for the current view when grouping records on many2one fields. It is also possible to add `field`, inside the `groupby` which can be used for modifiers. These fields thus belong on the many2one comodel. These extra fields will be fetched in batch."
msgid "The following example will override the default \"add a line\" button by replacing it with 3 new buttons: \"Add a product\", \"Add a section\" and \"Add a note\"."
msgid "This view is able to display records on a map and the routes between them. The record are represented by pins. It also allows the visualization of fields from the model in a popup tied to the record's pin."
msgid "The model on which the view is applied should contains a res.partner many2one since the view relies on the res.partner's address and coordinates fields to localize the records."
msgid "The view uses location data platforms' api to fetch the tiles (the map's background), do the geoforwarding (converting addresses to a set of coordinates) and fetch the routes. The view implements two api, the default one, openstreet map is able to fetch `tiles`_ and do `geoforwarding`_. This api does not require a token. As soon as a valid `MapBox`_ token is provided in the general settings the view switches to the Mapbox api. This api is faster and allows the computation of routes. The token are available by `signing up`_ to MapBox"
msgid "If a field is provided the view will override the model's default order. The field must be part of the model on which the view is applied not from res.partner"
msgid "if ``true`` the routes between the records will be shown. The view still needs a valid MapBox token and at least two located records. (i.e the records has a res.partner many2one and the partner has a address or valid coordinates)"
msgid "The ``<map>`` element can contain multiple ``<field>`` elements. Each ``<field>`` element will be interpreted as a line in the marker's popup. The field's attributes are the following:"
msgid "In Pivot view a ``field`` can have a ``widget`` attribute to dictate its format. The widget should be a field formatter, of which the most interesting are ``date``, ``datetime``, ``float_time``, and ``monetary``."
msgid "QWeb views are standard :ref:`reference/qweb` templates inside a view's ``arch``. They don't have a specific root element. Because QWeb views don't have a specific root element, their type must be specified explicitly (it can not be inferred from the root element of the ``arch`` field)."
msgid "they can be used as actual qweb views (opened inside an action), in which case they should be defined as regular view with an explicit ``type`` (it can not be inferred) and a model."
msgid "qweb-as-view has a special case for a ``<nav>`` element bearing the CSS class ``o_qweb_cp_buttons``: its contents should be buttons and will be extracted and moved to the control panel's button area, the ``<nav>`` itself will be removed, this is a work-around to control panel views not existing yet"
msgid "a lazy proxy to ``model.search(domain)``, this can be used if you just want to iterate the records and not perform more complex operations (e.g. grouping)"
msgid "``qweb_render_view(view_id, domain)`` is the method called by the client and will call the context-preparation methods and ultimately ``env['ir.qweb'].render()``."
msgid "Search views are a break from previous view types in that they don't display *content*: although they apply to a specific model, they are used to filter other view's content (generally aggregated views e.g. :ref:`reference/views/list` or :ref:`reference/views/graph`). Beyond that difference in use case, they are defined the same way."
msgid "fields define domains or contexts with user-provided values. When search domains are generated, field domains are composed with one another and with filters using **AND**."
msgid "by default, fields generate domains of the form :samp:`[({name}, {operator}, {provided_value})]` where ``name`` is the field's name and ``provided_value`` is the value provided by the user, possibly filtered or transformed (e.g. a user is expected to provide the *label* of a selection field's value, not the value itself)."
msgid "The ``operator`` attribute allows overriding the default operator, which depends on the field's type (e.g. ``=`` for float fields but ``ilike`` for char fields)"
msgid "complete domain to use as the field's search domain, can use a ``self`` variable to inject the provided value in the custom domain. Can be used to generate significantly more flexible domains than ``operator`` alone (e.g. searches on multiple fields at once)"
msgid "allows adding context keys, including the user-provided values (which as for ``domain`` are available as a ``self`` variable, an array of values e.g. ``[id_1, id_2]`` for a :class:`~odoo.fields.Many2one` field). By default, fields don't generate domains."
msgid "the domain and context are inclusive and both are generated if a ``context`` is specified. To only generate context values, set ``filter_domain`` to an empty list: ``filter_domain=\"[]\"``"
msgid "a filter is a predefined toggle in the search view, it can only be enabled or disabled. Its main purposes are to add data to the search context (the context passed to the data view for searching/filtering), or to append new sections to the search filter."
msgid "the name of a field of type ``date`` or ``datetime``. Using this attribute has the effect to create a set of filters available in a submenu of the filters menu. The filters proposed are time dependent but not dynamic in the sense that their domains are evaluated at the time of the control panel instantiation."
msgid "The example above allows to easily search for records with creation date field values in one of the periods below (if the current month is August 2019)."
msgid "only makes sense for a filter with non empty ``date`` attribute. determines which period is activated if the filter is in the default set of filters activated at the view initialization. If not provided, 'this_month' is used by default."
msgid "When the field is of type ``date`` or ``datetime``, the filter generates a submenu of the Group By menu in which the following interval options are available: day, week, month, quarter, year."
msgid "In case the filter is in the default set of filters activated at the view initialization, the records are grouped by month by default. This can be changed by using the syntax 'date_field:interval' as in the following example."
msgid "The results of read_groups grouped on a field may be influenced by its group_expand attribute, allowing to display empty groups when needed. For more information, please refer to :class:`~odoo.fields.Field` attributes documentation."
msgid "logical name for the filter, can be used to :ref:`enable it by default <reference/views/search/defaults>`, can also be used as :ref:`inheritance hook <reference/views/inheritance>`"
msgid "Sequences of filters (without non-filters separating them) are treated as inclusively composited: they will be composed with ``OR`` rather than the usual ``AND``, e.g."
msgid "allows to display a search panel on the left of any multi records view. By default, the list and kanban views have the searchpanel enabled. The search panel can be activated on other views with the attribute:"
msgid "This tool allows to quickly filter data on the basis of given fields. The fields are specified as direct children of the ``searchpanel`` with tag name ``field``, and the following attributes:"
msgid "Another way to solve performance issues is to properly override the ``search_panel_select_range`` and ``search_panel_select_multi_range`` methods."
msgid "``limit``: default is 200. Integer determining the maximal number of values to fetch for the field. If the limit is reached, no values will be displayed in the search panel and an error message will appear instead because we consider that is useless / bad performance-wise. All values will be fetched if set to 0."
msgid "A domain might be used to express a dependency on another field (with select=\"one\") of the search panel. Consider /!\\ This attribute is incompatible with a select=\"one\" with enabled counters; if a select=\"multi\" has a `domain` attribute, all select=\"one\" will have their counters disabled."
msgid "In the above example, the range of values for manager_id (manager names) available at screen will depend on the value currently selected for the field ``department_id``."
msgid "Search fields and filters can be configured through the action's ``context`` using :samp:`search_default_{name}` keys. For fields, the value should be the value to set in the field, for filters it's a boolean value or a number. For instance, assuming ``foo`` is a field and ``bar`` is a filter an action context of:"
msgid "A numeric value (between 1 and 99) can be used to describe the order of default groupbys. For instance if ``foo`` and ``bar`` refer to two groupbys"
msgid "There are many ways to solve a problem in JavaScript, and in Odoo. However, the Odoo framework was designed to be extensible (this is a pretty big constraint), and some common problems have a nice standard solution. The standard solution has probably the advantage of being easy to understand for an odoo developer, and will probably keep working when Odoo is modified."
msgid "This document tries to explain the way one could solve some of these issues. Note that this is not a reference. This is just a random collection of recipes, or explanations on how to proceed in some cases."
msgid "First of all, remember that the first rule of customizing odoo with JS is: *try to do it in python*. This may seem strange, but the python framework is quite extensible, and many behaviours can be done simply with a touch of xml or python. This has usually a lower cost of maintenance than working with JS:"
msgid "it is often more difficult to implement a customized behaviour if it needs to communicate with the server and properly integrate with the javascript framework. There are many small details taken care by the framework that customized code needs to replicate. For example, responsiveness, or updating the url, or displaying data without flickering."
msgid "This document does not really explain any concepts. This is more a cookbook. For more details, please consult the javascript reference page (see :doc:`javascript_reference`)"
msgid "This is probably a really common usecase: we want to display some information in a form view in a really specific (maybe business dependent) way. For example, assume that we want to change the text color depending on some business condition."
msgid "This can be done in three steps: creating a new widget, registering it in the field registry, then adding the widget to the field in the form view"
msgid "Note that only the form, list and kanban views use this field widgets registry. These views are tightly integrated, because the list and kanban views can appear inside a form view)."
msgid "Another use case is that we want to modify an existing field widget. For example, the voip addon in odoo need to modify the FieldPhone widget to add the possibility to easily call the given number on voip. This is done by *including* the FieldPhone widget, so there is no need to change any existing form view."
msgid "Another common usecase is the need to customize some elements from the user interface. For example, adding a message in the home menu. The usual process in this case is again to *include* the widget. This is the only way to do it, since there are no registries for those widgets."
msgid "Creating a new view is a more advanced topic. This cheatsheet will only highlight the steps that will probably need to be done (in no particular order):"
msgid "we need a view (a subclass of ``AbstractView``, this is the factory), a renderer (from ``AbstractRenderer``), a controller (from ``AbstractController``) and a model (from ``AbstractModel``). I suggest starting by simply extending the superclasses:"
msgid "The ``View`` class needs to parse the ``arch`` field and setup the other three classes. The ``Renderer`` is in charge of representing the data in the user interface, the ``Model`` is supposed to talk to the server, to load data and process it. And the ``Controller`` is there to coordinate, to talk to the web client, ..."
msgid "Assume we need to create a custom version of a generic view. For example, a kanban view with some extra *ribbon-like* widget on top (to display some specific custom information). In that case, this can be done with 3 steps: extend the kanban view (which also probably mean extending controllers/renderers and/or models), then registering the view in the view registry, and finally, using the view in the kanban arch (a specific example is the helpdesk dashboard)."
msgid "we now need to inform the web client that a specific ``ir.ui.view`` needs to use our new class. Note that this is a web client specific concern. From the point of view of the server, we still have a kanban view. The proper way to do this is by using a special attribute ``js_class`` (which will be renamed someday into ``widget``, because this is really not a good name) on the root node of the arch:"
msgid "Note: you can change the way the view interprets the arch structure. However, from the server point of view, this is still a view of the same base type, subjected to the same rules (rng validation, for example). So, your views still need to have a valid arch field."
msgid "For a very good and complete introduction to promises, please read this excellent article https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async%20%26%20performance/ch3.md"
msgid "Suppose that in a function you must do a rpc, and when it is completed set the result on this. The `this._rpc` is a function that returns a `Promise`."
msgid "Suppose that you were using a function `this.close` that takes as parameter a callback that is called when the closing is finished. Now suppose that you are doing that in a method that must send a promise that is resolved when the closing is finished."
msgid "line 3: we create and return a new promise. The constructor of a promise takes a function as parameter. This function itself has 2 parameters that we called here `resolve` and `reject`"
msgid "line 4: we are calling the function close on our object. It takes a function as parameter (the callback) and it happens that resolve is already a function, so we can pass it directly. To be clearer, we could have written:"
msgid "if you have multiple promises that all need to be waited, you can convert them into a single promise that will be resolved when all the promises are resolved using Promise.all(arrayOfPromises)."
msgid "If you have an asynchronous process that you want to wait to do something, but you also want to return to the caller before that something is done."
msgid "The general idea is that a promise should not be rejected for control flow, but should only be rejected for errors. When that is the case, you would have multiple resolutions of your promise with, for instance status codes that you would have to check in the `then` handlers and a single `catch` handler at the end of the promise chain."
msgid "In Odoo, it happens that we use promise rejection for control flow, like in mutexes and other concurrency primitives defined in module `web.concurrency` We also want to execute the catch for *business* reasons, but not when there is a coding error in the definition of the promise or of the handlers. For this, we have introduced the concept of `guardedCatch`. It is called like `catch` but not when the rejected reason is an error"
msgid "In the tests code, we support the latest version of Javascript, including primitives like `async` and `await`. This makes using and waiting for promises very easy. Most helper methods also return a promise (either by being marked `async` or by returning a promise directly."
msgid "This document presents the Odoo Javascript framework. This framework is not a large application in term of lines of code, but it is quite generic, because it is basically a machine to turn a declarative interface description into a live application, able to interact with every model and records in the database. It is even possible to use the web client to modify the interface of the web client."
msgid "the *web client*: this is the private web application, where one can view and edit business data. This is a single page application (the page is never reloaded, only the new data is fetched from the server whenever it is needed)"
msgid "the *website*: this is the public part of Odoo. It allows an unidentified user to browse some content, to shop or to perform many actions, as a client. This is a classical website: various routes with controllers and some javascript to make it work."
msgid "Some javascript code is common to these three use cases, and is bundled together (see below in the assets section). This document will focus mostly on the web client design."
msgid "In short, the *webClient*, instance of *WebClient* is the root component of the whole user interface. Its responsibility is to orchestrate all various subcomponents, and to provide services, such as rpcs, local storage and more."
msgid "In runtime, the web client is a single page application. It does not need to request a full page from the server each time the user perform an action. Instead, it only requests what it needs, and then replaces/updates the view. Also, it manages the url: it is kept in sync with the web client state."
msgid "It means that while a user is working on Odoo, the web client class (and the action manager) actually creates and destroys many sub components. The state is highly dynamic, and each widget could be destroyed at any time."
msgid "Here, we give a very quick overview on the web client code, in the *web/static/src/js* addon. Note that it is deliberately not exhaustive. We only cover the most important files/folders."
msgid "*core/*: this is a collection of lower level building blocks. Notably, it contains the class system, the widget system, concurrency utilities, and many other class/functions."
msgid "*chrome/abstract_web_client.js* and *chrome/web_client.js*: together, these files define the WebClient widget, which is the root widget for the web client."
msgid "*chrome/search_X.js* all these files define the search view (it is not a view in the point of view of the web client, only from the server point of view)"
msgid "Managing assets in Odoo is not as straightforward as it is in some other apps. One of the reason is that we have a variety of situations where some, but not all the assets are required. For example, the needs of the web client, the point of sale, the website or even the mobile application are different. Also, some assets may be large, but are seldom needed. In that case, we sometimes want them to be loaded lazily."
msgid "The main idea is that we define a set of *bundles* in xml. A bundle is here defined as a collection of files (javascript, css, scss). In Odoo, the most important bundles are defined in the file *addons/web/views/webclient_templates.xml*. It looks like this:"
msgid "all the *scss* files described in the bundle are compiled into css files. A file named *file.scss* will be compiled in a file named *file.scss.css*."
msgid "When the Odoo server is started, it checks the timestamp of each file in a bundle, and if necessary, will create/recreate the corresponding bundles."
msgid "*web.assets_common*: this bundle contains most assets which are common to the web client, the website, and also the point of sale. This is supposed to contain lower level building blocks for the odoo framework. Note that it contains the *boot.js* file, which defines the odoo module system."
msgid "The proper way to add a file located in *addons/web* to a bundle is simple: it is just enough to add a *script* or a *stylesheet* tag to the bundle in the file *webclient_templates.xml*. But when we work in a different addon, we need to add a file from that addon. In that case, it should be done in three steps:"
msgid "Note that the files in a bundle are all loaded immediately when the user loads the odoo web client. This means that the files are transferred through the network every time (except when the browser cache is active). In some cases, it may be better to lazyload some assets. For example, if a widget requires a large library, and that widget is not a core part of the experience, then it may be a good idea to only load the library when the widget is actually created. The widget class has actually builtin support just for this use case. (see section :ref:`reference/javascript_reference/qweb`)"
msgid "once the server is started, it does not know if an asset file has been modified. So, you can simply restart the server to regenerate the assets."
msgid "use the *debug=assets* mode. This will actually bypass the asset bundles (note that it does not actually solve the issue. The server still uses outdated bundles)"
msgid "finally, the most convenient way to do it, for a developer, is to start the server with the *--dev=all* option. This activates the file watcher options, which will automatically invalidate assets when necessary. Note that it does not work very well if the OS is Windows."
msgid "Once an asset file has been recreated, you need to refresh the page, to reload the proper files (if that does not work, the files may be cached)."
msgid "Once we are able to load our javascript files into the browser, we need to make sure they are loaded in the correct order. In order to do that, Odoo has defined a small module system (located in the file *addons/web/static/src/js/boot.js*, which needs to be loaded first)."
msgid "The Odoo module system, inspired by AMD, works by defining the function *define* on the global odoo object. We then define each javascript module by calling that function. In the Odoo framework, a module is a piece of code that will be executed as soon as possible. It has a name and potentially some dependencies. When its dependencies are loaded, a module will then be loaded as well. The value of the module is then the return value of the function defining the module."
msgid "If some dependencies are missing/non ready, then the module will simply not be loaded. There will be a warning in the console after a few seconds."
msgid "*moduleName*: the name of the javascript module. It should be a unique string. The convention is to have the name of the odoo addon followed by a specific description. For example, 'web.Widget' describes a module defined in the *web* addon, which exports a *Widget* class (because the first letter is capitalized)"
msgid "*dependencies*: the second argument is optional. If given, it should be a list of strings, each corresponding to a javascript module. This describes the dependencies that are required to be loaded before the module is executed. If the dependencies are not explicitly given here, then the module system will extract them from the function by calling toString on it, then using a regexp to find all *require* statements."
msgid "finally, the last argument is a function which defines the module. Its return value is the value of the module, which may be passed to other modules requiring it. Note that there is a small exception for asynchronous modules, see the next section."
msgid "``Missing dependencies``: These modules do not appear in the page. It is possible that the JavaScript file is not in the page or that the module name is wrong"
msgid "It can happen that a module needs to perform some work before it is ready. For example, it could do a rpc to load some data. In that case, the module can simply return a promise. In that case, the module system will simply wait for the promise to complete before registering the module."
msgid "declare all your dependencies at the top of the module. Also, they should be sorted alphabetically by module name. This makes it easier to understand your module."
msgid "asynchronous modules can be used to simplify some use cases. For example, the *web.dom_ready* module returns a promise which will be resolved when the dom is actually ready. So, another module that needs the DOM could simply have a `require('web.dom_ready')` statement somewhere, and the code will only be executed when the DOM is ready."
msgid "Odoo was developed before ECMAScript 6 classes were available. In Ecmascript 5, the standard way to define a class is to define a function and to add methods on its prototype object. This is fine, but it is slightly complex when we want to use inheritance, mixins."
msgid "For these reasons, Odoo decided to use its own class system, inspired by John Resig. The base Class is located in *web.Class*, in the file *class.js*."
msgid "Let us discuss how classes are created. The main mechanism is to use the *extend* method (this is more or less the equivalent of *extend* in ES6 classes)."
msgid "In this example, the *init* function is the constructor. It will be called when an instance is created. Making an instance is done by using the *new* keyword."
msgid "It is convenient to be able to inherit an existing class. This is simply done by using the *extend* method on the superclass. When a method is called, the framework will secretly rebind a special method: *_super* to the currently called method. This allows us to use *this._super* whenever we need to call a parent method."
msgid "The odoo Class system does not support multiple inheritance, but for those cases when we need to share some behaviour, we have a mixin system: the *extend* method can actually take an arbitrary number of arguments, and will combine all of them in the new class."
msgid "It is not common, but we sometimes need to modify another class *in place*. The goal is to have a mechanism to change a class and all future/present instances. This is done by using the *include* method:"
msgid "This is obviously a dangerous operation and should be done with care. But with the way Odoo is structured, it is sometimes necessary in one addon to modify the behavior of a widget/class defined in another addon. Note that it will modify all instances of the class, even if they have already been created."
msgid "The *Widget* class is really an important building block of the user interface. Pretty much everything in the user interface is under the control of a widget. The Widget class is defined in the module *web.Widget*, in *widget.js*."
msgid "For this example, assume that the template *some.template* (and is properly loaded: the template is in a file, which is properly defined in the *qweb* key in the module manifest) is given by:"
msgid "This example illustrates a few of the features of the *Widget* class, including the event system, the template system, the constructor with the initial *parent* argument."
msgid "Like many component systems, the widget class has a well defined lifecycle. The usual lifecycle is the following: *init* is called, then *willStart*, then the rendering takes place, then *start* and finally *destroy*."
msgid "this is the constructor. The init method is supposed to initialize the base state of the widget. It is synchronous and can be overridden to take more parameters from the widget's creator/parent"
msgid "this method will be called once by the framework when a widget is created and in the process of being appended to the DOM. The *willStart* method is a hook that should return a promise. The JS framework will wait for this promise to complete before moving on to the rendering step. Note that at this point, the widget does not have a DOM root element. The *willStart* hook is mostly useful to perform some asynchronous work, such as fetching data from the server"
msgid "This step is automatically done by the framework. What happens is that the framework checks if a template key is defined on the widget. If that is the case, then it will render that template with the *widget* key bound to the widget in the rendering context (see the example above: we use *widget.count* in the QWeb template to read the value from the widget). If no template is defined, we read the *tagName* key and create a corresponding DOM element. When the rendering is done, we set the result as the $el property of the widget. After this, we automatically bind all events in the events and custom_events keys."
msgid "when the rendering is complete, the framework will automatically call the *start* method. This is useful to perform some specialized post-rendering work. For example, setting up a library."
msgid "This is always the final step in the life of a widget. When a widget is destroyed, we basically perform all necessary cleanup operations: removing the widget from the component tree, unbinding all events, ..."
msgid "Automatically called when the widget's parent is destroyed, must be called explicitly if the widget has no parent or if it is removed but its parent remains."
msgid "Note that the willStart and start method are not necessarily called. A widget can be created (the *init* method will be called) and then destroyed (*destroy* method) without ever having been appended to the DOM. If that is the case, the willStart and start will not even be called."
msgid "Used if the widget has no template defined. Defaults to ``div``, will be used as the tag name to create the DOM element to set as the widget's DOM root. It is possible to further customize this generated DOM root with the following attributes:"
msgid "Used to generate an ``id`` attribute on the generated DOM root. Note that this is rarely needed, and is probably not a good idea if a widget can be used more than once."
msgid "Used to generate a ``class`` attribute on the generated DOM root. Note that it can actually contain more than one css class: *'some-class other-class'*"
msgid "Mapping (object literal) of attribute names to attribute values. Each of these k:v pairs will be set as a DOM attribute on the generated DOM root."
msgid "Should be set to the name of a :ref:`QWeb template <reference/qweb>`. If set, the template will be rendered after the widget has been initialized but before it has been started. The root element generated by the template will be set as the DOM root of the widget."
msgid "List of paths to xml files that need to be loaded before the widget can be rendered. This will not induce loading anything that has already been loaded. This is useful when you want to load your templates lazily, or if you want to share a widget between the website and the web client interface."
msgid "Events are a mapping of an event selector (an event name and an optional CSS selector separated by a space) to a callback. The callback can be the name of a widget's method or a function object. In either case, the ``this`` will be set to the widget:"
msgid "The selector is used for jQuery's event delegation, the callback will only be triggered for descendants of the DOM root matching the selector. If the selector is left out (only an event name is specified), the event will be set directly on the widget's DOM root."
msgid "this is almost the same as the *events* attribute, but the keys are arbitrary strings. They represent business events triggered by some sub widgets. When an event is triggered, it will 'bubble up' the widget tree (see the section on component communication for more details)."
msgid "Re-sets the widget's DOM root to the provided element, also handles re-setting the various aliases of the DOM root as well as unsetting and re-setting delegated events."
msgid "All of these methods accept whatever the corresponding jQuery method accepts (CSS selectors, DOM nodes or jQuery objects). They all return a promise and are charged with three tasks:"
msgid "Identifiers (``id`` attribute) should be avoided. In generic applications and modules, ``id`` limits the re-usability of components and tends to make code more brittle. Most of the time, they can be replaced with nothing, classes or keeping a reference to a DOM node or jQuery element."
msgid "If an ``id`` is absolutely necessary (because a third-party library requires one), the id should be partially generated using ``_.uniqueId()`` e.g.:"
msgid "Avoid predictable/common CSS class names. Class names such as \"content\" or \"navigation\" might match the desired meaning/semantics, but it is likely an other developer will have the same need, creating a naming conflict and unintended behavior. Generic class names should be prefixed with e.g. the name of the component they belong to (creating \"informal\" namespaces, much as in C or Objective-C)."
msgid "Global selectors should be avoided. Because a component may be used several times in a single page (an example in Odoo is dashboards), queries should be restricted to a given component's scope. Unfiltered selections such as ``$(selector)`` or ``document.querySelectorAll(selector)`` will generally lead to unintended or incorrect behavior. Odoo Web's :class:`~Widget` has an attribute providing its DOM root (:attr:`~Widget.$el`), and a shortcut to select nodes directly (:func:`~Widget.$`)."
msgid "More generally, never assume your components own or controls anything beyond its own personal :attr:`~Widget.$el` (so, avoid using a reference to the parent widget)"
msgid "All interactive components (components displaying information to the screen or intercepting DOM events) must inherit from :class:`~Widget` and correctly implement and use its API and life cycle."
msgid "The web client uses the :doc:`qweb` template engine to render widgets (unless they override the *renderElement* method to do something else). The Qweb JS template engine is based on XML, and is mostly compatible with the python implementation."
msgid "Now, let us explain how the templates are loaded. Whenever the web client starts, a rpc is made to the */web/webclient/qweb* route. The server will then return a list of all templates defined in data files for each installed modules. The correct files are listed in the *qweb* entry in each module manifest."
msgid "This mechanism works quite well for our needs, but sometimes, we want to lazy load a template. For example, imagine that we have a widget which is rarely used. In that case, maybe we prefer to not load its template in the main file, in order to make the web client slightly lighter. In that case, we can use the *xmlDependencies* key of the Widget:"
msgid "With this, the *Counter* widget will load the xmlDependencies files in its *willStart* method, so the template will be ready when the rendering is performed."
msgid "There are currently two event systems supported by Odoo: a simple system which allows adding listeners and triggering events, and a more complete system that also makes events 'bubble up'."
msgid "Both of these event systems are implemented in the *EventDispatcherMixin*, in the file *mixins.js*. This mixin is included in the *Widget* class."
msgid "the use of this event system is discouraged, we plan to replace each *trigger* method by the *trigger_up* method from the extended event system"
msgid "The custom event widgets is a more advanced system, which mimic the DOM events API. Whenever an event is triggered, it will 'bubble up' the component tree, until it reaches the root widget, or is stopped."
msgid "*trigger_up*: this is the method that will create a small *OdooEvent* and dispatch it in the component tree. Note that it will start with the component that triggered the event"
msgid "The OdooEvent class is very simple. It has three public attributes: *target* (the widget that triggered the event), *name* (the event name) and *data* (the payload). It also has 2 methods: *stopPropagation* and *is_stopped*."
msgid "A common need in the Odoo ecosystem is to extend/change the behaviour of the base system from the outside (by installing an application, i.e. a different module). For example, one may need to add a new widget type in some views. In that case, and many others, the usual process is to create the desired component, then add it to a registry (registering step), to make the rest of the web client aware of its existence."
msgid "The field registry contains all field widgets known to the web client. Whenever a view (typically form or list/kanban) needs a field widget, this is where it will look. A typical use case look like this:"
msgid "This registry contains all JS views known to the web client (and in particular, the view manager). Each value of this registry should be a subclass of *AbstractView*."
msgid "We keep track of all client actions in this registry. This is where the action manager looks up whenever it needs to create a client action. In version 11, each value should simply be a subclass of *Widget*. However, in version 12, the values are required to be *AbstractAction*."
msgid "In this case, the widget's job is simply to notify its environment that something happened. Since we do not want the widget to have a reference to its parent (this would couple the widget with its parent's implementation), the best way to proceed is usually to trigger an event, which will bubble up the component tree, by using the ``trigger_up`` method:"
msgid "Cross component communication can be achieved by using a bus. This is not the preferred form of communication, because it has the disadvantage of making the code harder to maintain. However, it has the advantage of decoupling the components. In that case, this is simply done by triggering and listening to events on a bus. For example:"
msgid "In version 11.0, we introduced the notion of *service*. The main idea is to give to sub components a controlled way to access their environment, in a way that allow the framework enough control, and which is testable."
msgid "The service system is organized around three ideas: services, service providers and widgets. The way it works is that widgets trigger (with *trigger_up*) events, these events bubble up to a service provider, which will ask a service to perform a task, then maybe return an answer."
msgid "A service is an instance of the *AbstractService* class. It basically only has a name and a few methods. Its job is to perform some work, typically something depending on the environment."
msgid "For example, we have the *ajax* service (job is to perform a rpc), the *localStorage* (interact with the browser local storage) and many others."
msgid "For services to work, it is necessary that we have a service provider ready to dispatch the custom events. In the *backend* (web client), this is done by the main web client instance. Note that the code for the service provider comes from the *ServiceProviderMixin*."
msgid "The widget is the part that requests a service. In order to do that, it simply triggers an event *call_service* (typically by using the helper function *call*). This event will bubble up and communicate the intent to the rest of the system."
msgid "In practice, some functions are so frequently called that we have some helpers functions to make them easier to use. For example, the *_rpc* method is a helper that helps making a rpc."
msgid "If a widget is destroyed, it will be detached from the main component tree and will not have a parent. In that case, the events will not bubble up, which means that the work will not be done. This is usually exactly what we want from a destroyed widget."
msgid "There are typically two usecases when working on Odoo: one may need to call a method on a (python) model (this goes through a controller *call_kw*), or one may need to directly call a controller (available on some route)."
msgid "The Odoo framework has a standard way to communicate various information to the user: notifications, which are displayed on the top right of the user interface."
msgid "Also, notifications can be used to ask a question to the user without disturbing its workflow. Imagine a phone call received through VOIP: a sticky notification could be displayed with two buttons *Accept* and *Decline*."
msgid "a *NotificationService*: a service whose responsibility is to create and destroy notifications whenever a request is done (with a custom_event). Note that the web client is a service provider."
msgid "a client action *display_notification*: this allows to trigger the display of a notification from python (e.g. in the method called when the user clicked on a button of type object)."
msgid "*sticky*: boolean, optional. If true, the notification will stay until the user dismisses it. Otherwise, the notification will be automatically closed after a short delay."
msgid "*className*: string, optional. This is a css class name that will be automatically added to the notification. This could be useful for styling purpose, even though its use is discouraged."
msgid "There is currently no specific API for systray widgets. They are supposed to be simple widgets, and can communicate with their environment just like other widgets with the *trigger_up* method."
msgid "Before adding the widget to himself, the Systray Menu will sort the items by a sequence property. If that property is not present on the prototype, it will use 50 instead. So, to position a systray item to be on the right, one can set a very high sequence number (and conversely, a low number to put it on the left)."
msgid "Some translations are made on the server side (basically all text strings rendered or processed by the server), but there are strings in the static files that need to be translated. The way it currently works is the following:"
msgid "in runtime, whenever the function *_t* is called, it will look up in this list in order to find a translation, and return it or the original string if none is found."
msgid "There is a specific module provided by the web client which contains some information specific to the user current *session*. Some notable keys are"
msgid "When the /web route is loaded, the server will inject some session information in the template a script tag. The information will be read from the method *session_info* of the model *ir.http*. So, if one wants to add a specific information, it can be done by overriding the session_info method and adding it to the dictionary."
msgid "Note that this mechanism is designed to reduce the amount of communication needed by the web client to be ready. It is more appropriate for data which is cheap to compute (a slow session_info call will delay the loading for the web client for everyone), and for data which is required early in the initialization process."
msgid "The word 'view' has more than one meaning. This section is about the design of the javascript code of the views, not the structure of the *arch* or anything else."
msgid "Views (in a generic sense) are now described with 4 pieces: a View, a Controller, a Renderer and a Model. The API of these 4 pieces is described in the AbstractView, AbstractController, AbstractRenderer and AbstractModel classes."
msgid "the View is the factory. Its job is to get a set of fields, arch, context and some other parameters, then to construct a Controller/Renderer/Model triplet."
msgid "The view's role is to properly setup each piece of the MVC pattern, with the correct information. Usually, it has to process the arch string and extract the data necessary for each other parts of the view."
msgid "the Renderer has one job: representing the data being viewed in a DOM element. Each view can render the data in a different way. Also, it should listen on appropriate user actions and notify its parent (the Controller) if necessary."
msgid "the Model: its job is to fetch and hold the state of the view. Usually, it represents in some way a set of records in the database. The Model is the owner of the 'business data'. It is the M in the MVC pattern."
msgid "the Controller: its job is to coordinate the renderer and the model. Also, it is the main entry point for the rest of the web client. For example, when the user changes something in the search view, the *update* method of the controller will be called with the appropriate information."
msgid "The JS code for the views has been designed to be usable outside of the context of a view manager/action manager. They could be used in a client action, or, they could be displayed in the public website (with some work on the assets)."
msgid "A good part of the web client experience is about editing and creating data. Most of that work is done with the help of field widgets, which are aware of the field type and of the specific details on how a value should be displayed and edited."
msgid "the widgets are shared between all views (well, Form/List/Kanban). No need to duplicate the implementation anymore. Note that it is possible to have a specialized version of a widget for a view, by prefixing it with the view name in the view registry: *list.many2one* will be chosen in priority over *many2one*."
msgid "the widgets do no longer need to be able to switch between edit and readonly mode. Now, when such a change is necessary, the widget will be destroyed and rerendered again. It is not a problem, since they do not own their value anyway"
msgid "Like the list view, field widgets have a simple support for decorations. The goal of decorations is to have a simple way to specify a text color depending on the record current state. For example,"
msgid "Each decoration *decoration-X* will be mapped to a css class *text-X*, which is a standard bootstrap css class (except for *text-it* and *text-bf*, which are handled by odoo and correspond to italic and bold, respectively). Note that the value of the decoration attribute should be a valid python expression, which will be evaluated with the record as evaluation context."
msgid "On edit mode, the field is rendered as an input with the HTML attribute type set on *number* (so user can benefit the native support, especially on mobile). In this case, the default formatting is disabled to avoid incompability."
msgid "The goal of this widget is to display properly a float value that represents a time interval (in hours). So, for example, 0.5 should be formatted as 0:30, or 4.75 correspond to 4:45."
msgid "This widget aims to display properly a float value that converted using a factor given in its options. So, for example, the value saved in database is 0.5 and the factor is 3, the widget value should be formatted as 1.5."
msgid "The goal of this widget is to replace the input field by a button containing a range of possible values (given in the options). Each click allows the user to loop in the range. The purpose here is to restrict the field value to a predefined selection. Also, the widget support the factor conversion as the *float_factor* widget (Range values should be the result of the conversion)."
msgid "This is the default field type for fields of type *date*. Note that it also works with datetime fields. It uses the session timezone when formatting dates."
msgid "This widget can be used on date and datetime fields. In readonly, it displays the delta (in days) between the value of the field and today. The widget is intended to be used for informative purpose: therefore the value cannot be modified in edit mode."
msgid "This is the default field type for fields of type 'monetary'. It is used to display a currency. If there is a currency fields given in option, it will use that, otherwise it will fall back to the default currency (in the session)"
msgid "This field displays a phone number. The main reason to use it is that it is rendered as an anchor tag with the proper href, in readonly mode, but only in some cases: we only want to make it clickable if the device can call this particular number."
msgid "This field displays an url (in readonly mode). The main reason to use it is that it is rendered as an anchor tag with the proper css classes and href."
msgid "The \"Domain\" field allows the user to construct a technical-prefix domain thanks to a tree-like interface and see the selected records in real time. In debug mode, an input is also there to be able to enter the prefix char domain directly (or to build advanced domains the tree-like interface does not allow to)."
msgid "The LinkButton widget actually simply displays a span with an icon and the text value as content. The link is clickable and will open a new browser window with its value as url."
msgid "This widget is used to represent a binary value as an image. In some cases, the server returns a 'bin_size' instead of the real image (a bin_size is a string representing a file size, such as 6.5kb). In that case, the widget will make an image with a source attribute corresponding to an image on the server."
msgid "preview_image: if the image is only loaded as a 'bin_size', then this option is useful to inform the web client that the default field name is not the name of the current field, but the name of another field."
msgid "accepted_file_extensions: the file extension the user can pick from the file input dialog box (default value is `image/\\*`) (cf: ``accept`` attribute on <input type=\"file\"/>)"
msgid "accepted_file_extensions: the file extension the user can pick from the file input dialog box (cf: ``accept`` attribute on <input type=\"file\"/>)"
msgid "filename: saving a binary file will lose its file name, since it only saves the binary value. The filename can be saved in another field. To do that, an attribute filename should be set to a field present in the view."
msgid "This widget is rendered as a set of stars, allowing the user to click on it to select a value or not. This is useful for example to mark a task as high priority."
msgid "Image widget for many2one fields. If the field is set, this widget will be rendered as an image with the proper src url. This widget does not have a different behaviour in edit or readonly mode, it is only useful to view an image."
msgid "Options: a dictionary with a mapping from a selection value to an object with the url for an image (*image_link*) and a preview image (*preview_link*)."
msgid "This is a specialized selection widget. It assumes that the record has some hardcoded fields, present in the view: *stage_id*, *legend_normal*, *legend_blocked*, *legend_done*. This is mostly used to display and change the state of a task in a project, with additional information displayed in the dropdown."
msgid "The Boolean Button widget is meant to be used in a stat button in a form view. The goal is to display a nice button with the current state of a boolean field (for example, 'Active'), and allow the user to change that field when clicking on it."
msgid "terminology: it can be either 'active', 'archive', 'close' or a customized mapping with the keys *string_true*, *string_false*, *hover_true*, *hover_false*"
msgid "This widget is meant to represent statistical information in a *stat button*. This is similar to a statinfo widget, but the information is represented in a *pie* chart (empty to full). Note that the value is interpreted as a percentage (a number between 0 and 100)."
msgid "This widget is intended to be used on boolean fields. It toggles a button switching between a green bullet / gray bullet. It also set up a tooltip, depending on the value and some options."
msgid "This is a more specialized widget, useful to display a graph representing a set of data. For example, it is used in the accounting dashboard kanban view."
msgid "By default, the badge has a lightgrey background, but it can be customized by using the decoration-X mechanism. For instance, to display a red badge under a given condition:"
msgid "create_name_field: when creating a related record, if this option is set, the value of the *create_name_field* will be filled with the value of the input (default: *name*)"
msgid "always_reload: boolean, default to false. If true, the widget will always do an additional name_get to fetch its name value. This is used for the situations where the name_get method is overridden (please do not do that)"
msgid "Specialization of many2one field for list views. The main reason is that we need to render many2one fields (in readonly mode) as a text, which does not allow opening the related records."
msgid "Specialization of many2one field where the user is allowed to use the native camera to scan a barcode. Then it uses name_search to search this value."
msgid "This widget is only supported on many2one fields pointing to a model which inherits from 'image.mixin'. In readonly, it displays the image of the related record next to its display_name. Note that the display_name isn't a clickable link in this case. In edit, it behaves exactly like the regular many2one."
msgid "This widget is a specialization of the Many2OneAvatar. When the avatar is clicked, we open a chat window with the corresponding user. This widget can only be set on many2one fields pointing to the 'res.users' model."
msgid "This field displays a list of checkboxes and allows the user to select a subset of the choices. Note that the number of displayed values is limited to 100. This limit isn't customizable. It simply allows to handle extreme cases where this widget is wrongly set on a field with a huge comodel. In those cases, a list view is more adequate as it allows pagination and filtering."
msgid "This is a really specialized widget for the form views. It is the bar on top of many forms which represent a flow, and allow selecting a specific state."
msgid "The FieldReference is a combination of a select (for the model) and a FieldMany2One (for its value). It allows the selection of a record on an arbitrary model."
msgid "The idea of a client action is a customized widget that is integrated in the web client interface, just like a *act_window_action*. This is useful when you need a component that is not closely linked to an existing view or a specific model. For example, the Discuss application is actually a client action."
msgid "from the perspective of the web client, it is a widget, which inherit from the class AbstractAction, and is supposed to be registered in the action registry under the corresponding key (from the field char)"
msgid "Whenever a menu item is associated to a client action, opening it will simply fetch the action definition from the server, then lookup into its action registry to get the Widget definition at the appropriate key, and finally, it will instantiate and append the widget to the proper place in the DOM."
msgid "A client action is a widget which will control the part of the screen below the menu bar. It can have a control panel, if necessary. Defining a client action can be done in two steps: implementing a new widget, and registering the widget in the action registry."
msgid "Then, to use the client action in the web client, we need to create a client action record (a record of the model ``ir.actions.client``) with the proper ``tag`` attribute:"
msgid "when the ``loadControlPanel`` is set to true, the client action will automatically get the content of a search view or a control panel view. In this case, a model name should be specified like this:"
msgid "The ``updateControlPanel`` is the main method to customize the content in controlpanel. For more information, look into the `control_panel_renderer.js <https://github.com/odoo/odoo/blob/13.0/addons/web/static/src/js/views/control_panel/control_panel_renderer.js#L130>`_ file."
msgid "The application is a combination of **Odoo Web** and **Native Mobile components**. In other words it is a Odoo Web instance loaded inside a native, mobile, WebView container."
msgid "This page documents how you can access mobile native components like Camera, Vibration, Notification and Toast through Odoo Web (via JavaScript). For this, you do not need to be a mobile developer, if you know Odoo JavaScript API you can access all available mobile features."
msgid "Of course, it is a web page that loads on a Mobile Native Web container. But it is integrated in such a way that you can access native resources from your web JavaScript."
msgid "Process time taken by the Native component depends on what you are requesting from the Native resources. For example the Camera or GPS Location."
msgid "A toast provides simple feedback about an operation in a small popup. It only fills the amount of space required for the message and the current activity remains visible and interactive."
msgid "Snackbars provide lightweight feedback about an operation. They show a brief message at the bottom of the screen on mobile or in the lower left corner on larger devices. Snackbars appear above all the other elements on the screen and only one can be displayed at a time."
msgid "A notification is a message you can display to the user outside of your application's normal UI. When you tell the system to issue a notification, it first appears as an icon in the notification area. To see the details of the notification, the user opens the notification drawer. Both the notification area and the notification drawer are system-controlled areas that the user can view at any time."
msgid "Dictionary with contact details. Possible keys (name, mobile, phone, fax, email, website, street, street2, country_id, state_id, city, zip, parent_id, function and image)"
msgid "QWeb is the primary templating_ engine used by Odoo\\ [#othertemplates]_. It is an XML templating engine\\ [#genshif]_ and used mostly to generate HTML_ fragments and pages."
msgid "Template directives are specified as XML attributes prefixed with ``t-``, for instance ``t-if`` for :ref:`reference/qweb/conditionals`, with elements and other attributes being rendered directly."
msgid "To avoid element rendering, a placeholder element ``<t>`` is also available, which executes its directive but doesn't generate any output in and of itself::"
msgid "QWeb has a primary output directive which automatically HTML-escape its content limiting XSS_ risks when displaying user-provided content: ``esc``."
msgid "There is one other output directive ``raw`` which behaves the same as respectively ``esc`` but *does not HTML-escape its output*. It can be useful to display separately constructed markup (e.g. from functions) or already sanitized user-provided markup."
msgid "QWeb has an iteration directive ``foreach`` which take an expression returning the collection to iterate on, and a second parameter ``t-as`` providing the name to use for the \"current item\" of the iteration::"
msgid "``foreach`` can iterate on an array (the current item will be the current value) or a mapping (the current item will be the current key). Iterating on an integer (equivalent to iterating on an array between 0 inclusive and the provided integer exclusive) is still supported but deprecated."
msgid "the current iteration value, identical to ``$as`` for lists and integers, but for mappings it provides the value (where ``$as`` provides the key)"
msgid "whether the current item is the last of the iteration (equivalent to :samp:`{$as}_index + 1 == {$as}_size`), requires the iteratee's size be available"
msgid "These extra variables provided and all new variables created into the ``foreach`` are only available in the scope of the``foreach``. If the variable exists outside the context of the ``foreach``, the value is copied at the end of the foreach into the global context."
msgid "QWeb can compute attributes on-the-fly and set the result of the computation on the output node. This is done via the ``t-att`` (attribute) directive which exists in 3 different forms:"
msgid "same as previous, but the parameter is a :term:`format string` instead of just an expression, often useful to mix literal and non-literal string (e.g. classes)::"
msgid "if the parameter is a pair (tuple or array of 2 element), the first item of the pair is the name of the attribute and the second item is the value::"
msgid "QWeb allows creating variables from within the template, to memoize a computation (to use it multiple times), give a piece of data a clearer name, ..."
msgid "QWeb templates can be used for top-level rendering, but they can also be used from within another template (to avoid duplication or give names to parts of templates) using the ``t-call`` directive::"
msgid "However this has the problem of being visible from outside the ``t-call``. Alternatively, content set in the body of the ``call`` directive will be evaluated *before* calling the sub-template, and can alter a local context::"
msgid "The body of the ``call`` directive can be arbitrarily complex (not just ``set`` directives), and its rendered form will be available within the called template as a magical ``0`` variable::"
msgid "The ``t-field`` directive can only be used when performing field access (``a.b``) on a \"smart\" record (result of the ``browse`` method). It is able to automatically format based on field type, and is integrated in the website's rich text editing."
msgid "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:`odoo.http.HttpRequest.render`:"
msgid "name of the Odoo model to use for rendering, can be used to expand or customize QWeb locally (by creating a \"new\" qweb based on ``ir.qweb`` with alterations)"
msgid "It takes no other parameter, but can be used with a ``<t>`` element or any other. With a ``<t>`` element, the ``<t>`` should have a single child."
msgid "The template name is an arbitrary string, although when multiple templates are related (e.g. called sub-templates) it is customary to use dot-separated names to indicate hierarchical relationships."
msgid "``t-inherit-mode`` which is the behaviour of the inheritance: it can either be set to ``primary`` to create a new child template from the parented one or to ``extension`` to alter the parent template in place."
msgid "An optional ``t-name`` directive can also be specified. It will be the name of the newly created template if used in primary mode, else it will be added as a comment on the transformed template to help retrace inheritances."
msgid "For the inheritance itself, the changes are done using xpaths directives. See the XPATH_ documentation for the complete set of available instructions."
msgid "The ``t-jquery`` directives takes a `CSS selector`_. This selector is used on the extended template to select *context nodes* to which the specified ``t-operation`` is applied:"
msgid "the nodes's body should be any number of ``attribute`` elements, each with a ``name`` attribute and some textual content, the named attribute of the context node will be set to the specified value (either replaced if it already existed or added if not)"
msgid "the node's body is javascript code executed during template rendering. Takes a ``context`` parameter, which is the name under which the rendering context will be available in the ``t-js``'s body::"
msgid "(core is the ``web.core`` module) An instance of :js:class:`QWeb2.Engine` with all module-defined template files loaded, and references to standard helper objects ``_`` (underscore), ``_t`` (translation function) and JSON_."
msgid "Odoo Web instantiates one for the user in the core module, and exports it to ``core.qweb``. It also loads all the template files of the various modules into that QWeb instance."
msgid "Renders a previously loaded template to a String, using ``context`` (if provided) to find the variables accessed during template rendering (e.g. strings to display)."
msgid "The engine exposes an other method which may be useful in some cases (e.g. if you need a separate template namespace with, in Odoo Web, Kanban views get their own :js:class:`QWeb2.Engine` instance so their templates don't collide with more general \"module\" templates):"
msgid "Boolean flag putting the engine in \"debug mode\". Normally, QWeb intercepts any error raised during template execution. In debug mode, it leaves all exceptions go through without intercepting them."
msgid "A ``Function``. If present, called before compiling each DOM node to template code. In Odoo Web, this is used to automatically translate text content and some attributes in templates. Defaults to ``null``."
msgid "although it uses a few others, either for historical reasons or because they remain better fits for the use case. Odoo 9.0 still depends on Jinja_ and Mako_."
