msgid "Learn through tutorials and get help using reference guides."
msgstr ""
#: ../../content/developer/glossary.rst:5
msgid "Glossary"
msgstr ""
#: ../../content/developer/glossary.rst:8
msgid "external id"
msgstr ""
#: ../../content/developer/glossary.rst:9
msgid "external identifier"
msgstr ""
#: ../../content/developer/glossary.rst:10
msgid "external identifiers"
msgstr ""
#: ../../content/developer/glossary.rst:12
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 "On installing the `account <https://github.com/odoo/odoo/blob/16.0/addons/account>`_ 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 <https://github.com/odoo/odoo/blob/16.0/addons/l10n_generic_coa>`_ (US) localization module is installed by default. Check `post init hook <https://github.com/odoo/odoo/blob/16.0/addons/account/__init__.py>`_ for details."
msgid "For example, `l10n_ch <https://github.com/odoo/odoo/blob/16.0/addons/l10n_ch>`_ will be installed if the company has ``Switzerland`` as country."
msgid "Recommended **xmlid** for the record is `chart_template`. If you need many chart of accounts, you can add some suffixes, i.e. `chart_template_XXX`."
msgid "Tags are a way to sort accounts. For example, imagine you want to create a financial report having multiple lines but you have no way to find a rule to dispatch the accounts according to their ``code``. The solution is the usage of tags, one for each report line, to filter accounts like you want."
msgid "Obviously, :guilabel:`Chart of Accounts` cannot exist without :guilabel:`Accounts`. You need to specify them in :file:`data/account.account.template.csv`."
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 "Only one account of type payable/receivable is enough for the generic case. We need to define a PoS receivable account as well however. (linked in the CoA)"
msgid "Don't create too many accounts: 200-300 is enough. But mostly, we try to find a good balance where the CoA needs minimal adapting for most companies afterwards."
msgid "Next settings for the chart of accounts are set in a separate file, because we need to provide a :ref:`list of accounts <howtos/account_localization/accounts>` first. In :file:`data/account_chart_post_data.xml`, we set some default accounts:"
msgid "Account groups allow describing the hierarchical structure of the chart of accounts. The filter needs to be activated in the report and then when you decollapse into journal entries it will show the parents of the account."
msgid "It works with the prefix *start*/*end*, so every account where the code starts with something between *start* and *end* will have this account.group as the parent group. Furthermore, the account groups can have a parent account group as well to form the hierarchy."
msgid "To add taxes you first need to specify tax groups. You normally need just one tax group for every tax rate, except for the 0% as you need to often distinguish between exempt, 0%, not subject, ... taxes. This model only has two required fields: *name* and *country*. Create the file :file:`data/account_tax_group_data.xml` and list the groups:"
msgid "Now you can add the taxes via :file:`data/account_tax_template_data.xml` file. The first tax you define that is purchase/sale also becomes the default purchase/sale tax for your products."
msgid "The tax report is declared in the :guilabel:`Invoicing` (`account`) app, but the report is only accessible when :guilabel:`Accounting` (`account_accountant`) is installed."
msgid "In the previous section, you noticed the fields `invoice_repartition_line_ids` or `refund_repartition_line_ids` and probably understood nothing about them. Good news: you are not alone on this incomprehension. Bad news: you have to figure it out a bit. The topic is complicated. Indeed:"
msgid "The simple version is that, in the tax template, you indicate in the invoice/refund repartition lines whether the base or a percentage of the tax needs to be reported in which report line (through the *minus/plus_report_line_ids* fields). It becomes clear also when you check the tax configuration in the Odoo interface (or check the docs :ref:`Tax References <reference/account_tax>`, :ref:`Tax Repartition References <reference/account_tax_repartition>`)."
msgid "So, once you have properly configured taxes, you just need to add the :file:`data/account_tax_report_data.xml` file with a record for your `account.report`. For it to be considered as a tax report, you need to provide it with the right `root_report_id`."
msgid "The last step when installing a localization module is to try to apply its chart of accounts to the current company (if it does not already have one). The file :file:`data/account_chart_template_try_loading.xml` is responsible for that."
msgid "Accounting reports should be added via a separate module `l10n_XX_reports` that should go to the `enterprise repository <https://github.com/odoo/enterprise/blob/16.0>`_."
msgid "If you gave a `root_report_id` to your report, it is now available in its variant selector. If not, you still need to add a menu item for it. A default menu item can be created from the form view of the report by clicking on :menuselection:`Actions --> Create Menu Item`. You will then need to refresh the page to see it. Alternatively, to create a dedicated section for a totally new report in the :guilabel:`Reporting` menu, you need to create a new `ir.ui.menu` record (usually in the main `l10n_XX` module) and a new `ir.actions.client` (usually in the new report XML file) that calls the `account.report` with the new **report id**. Then, set the new menu as `parent_id` field in the action model."
msgid "`ir.actions.client and menu item creation <https://github.com/odoo/enterprise/blob/16.0/l10n_be_reports/data/partner_vat_listing.xml>`_"
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 :doc:`../tutorials/getting_started` tutorial first if needed."
msgstr ""
#: ../../content/developer/howtos/company.rst:13
msgid "As of version 13.0, a user can be logged in to 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 managed correctly, it may be the source of a lot of inconsistent multi-company behaviors. For instance, a user logged in to 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 logs 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 the 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 to companies A and B with A as the main company and creates a record for company B, the value 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 by 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."
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 means 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`."
msgstr ""
#: ../../content/developer/howtos/company.rst:132
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 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 view if the user does not have access to multiple companies. This is assessed 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 contain the current companies of the user (the companies the user checked in the multi-company widget)."
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 "SQL views are a technique for creating customized reports to show data that cannot be shown with existing models' fields and views. In other words, this technique helps avoid unnecessary creation and calculation of additional fields solely for data analysis purposes."
msgid "`_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)"
msgid "Regardless of which way is used, a SQL query will be executed to populate the model. Therefore, any SQL commands can be used to collect and/or calculate the data needed and you are expected to keep in mind that you are bypassing the ORM (i.e. it is a good idea to read through :ref:`reference/security` if you haven't already). The columns returned from the `SELECT` will populate the model's fields, so ensure that your column names match your field names, or use alias names that match."
msgid "In most cases, overriding the `BaseModel.init()` method is the standard and better option to use. It requires the import of `tools` and is typically written as follows:"
msgid "`tools.drop_view_if_exists` ensures that a conflicting view is not created when the SQL query is executed. 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 at minimum, the `_select` and `_from` methods are common, and of course, all these methods will return strings."
msgid "An example of when the property should be used instead of overriding `BaseModel.init()` is in a multi-company and multi-currency environment where currency related amounts need to be converted using currency exchange rates when the user switches between companies."
msgid "Views and menu items for your SQL views are created and used in the same way as any other Odoo model. You are all set to start using your SQL view. Have fun!"
msgid "A common mistake in SQL views is not considering the duplication of certain data due to table JOINs. This can lead to miscounting when using a field's `group_operator` and/or the pivot view. It is best to test your SQL view with sufficient data to ensure the resulting field values are as you expect."
msgid "A client action triggers an action that is entirely implemented in the client side. One of the benefits of using a client action is the ability to create highly customized interfaces with ease. A client action is typically defined by an OWL component; we can also use the web framework and use services, core components, hooks,..."
msgid "Let's take an example where we want to extends the `BooleanField` to create a boolean field displaying \"Late!\" in red whenever the checkbox is checked."
msgid "The component uses a new template with the name `my_module.LateOrderBooleanField`. Create it by inheriting the current template of the `BooleanField`."
msgid "The imported `standardFieldProps` contains the standard props passed by the `View` such as the `update` function to update the value, the `type` of the field in the model, the `readonly` boolean, and others."
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 in a few steps:"
msgid "In our custom kanban, we defined a new template. We can either inherit the kanban controller template and add our template pieces or we can define a completely new template."
msgid "The possibilities for extending views are endless. While we have only extended the controller here, you can also extend the renderer to add new buttons, modify how records are presented, or customize the dropdown, as well as extend other components such as the model and `buttonTemplate`."
msgid "The primary role of a controller is to facilitate the coordination between various components of a view, such as the Renderer, Model, and Layout."
msgid "There are many ways to lean and simplify SCSS. The first step is to establish if custom code is needed at all."
msgstr ""
#: ../../content/developer/howtos/scss_tips.rst:8
msgid "Odoo's webclient has been designed to be modular, meaning that (potentially all) classes can be shared across views. Check the code before creating a new class. Chances are that there is already a class or an HTML tag doing exactly what you're looking for."
msgid "On top of that, Odoo relies on `Bootstrap <https://getbootstrap.com/docs/5.1/getting-started/introduction/>`_ (BS), one of the most complete CSS frameworks available. The framework has been customized in order to match Odoo's design (both community and enterprise versions), meaning that you can use any BS class directly in Odoo and achieve a visual result that is consistent with our UI."
msgid "The fact that a class achieves the desired visual result doesn't necessarily mean that it's the right one for the job. Be aware of classes triggering JS behaviors, for example."
msgid "Be careful about class semantics. Applying a **button class** to a **title** is not only semantically wrong, it may also lead to migration issues and visual inconsistencies."
msgid "By default, each browser renders content using a *user agent stylesheet*. To overcome inconsistencies between browsers, some of these rules are overridden by `Bootstrap Reboot <https://getbootstrap.com/docs/5.1/content/reboot/>`_."
msgid "At this stage all \"browser-specific-decoration\" rules have been stripped away, but a big chunk of rules defining basic layout information is maintained (or reinforced by *Reboot* for consistency reasons)."
msgid "It may seem obvious, but the simplest and most **consistent** way of making text look like a title is to use a header tag (`<h1>`, `<h2>`, ...). Besides reboot rules, mostly all tags carry decorative styles defined by Odoo."
msgid "Besides reducing the amount of code, a modular-design approach (use classes, tags, mixins...) keeps the visual result consistent and easily **maintainable**."
msgid "Following the last example, if Odoo titles' design changes, these changes will be applied in the `o_module_custom_title` element too since it's using an `<h5>` tag."
msgid "Our framework defines a multitude of utility classes designed to cover almost all layout/design/interaction needs. The simple fact that a class already exists justifies its use over custom CSS whenever possible."
msgid "Odoo relies on the default `Bootstrap utility-classes <https://getbootstrap.com/docs/5.1/utilities/background/>`_ stack and defines its own using `Bootstrap API <https://getbootstrap.com/docs/5.1/utilities/api/>`_."
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 "Upgrading to a new version of Odoo can be challenging, especially if the database you work on contains custom modules. This page intent is to explain the technical process of upgrading a database with customized modules. Refer to :doc:`Upgrade documentation </administration/upgrade>` for guidance on how to upgrade a database without customized modules."
msgid "We consider a custom module, any module that extends the standard code of Odoo and that was not built with the Studio app. Before upgrading such a module, or before requesting its upgrade, have a look at the :ref:`upgrade/sla` to make sure who's responsible for it."
msgid "With every new version of Odoo, changes are introduced. These changes can impact modules on which customization have been developed. This is the reason why upgrading a database that contains custom modules requires additional steps in order to upgrade the source code."
msgid "Starting an upgrade requires commitment and development resources. If developments keep being made at the same time, those features will need to be re-upgraded and tested every time you change them. This is why we recommend a complete freeze of the codebase when starting the upgrade process. Needless to say, bug fixing is exempt from this recommendation."
msgid "Once you have stopped development, it is a good practice to assess the developments made and compare them with the features introduced between your current version and the version you are targeting. Challenge the developments as much as possible and find functional workarounds. Removing redundancy between your developments and the standard version of Odoo will lead to an eased upgrade process and reduce technical debt."
msgid "Once the developments have stopped for the custom modules and the implemented features have been challenged to remove redundancy and unnecessary code, the next step is to request an upgraded test database. To do so, follow the steps mentioned in :ref:`upgrade/request-test-database`, depending on the hosting type of your database."
msgid "The purpose of this stage is not to start working with the custom modules in the upgraded database, but to make sure the standard upgrade process works seamlessly, and the test database is delivered properly. If that's not the case, and the upgrade request fails, request the assistance of Odoo via the `support page <https://odoo.com/help?stage=migration>`_ by selecting the option related to testing the upgrade."
msgid "Before working on an upgraded test database, we recommend to make the custom developments work on an empty database in the targeted version of your upgrade. This ensures that the customization is compatible with the new version of Odoo, allows to analyze how it behaves and interacts with the new features, and guarantees that they will not cause any issues when upgrading the database."
msgid "Making the custom modules work in an empty database also helps avoid changes and wrong configurations that might be present in the production database (like studio customization, customized website pages, email templates or translations). They are not intrinsically related to the custom modules and that can raise unwanted issues in this stage of the upgrade process."
msgid "The first step is to make the custom modules installable in the new Odoo version. This means, starting by ensuring there are no tracebacks or warnings during their installation. For this, install the custom modules, one by one, in an empty database of the new Odoo version and fix the tracebacks and warnings that arise from that."
msgid "Once there are no more tracebacks when installing the modules, the next step is to test them. Even if the custom modules are installable on an empty database, this does not guarantee there are no errors during their execution. Because of this, we encourage to test thoroughly all the customization to make sure everything is working as expected."
msgid "This process will help detect further issues that are not identified during the module installation and can only be detected in runtime. For example, deprecated calls to standard python or OWL functions, non-existing references to standard fields, etc."
msgid "We also encourage to write automated tests to save time during the testing iterations, increase the test coverage, and ensure that the changes and fixes introduced do not break the existing flows. If there are tests already implemented in the customization, make sure they are upgraded to the new Odoo version and run successfully, fixing issues that might be present."
msgid "Once the previous steps are completed, we advise to make sure all standard tests associated to the dependencies of the custom module pass. Standard tests ensure the validation of the code logic and prevent data corruption. They will help you identify bugs or unwanted behavior before you work on your database."
msgid "Once the custom modules are installable and working properly in an empty database, it is time to make them work on an :ref:`upgraded database <upgrade/request-test-database>`."
msgid "During the upgrade of the custom modules, you might have to use :doc:`upgrade scripts <../reference/upgrade_scripts>` to reflect changes from the source code to their corresponding data. Together with the upgrade scripts, you can also make use of the :doc:`../reference/upgrade_utils` and its helper functions."
msgid "Any technical data that was renamed during the upgrade of the custom code (models, fields, external identifiers) should be renamed using upgrade scripts to avoid data loss during the module upgrade. See also: :meth:`rename_field`, :meth:`rename_model`, :meth:`rename_xmlid`."
msgid "Data from standard models removed from the source code of the newer Odoo version and from the database during the standard upgrade process might need to be recovered from the old model table if it is still present."
msgid "Custom fields for model ``sale.subscription`` are not automatically migrated from Odoo 15 to Odoo 16 (when the model was merged into ``sale.order``). In this case, a SQL query can be executed on an upgrade script to move the data from one table to the other. Take into account that all columns/fields must already exist, so consider doing this in a ``post-`` script (See :ref:`upgrade-scripts/phases`)."
msgid "Ease the processing time of an upgrade. For example, to store the value of computed stored fields on models with an excessive number of records by using SQL queries."
msgid "As the instalation of custom modules containing Python files is not allowed on Odoo Online databases, it is not possible to run upgrade scripts on this platform."
msgid "Once the upgrade of a staging branch is on \"Update on commit\" mode, each time a commit is pushed on the branch, the upgraded backup is restored and all the custom modules are updated. This update includes the execution of the upgrade scripts."
msgid "When upgrading the production database, the execution of the upgrade scripts is also part of the update of the custom modules done by the platform when the upgraded database is restored."
msgid "Once you receive the upgraded dump of the database from the `Upgrade platform <https://upgrade.odoo.com>`_, deploy the database and update all the custom modules by invoking the command :doc:`odoo-bin </developer/reference/cli>` in the shell. To update the custom modules, use the option: `-u <modules>, --update <modules>`."
msgid "To make sure the custom modules work properly with your data in the upgraded database, they need to be tested as well. This helps ensure both the standard and the custom data stored in the database are consistent and that nothing was lost during the upgrade process."
msgid "Views not working: During the upgrade, if a view causes issues because of its content, it gets disabled. You can find the information on disabled views on the :ref:`Upgrade report <upgrade/upgrade_report>`. This view needs to be activated again (or removed if not useful anymore). To achieve this, we recommend the use of upgrade scripts."
msgid ":doc:`Module data <../tutorials/define_module_data>` not updated: Custom records that have the ``noupdate`` flag are not updated when upgrading the module in the new database. For the custom data that needs to be updated due to changes in the new version, we recommend to use upgrade scripts to do so. See also: :meth:`update_record_from_xml`."
msgid "When the custom modules are working properly in the upgraded database, it is crucial to do another round of testing to assess the database usability and detect any issues that might have gone unnoticed in previous tests. For further information about testing the upgraded database, check :ref:`upgrade/test_your_db`."
msgid "As mentioned in :ref:`upgrade/upgrade-prod`, both standard upgrade scripts and your database are constantly evolving. Therefore it is highly recommended to frequently request new upgraded test databases and ensure that the upgrade process is still successful."
msgid "In addition to that, make a full rehearsal of the upgrade process the day before upgrading the production database to avoid undesired behavior during the upgrade and to detect any issue that might have occurred with the migrated data."
msgid "Once you are confident about upgrading your production database, follow the process described on :ref:`upgrade/upgrade-prod`, depending on the hosting type of your database."
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 "The Odoo Website Builder is an excellent tool for creating a website fully integrated with other Odoo apps. Using the theme's options and building blocks is easy and allows you to personalize your web presence the way you want. However, you can take things even further."
msgid "In this documentation, you will learn to completely customize your website without touching Odoo's core files, and this way, preserve the editing options of the Website Builder."
msgid "The information compiled in this documentation is based on our past experiences - both failures and successes. We invite you to use it as a base to build your own website and adapt it to your needs."
msgid "In standard, you can add animations to columns when they appear, thanks to the Website Builder. Odoo detects when your element is in the viewport and launches the animation. A large selection of animations is available:"
msgid "You can easily define an animation on a column in your custom theme. You need to add two classes: `o_animate` and `o_anim_fade_in`. The second class changes depending on the type of animation you want to use."
msgid "Add the `o_animate_both_scroll` class to launch the animation every time the column appears on the screen. The animation is only launched once by default."
msgid "Snippets are editable by the user using the Website Builder. Some Bootstrap classes are important as **they trigger some Website Builder options**."
msgid "The standard main container of any snippet is a `section`. Any section element can be edited like a block of content that you can move or duplicate."
msgid "Avoid adding a `section` tag inside another `section` tag: this will trigger twice the Website Builder's options. You can use inner content snippets instead."
msgid "Any large Bootstrap columns directly descending from a `.row` element (respecting Bootstrap structure) will be triggered by the Website Builder to make them resizable."
msgid "The `data-vcss` and `data-js` attributes indicate to the system which file version to load for that snippet (e.g., :file:`001.js`, :file:`002.scss`)."
msgid "Options allow users to edit a snippet's appearance using the Website Builder. You can create snippet options easily and automatically add them to the Website Builder."
msgid "`data-selector` binds all the options included in the group to a particular element. It can be used in combination with `data-target` and `data-exclude`."
msgid "Options can apply standard or custom CSS classes to the snippet. Depending on the method that you choose, the user interface will behave differently."
msgid "By default, Dynamic Content blocks have a selection of templates available in the Website Builder. You can also add your own template to the list."
msgid "You can add your success message directly under the form tag. Always add the `d-none` class to make sure that your success message is hidden if the form hasn't been submitted."
msgid "As you already know, the Website Builder creates content based on Bootstrap. This is also true for forms. Below you can find a selection of Bootstrap variables, or check out the `full list of variables <https://github.com/twbs/bootstrap/blob/main/scss/_variables.scss>`_."
msgid "If you need to re-import a module after making some changes, follow the same steps, but before importing the module, open the developer menu and select :guilabel:`Become Superuser`. To leave the Superuser mode, log out and log back in."
msgid "In standard, you can select several gradients directly from the Website Builder. However, for custom themes, you must add the gradients directly in the section tag with a style attribute."
msgid "An Odoo page combines cross-page and unique elements. Cross-page elements are the same on every page, while unique elements are only related to a specific page. By default, a page has two cross-page elements, the header and the footer, and a unique main element that contains the specific content of that page."
msgid "Using precise file names is important to find information through all modules quickly. File names should only contain lowercase alphanumerics and underscores."
msgid "XPath (XML Path Language) is an expression language that enables you to navigate through elements and attributes in an XML document easily. XPath is used to extend standard Odoo templates."
msgid "Be careful when replacing default elements' attributes. As your theme extends the default one, your changes will take priority over any future Odoo update."
msgid "*XML IDs* of inheriting views should use the same *ID* as the original record. It helps to find all inheritance at a glance. As final *XML IDs* are prefixed by the module that creates them, there is no overlap."
msgid "XPath uses path expressions to select nodes in an XML document. Selectors are used inside the expression to target the right element. The most useful ones are listed below."
msgid "This XPath adds `x_airproof_header` in the class attribute of the header. You also need to define a `separator` attribute to add a space before the class you are adding."
msgid "By default, the header contains a responsive navigation menu and the company's logo. You can easily add new elements or create your own template."
msgid "You can add a :ref:`header overlay <header_overlay>` to position your header over the content of your page. It has to be done on each page individually."
msgid "Instead of defining the complete layout of a page, you can create building blocks (snippets) and let the user choose where to drag and drop them, creating the page layout on their own. We call this *modular design*."
msgid "As of v4.3.0, Bootstrap ships with the option to enable responsive font sizes, allowing text to scale more naturally across device and viewport sizes. Enable them by changing the `$enable-responsive-font-sizes` Sass variable to true."
msgid "Odoo automatically generates some basic menu items depending on the apps you installed. For example, the Website app adds two items to the main menu. These items are linked to pages, which are also automatically created."
msgid "A mega menu is a dropdown menu with additional possibilities and not just a list of links. In a mega menu, you can use any kind of content (text, images, icons, ...)."
msgid "You can record images in the database and use them later in your design/code. They will also be available for the end user through the *media dialog*."
msgid "The image size greatly influences the user experience, search engine optimization, and overall website performance. So, be sure to size your images correctly."
msgid "By default, the Font Awesome icons library is included in the Website Builder. You can place icons anywhere using the CSS Prefix `fa` and the icon's name. Font Awesome is designed to be used with inline elements. You can use `<i>` tag for brevity, but using a `<span>` is more semantically correct."
msgid "There are multiple ways to :doc:`install Odoo <../../../administration/install>`, depending on the intended use case. This documentation assumes you use the :doc:`source install <../../../administration/install/source>` (running Odoo from the source code), which is best suited for Odoo designers and developers."
msgid "Every Odoo application works similarly; they are built with the same logic. A model contains fields and relational fields that link to other models. Each model has views representing all its fields, with backend and frontend views."
msgid "The basis of Odoo is models. Models use fields to record the data. Records are stored in a database: they are therefore linked to a model. In Odoo, you can find the different models in the backend by enabling the :ref:`developer mode <developer-mode>` and then going to :menuselection:`Settings --> Technical --> Database Structure: Models`."
msgid "Relational fields call a field from another model. They allow you to link models together and make them interact easily. In other words, when you use a relational field, you link a record with another one (located on another model), enabling you to retrieve the content of the fields located on this linked record."
msgid "**Many2one** fields are filled in by choosing one record from a list of records on another model (from *many* records, you select *one*). For example, the *customer* field on a quotation makes you choose one customer from a list of several customers on the *contact* model."
msgid "**One2many** fields are reverse searches of existing many2one relations. For example, you could list on a contact all their existing quotations (from *one* record, you display *many*)."
msgid "**Many2many** fields are filled in by choosing one or several records from a list of records on another model. For example, you can put several tags on one product, and several products can use the same tags (from *many* records, you can select *many*)."
msgid "Views define how records should be displayed to end-users. They are specified in XML, meaning they can be edited independently from the models they represent. They are flexible and allow deep customization of the screens they control."
msgid "**Dynamic pages** are dynamically generated, such as the product page. Their URL is dynamic and is accessible to all by default (this can be changed by configuring access rights)."
msgid "**Standard views** are base views implemented by Odoo. They are directly derived from their model. You should never change them as they allow updating an Odoo database without overwriting a client's modifications."
msgid "**Inherited views** are duplicated views. Modifications always take place in an inherited view. If there is a duplicate view, there will be two views with the same name in the database, but the duplicated view will not have an ID like for standard view."
msgid "Click the :guilabel:`Download` icon. Select :guilabel:`Testing` under :guilabel:`Purpose` and :guilabel:`With filestore` under :guilabel:`Filestore`."
msgid "Once all dependencies are set up, Odoo can be launched by running `odoo-bin`, the command-line interface of the server. It is located at the root of the Odoo Community directory."
msgid "The :ref:`CLI <reference/cmdline>` offers several functionalities related to Odoo. You can use it to :ref:`run the server <reference/cmdline/server>`, scaffold an Odoo theme, populate a database, or count the number of lines of code."
msgid "After the server has started (the INFO log `odoo.modules.loading: Modules loaded.` is printed), open http://localhost:8069 in your web browser and log in with the base administrator account."
msgid "The developer mode, also known as debug mode, is useful for development as it gives access to additional tools. In the next chapters, it is assumed that you have enabled the developer mode."
msgid "Background shapes are SVG files that you can add as a decorative background in your different sections. Each shape has one or several customizable colors, and some of them are animated."
msgid "Sometimes, your image shape might not be applied after adding your changes. To fix the issue, open the Website Builder and save the page to force the shape to load."
msgid "After your development environment is fully set up, you can start building the skeleton of your theme module. In this chapter, you will discover how to:"
msgid "Remember to add the directory containing your module to the `addons-path` command-line argument when running Odoo in your development environment."
msgid "An Odoo module is also a Python package with a :file:`__init__.py` file containing import instructions for various Python files in the module. This file can remain empty for now."
msgid "An Odoo module is declared by its manifest file. This file declares a Python package as an Odoo module and specifies the module's metadata. It must at least contain the `name` field, which is always required. It usually contains much more information."
msgid "To create a website theme, you only need to install the Website app. If you need other apps (Blogs, Events, eCommerce, ...), you can also add them."
msgid "You do not re-invent something which already exists. For example, as Odoo provides an option to add a border on the footer, you shouldn't recode it yourself. Instead, enable the default option first, then extend it if needed."
msgid "The user can still use all of Odoo's features with your theme. For example, if you recode the border on the footer, you may break the default option or make it useless, giving the user a bad experience. Also, your recode might not work as well as the default option, as other Odoo features may rely on it."
msgid "Odoo declares many CSS rules, most entirely customizable by overriding the related SCSS variables. To do so, create a :file:`primary_variables.scss` file and add it to the `_assets_primary_variables` bundle."
msgid "Based on the previously defined five color palettes, the Website Builder automatically generates five color combinations, each defining a color for the background, text, headings, links, primary buttons, and secondary buttons. These colors can be customized later by the user."
msgid "The colors used in a color combination are accessible and can be overridden through the BS `$colors map` using a specific prefix (`o-cc` for `color combination`)."
msgid "The Website Builder automatically generates a page to view the color combinations of the theme color palette: http://localhost:8069/website/demo/color-combinations"
msgid "If Odoo does not provide the variable you are looking for, there could be a Bootstrap variable that allows it. Indeed all Odoo layouts respect Bootstrap structures and use Bootstrap components or their extensions. If you customize a Bootstrap variable, you add a generic style for the whole user website."
msgid "Use a dedicated file added to the :file:`_assets_frontend_helpers` bundle to override Bootstrap values and *not* the :file:`primary_variables.scss` file."
msgid "Don't override Bootstrap variables that depend on Odoo variables. Otherwise, you might break the possibility for the user to customize them using the Website Builder."
msgid "For this part, we will refer to the `assets_frontend` bundle located in the web module. This bundle specifies the list of assets loaded by the Website Builder, and the goal is to add your SCSS and JS files to the bundle."
msgid "The Website Builder together with Bootstrap are great for defining the basic styles of your website. But to design something unique, you should go a step further. For this, you can easily add any SCSS file to your theme."
msgid "Most new Odoo JavaScript codes should use the native JavaScript module system. It's simpler and brings the benefit of a better developer experience with better integration with the IDE."
msgid "Odoo needs to know which files should be translated into :ref:`Odoo modules <frontend/js_modules>` and which files should not. It's an opt-in system: Odoo looks at the first line of a JavaScript file and checks if it contains the string `@odoo-module`. If so, it will automatically be converted to an Odoo module."
msgid "Do not name a variable `event`; use `ev.` instead. This is to avoid bugs on non-Chrome browsers, as Chrome is magically assigning a global event variable (so if you use the event variable without declaring it, it will work fine on Chrome but crash on every other browser)."
msgid "To translate your pages with the Website Builder, go to your website and click on the language selector to switch to it. If your website was never translated to the target language, click :guilabel:`Add a language...`, select it in the pop-up window, and click :guilabel:`Add`."
msgid "Click :guilabel:`Translate` to start translating. Depending on the language, some text is automatically translated and highlighted in green, while everything that should be translated manually is highlighted in yellow."
msgid "Translating pages directly from the backend allows you to translate several languages at the same time. To do so, go to :menuselection:`Settings --> Technical --> User Interface: Views`, search for the name of the page you want to translate, and click the :guilabel:`Edit Translations` button."
msgid "Once you are done translating, you need to export the translations to integrate them into your module. To export everything at once, open your database, activate :ref:`developer mode <developer-mode>`, and go to :menuselection:`Settings --> Translations --> Export Translation`. Select the :guilabel:`Language` you translated, *PO File* under :guilabel:`File Format`, and *website_airproof* as the :guilabel:`Apps To Export`."
msgid "You can translate directly by editing a :file:`.po` file or creating the file yourself. Check out the :doc:`translating modules documentation <../translations>` to write your translations."
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``"
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.::"
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 "A definition of how all static files are loaded in various assets bundles. See the :ref:`assets <reference/assets>` page for more details on how to describe bundles."
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. ::"
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."
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::"
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 "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:"
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 "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."
msgid "One important thing to know about models is that they don't necessarily perform database updates right away. Indeed, for performance reasons, the framework delays the recomputation of fields after modifying records. And some database updates are delayed, too. Therefore, before querying the database, one has to make sure that it contains the relevant data for the query. This operation is called *flushing* and performs the expected database updates."
msgid "Before every SQL query, one has to flush the data needed for that query. There are three levels for flushing, each with its own API. One can flush either everything, all the records of a model, or some specific records. Because delaying updates improves performance in general, we recommend to be *specific* when flushing."
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 "Just like flushing, one can invalidate either the whole cache, the cache of all the records of a model, or the cache of specific records. One can even invalidate specific fields on some records or all records of a model. As the cache improves performance in general, we recommend to be *specific* when invalidating."
msgid "The methods above keep the caches and the database consistent with each other. However, if computed field dependencies have been modified in the database, one has to inform the models for the computed fields to be recomputed. The only thing the framework needs to know is *what* fields have changed on *which* records."
msgid "One has to figure out which records have been modified. There are many ways to do this, possibly involving extra SQL queries. In the example above, we take advantage of the ``RETURNING`` clause of PostgreSQL to retrieve the information without an extra query. After making the cache consistent by invalidation, invoke the method ``modified`` on the modified records with the fields that have been updated."
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."
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."
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."
msgid "Translations for translated fields are stored as JSONB values with `#97692 <https://github.com/odoo/odoo/pull/97692>`_ and `#101115 <https://github.com/odoo/odoo/pull/101115>`_. Code translations are no longer stored into the database. They become static and are extracted from the PO files when needed."
msgid ":meth:`~odoo.models.Model.search_count` takes the :attr:`limit` argument into account with `#95589 <https://github.com/odoo/odoo/pull/95589>`_. It limits the number of records to count, improving performance when a partial result is acceptable."
msgid "New API for flushing to the database and invalidating the cache with `#87527 <https://github.com/odoo/odoo/pull/87527>`_. New methods have been added to `odoo.models.Model` and `odoo.api.Environment`, and are less confusing about what is actually done in each case. See the section :ref:`SQL Execution <reference/orm/sql>`."
msgid "The argument `args` is renamed to `domain` for :meth:`~odoo.models.Model.search`, :meth:`~odoo.models.Model.search_count` and :meth:`~odoo.models.Model._search`. `#83687 <https://github.com/odoo/odoo/pull/83687>`_"
msgid "The methods :meth:`~odoo.models.Model.fields_get_keys` and :meth:`~odoo.models.Model.get_xml_id` on :class:`~odoo.models.Model` are deprecated. `#83687 <https://github.com/odoo/odoo/pull/83687>`_"
msgid "Remove the :attr:`limit` attribute of :class:`~odoo.fields.One2many` and :class:`~odoo.fields.Many2many`. `#83687 <https://github.com/odoo/odoo/pull/83687>`_"
msgid "Specific index types on fields: With `#83274 <https://github.com/odoo/odoo/pull/83274>`_ and `#83015 <https://github.com/odoo/odoo/pull/83015>`_, developers can now define what type of indexes can be used on fields by PostgreSQL. See the :ref:`index property <reference/fields>` of `odoo.fields.Field`."
msgid "The :attr:`_sequence` attribute of :class:`~odoo.models.Model` is removed. Odoo lets PostgreSQL use the default sequence of the primary key. `#82727 <https://github.com/odoo/odoo/pull/82727>`_"
msgid "The method :meth:`~odoo.models.Model._write` does not raise an error for non-existing records. `#82727 <https://github.com/odoo/odoo/pull/82727>`_"
msgid "The :attr:`column_format` and :attr:`deprecated` attributes of :class:`~odoo.fields.Field` are removed. `#82727 <https://github.com/odoo/odoo/pull/82727>`_"
msgid "Profiling is about analysing the execution of a program and measure aggregated data. These data can be the elapsed time for each function, the executed SQL queries..."
msgid "While profiling does not improve the performance of a program by itself, it can prove very helpful in finding performance issues and identifying which part of the program is responsible for them."
msgid "Odoo provides an integrated profiling tool that allows recording all executed queries and stack traces during execution. It can be used to profile either a set of requests of a user session, or a specific portion of code. Profiling results can be either inspected with the integrated `speedscope <https://github.com/jlfwong/speedscope>`_ :dfn:`open source app allowing to visualize a flamegraph` view or analyzed with custom tools by first saving them in a JSON file or in the database."
msgid "The profiler can either be enabled from the user interface, which is the easiest way to do so but allows profiling only web requests, or from Python code, which allows profiling any piece of code including tests."
msgid "Open the :ref:`developer mode tools <developer-mode/mode-tools>`, then toggle the :guilabel:`Enable profiling` button. A wizard suggests a set of expiry times for the profiling. Click on :guilabel:`ENABLE PROFILING` to enable the profiler globally."
msgid "After the profiler is enabled on the database, users can enable it on their session. To do so, toggle the :guilabel:`Enable profiling` button in the :ref:`developer mode tools <developer-mode/mode-tools>` again. By default, the recommended options :guilabel:`Record sql` and :guilabel:`Record traces` are enabled. To learn more about the different options, head over to :ref:`performance/profiling/collectors`."
msgid "When the profiler is enabled, all the requests made to the server are profiled and saved into an `ir.profile` record. Such records are grouped into the current profiling session which spans from when the profiler was enabled until it is disabled."
msgid "Starting the profiler manually can be convenient to profile a specific method or a part of the code. This code can be a test, a compute method, the entire loading, etc."
msgid "To start the profiler from Python code, call it as a context manager. You may specify *what* you want to record through the parameters. A shortcut is available for profiling test classes: :code:`self.profile()`. See :ref:`performance/profiling/collectors` for more information on the `collectors` parameter."
msgid "When the profiler is enabled, all executions of a test method are profiled and saved into an `ir.profile` record. Such records are grouped into a single profiling session. This is especially useful when using the :code:`@warmup` and :code:`@users` decorators."
msgid "It can be complicated to analyze profiling results of a method that is called several times because all the calls are grouped together in the stack trace. Add an **execution context** as a context manager to break down the results into multiple frames."
msgid "To browse the profiling results, make sure that the :ref:`profiler is enabled globally on the database <performance/profiling/enable>`, then open the :ref:`developer mode tools <developer-mode/mode-tools>` and click on the button in the top-right corner of the profiling section. A list view of the `ir.profile` records grouped by profiling session opens."
msgid "Speedscope falls out of the scope of this documentation but there are a lot of tools to try: search, highlight of similar frames, zoom on frame, timeline, left heavy, sandwich view..."
msgid "The :guilabel:`sql (no gap)` view shows all the SQL queries as if they were executed one after another, without any Python logic. This is useful for optimizing SQL only."
msgid "The :guilabel:`sql (density)` view shows only all the SQL queries, leaving gap between them. This can be useful to spot if eiter SQL or Python code is the problem, and to identify zones in where many small queries could be batched."
msgid "Even though the profiler has been designed to be as light as possible, it can still impact performance, especially when using the :ref:`Sync collector <performance/profiling/collectors/sync>`. Keep that in mind when analyzing speedscope results."
msgid "Each collector specializes in collecting profiling data in its own format and manner. They can be individually enabled from the user interface through their dedicated toggle button in the :ref:`developer mode tools <developer-mode/mode-tools>`, or from Python code through their key or class."
msgid "The SQL collector saves all the SQL queries made to the database in the current thread (for all cursors), as well as the stack trace. The overhead of the collector is added to the analysed thread for each query, which means that using it on a lot of small queries may impact execution time and other profilers."
msgid "It is especially useful to debug query counts, or to add information to the :ref:`Periodic collector <performance/profiling/collectors/periodic>` in the combined speedscope view."
msgid "This collector runs in a separate thread and saves the stack trace of the analysed thread at every interval. The interval (by default 10 ms) can be defined through the :guilabel:`Interval` option in the user interface, or the `interval` parameter in Python code."
msgid "If the interval is set at a very low value, profiling long requests will generate memory issues. If the interval is set at a very high value, information on short function executions will be lost."
msgid "This collector saves the Python execution time and queries of all directives. As for the :ref:`SQL collector <performance/profiling/collectors/sql>`, the overhead can be important when executing a lot of small directives. The results are different from other collectors in terms of collected data, and can be analysed from the `ir.profile` form view using a custom widget."
msgid "It can be useful to debug and understand complex flows, and follow their execution in the code. It is however not recommended for performance analysis because the overhead is high."
msgid "Be careful with blocking calls. In some cases, external `c_call` may take some time before releasing the GIL, thus leading to unexpected long frames with the :ref:`Periodic collector <performance/profiling/collectors/periodic>`. This should be detected by the profiler and give a warning. It is possible to trigger the profiler manually before such calls if needed."
msgid "Be aware of the profiler's overhead. The :ref:`SQL collector <performance/profiling/collectors/sql>`'s overhead can be important when a lot of small queries are executed. Profiling is practical to spot a problem but you may want to disable the profiler in order to measure the real impact of a code change."
msgid "Profiling results can be memory intensive. In some cases (e.g., profiling an install or a long request), it is possible that you reach memory limit, especially when rendering the speedscope results, which can lead to an HTTP 500 error. In this case, you may need to start the server with a higher memory limit: `--limit-memory-hard $((8*1024**3))`."
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."
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."
msgid "This example is not optimal nor correct in all cases. It is only a substitute for a `search_count`. Another solution could be to prefetch and count the inverse `One2many` field."
msgid "Instead, accumulate the create values and call the `create` method on the batch. Doing so has mostly no impact and helps the framework optimize fields computation."
msgid "We can verify that the records are prefetched in batch by reading the field `prefetch_ids` which includes each of the record ids.browsing all records together is unpractical,"
msgid "Algorithmic complexity is a measure of how long an algorithm would take to complete in regard to the size `n` of the input. When the complexity is high, the execution time can grow quickly as the input becomes larger. In some cases, the algorithmic complexity can be reduced by preparing the input's data correctly."
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/external_api/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):"
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::"
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/16.0/addons/web_tour/static/src/js/tour_step_utils.js>`_ or write your own personalized step."
msgid "**trigger**: Selector/element to ``run`` an action on. The tour will wait until the element exists and is visible before ``run``-ing the action *on it*."
msgid "**extra_trigger**: Optional secondary condition for the step to ``run``. Will be waited for like the **trigger** element but the action will not run on the extra trigger."
msgid "By default, ``click`` (and variants) will trigger \"exit\" events on the trigger element (mouseout, mouseleave). This helper suppresses those (note: further clicks on other elements will not trigger those events implicitly)."
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 "**position**: Optional, ``\"top\"``, ``\"right\"``, ``\"bottom\"``, or ``\"left\"``. Where to position the tooltip relative to the **target** when running interactive tours."
msgid "**content**: Optional but recommended, the content of the tooltip in interactive tours, also logged to the console so very useful to trace and debug automated tours."
msgid "The last step(s) of a tour should always return the client to a \"stable\" state (e.g. no ongoing editions) and ensure all side-effects (network requests) have finished running to avoid race conditions or errors during teardown."
msgid "in the javascript console, or by enabling :ref:`tests mode <frontend/framework/tests_debug_mode>` by setting ``?debug=tests`` in the URL, then selecting **Start Tour** in the debug menu and picking a tour:"
msgid "You may want to comment the ``start_tour`` or ``browser_js`` call if you also want the test to continue afterwards, depending on the tour's side-effects."
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 "When trying to fix / debug a tour, the screenshots (on failure) are not necessarily sufficient. In that case it can be useful to see what's happening at some or each step."
msgid "While this is pretty easy when in an \"onboarding\" (as they're mostly driven explicitly by the user) it's more complicated when running \"test\" tours, or when running tours through the test suite. In that case there are two main tricks:"
msgid "This can be added to an existing step, or can be a new dedicated step. Once the step's **trigger** is matched, the execution will stop all javascript execution."
msgid "The browser will wait for the **trigger** until the ``timeout`` before it fails the tour, this allows inspecting and interacting with the page until the developer is ready to resume, by manually enabling the **trigger** (a nonsense class is useful there, as it can be triggered by adding the class to any visible element of the page)."
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 "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 "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 "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 "if the ``attribute`` element has an ``add`` attribute, a ``remove`` attribute, or both, the value of the matched node's attribute named after ``name`` is recomputed to include the value(s) of ``add`` (separated by ``separator``) and delete the value(s) of ``remove`` (separated by ``separator``). If ``separator`` is not provided, ``,`` is used instead."
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 "By default the calendar view will be centered around the current date (today). You can pass a specific initial date to the context of the action in order to set the initial focus of the calendar on the period (see `mode`) around this date (the context key to use being `initial_date`)"
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`` (the field to which this values is saved can be controlled through ``rec_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 "name of the record's field holding the textual representation of the record, this is used when creating records through the 'quick create' mechanism"
msgid "you can add a filter and save the result in the defined model, the filter is added in the sidebar. The ``filter_field`` is optional and allows you to specify the field that will hold the status of the filter."
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 "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 "name of the ``many2many`` field that provides the dependency relation between two records. If B depends on A, ``dependency_field`` is the field that allows getting A from B. Both this field and ``dependency_inverted_field`` field are used to draw dependency arrows between pills and reschedule them."
msgid "name of the ``many2many`` field that provides the invert dependency relation than ``dependency_field``. If B depends on A, ``dependency_inverted_field`` is the field that allows getting B from A."
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 "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 "if set to ``measure``, the field will be used as an aggregated value within a group instead of a grouping criteria. It only works for the last field with that attribute but it is useful for other fields with string attribute (see below)."
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). Default is ``month``."
msgid "only used for field with ``type=\"measure\"``. The name that will be used to display the field in the graph view, overrides the default python String attribute of the field."
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 "only ``date`` column fields have been tested, ``selection`` and ``many2one`` are nominally implemented and supported but have not been tested, ``datetime`` is not implemented at all."
msgid "``create``, ``edit`` and ``delete`` ACL metadata doesn't get automatically set on the view root due to limitations in ``fields_view_get`` post-processing (there's a fixed explicit list of the view types getting those attributes)"
msgid "``adjustment`` can be either ``object`` or ``action`` to indicate whether a cell's adjustment should be performed through a method call or an action execution. ``adjust_name`` provides respectively the method name and the action id."
msgid "In both cases, the adjustment parameters are provided as a ``grid_adjust`` context member, in the ``object`` case, the parameters are also provided as positional function parameters (next to an empty list of ids):"
msgid "set to ``true`` in order to display an additional row at bottom of the grid with an ``Add a line`` button (default false). When this option is set to ``true``, the ``Add a line`` button from the control panel is hidden. When no data is available and when ``display_empty`` is not set (so when the help content is displayed), the the ``Add a line`` button from the control panel is shown in order to let the user create a first record."
msgid "set to ``true`` in order to keep displaying the grid when there is no data (default false). This can be useful when you want the user to be able to keep track of the current period (as dates are displayed in the columns headers). As a reminder, when no data are present and when this attribute is no set, the help content is displayed instead of the grid."
msgid "The server callback is provided with all the record ids displayed in the view, either as the ids passed to the method (``object`` button) or as the context's ``active_ids`` (``action`` buttons)"
msgid "The order of ``row`` fields in the view provides their grouping depth: if the first field is ``school`` and the second is ``age`` the records will be grouped by ``school`` first and by ``age`` within each school."
msgid "The col field can contain 0+ ``<range>`` elements which specify customisable column ranges. ``range`` elements have the following mandatory attributes"
msgid "Note that the grid data is *dense*, if querying the database yields no group matching a cell a cell will generate an \"empty\" cell with default values for required keys."
msgid "``prev`` and ``next`` which can be either falsy (no pagination) or a context item to merge into the view's own context to ``read_grid`` the previous or next page, it should be assumed to be opaque"
msgid "``read_grid_domain(field, range)`` (provided on al models by the module) returns the domain matching the current configured \"span\" of the grid. This is also done internally by ``read_grid``, but can be useful or necessary to call independently to use with separate e.g. ``search_count`` or ``read_group``."
msgid "generates a ColumnMetadata object based on the column type, storing values either returned directly (as part of ``read_grid``) or used query and reformat ``read_group`` into ``read_grid``:"
msgid "context segments which will be sent to ``read_grid`` for pages before and after the current one. If ``False``, disables pagination in that direction"
msgid "For date fields, the reference date around which the initial span will be computed. The default date anchor is \"today\" (in the user's timezone)"
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 "whether a ``date`` or ``datetime`` field allows a value computed from a group range (which consists of the first and last dates of the group). Enables the 'quick create' and 'drag and drop' features when the kanban view is grouped by that field. Default: false."
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 "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 "makes the column optional. If set to \"hide\", the column is hidden by default. If set to \"show\", the column is visible by default. User visibility choices are stored in the browser local storage."
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 records 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 contain 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, OpenStreetMap and MapBox. OpenStreetMap is used by default and 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. A token can be obtained by `signing up`_ to MapBox."
msgid "If a field is provided the view overrides 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 ``1`` display the routes between the records. The view needs a valid MapBox token and at least two located records (i.e the records have a `res.partner` many2one and the partner has an address or valid coordinates)."
msgid "The ``<map>`` element can contain multiple ``<field>`` elements. Each ``<field>`` element is interpreted as a line in the pin's popup. The field's attributes are the following:"
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 "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 periods are 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 "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 "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 :doc:`running Odoo from source <../../administration/install/source>` with the :file:`odoo-bin` file. If you installed Odoo :doc:`from a distribution package <../../administration/install/packages>` or with `Docker <https://hub.docker.com/_/odoo/>`_, 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 "list of server-wide modules to load. Those modules are supposed to provide features not necessarily tied to a particular database. This is in contrast to modules that are always bound to a specific database when they are installed (i.e. the majority of Odoo addons). Default is ``base,web``."
msgid "path to an alternate :ref:`configuration file <reference/cmdline/config>`. If not defined, Odoo checks ``ODOO_RC`` environmental variable and default location :file:`{$HOME}/.odoorc`. See configuration file section :ref:`below <reference/cmdline/config>`."
msgid "directory path where to store Odoo data (eg. filestore, sessions). If not specified, Odoo will fallback to a predefined path. On Unix systems its one defined in ``$XDG_DATA_HOME`` environmental variable or :file:`~/.local/share/Odoo` or :file:`/var/lib/Odoo`."
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 "Define which email address the SMTP configuration will apply to. The field can be a domain name or an entire email address, or it can remain empty. If the sender's email address does not match this set filter, then the email will be encapsulated using a combination of the two system parameters: ``mail.default.from`` and ``mail.catchall.domain``. For example, \"Admin\" <admin\\@example.com> => \"Admin\" <notifications\\@mycompany.com>."
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 QWeb template 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. Particularly, templates are not translated on using this option."
msgid "It always gets the real IP from the last entry of the ``X-Forwarded-For`` chain. Configure your web server accordingly using directives such as nginx's `set_real_ip_from <https://nginx.org/en/docs/http/ngx_http_realip_module.html>`_ in case there are other trusted proxies along the chain that must be ignored."
msgid "``X-Forwarded-Proto`` and ``X-Forwarded-Host`` are used to update the request root URL, which in turn is used to update the ``web.base.url`` system parameter upon a successful admin authentication. This system parameter is used to generate all links for the current database; see :ref:`domain-name/web-base-url`."
msgid "delegates serving attachments files to the static web server and sets both ``X-Sendfile`` (apache) and ``X-Accel-*`` (nginx) http headers on stream responses. See :ref:`deploy/streaming` for web server configuration."
msgid "By default, Odoo displays all logging of level_ ``INFO``, ``WARNING`` and ``ERROR``. All logs independently of the level are output on ``stderr``. Various options are available to redirect logging to other destinations and to customize the verbosity."
msgid "sends logging output to the specified file instead of ``stderr``. 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 "Maximum allowed virtual memory per worker in bytes. If the limit is exceeded, the worker is killed and recycled at the end of the current request."
msgid "Hard limit on virtual memory in bytes, 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 "The Odoo command line also allows launching Odoo as a Python console environment, enabling direct interaction with the :ref:`orm <reference/orm>` and its functionalities."
msgid "By default, the shell is running in transaction mode. This means that any change made to the database is rolled back when exiting the shell. To commit changes, use `env.cr.commit()`."
msgid "Specify a preferred REPL to use in shell mode. This shell is started with the `env` variable already initialized to be able to access the ORM and other Odoo modules."
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/performance/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, CSS, SCSS, 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. Finally, it counts the lines of code of Javascript, CSS, and SCSS files, and of QWeb views from imported modules."
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 "When working on javascript, there are ways to help your editor providing you with powerful auto-completion. One of those ways is the use of a tsconfig.json file. Originally meant for typescript, editors can use its information with plain javascript also. With this config file, you will now have full auto-completion across modules."
msgid "The command to generate this files takes as many unnamed arguments as you need. Those are relative paths to your addon directories. In the example below, we move up one folder to save the tsconfig file in the folder containing community and enterprise."
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."
msgid "Starting with PHP8, the XML-RPC extension may not be available by default. Check out the `manual <https://www.php.net/manual/en/xmlrpc.installation.php>`_ for the installation steps."
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:"
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."
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)."
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."
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)."
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."
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."
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."
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."
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):"
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."
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."
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."
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."
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."
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)."
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."
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)."
msgid "Records of a model are created using :meth:`~odoo.models.Model.create`. The method creates a single record and returns its database identifier."
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."
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`),"
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>`."
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`."
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)."
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."
msgid "The service scans documents using an :abbr:`OCR (Optical Character Recognition)` engine and then uses :abbr:`AI(Artificial Intelligence)`-based algorithms to extract fields of interest such as the total, due date, or invoice lines for *invoices*, the total, date for *expenses*, or the name, email, phone number for *resumes*."
msgid "This service is a paid service. Each document processing will cost you one credit. Credits 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 Accounting, Expense, or Recruitment 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:`/parse <extract_api/parse>` to submit your documents (one call for each document). On success, you receive a `document_token` in the response."
msgid "Alternatively, you can provide a `webhook_url` at the time of the call to :ref:`/parse <extract_api/parse>` and you will be notified (via a POST request) when the result is ready."
msgid "The HTTP POST method should be used for all of them. A python implementation of the full flow for invoices can be found :download:`here <extract_api/implementation.py>` and a token for integration testing is provided in the :ref:`integration testing section <latestextract_api/integration_testing>`."
msgid "Request the processing of a document from the OCR. The route will return a `document_token`, you can use it to obtain the result of your request."
msgid "The version will determine the format of your requests and the format of the server response. You should use the :ref:`latest version available <extract_api/version>`."
msgid "The document 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 sending the document to the extract service. It can be the client or the supplier (depending on the ``perspective``). This information is not required in order for the service to work but it greatly improves the quality of the result."
msgid "Can be ``client`` or ``supplier``. This field is useful for invoices only. ``client`` means that the user information provided are related to the client of the invoice. ``supplier`` means that it's related to the supplier. If not provided, client will be used."
msgid "The ``user_infos`` parameter is optional but it greatly improves the quality of the result, especially for invoices. The more information you can provide, the better."
msgid "When getting the results from the parse, the detected field vary a lot depending on the type of document. Each response is a list of dictionaries, one for each document. The keys of the dictionary are the name of the field and the value is the value of the field."
msgid "Each field of interest we want to extract from the document such as the total or the due date are also called **features**. An exhaustive list of all the extracted features associated to a type of document can be found in the sections 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 "Invoices are complex and can have a lot of different fields. The following table gives an exhaustive list of all the fields we can extract from an invoice."
msgid "Depending on the value of perspective in the user_infos, this will be the VAT number of the supplier or the client. If perspective is client, it'll be the supplier's VAT number. If it's supplier, it's the client's VAT number."
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:`latestextract_api/get_result/feature_result` structure."
msgid "The expenses are less complex than invoices. The following table gives an exhaustive list of all the fields we can extract from an expense report."
msgid "This third type of document is meant for processing resumes. The following table gives an exhaustive list of all the fields we can extract from a resume."
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 **document** 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_result <extract_api/get_result>` is a hard-coded one."
msgid "Managing assets in Odoo is not as straightforward as it is in some other apps. One of the reasons is that we have a variety of situations where some, but not all of the assets are required. For example, the needs of the web client, the point of sale app, the website or even the mobile application are different. Also, some assets may be large, but are seldom needed: in that case we may want them to be :ref:`loaded lazily (on demand) <frontend/assets/lazy_loading>`."
msgid "Odoo supports :ref:`three different kinds of javascript files<frontend/js_modules>`. All these files are then processed (native JS modules are transformed into odoo modules), then minified (if not in `debug=assets` :ref:`mode <frontend/framework/assets_debug_mode>`) and concatenated. The result is then saved as a file attachment. These file attachments are usually loaded via a `<script>` tag in the `<head>` part of the page (as a static file)."
msgid "Styling can be done with either `css` or `scss <https://sass-lang.com/>`_. Like the javascript files, these files are processed (`scss` files are converted into `css`), then minified (again, if not in `debug=assets` :ref:`mode <frontend/framework/assets_debug_mode>`) and concatenated. The result is then saved as a file attachment. They are then usually loaded via a `<link>` tag in the `<head>` part of the page (as a static file)."
msgid "Templates (static `xml` files) are handled in a different way: they are simply read from the file system whenever they are needed, and concatenated."
msgid "It is useful to know that in most cases, a browser only performs a request the first time it loads a page. This is because each of these assets are associated with a checksum, which is injected into the page source. The checksum is then added to the url, which means that it is possible to safely set the cache headers to a long period."
msgid "Odoo assets are grouped by *bundles*. Each bundle (a *list of file paths* of specific types: `xml`, `js`, `css` or `scss`) is listed in the :ref:`module manifest <reference/module/manifest>`. Files can be declared using `glob <https://en.wikipedia.org/wiki/Glob_(programming)>`_ syntax, meaning that you can declare several asset files using a single line."
msgid "The bundles are defined in each module's :file:`__manifest__.py`, with a dedicated `assets` key which contains a dictionary. The dictionary maps bundle names (keys) to the list of files they contain (values). It looks like this:"
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 :file:`boot.js` file, which defines the odoo module system."
msgid "`web.assets_backend`: this bundle contains the code specific to the web client (notably the web client/action manager/views/static XML templates)"
msgid "Typically, handling assets is simple: you just need to add some new files to a frequently used bundle like `assets_common` or `assets_backend`. But there are other operations available to cover some more specific use cases."
msgid "Note that all directives targeting a certain asset file (i.e. `before`, `after`, `replace` and `remove`) need that file to be declared beforehand, either in manifests higher up in the hierarchy or in ``ir.asset`` records with a lower sequence."
msgid "By default, adding a simple string to a bundle will append the files matching the glob pattern at the end of the bundle. Obviously, the pattern may also be directly a single file path."
msgid "Useful when you need to put a certain file before the others in a bundle (for example with css files). The `prepend` operation is invoked with the following syntax: `('prepend', <path>)`."
msgid "Prepending a file at the beginning of a bundle might not be precise enough. The `before` directive can be used to add the given file(s) right *before* the target file. It is declared by replacing the normal path with a 3-element tuple `('before', <target>, <path>)`."
msgid "Same as `before`, with the matching file(s) appended right *after* the target file. It is declared by replacing the normal path with a 3-element tuple `('after', <target>, <path>)`."
msgid "The `include` directive is a way to use a bundle in other bundles to minimize the size of your manifest. In Odoo we use sub bundles (prefixed with an underscore by convention) to batch files used in multiple other bundles. You can then specify the sub bundle as a pair `('include', <bundle>)` like this:"
msgid "In some cases, you may want to remove one or multiple files from a bundle. This can be done using the `remove` directive by specifying a pair `('remove', <target>)`:"
msgid "Let us say that an asset needs not only to be removed, but you also want to insert your new version of that asset at the same exact position. This can be done with the `replace` directive, using a 3-element tuple `('replace', <target>, <path>)`:"
msgid "The order in which assets are loaded is sometimes critical and must be deterministic, mostly for stylesheets priorities and setup scripts. Assets in Odoo are processed as follows:"
msgid "All records of type `ir.asset` matching the bundle are fetched and sorted by sequence number. Then all records with a sequence strictly less than 16 are processed and applied to the current list of assets."
msgid "All modules declaring assets for said bundle in their manifest apply their assets operations to this list. This is done following the order of modules dependencies (e.g. `web` assets is processed before `website`). If a directive tries to add a file already present in the list, nothing is done for that file. In other word, only the first occurrence of a file is kept in the list."
msgid "Assets declared in the manifest may need to be loaded in a particular order, for example :file:`jquery.js` must be loaded before all other jquery scripts when loading the lib folder. One solution would be to create an :ref:`ir.asset <frontend/assets/ir_asset>` record with a lower sequence or a 'prepend' directive, but there is another simpler way to do so."
msgid "Since the unicity of each file path in the list of assets is guaranteed, you can mention any specific file before a glob that includes it. That file will thus appear in the list before all the others included in the glob."
msgid "A module *b* removing/replacing the assets declared in a module *a* will have to depend on it. Trying to operate on assets that have yet to be declared will result in an error."
msgid "It is sometimes useful to load files and/or asset bundles dynamically, for example to only load a library once it is needed. To do that, the Odoo framework provides a few helper functions, located in :file:`@web/core/assets`."
msgid "In most cases the assets declared in the manifest will largely suffice. Yet for more flexibility, the framework also supports dynamic assets declared in the database."
msgid "This is done by creating `ir.asset` records. Those will be processed as if they were found in a module manifest, and they give the same expressive power as their manifest counterparts."
msgid "This field determines how the `path` (and `target` if needed) will be interpreted. Here is the list of available directives along with their required arguments:"
msgid "Loading order of the asset records (ascending). A sequence lower than 16 means that the asset will be processed *before* the ones declared in the manifest."
msgid "The Odoo Javascript framework is a set of features/building blocks provided by the ``web/`` addon to help build odoo applications running in the browser. At the same time, the Odoo Javascript framework is a single page application, usually known as the *web client* (available at the url ``/web``)."
msgid "The web client started as an application made with a custom class and widget system, but it is now transitioning to using native javascript classes instead, and Owl as a component system. This explains why both systems are currently in use in the codebase."
msgid "From a high-level perspective, the web client is a single-page application: it does not need to request a full page from the server each time the user performs an action. Instead, it only requests what it needs and then replaces/updates the current screen accordingly. Also, it manages the url to keep it in sync with the current state."
msgid "The javascript framework (all or some parts) is also used in other situations, such as the Odoo website or the point of sale. This reference is mostly focused on the web client."
msgid "It is common in the Odoo ecosystem to see the words *frontend* and *backend* as synonyms for the odoo website (public) and the web client, respectively. This terminology is not to be confused with the more common use of browser-code (frontend) and server (backend)."
msgid "The ``web/static/src`` folder contains all the ``web/`` javascript (and css and templates) codebase. Here is a list of the most important folders:"
msgid "The ``web/static/src`` is the root folder. Everything inside can simply be imported by using the ``@web`` prefix. For example, here is how one can import the ``memoize`` function located in ``web/static/src/core/utils/functions``:"
msgid "As we can see, it basically is a wrapper for a navbar, the current action and some additional components. The ``ActionContainer`` is a higher order component that will display the current action controller (so, a client action, or a specific view in the case of actions of type ``act_window``). Managing actions is a huge part of its work: the action service keeps in memory a stack of all active actions (represented in the breadcrumbs), and coordinates each change."
msgid "Another interesting thing to note is the ``MainComponentsContainer``: it is simply a component that displays all components registered in the ``main_components`` registry. This is how other parts of the system can extend the web client."
msgid "As an Owl application, the Odoo web client defines its own environment (components can access it using ``this.env``). Here is a description of what Odoo adds to the shared ``env`` object:"
msgid "So, for example, to translate a string in a component (note: templates are automatically translated, so no specific action is required in that case), one can do this:"
msgid "Having a reference to the environment is quite powerful, because it provides access to all services. This is useful in many cases: for example, user menu items are mostly defined as a string, and a function taking the `env` as unique argument. This is enough to express all user menu needs."
msgid ":ref:`Registries <frontend/registries>` are basically a simple key/value mapping that stores some specific kind of objects. They are an important part of the extensibility of the UI: once some object is registered, the rest of the web client can use it. For example, the field registry contains all field components (or widgets) that can be used in views."
msgid ":ref:`Services <frontend/services>` are long lived pieces of code that provide a feature. They may be imported by components (with ``useService``) or by other services. Also, they can declare a set of dependencies. In that sense, services are basically a DI (dependency injection) system. For example, the ``notification`` service provides a way to display a notification, or the ``rpc`` service is the proper way to perform a request to the Odoo server."
msgid ":ref:`Components <frontend/components>` and :ref:`hooks <frontend/hooks>` are ideas coming from the `Owl component system <https://github.com/odoo/owl/blob/master/doc/readme.md>`_. Odoo components are simply owl components that are part of the web client."
msgid "`Hooks <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md>`_ are a way to factorize code, even if it depends on lifecycle. This is a composable/functional way to inject a feature in a component. They can be seen as a kind of mixin."
msgid "An important concept in the Odoo javascript is the *context*: it provides a way for code to give more context to a function call or a rpc, so other parts of the system can properly react to that information. In some way, it is like a bag of information that is propagated everywhere. It is useful in some situations, such as letting the Odoo server know that a model rpc comes from a specific form view, or activating/disabling some features in a component."
msgid "There are two different contexts in the Odoo web client: the *user context* and the *action context* (so, we should be careful when using the word *context*: it could mean a different thing depending on the situation)."
msgid "The `context` object may be useful in many cases, but one should be careful not to overuse it! Many problems can be solved in a standard way without modifying the context."
msgid "In practice, the `orm` service automatically adds the user context to each of its requests. This is why it is usually not necessary to import it directly in most cases."
msgid "The :ref:`ir.actions.act_window<reference/actions/window>` and :ref:`ir.actions.client<reference/actions/client>` support an optional `context` field. This field is a `char` that represents an object. Whenever the corresponding action is loaded in the web client, this context field will be evaluated as an object and given to the component that corresponds to the action."
msgid "It can be used in many different ways. For example, the views add the action context to every requests made to the server. Another important use is to activate some search filter by default (see example above)."
msgid "Sometimes, when we execute new actions manually (so, programmatically, in javascript), it is useful to be able to extend the action context. This can be done with the `additional_context` argument."
msgid "In this example, the action with xml_id `addon_name.something` will be loaded, and its context will be extended with the `default_period_id` value. This is a very important usecase that lets developers combine actions together by providing some information to the next action."
msgid "The Odoo framework features a built-in small python interpreter. Its purpose is to evaluate small python expressions. This is important, because views in Odoo have modifiers written in python, but they need to be evaluated by the browser."
msgid "Broadly speaking, domains in Odoo represent a set of records that matches some specified conditions. In javascript, they are usually represented either as a list of conditions (or of operators: `|`, `&` or `!` in prefix notation), or as string expressions. They don't have to be normalized (the `&` operator is implied if necessary). For example:"
msgid "String expressions are more powerful than list expressions: they can contain python expressions and unevaluated values, that depends on some evaluation context. However, manipulating string expressions is more difficult."
msgid "Returns a list description for the domain. Note that this method takes an optional `context` object that will be used to replace all free variables."
msgid "The web client :ref:`environment <frontend/framework/environment>` object contains an event bus, named `bus`. Its purpose is to allow various parts of the system to properly coordinate themselves, without coupling them. The `env.bus` is an owl `EventBus <https://github.com/odoo/owl/blob/master/doc/reference/event_bus.md>`_, that should be used for global events of interest."
msgid "The javascript framework also provides a special object ``browser`` that provides access to many browser APIs, like ``location``, ``localStorage`` or ``setTimeout``. For example, here is how one could use the ``browser.setTimeout`` function:"
msgid "It is mostly interesting for testing purposes: all code using the browser object can be tested easily by mocking the relevant functions for the duration of the test."
msgid "The `debug` mode is described by a string. An empty string means that the `debug` mode is not active. Otherwise, it is active. If the string contains `assets` or `tests`, then the corresponding specific sub modes are activated (see below). Both modes can be active at the same time, for example with the string `assets,tests`."
msgid "The `debug=assets` sub mode is useful to debug javascript code: once activated, the :ref:`assets<reference/assets>` bundles are no longer minified, and source-maps are generated as well. This makes it useful to debug all kind of javascript code."
msgid "There is another sub mode named `tests`: if enabled, the server injects the bundle `web.assets_tests` in the page. This bundle contains mostly test tours (tours whose purpose is to test a feature, not to show something interesting to users). The `tests` mode is then useful to be able to run these tours."
msgid "`Owl hooks <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md>`_ are a way to factorize code, even if it depends on some component lifecycle. Most hooks provided by Owl are related to the lifecycle of a component, but some of them (such as `useComponent <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#usecomponent>`_) provide a way to build specific hooks."
msgid "Using these hooks, it is possible to build many customized hooks that help solve a specific problem, or make some common tasks easier. The rest of this page documents the list of hooks provided by the Odoo web framework."
msgid "Focus an element referenced by a t-ref=\"autofocus\" in the current component as soon as it appears in the DOM and if it was not displayed before."
msgid "Display the :ref:`Pager <frontend/pager>` of the control panel of a view. This hooks correctly sets `env.config` to provide the props to the pager."
msgid "Helps positioning an HTMLElement (the `popper`) relatively to another HTMLElement (the `reference`). This hook ensures the positioning is updated when the window is resized/scrolled."
msgid "this is a `useRef reference <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useref>`_ for the element that will get positioned. Default is `\"popper\"`."
msgid "the container from which the popper is expected not to overflow. If overflowing occurs, other popper positions are tried until a not overflowing one is found. (default: the `<html/>` node)"
msgid "the desired position. It is a string composed of one `Direction` and one `Variant` separated by a dash character. `Direction` could be: `top`, `bottom`, `right`, `left`. `Variant` could be: `start`, `middle`, `end`. The variant can be omitted (default variant is `middle`). Examples of valid positions: `right-end`, `top-start`, `left-middle`, `left`. (default position: `bottom`)"
msgid "a callback that will be called everytime a positioning occurs (e.g. on component mounted/patched, document scroll, window resize...). Can be used i.e. for dynamic styling regarding the current position. The `PositioningSolution` is an object having the following type: `{ direction: Direction, variant: Variant, top: number, left: number }`."
msgid "As described in the :ref:`assets management page <reference/assets>`, all javascript files are bundled together and served to the browser. Note that native javascript files are processed by the Odoo server and transformed into Odoo custom modules."
msgid "Let us briefly explain the purpose behind each kind of javascript file. Plain javascript files should be reserved only for external libraries and some small specific low level purposes. All new javascript files should be created in the native javascript module system. The custom module system is only useful for old, not yet converted files."
msgid "Plain javascript files can contain arbitrary content. It is advised to use the *iife* :dfn:`immediately invoked function execution` style when writing such a file:"
msgid "Clearly, plain javascript files do not offer the benefits of a module system, so one needs to be careful about the order in the bundle (since the browser will execute them precisely in that order)."
msgid "Most new Odoo javascript code should use the native javascript module system. This is simpler, and brings the benefits of a better developer experience with a better integration with the IDE."
msgid "There is a very important point to know: Odoo needs to know which files should be translated into :ref:`Odoo modules <frontend/modules/odoo_module>` and which files should not be translated. This is an opt-in system: Odoo will look at the first line of a JS file and check if it contains the string *@odoo-module*. If so, it will automatically be converted to an Odoo module."
msgid "Note the comment in the first line: it describes that this file should be converted. Any file without this comment will be kept as-is (which will most likely be an error). This file will then be translated into an Odoo module that look like this:"
msgid "Another important point is that the translated module has an official name: *@web/file_a*. This is the actual name of the module. Every relative imports will be converted as well. Every file located in an Odoo addon :file:`some_addon/static/src/path/to/file.js` will be assigned a name prefixed by the addon name like this: *@some_addon/path/to/file*."
msgid "Because :ref:`Odoo modules <frontend/modules/odoo_module>` follow a different module naming pattern, a system exists to allow a smooth transition towards the new system. Currently, if a file is converted to a module (and therefore follow the new naming convention), other files not yet converted to ES6-like syntax in the project won't be able to require the module. Aliases are here to map old names with new ones by creating a small proxy function. The module can then be called by its new *and* old name."
msgid "The default behaviour of aliases is to re-export the ``default`` value of the module they alias. This is because \"classic\" modules generally export a single value which would be used directly, roughly matching the semantics of default exports. However it is also possible to delegate more directly, and follow the exact behaviour of the aliased module:"
msgid "Only one alias can be defined using this method. If you were to need another one to have, for example, three names to call the same module, you would have to add a proxy manually. This is not good practice and should be avoided unless there is no other options."
msgid "For performance reasons, Odoo does not use a full javascript parser to transform native modules. There are, therefore, a number of limitations including but not limited to:"
msgid "Odoo needs a way to determine if a module is described by a path (like :file:`./views/form_view`) or a name (like `web.FormView`). It has to use a heuristic to do just that: if there is a `/` in the name, it is considered a path. This means that Odoo does not really support module names with a `/` anymore."
msgid "As \"classic\" modules are not deprecated and there is currently no plan to remove them, you can and should keep using them if you encounter issues with, or are constrained by the limitations of, native modules. Both styles can coexist within the same Odoo addon."
msgid "Odoo has defined a small module system (located in the file :file:`addons/web/static/src/js/boot.js`, which needs to be loaded first). 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 the `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 an rpc to load some data. In that case, the module can simply return a promise. The module system will simply wait for the promise to complete before registering the module."
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 "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 "Large applications are usually broken up into smaller files, that need to be connected together. Some file may need to use some part of code defined in another file. There are two ways of sharing code between files:"
msgid "use a module system that will provide a way for each modules to export or import values, and will make sure that they are loaded in a proper order."
msgid "Module systems help resolve these issues: because modules specify their dependencies the module system can ensure the necessary order of loading is respected, and because modules can precisely specify their exports it is less likely that they will leak implementation details."
msgid "For most Odoo code, we want to use a module system. Because of the way assets work in Odoo (and in particular, the fact that each installed odoo addon can modify the list of files contained in a bundle), Odoo has to resolve modules browser side. To do that, Odoo provides a small module system described just below (see :ref:`frontend/modules/odoo_module`)."
msgid "However, Odoo also provides support for native javascript modules (see :ref:`frontend/modules/native_js`). These modules will simply be translated by the server into odoo modules. It is encouraged to write all javascript code as a native module, for a better IDE integration. In the future, the Odoo module system should be considered an implementation detail, not the primary way to write javascript code."
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 "Note that the custom class system should be avoided for creating new code. It will be deprecated at some point, and then removed. New classes should use the standard ES6 class system."
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 assets of the module manifest ``'assets': {'web.assets_qweb': [...]}``, see :ref:`assets <reference/assets>`.) 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 *web.assets_qweb* entry in each module manifest. It is also possible to lazy-load another bundle's templates by calling this same route and giving it the corresponding \"bundle\" query parameter."
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 (default false). If true, the notification will stay until the user dismisses it. Otherwise, the notification will be automatically closed after a short delay."
msgid "*type*: string, optional (default 'warning'). Determines the style of the notification. Possible values: 'info', 'success', 'warning', 'danger', ''."
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 "website_path: (default:false) by default, the widget forces (if not already the case) the href value to begin with http:// except if this option is set to true, thus allowing redirections to the database's own website."
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 "no_create: prevent the creation of related records - hide both the 'Create \"xxx\"' and \"Create and Edit...\" dropdown menu items (default: false)"
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 into the web client interface, just like an *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 inherits 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 with 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 that 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 the control panel. For more information, look into the `control_panel_renderer.js <https://github.com/odoo/odoo/blob/16.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 "Odoo Editor is Odoo's own rich text editor. Its sources can be found in the `odoo-editor directory <https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/editor/odoo-editor>`_."
msgid "The Powerbox is a piece of user interface that contains :ref:`commands <reference/frontend/odoo_editor/powerbox/command>` organized into :ref:`categories <reference/frontend/odoo_editor/powerbox/category>`. It appears when typing `/` in the editor. The commands can be filtered when the user inputs text, and navigated with the arrow keys."
msgid "Only one Powerbox should be instantiated at the time, and that job is done by the editor itself. Its Powerbox instance can be found in its `powerbox` instance variable. To change the Powerbox's contents and options, change the options passed to the editor before it gets instantiated."
msgid "Say we want to add a new command `Document` to the Powerbox, just for the `mass_mailing` module. We want to add it to a new category called `Documentation` and we want it all the way at the top of the Powerbox."
msgid "`mass_mailing` `extends <https://github.com/odoo/odoo/blob/16.0/addons/mass_mailing/static/src/js/wysiwyg.js>`_ `web_editor`'s `Wysiwyg class <https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js>`_, which instantiates the editor in its `start` method. Before doing so, it calls its own `_getPowerboxOptions` method, which can conveniently be overridden to add our new commands."
msgid "To avoid out-of-control escalations, don't use random numbers for your priorities: look at which other priorities already exist and choose your value accordingly (like you would do for a `z-index`)."
msgid "It is possible to open the Powerbox with a custom set of categories and commands, bypassing all pre-existing ones. To do that, call the `open` method of the Powerbox and pass it your custom commands and categories."
msgid "We need the current instance of the Powerbox, which can be found in the current editor. In the `Wysiwyg class <https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js>`_, you will find it as `this.odooEditor.powerbox`."
msgid "The user can filter commands by simply typing text after opening the Powerbox. It will fuzzy-match that text with the names of the categories and commands."
msgid "used to order the category: a category with a higher priority is displayed higher into the Powerbox (categories with the same priority are ordered alphabetically)"
msgid "If several categories exist with the same name, they will be grouped into one. Its priority will be that defined in the version of the category that was declared last."
msgid "used to order the command: a command with a higher priority is displayed higher into the Powerbox (commands with the same priority are ordered alphabetically)"
msgid "The Odoo Javascript framework uses a custom component framework called Owl. It is a declarative component system, loosely inspired by Vue and React. Components are defined using :doc:`QWeb templates <qweb>`, enriched with some Owl specific directives. The official `Owl documentation <https://github.com/odoo/owl/blob/master/doc/readme.md>`_ contains a complete reference and a tutorial."
msgid "Although the code can be found in the `web` module, it is maintained from a separate GitHub repository. Any modification to Owl should therefore be made through a pull request on https://github.com/odoo/owl."
msgid "The `Owl documentation`_ already documents in detail the Owl framework, so this page will only provide Odoo specific information. But first, let us see how we can make a simple component in Odoo."
msgid "This example shows that Owl is available as a library in the global namespace as `owl`: it can simply be used like most libraries in Odoo. Note that we defined here the template as a static property, but without using the `static` keyword, which is not available in some browsers (Odoo javascript code should be Ecmascript 2019 compliant)."
msgid "We define here the template in the javascript code, with the help of the `xml` helper. However, it is only useful to get started. In practice, templates in Odoo should be defined in an xml file, so they can be translated. In that case, the component should only define the template name."
msgid "In practice, most components should define 2 or 3 files, located at the same place: a javascript file (`my_component.js`), a template file (`my_component.xml`) and optionally a scss (or css) file (`my_component.scss`). These files should then be added to some assets bundle. The web framework will take care of loading the javascript/css files, and loading the templates into Owl."
msgid "Odoo code is not yet completely made in Owl, so it needs a way to tell the difference between Owl templates (new code) and old templates (for components). To do that in a backward-compatible way, all new templates should be defined with the `owl` attribute set to 1."
msgid "First of all, components are classes, so they have a constructor. But constructors are special methods in javascript that are not overridable in any way. Since this is an occasionally useful pattern in Odoo, we need to make sure that no component in Odoo directly uses the constructor method. Instead, components should use the `setup` method:"
msgid "Another good practice is to use a consistent convention for template names: `addon_name.ComponentName`. This prevents name collision between odoo addons."
msgid "The Odoo web client is built with `Owl <https://github.com/odoo/owl>`_ components. To make it easier, the Odoo javascript framework provides a suite of generic components that can be reused in some common situations, such as dropdowns, checkboxes or datepickers. This page explains how to use these generic components."
msgid "This is a component that can perform actions when an element is swiped horizontally. The swiper is wrapping a target element to add actions to it. The action is executed once the user has released the swiper passed a portion of its width."
msgid "The simplest way to use the component is to use it around your target element directly in an xml template as shown above. But sometimes, you may want to extend an existing element and would not want to duplicate the template. It is possible to do just that."
msgid "If you want to extend the behavior of an existing element, you must place the element inside, by wrapping it directly. Also, you can conditionnally add props to manage when the element might be swipable, its animation and the minimum portion to swipe to perform the action."
msgid "`action`, which is the callable `Function` serving as a callback. Once the swipe has been completed in the given direction, that action is performed."
msgid "`bgColor` is the background color, given to decorate the action. can be one of the following `bootstrap contextual color <https://getbootstrap.com/docs/3.3/components/#available-variations>`_ (`danger`, `info`, `secondary`, `success` or `warning`)."
msgid "In the following example, you can use `xpath`'s to wrap an existing element in the ActionSwiper component. Here, a swiper has been added to mark a message as read in mail."
msgid "This is a simple checkbox component with a label next to it. The checkbox is linked to the label: the checkbox is toggled whenever the label is clicked."
msgid "The ColorList let you choose a color from a predefined list. By default, the component displays the current selected color, and is not expandable until the `canToggle` props is present. Different props can change its behavior, to always expand the list, or make it act as a toggler once it is clicked, to display the list of available colors until a choice is selected."
msgid "To solve these issues once and for all, the Odoo framework provides a set of two components: a `Dropdown` component (the actual dropdown), and `DropdownItem`, for each element in the item list."
msgid "A `<Dropdown/>` component is simply a `<div class=\"dropdown\"/>` having a `<button class=\"dropdown-toggle\"/>` next to menu div (`<div class=\"dropdown-menu\"/>`). The button is responsible for the menu being present in the DOM or not."
msgid "defines the desired menu opening position. RTL direction is automatically applied. Should be a valid :ref:`usePosition <frontend/hooks/useposition>` hook position. (default: `bottom-start`)"
msgid "when set to `\"parent\"` the `<button class=\"dropdown-toggle\"/>` is not rendered (thus `toggler` slot is ignored) and the toggling feature is handled by the parent node (e.g. use case: pivot cells). (default: `undefined`)"
msgid "A `<DropdownItem/>` is simply a span (`<span class=\"dropdown-item\"/>`). When a `<DropdownItem/>` is selected, it calls its `onSelected` prop. If this prop is a method, make sure it is bound if the method need to use the `this` value."
msgid "if provided the DropdownItem will become an `<a href=\"value\" class=\"dropdown-item\"/>` instead of a `<span class=\"dropdown-item\"/>`. (default: not provided)"
msgid "optional object containing values that should be added to the root element's dataset. This can be used so that the element is easier to find programmatically, for example in tests or tours."
msgid "To properly use a `<Dropdown/>` component, you need to populate two `OWL slots <https://github.com/odoo/owl/blob/master/doc/reference/slots.md>`_ :"
msgid "`toggler` slot: it contains the *toggler* elements of your dropdown and is rendered inside the dropdown `button` (unless the `toggler` prop is set to `parent`),"
msgid "`default` slot: it contains the *elements* of the dropdown menu itself and is rendered inside the `<div class=\"dropdown-menu\"/>`. Although it is not mandatory, there is usually at least one `DropdownItem` inside the `menu` slot."
msgid "When several dropdowns share the same parent element in the DOM, then they are considered part of a group, and will notify each other about their state changes. This means that when one of these dropdowns is open, the others will automatically open themselves on mouse hover, without the need for a click."
msgid "The Notebook is made to display multiple pages in a tabbed interface. Tabs can be located at the top of the element to display horizontally, or at the left for a vertical layout."
msgid "The other way to define your pages is by passing the props. This can be useful if some pages share the same structure. Create first a component for each page template that you may use."
msgid "The Pager is a small component to handle pagination. A page is defined by an `offset` and a `limit` (the size of the page). It displays the current page and the `total` number of elements, for instance, \"9-12 / 20\". In the previous example, `offset` is 8, `limit` is 4 and `total` is 20. It has two buttons (\"Previous\" and \"Next\") to navigate between pages."
msgid "The pager can be used anywhere but its main use is in the control panel. See the :ref:`usePager <frontend/hooks/usepager>` hook in order to manipulate the pager of the control panel."
msgid "Function that is called when page is modified by the pager. This function can be async, the pager cannot be edited while this function is executing."
msgid "Sometimes, we need to customize the way the UI works. Many common needs are covered by some supported API. For example, all registries are good extension points: the field registry allows adding/removing specialized field components, or the main component registry allows adding components that should be displayed all the time."
msgid "However, there are situations for which it is not sufficient. In those cases, we may need to modify an object or a class in place. To achieve that, Odoo provides the utility function `patch`. It is mostly useful to override/update the behavior of some other component/piece of code that one does not control."
msgid "The `patch` function modifies in place the `obj` object (or class) and applies all key/value described in the `patchValue` object. This operation is registered under the `patchName` name, so it can be unpatched later if necessary."
msgid "Most patch operations provide access to the parent value by using the `_super` property (see below in the examples). To do that, the `patch` method wraps each pair key/value in a getter that dynamically binds `_super`."
msgid "When patching functions, we usually want to be able to access the ``parent`` function. Since we are working with patch objects, not ES6 classes, we cannot use the native ``super`` keyword. So, Odoo provides a special method to simulate this behaviour: ``this._super``:"
msgid "``this._super`` is reassigned after each patched function is called. This means that if you use an asynchronous function in the patch then you cannot call ``this._super`` after an ``await``, because it may or may not be the function that you expect. The correct way to do that is to keep a reference to the initial ``_super`` method:"
msgid "However, since javascript classes work with the prototypal inheritance, when one wishes to patch a standard method from a class, then we actually need to patch the `prototype`:"
msgid "Also, Javascript handles the constructor in a special native way which makes it impossible to be patched. The only workaround is to call a method in the original constructor and patch that method instead:"
msgid "Components are defined by javascript classes, so all the information above still holds. For these reasons, Owl components should use the `setup` method, so they can easily be patched as well (see the section on :ref:`best practices<frontend/owl/best_practices>`."
msgid "Removes an existing patch from an object `obj`. This is mostly useful for testing purposes, when we patch something at the beginning of a test, and unpatch it at the end."
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 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 "There are two equivalent syntaxes for format strings: ``\"plain_text {{code}}\"`` (aka jinja-style) and ``\"plain_text #{code}\"`` (aka ruby-style)."
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 "Content which does *not* need to be escaped will instead be injected as-is in the document, and may become part of the document's actual markup."
msgid "The only cross-platform \"safe\" content is the output of :ref:`t-call <reference/qweb/call>` or a :ref:`t-set <reference/qweb/set>` used with a \"body\" (as opposed to ``t-value`` or ``t-valuef``)."
msgid "Usually you should not have to care too much: APIs for which it makes sense should generate \"safe\" content automatically, and things should work transparently."
msgid "For the cases where things need to be clearer though the following APIs output safe content which will by default not be (re-)escaped when injected into templates:"
msgid ":class:`markupsafe.Markup` is an unsafe API, it's an *assertion* that you want the content to be markup-safe but necessarily can not check that, it should be used with care."
msgid "See the official documentation for explanations, but the big advantage of :class:`~markupsafe.Markup` is that it's a very rich type overriding :class:`str` operations to *automatically escape parameters*."
msgid "This means that it's easy to create *safe* html snippets by using :class:`~markupsafe.Markup` on a string literal and \"formatting in\" user-provided (and thus potentially unsafe) content:"
msgid "Therefore it doesn't override methods either, and any operation involving :js:class:`Markup` will return a normal :js:class:`String` (and in reality not even that, but a \"primitive string\")."
msgid "If content is marked as safe but for some reason needs to be escaped anyway (e.g. printing the markup of an HTML fields), it can just be converted back to a normal string to \"strip\" the safety flag e.g. `str(content)` in Python and `String(content)` in Javascript."
msgid "Because :class:`~markupsafe.Markup` is a much richer type than :js:class:`Markup`, some operations will strip the safety information from a :js:class:`Markup` but not a :class:`~markupsafe.Markup` e.g. string concatenation (``'' + content``) in Python will result in a :class:`~markupsafe.Markup` with the other operand having been properly escaped, while in Javascript will yield a :js:class:`String` where the other operand was *not* escaped before the concatenation."
msgid "An alias for ``out``, would originally HTML-escape its input. Not yet formally deprecated as the only difference between ``out`` and ``esc`` is that the latter is a bit unclear / incorrect."
msgid "``t-raw`` was deprecated because as the code *producting* the content evolves it can be hard to track that it's going to be used for markup, leading to more complicated reviews and more dangerous lapses."
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 "``t-cache=\"key_cache\"`` tags part of template to be cached at rendering time. Every sub-directives will be call only during the first rendering. It means that the sql queries excecuted during the rendering of those sub-directives are also done only once."
msgid "This directive is used to speed up the rendering, by caching parts of the final document, which may save queries to the database. However, it should be used sparingly, as ``t-cache`` will inevitably complicate templates (and their understanding of ``t-set`` for example)."
msgid "However, in order to actually save database queries, it might be necessary to render the template with values that are evaluated lazily. If those lazy values are used in a cached part, they will not be evaluated if the part is available in cache."
msgid "The ``t-cache`` directive is useful for template parts using values that depend on a limited amount of data. We recommend to analyze the rendering of the template with the profiler (by activating the \"**Add qweb directive context**\" option). Passing lazy values to the rendering in controllers allow you to display the directives using these values and triggering the queries."
msgid "A concern of using such a cache are making it available to different users (different users should render the cached parts the same way). Another potential issue is to invalidate its entries when necessary. For the latter, the **key expression** should be chosen wisely. Using the ``write_date`` of a recordset can make a cache key out-of-date without having to discard it explicitly from the cache, for instance."
msgid "One should also pay attention to the fact that the values in ``t-cache`` parts are scoped. This implies that if there are ``t-set`` directives in this part of the template, the rendering of what comes after it could be different than if there was no ``t-cache`` directive."
msgid "The parts are cached. Each containing only the string corresponding to its rendering. Thus, the ``t-cache`` inside will probably be read less often, its cache key will not necessarily be used. If this must be the case, then you may need to add a ``t-nocache`` (on the same node or a parent)."
msgid "If you want to cache part of a template with ``t-cache`` but a small piece must remain dynamic and be evaluated at cache times. However, the part in ``t-nocache`` will not have access to the ``t-set`` value of the template. Only the values provided by the controller are accessible there. For example, the menu is cached because it's the same all the time and takes time to render (using the performance devtools with the qweb context lets you investigate). However, in the menu, we want the ecommerce cart to be always up to date. So there is a ``t-nocache`` to keep this part dynamic."
msgid "The ``t-cache`` directive allows you to store the rendered result of a template. The **key expression** (eg 42: ``t-cache=\"42\"``) will be evaluated as a python expression. This will be used to generate the **cache key**. So there can be different **cache values** (cached render part) for the same template part. If the **key expression** is a tuple or a list, it will be searched when generating the **cache key**. If one or more recordsets are returned by the **key expression**, then the model, ids and their corresponding write_date will be used to generate the **cache key**. Special case: If the **key expression** returns a Falsy value, then the content will not be cached."
msgid "In this case, there may be values (string) in the cache corresponding to each record already returned with a true condition, as well as for the false condition. And if a module modifies the record, the write_date being modified, the cached value is discarded."
msgid "Values in ``t-cache`` are scoped, this involves a change in behavior between having or not having ``t-cache`` on one of the parent nodes. Don't forget to take into account that Odoo uses a lot of templates, ``t-call`` and view inheritance. Adding a ``t-cache`` can therefore modify the rendering of a template that you do not see when editing. (``t-foreach`` it's like a ``t-set`` for each iteration)"
msgid "The template part contained in a node with a ``t-nocache`` attribute is not cached. This content is therefore **dynamic** and is rendered systematically. However the available values are those provided by the controller (when calling the ``_render`` method)."
msgid "The contents of the ``t-nocache`` tag can be used for documentation and to explain why the directive is added. The values are scoped into ``t-nocache``, these values are root values only (values provided by the controller and/or when calling the ``_render`` method of ``ir.qweb``). ``t-set`` can be done in the template part, but will not be available elsewhere."
msgid "Here the ``<i>`` tag that contains the container will always be rendered. While the rest is as a single string in the cache. The counter is not updated by the ``t-set`` out of the ``t-nocache``"
msgid "In order to be able to use values generated in the template, it is possible to cache them. The directive is used as ``t-nocache-*=\"expr\"`` where ``*`` is the name of the chosen value and ``expr`` the python expression so the result will be cached. The cached value must be primitive type."
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 "At a deeper level than the previous helper is the ``_render`` method on ``ir.qweb`` (use the datable) and the public module method ``render`` (don't use the database):"
msgid "``_prepare_environment`` method sets up a number of default values in the rendering context. The ``http_routing`` and ``website`` addons, also default values they need. You can use ``minimal_qcontext=False`` option to avoid this default value like the public method ``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_."
msgid "Registries are (ordered) key/value maps. They are the main web client extension points: many features provided by the Odoo javascript framework simply look up into a registry whenever it needs a definition for some object (such as fields, views, client actions or services). Customizing the web client is then simply done by adding specific values in the correct registry."
msgid "A useful feature of registries is that they maintain a set of sub registries, obtained by the `category` method. If the sub registry does not exist yet, it is created on the fly. All registries used by the web client are obtained in such a way from one root registry, exported in `@web/core/registry`."
msgid "Creates a new registry. Note that a registry is an event bus, so one can listen to the `UPDATE` event if necessary. Registries are ordered: the :js:meth:`getAll <Registry.getAll>` method returns a list of values ordered according to their sequence number."
msgid "Inserts a value at a specific key. If the key is already used, this method throws an error (unless the option `force` is set to true). The option `sequence` is useful to insert the value at a specific position. This method also triggers an `UPDATE` event."
msgid "Returns the value corresponding to the `key` argument. If the registry does not contain that key, this method returns `defaultValue` if given, or throws an error otherwise."
msgid "The `effects` registry contains the implementations of all available effects. See the section on the :ref:`effect service <frontend/services/effect_registry>` for more details."
msgid "The main component registry (`main_components`) is useful for adding top level components in the web client. The webclient has a `MainComponentsContainer` as direct child. This component is basically a live representation of the ordered list of components registered in the main components registry."
msgid "The systray is the zone on the right of the navbar that contains various small components, that usually display some sort of information (like the number of unread messages), notifications and/or let the user interact with them."
msgid "`isDisplayed (optional)`: a function that takes the :ref:`env <frontend/framework/environment>` and returns a boolean. If true, the systray item is displayed. Otherwise it is removed."
msgid "The sequence number defaults to 50. If given, this number will be used to order the items. The lowest sequence is on the right and the highest sequence is on the left in the systray menu."
msgid "The user menu registry (category: `user_menuitems`) contains all menu items that are shown when opening the user menu (the navbar element with the user name, on the top right)."
msgid "User menu items are defined by a function taking the :ref:`env <frontend/framework/environment>` and returning a plain object, containing the following information:"
msgid "Services are long lived pieces of code that provide a feature. They may be imported by components (with ``useService``) or by other services. Also, they can declare a set of dependencies. In that sense, services are basically a DI :dfn:`dependency injection` system. For example, the ``notification`` service provides a way to display a notification, or the ``rpc`` service is the proper way to perform a request to the Odoo server."
msgid "At startup, the web client starts all services present in the `services` registry. Note that the name used in the registry is the name of the service."
msgid "Most code that is not a component should be *packaged* in a service, in particular if it performs some side effect. This is very useful for testing purposes: tests can choose which services are active, so there are less chance for unwanted side effects interfering with the code being tested."
msgid "This is the main definition for the service. It can return either a value or a promise. In that case, the service loader simply waits for the promise to resolve to a value, which is then the value of the service."
msgid "Some services do not export any value. They may just do their work without a need to be directly called by other code. In that case, their value will be set to ``null`` in ``env.services``."
msgid "Some services need to provide an asynchronous API. For example, the `rpc` service is an asynchronous function, or the `orm` service provides a set of functions to call the Odoo server."
msgid "In that case, it is possible for components that use a service to be destroyed before the end of an asynchronous function call. Most of the time, the asynchronous function call needs to be ignored. Doing otherwise is potentially very risky, because the underlying component is no longer active. The `async` flag is a way to do just that: it signals to the service creator that all asynchronous calls coming from components should be left pending if the component is destroyed."
msgid "A service that depends on other services and has properly declared its ``dependencies`` simply receives a reference to the corresponding services in the second argument of the ``start`` method."
msgid "The ``useService`` hook is the proper way to use a service in a component. It simply returns a reference to the service value, that can then be used by the component later. For example:"
msgid "Effects are graphical elements that can be temporarily displayed on top of the page, usually to provide feedback to the user that something interesting happened."
msgid "And then, call it somewhere you want and you will see the result. Here, it is called in webclient.js to make it visible everywhere for the example."
msgid "While most interactions between the client and the server in odoo are `RPCs` (`XMLHTTPRequest`), lower level control on requests may sometimes be required."
msgid "`search (object)`: a dictionary mapping each search keyword (the querystring) from the url to its value. An empty string is the value if no value was explicitely given"
msgid "Updates the URL with each key/value pair from the `hash` object. If a value is set to an empty string, the key is added to the url without any corresponding value."
msgid "If true, the `replace` argument tells the router that the url hash should be completely replaced (so values not present in the `hash` object will be removed)."
msgid "This method call does not reload the page. It also does not trigger a `hashchange` event, nor a `ROUTE_CHANGE` in the :ref:`main bus <frontend/framework/bus>`. This is because this method is intended to only updates the url. The code calling this method has the responsibility to make sure that the screen is updated as well."
msgid "Redirect the browser to `url`. This method reloads the page. The `wait` argument is rarely used: it is useful in some cases where we know that the server will be unavailable for a short duration, typically just after an addon update or install operation."
msgid "The `rpc` service provides a single asynchronous function to send requests to the server. Calling a controller is very simple: the route should be the first argument and optionally, a ``params`` object can be given as a second argument."
msgid "Note that the ``rpc`` service is considered a low-level service. It should only be used to interact with Odoo controllers. To work with models (which is by far the most important usecase), one should use the ``orm`` service instead."
msgid "``xhr``, which should be a ``XMLHTTPRequest`` object. In that case, the ``rpc`` method will simply use it instead of creating a new one. This is useful when one accesses advanced features of the `XMLHTTPRequest` API."
msgid "The ``rpc`` service communicates with the server by using a ``XMLHTTPRequest`` object, configured to work with the ``application/json`` content type. So clearly the content of the request should be JSON serializable. Each request done by this service uses the ``POST`` http method."
msgid "either the odoo server returns an error (so, we call this a ``server`` error). In that case the http request will return with an http code 200 BUT with a response object containing an ``error`` key."
msgid "If it is a network error, then the error description is simply an object ``{type: 'network'}``. When a network error occurs, a :ref:`notification <frontend/services/notification>` is displayed and the server is regularly contacted until it responds. The notification is closed as soon as the server responds."
msgid "The service adds an event listener to get `click`'s on the document. The service checks if the selector contained in its href attribute is valid to distinguish anchors and Odoo actions (e.g. `<a href=\"#target_element\"></a>`). It does nothing if it is not the case."
msgid "An event `SCROLLER:ANCHOR_LINK_CLICKED` is triggered on the main application bus if the click seems to be targeted at an element. The event contains a custom event containing the `element` matching and its `id` as a reference. It may allow other parts to handle a behavior relative to anchors themselves. The original event is also given as it might need to be prevented. If the event is not prevented, then the user interface will scroll to the target element."
msgid "The scroller service emits a `SCROLLER:ANCHOR_LINK_CLICKED` event on the :ref:`main bus <frontend/framework/bus>`. To avoid the default scroll behavior of the scroller service, you must use `preventDefault()` on the event given to the listener so that you can implement your own behavior correctly from the listener."
msgid "The `title` service offers a simple API that allows to read/modify the document title. For example, if the current document title is \"Odoo\", we can change it to \"Odoo 15 - Apple\" by using the following command:"
msgid "This is a string representing the current title. It is structured in the following way: ``value_1 - ... - value_n`` where each `value_i` is a (non null) value found in the `Parts` object (returned by the `getParts` function)"
msgid "The ``setParts`` method allows to add/replace/delete several parts of the title. Delete a part (a value) is done by setting the associated key value to `null`."
msgid "An upgrade script is a Python file containing a function called :meth:`migrate`, which the upgrade process invokes during the update of a module."
msgid "The structure of an upgrade script path is :file:`$module/migrations/$version/{pre,post,end}-*.py`, where `$module` is the module for which the script will run, `$version` is the full version of the module (including Odoo's major version and the module's minor version) and `{pre|post|end}-*.py` is the file that needs to be executed. The file's name will determine the :ref:`phase <upgrade-scripts/phases>` and order in which it is executed for that module and version."
msgid "Upgrade scripts are only executed when the module is being updated. Therefore, the module's minor version set in the `$version` directory needs to be higher than the module's installed version and equal or lower to the updated version of the module."
msgid "Note that in the second example, the script takes advantage of the :doc:`./upgrade_utils` to access the ORM. Check the documentation to find out more about this library."
msgid "Upgrade scripts are grouped according to the first part of their filenames into the corresponding phase. Within each phase, the files are executed according to their lexical order."
msgid "`Upgrade utils <https://github.com/odoo/upgrade-util/>`_ is a library that contains helper functions to facilitate the writing of upgrade scripts. This library, used by Odoo for the upgrade scripts of standard modules, provides reliability and helps speed up the upgrade process:"
msgid "Clone the `Upgrade utils repository <https://github.com/odoo/upgrade-util/>`_ locally and start ``odoo`` with the ``src`` directory prepended to the ``--upgrade-path`` option."
msgid "On `Odoo.sh <https://www.odoo.sh/>`_ it is recommended to add it to the :file:`requirements.txt` of the custom repository. For this, add the following line inside the file::"
msgid "Upgrade utils provides many useful functions to ease the upgrade process. Here, we describe some of the most useful ones. Refer to the `util folder <https://github.com/odoo/upgrade-util/tree/master/src/util>`_ for the comprehensive declaration of helper functions."
msgid "All util functions receive :attr:`cr` as a parameter. This refers to the database cursor. Pass the one received as a parameter in :meth:`migrate`."
msgid "whether all references of field ``old`` to ``new`` are replaced in: ``ir_filters``, ``ir_exports_line``, ``ir_act_server``, ``mail_alias``, ``ir_ui_view_custom (dashboard)``, ``domains (using \"domain_adapter\")``, ``related fields``"
msgid "function that takes three arguments and returns a domain that substitutes the original leaf: ``(leaf: Tuple[str,str,Any], in_or: bool, negated: bool)`` -> ``List[Union[str,Tuple[str,str,Any]]]``"
msgid "Merge the references from ``source`` model into ``target`` model and removes ``source`` model and its references. By default, only the fields with the same name in both models are mapped."
msgid "This function does NOT empty the cache maintained on the cursor for superuser with an empty environment. A call to `invalidate_cache` will most probably be necessary every time you directly modify something in database."
msgid "This function is useful when migrating in-database records into a custom module, to create the record's xmlid before the module is updated and avoid duplication."
msgid "Dictionary ``{\"fieldname_1\": \"value_1\", ...}`` mapping fields and values to search for the record to update. For example: .. code-block:: python values = {\"id\": 123} values = {\"name\": \"INV/2024/0001\", company_id: 1}"
msgid "To cover FontAwesome's lack of iconography for specific functionalities, we designed our own icon-font. These icons can be rendered using the main `oi` class in conjunction with the specific icon class."
msgid "Indeed, since the compilation process acts across different interdependent bundles, re-assigning a variable in the \"wrong spot\" may lead to unexpected cascading results."
msgid "SCSS provides several techniques to overcome these issues (e.g.: `shadowing <https://sass-lang.com/documentation/variables#shadowing>`_), but the most critical procedure in Odoo is the use of the `!default` flag."
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."
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:"
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."
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."
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."
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:"
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."
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]_."
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 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 "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)."
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`."
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."
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."
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)."
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."
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 "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 "Their root element is ``<form>``. They are composed of high-level structure elements (groups, notebooks) and interactive elements (buttons and fields):"
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."
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:"
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."
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."
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::"
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::"
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 "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."
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."
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 "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."
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"
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."
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\"::"
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."
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)."
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."
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``."
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``."
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::"
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 "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."
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."
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."
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>`."
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::"
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."
msgid "Since we added a constraint for the Course name uniqueness, it is not possible to use the \"duplicate\" function anymore (:menuselection:`Form --> Duplicate`)."
msgid "Re-implement your own \"copy\" method which allows to duplicate the Course object, changing the original name into \"Copy of [original name]\"."
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."
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."
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."
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 "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)."
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 "This tutorial is an extension of the :doc:`getting_started` tutorial. Make sure you have completed it and use the `estate` module you have built as a base for the exercises in this tutorial. Fetch the branch `16.0-core` from the `technical-training-solutions <https://github.com/odoo/technical-training-solutions/tree/16.0-core>`_ repository if you want to start from a clean base."
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:`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, e.g. countries, currencies, units of measure, as well as complete country localization (legal reports, tax definitions, chart of account), and much more..."
msgid "Have a set of working data for developers to test new features and see how these new features look with data they might not have added themselves."
msgid "Demo data is automatically loaded when you start the server if you don't explicitly say 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 paths to the files declaring the data."
msgid "Usually, demo data is in a ``demo`` folder, views and actions are in a ``views`` folder, security related data is in a ``security`` folder, and other data is 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 otherwise."
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:`tutorials/getting_started/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 <tutorials/getting_started/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 "This tutorial is designed to introduce you to the basics of the Odoo Javascript framework. Whether you are new to the framework or have some prior experience, this tutorial will provide you with a solid foundation for using the Odoo JavaScript framework in your projects."
msgid "This tutorial is divided into two parts. The first part covers the basics of Owl components, which are a key part of the Odoo JS framework. Owl components are reusable UI components that can be used to build complex web interfaces quickly and efficiently. We will explore how to create and use Owl components in Odoo."
msgid "The second part of the tutorial focuses on creating a dashboard using various features of Odoo. Dashboards are an essential part of any web application, and provide a nice starting point to use and interact with the Odoo codebase."
msgid "This tutorial assumes that you have some basic knowledge of development with Odoo in general (models, controllers, QWeb, ...). If you are new to Odoo, we recommend that you start with the :doc:`Getting started </developer/tutorials/getting_started>` tutorial before proceeding with this one."
msgid "This chapter introduces the `Owl framework <https://github.com/odoo/owl>`_, a tailor-made component system for Odoo. The main building blocks of OWL are `components <https://github.com/odoo/owl/blob/master/doc/reference/component.md>`_ and `templates <https://github.com/odoo/owl/blob/master/doc/reference/templates.md>`_."
msgid "In Owl, every part of user interface is managed by a component: they hold the logic and define the templates that are used to render the user interface. In practice, a component is represented by a small JavaScript class subclassing the `Component` class."
msgid "Before getting into the exercises, make sure you have followed all the steps described in this :ref:`tutorial introduction <tutorials/discover_js_framework/setup>`."
msgid "The solutions for each exercise of the chapter are hosted on the `official Odoo tutorials repository <https://github.com/odoo/tutorials/commits/16.0-solutions/owl_playground>`_. It is recommended to try to solve them first without looking at the solution!"
msgid "If you use Chrome as your web browser, you can install the `Owl Devtools` extension. This extension provides many features to help you understand and profile any Owl application."
msgid "In this chapter, we use the `owl_playground` addon, which provides a simplified environment that only contains Owl and a few other files. The goal is to learn Owl itself, without relying on Odoo web client code. To get started, open the `/owl_playground/playground` route with your browser: it should display an Owl component with the text *hello world*."
msgid "First, let us have a look at a simple example. The `Counter` component shown below is a component that maintains an internal number value, displays it, and updates it whenever the user clicks on the button."
msgid "You maybe noticed the `owl=\"1\"` temporary attribute, it allows Odoo to differentiate Owl templates from the old JavaScript framework templates. Note that Owl templates are not the same as QWeb templates: they can contain additional directives, such as `t-on-click`."
msgid "As a first exercise, let us implement a counter in the `Playground` component located in :file:`owl_playground/static/src/`. To see the result, you can go to the `/owl_playground/playground` route with your browser."
msgid "Modify :file:`playground.js` so that it acts as a counter like in the example above. You will need to use the `useState hook <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#usestate>`_ so that the component is re-rendered whenever any part of the state object that has been read by this component is modified."
msgid "Modify the template in :file:`playground.xml` so that it displays your counter variable. Use `t-esc <https://github.com/odoo/owl/blob/master/doc/reference/templates.md#outputting-data>`_ to output the data."
msgid "Add a button in the template and specify a `t-on-click <https://github.com/odoo/owl/blob/master/doc/reference/event_handling.md#event-handling>`_ attribute in the button to trigger the `increment` method whenever the button is clicked."
msgid "The Odoo JavaScript files downloaded by the browser are minified. For debugging purpose, it's easier when the files are not minified. Switch to :ref:`debug mode with assets <developer-mode/url>` so that the files are not minified."
msgid "For now we have the logic of a counter in the `Playground` component, let us see how to create a `sub-component <https://github.com/odoo/owl/blob/master/doc/reference/component.md#sub-components>`_ from it."
msgid "You can do it in the same file first, but once it's done, update your code to move the `Counter` in its own folder and file. Import it relatively from `./counter/counter`. Make sure the template is in its own file, with the same name."
msgid "Don't forget :code:`/** @odoo-module **/` in your JavaScript files. More information on this can be found :ref:`here <frontend/modules/native_js>`."
msgid "We will create new components in :file:`owl_playground/static/src/` to keep track of a list of todos. This will be done incrementally in multiple exercises that will introduce various concepts."
msgid "Create a `Todo` component that receive a `todo` object in `props <https://github.com/odoo/owl/blob/master/doc/reference/props.md>`_, and display it. It should show something like **3. buy milk**."
msgid "Add the Bootstrap classes `text-muted` and `text-decoration-line-through` on the task if it is done. To do that, you can use `dynamic attributes <https://github.com/odoo/owl/blob/master/doc/reference/templates.md#dynamic-attributes>`_."
msgid "Modify :file:`owl_playground/static/src/playground.js` and :file:`owl_playground/static/src/playground.xml` to display your new `Todo` component with some hard-coded props to test it first."
msgid "The `Todo` component has an implicit API. It expects to receive in its props the description of a todo object in a specified format: `id`, `description` and `done`. Let us make that API more explicit. We can add a props definition that will let Owl perform a validation step in `dev mode <https://github.com/odoo/owl/blob/master/doc/reference/app.md#dev-mode>`_. You can activate the dev mode in the `App configuration <https://github.com/odoo/owl/blob/master/doc/reference/app.md#configuration>`_."
msgid "Open the :guilabel:`Console` tab of your browser's dev tools and make sure the props validation passes in dev mode, which is activated by default in `owl_playground`. The dev mode can be activated and deactivated by modifying the `dev` attribute in the in the `config` parameter of the `mount <https://github.com/odoo/owl/blob/master/doc/reference/app.md#mount-helper>`_ function in :file:`owl_playground/static/src/main.js`."
msgid "Change the code to display a list of todos instead of just one. Create a new `TodoList` component to hold the `Todo` components and use `t-foreach <https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loops>`_ in its template."
msgid "Implement `addTodo` to check if enter was pressed (:code:`ev.keyCode === 13`), and in that case, create a new todo with the current content of the input as the description and clear the input of all content."
msgid "Let's see how we can access the DOM with `t-ref <https://github.com/odoo/owl/blob/master/doc/reference/refs.md>`_ and `useRef <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useref>`_."
msgid "Focus the `input` from the previous exercise when the dashboard is `mounted <https://github.com/odoo/owl/blob/master/doc/reference/component.md#mounted>`_. This this should be done from the `TodoList` component."
msgid "Bonus point: extract the code into a specialized `hook <https://github.com/odoo/owl/blob/master/doc/reference/hooks.md>`_ `useAutofocus` in a new :file:`owl_playground/utils.js` file."
msgid "Now, let's add a new feature: mark a todo as completed. This is actually trickier than one might think. The owner of the state is not the same as the component that displays it. So, the `Todo` component needs to communicate to its parent that the todo state needs to be toggled. One classic way to do this is by using a `callback prop <https://github.com/odoo/owl/blob/master/doc/reference/props.md#binding-function-props>`_ `toggleState`."
msgid "Owl has a powerful `slot <https://github.com/odoo/owl/blob/master/doc/reference/slots.md>`_ system to allow you to write generic components. This is useful to factorize the common layout between different parts of the interface."
msgid "This component should have two slots: one slot for the title, and one for the content (the default slot). It should be possible to use the `Card` component as follows:"
msgid "The first part of this tutorial introduced you to most of Owl ideas. It is now time to learn about the Odoo JavaScript framework in its entirety, as used by the web client."
msgid "For this chapter, we will start from the empty dashboard provided by the `awesome_tshirt` addon. We will progressively add features to it, using the Odoo JavaScript framework."
msgid "The solutions for each exercise of the chapter are hosted on the `official Odoo tutorials repository <https://github.com/odoo/tutorials/commits/16.0-solutions/awesome_tshirt>`_."
msgid "Most screens in the Odoo web client uses a common layout: a control panel on top, with some buttons, and a main content zone just below. This is done using the `Layout component <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/search/layout.js>`_, available in `@web/search/layout`."
msgid "Update the `AwesomeDashboard` component located in :file:`awesome_tshirt/static/src/` to use the `Layout` component. You can use :code:`{controlPanel: { \"top-right\": false, \"bottom-right\": false } }` for the `display` props of the `Layout` component."
msgid "`Example: use of Layout in client action <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/webclient/actions/reports/report_action.js>`_ and `template <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/webclient/actions/reports/report_action.xml>`_"
msgid ":ref:`Services <frontend/services>` is a notion defined by the Odoo JavaScript framework; it is a persistent piece of code that exports a state and/or functions. Each service can depend on other services, and components can import a service with the `useService()` hook."
msgid "A button `Customers`, which opens a kanban view with all customers (this action already exists, so you should use `its xml id <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ odoo/addons/base/views/res_partner_views.xml#L525>`_)."
msgid "A button `New Orders`, which opens a list view with all orders created in the last 7 days. Use the `Domain <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ /addons/web/static/src/core/domain.js#L19>`_ helper class to represent the domain."
msgid "One way to represent the desired domain could be :code:`[('create_date','>=', (context_today() - datetime.timedelta(days=7)).strftime('%Y-%m-%d'))]`"
msgid "A button `Cancelled Order`, which opens a list of all orders created in the last 7 days, but already cancelled. Rather than defining the action twice, factorize it in a new `openOrders` method."
msgid "Let's improve the dashboard by adding a few cards (see the `Card` component :ref:`made in the previous chapter <tutorials/discover_js_framework/generic_card>`) containing a few statistics. There is a route `/awesome_tshirt/statistics` that performs some computations and returns an object containing some useful information."
msgid "Whenever we need to call a specific controller, we need to use the :ref:`rpc service <frontend/services/rpc>`. It only exports a single function that perform the request: :code:`rpc(route, params, settings)`"
msgid "`Example: calling a route in onWillStart <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/lunch/static/src/views/search_model.js#L21>`_"
msgid "If you open the :guilabel:`Network` tab of your browser's dev tools, you will see that the call to `/awesome_tshirt/statistics` is done every time the client action is displayed. This is because the `onWillStart` hook is called each time the `Dashboard` component is mounted. But in this case, we would prefer to do it only the first time, so we actually need to maintain some state outside of the `Dashboard` component. This is a nice use case for a service!"
msgid "Use the `memoize <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/core/utils/functions.js#L11>`_ utility function from `@web/core/utils/functions` that will allow caching the statistics."
msgid "Everyone likes charts (!), so let us add a pie chart in our dashboard. It will display the proportions of t-shirts sold for each size: S/M/L/XL/XXL."
msgid "For this exercise, we will use `Chart.js <https://www.chartjs.org/>`_. It is the chart library used by the graph view. However, it is not loaded by default, so we will need to either add it to our assets bundle, or lazy load it. Lazy loading is usually better since our users will not have to load the chartjs code every time if they don't need it."
msgid "Load chartjs, you can use the `loadJs <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/core/assets.js#L23>`_ function to load :file:`/web/static/lib/Chart/Chart.js`."
msgid "In a `Card` (from previous exercises), display a `pie chart <https://www.chartjs.org/docs/2.8.0/charts/doughnut.html>`_ in the dashboard that displays the correct quantity for each sold t-shirts in each size (that information is available in the statistics route)."
msgid "`Example: rendering a chart in a component <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/views/graph/graph_renderer.js#L618>`_"
msgid "`Example: use of env._t function <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/account/static/src/components/bills_upload/bills_upload.js#L64>`_"
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 "The goal of this tutorial is for you to get an insight of the most important parts of the Odoo development framework while developing your own Odoo module to manage real estate assets. 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 "Are you following this tutorial as part of your technical onboarding as an Odoo employee? Then, we ask you to complete all the chapters before joining your new team."
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 "Since version 15.0, Odoo is actively transitioning to using its own in-house developed `OWL framework <https://odoo.github.io/owl/>`_ as part of its presentation tier. The legacy JavaScript framework is still supported but will be deprecated over time. This will be discussed further in advanced topics."
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."
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 :doc:`next chapter <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 "Depending on the intended use case, there are multiple ways to install Odoo. For developers of the Odoo community and Odoo employees alike, the preferred way is to perform a source install (:dfn:`running Odoo from the source code`)."
msgid "By now, you should have downloaded the source code into two local repositories, one for `odoo/odoo` and one for `odoo/enterprise`. These repositories are set up to push changes to pre-defined shared forks on GitHub. This will prove to be convenient when you start contributing to the codebase, but for the scope of this tutorial, we want to avoid polluting the shared repositories with training material. Let's then develop your own module in a third repository `technical-training-sandbox`. Like the first two repositories, it will be part of the `addons-path` that references all directories containing Odoo modules."
msgid "Following the same process as with the `odoo/odoo` and `odoo/enterprise` repositories, visit `github.com/odoo/technical-training-sandbox <https://github.com/odoo/technical-training-sandbox>`_ and click the :guilabel:`Fork` button to create a fork of the repository under your account."
msgid "That's it! Your environment is now prepared to run Odoo from the sources, and you have successfully created a repository to serve as an addons directory. This will allow you to push your work to GitHub."
msgid "Now, make a small change in the `technical-training-sandbox` repository, such as updating the :file:`README.md` file. Then, follow the :ref:`contributing/development/first-contribution` section of the contributing guide to push your changes to GitHub and create a :abbr:`PR (Pull Request)`. This will enable you to share your upcoming work and receive feedback. Adjust the instructions to use the branch `master` and the repository `technical-training-sandbox`."
msgid "To ensure a continuous feedback loop, we recommend pushing a new commit as soon as you reach a new milestone, such as completing a chapter of the tutorial."
msgid "The specific location of the repositories on your file system is not crucial. However, for the sake of simplicity, we will assume that you have cloned all the repositories under the same directory. If this is not the case, make sure to adjust the following commands accordingly, providing the appropriate relative path from the `odoo/odoo` repository to the `odoo/technical-training-sandbox` repository."
msgid "There are multiple :ref:`command-line arguments <reference/cmdline/server>` that you can use to run the server. In this training you will only need some of them."
msgid "The :option:`--limit-time-cpu` and :option:`--limit-time-real` arguments can be used to prevent the worker from being killed when debugging the source code."
msgid "You may face an error similar to `AttributeError: module '<MODULE_NAME>' has no attribute '<$ATTRIBUTE'>`. In this case, you may need to re-install the module with :command:`$ pip install --upgrade --force-reinstall <MODULE_NAME>`."
msgid "If this error occurs with more than one module, you may need to re-install all the requirements with :command:`$ pip install --upgrade --force-reinstall -r requirements.txt`."
msgid "For now you cannot add `../technical-training-sandbox` to your `addons-path` as it is empty and will result into an invalid addons-path folder error, but you will have to add it back later on !"
msgid "Open http://localhost:8069/ on your browser. We recommend using `Chrome <https://www.google.com/intl/en/chrome/>`_, `Firefox <https://www.mozilla.org/firefox/new/>`_, or any other browser with development tools."
msgid "The developer or debug mode is useful for training as it gives access to additional (advanced) tools. In the next chapters, **we will always assume that you have enabled the developer mode**."
msgid "The main page of the Settings screen is only accessible if at least one application is installed. You will be led into installing your own application in the next chapter."
msgid "If you are working at Odoo, many of your colleagues are using `VSCode <https://code.visualstudio.com>`_, `VSCodium <https://vscodium.com>`_ (the open source equivalent), `PyCharm <https://www.jetbrains.com/pycharm/download/#section=linux>`_, or `Sublime Text <https://www.sublimetext.com>`_. However, you are free to choose your preferred editor."
msgid "It is important to configure your linters correctly. Using a linter helps you by showing syntax and semantic warnings or errors. Odoo source code tries to respect Python's and JavaScript's standards, but some of them can be ignored."
msgid "For JavaScript, we use ESLint and you can find a `configuration file example here <https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines#use-a-linter>`_."
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."
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 "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 its directory. In the `technical-training-sandbox` directory, add a new directory :file:`estate`."
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 "Restart the Odoo server and 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 "Remember to enable the :ref:`developer mode <developer-mode>` as explained in the previous chapter. You won't see the :guilabel:`Update Apps List` button otherwise."
msgid "At the end of the :ref:`previous chapter <tutorials/getting_started/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 single Odoo instance can run several databases in parallel within the same python process. Distinct modules might be installed on each of these databases, therefore we cannot rely on global variables that would be updated depending on installed modules."
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`. 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 <tutorials/getting_started/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 :doc:`../restrict_data_access`. 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/16.0/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 "Now that we've created our new :ref:`model <tutorials/getting_started/04_basicmodel>` and its corresponding :ref:`access rights <tutorials/getting_started/05_securityintro>`, it is time to interact with the user interface."
msgid "In :ref:`tutorials/getting_started/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 <tutorials/getting_started/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 <tutorials/getting_started/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 <tutorials/getting_started/07_basicviews>`."
msgid "We have seen in the :ref:`previous chapter <tutorials/getting_started/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 "XML does not allow ``<`` and ``&`` to be used inside XML elements. To avoid parsing errors, entity references should be used: ``<`` for ``<`` and ``&`` for ``&``. Other entity references (``>``, ``'`` & ``"``) are optional."
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 <tutorials/getting_started/08_relations>`."
msgid "The :ref:`previous chapter <tutorials/getting_started/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 <tutorials/getting_started/04_basicmodel>`, set the :ref:`model <tutorials/getting_started/05_securityintro>`, add an :ref:`action and a menu <tutorials/getting_started/06_firstui>`, and :ref:`create a view <tutorials/getting_started/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 <tutorials/getting_started/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 <tutorials/getting_started/09_compute_onchange>` will be lighter, don't worry ;-)"
msgid "The :ref:`relations between models <tutorials/getting_started/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:`tutorials/getting_started/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 <tutorials/getting_started/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:`tutorials/getting_started/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 <tutorials/getting_started/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/274dd3bf503e1b612179db92e410b336bfaecfb4/addons/stock/models/stock_quant.py#L239-L244>`__."
msgid "Always use the :meth:`~odoo.tools.float_utils.float_compare` and :meth:`~odoo.tools.float_utils.float_is_zero` methods from `odoo.tools.float_utils` 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 <tutorials/getting_started/12_sprinkles>`."
msgid "Our real estate module now makes sense from a business perspective. We created :ref:`specific views <tutorials/getting_started/07_basicviews>`, added several :ref:`action buttons <tutorials/getting_started/10_actions>` and :ref:`constraints <tutorials/getting_started/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:`tutorials/getting_started/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:`tutorials/getting_started/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 "It is also important to note that even though we can directly override the :meth:`~odoo.models.Model.unlink` method, you will almost always want to write a new method with the decorator :func:`~odoo.api.ondelete` instead. Methods marked with this decorator will be called during :meth:`~odoo.models.Model.unlink` and avoids some issues that can occur during uninstalling the model's module when :meth:`~odoo.models.Model.unlink` is directly overridden."
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 "Tip: create a new method with the :func:`~odoo.api.ondelete` decorator and remember that ``self`` can be a recordset with more than one record."
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 <tutorials/getting_started/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 <tutorials/getting_started/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 <tutorials/getting_started/10_actions>` on a property. To do so, we need to create a :ref:`model inheritance <tutorials/getting_started/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 "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' which have been made human readable with the :class:`~odoo.fields.Command` namespace. This namespace represents a triplet command to execute on a set of records. The triplet was originally the only option to do these commands, but it is now standard to use the namespace instead. The format is to place them in a list which is executed sequentially. 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 <tutorials/getting_started/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 "Refactor your code to respect the coding guidelines. Don't forget to run your linter and respect the module structure, the variable names, the method name convention, the model attribute order and the xml ids."
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 "This tutorial is designed for those who have completed the :doc:`discover_js_framework` tutorial and are looking to deepen their knowledge of the Odoo web framework."
msgid "For this training, we will step into the shoes of the IT staff at the fictional company Awesome T-Shirt, which is dedicated to printing custom t-shirts for online customers. The Awesome T-Shirt company uses Odoo to manage orders and has created a dedicated Odoo module to manage their workflow."
msgid "In this tutorial, we will explore various aspects of the Odoo web framework in detail, including fields and views, notifications, command palette, and much more. This tutorial will provide you with the knowledge and skills you need to take full advantage of the Odoo web framework. So, let's get started!"
msgid "In the previous chapter, we learned a range of skills, including how to create and use services, work with the Layout component, make the dashboard translatable, and lazy load a JavaScript library like Chart.js. Now, let's learn how to create new fields and views."
msgid "The solutions for each exercise of the chapter are hosted on the `official Odoo tutorials repository <https://github.com/odoo/tutorials/commits/16.0-solutions/awesome_tshirt>`_. It is recommended not to look at them before trying the exercises."
msgid "Fields and views are among the most important concepts in the Odoo user interface. They are key to many important user interactions, and should therefore work perfectly. In the context of the JavaScript framework, fields are components specialized for visualizing/editing a specific field for a given record. For example, a (Python) model may define a char field, which will be represented by a field component `CharField`."
msgid "A field component is basically just a component registered in the `fields` :ref:`registry <frontend/registries>`. The field component may define some additional static keys (metadata), such as `displayName` or `supportedTypes`, and the most important one: `extractProps`, which prepare the base props received by the `CharField`."
msgid "It receives an `update` function in its props, which is used by the field to notify the owner of the state that the value of this field has been changed. Note that the field does not (and should not) maintain a local state with its value. Whenever the change has been applied, it will come back (possibly after an onchange) by the way of the props."
msgid "It defines an `extractProps` function. This is a step that translates generic standard props, specific to a view, to specialized props, useful to the component. This allows the component to have a better API, and may make it so that it is reusable."
msgid "Fields have to be registered in the `fields` registry. Once it's done, they can be used in some views (namely: `form`, `list`, `kanban`) by using the `widget` attribute."
msgid "Each new order on the website will be created as an `awesome_tshirt.order`. This model has a `image_url` field (of type `char`), which is currently only visible as a string. We want to be able to see the image itself in the form view."
msgid "Create a new `ImagePreview` component and register it in the proper :ref:`registry <frontend/registries>`. Use the `CharField` component in your template. You can use `t-props <https://github.com/odoo/owl/blob/master/doc/reference/props.md#dynamic-props>`_ to pass props received by `ImagePreview` to `CharField`. Update the arch of the form view to use your new field by setting the `widget` attribute."
msgid "There is a `is_late`, readonly, boolean field on the order model. That would be useful information to see on the list/kanban/view. Then, let us say that we want to add a red word \"Late!\" next to it whenever it is set to `true`."
msgid "Create a new `LateOrderBoolean` field inheriting from `BooleanField`. The template of `LateOrderBoolean` can also :ref:`inherit <reference/qweb/template_inheritance>` from the `BooleanField` template."
msgid "Odoo form views support a `widget` API, which is like a field, but more generic. It is useful to insert arbitrary components in the form view. Let us see how we can use it."
msgid "`Example: Using the tag <widget> in a form view <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/calendar/views/calendar_views.xml#L197>`_"
msgid "Let’s see how we can display raw HTML in a template. The `t-out` directive can be used for that propose. Indeed, `it generally acts like t-esc, unless the data has been marked explicitly with a markup function <https://github.com/odoo/owl/blob/master/doc/reference/templates.md#outputting-data>`_. In that case, its value is injected as HTML."
msgid "Views are among the most important components in Odoo: they allow users to interact with their data. Let us discuss how Odoo views are designed."
msgid "The power of Odoo views is that they declare how a particular screen should work with an XML document (usually named `arch`, short for architecture). This description can be extended/modified by xpaths serverside. Then, the browser loads that document, parses it (fancy word to say that it extracts the useful information), and then represents the data accordingly."
msgid "The view description can define a `props` function, which receives the standard props, and computes the base props of the concrete view. The `props` function is executed only once, and can be thought of as being some kind of factory. It is useful to parse the `arch` XML document, and to allow the view to be parameterized (for example, it can return a Renderer component that will be used as Renderer). Then, it is easy to customize the specific renderer used by a sub view."
msgid "Finally, the root component, commonly called the `Controller`, coordinates everything. It uses the generic `Layout` component (to add a control panel), instantiates a `Model`, and uses a `Renderer` component in the `Layout` default slot. The `Model` is tasked with loading and updating data, and the `Renderer` is supposed to handle all rendering work, along with all user interactions."
msgid "In practice, once the t-shirt order is printed, we need to print a label to put on the package. To do that, let us add a button in the order's form view's control panel, which will call a model method."
msgid "There is a service dedicated to calling models methods: `orm_service`, located in `core/orm_service.js`. It provides a way to call common model methods, as well as a generic `call(model, method, args, kwargs)` method."
msgid "The button should be displayed as a primary button if the customer is properly set and if the task stage is `printed`. Otherwise, it should be displayed as a secondary button."
msgid "`Example: Using a js_class attribute <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/mass_mailing/views/mailing_contact_views.xml#L44>`_"
msgid "`Example: Using the orm service <https://github.com/odoo/odoo/blob/16.0/addons/account/static/src/components/open_move_widget/open_move_widget.js>`_"
msgid "Bafien is upset: he wants to see the kanban view of the tshirt orders on his external monitor, but the view needs to be up-to-date. He is tired of clicking on the :guilabel:`refresh` icon every 30s, so he tasked you to find a way to do it automatically."
msgid "If you use `setInterval` or something similar, make sure that it is properly canceled when your component is unmounted. Otherwise, you will introduce a memory leak."
msgid "In the previous task, we learned how to create fields and views. There is still much more to discover in the feature-rich Odoo web framework, so let's dive in and explore more in this chapter!"
msgid "After using the :guilabel:`Print Label` button for some t-shirt tasks, it is apparent that there should be some feedback that the `print_label` action is completed (or failed, for example, the printer is not connected or ran out of paper)."
msgid "`Example: Using the notification service <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/views/fields/image_url/image_url_field.js>`_"
msgid "Our beloved leader wants to keep a close eye on new orders. He wants to see the number of new, unprocessed orders at all time. Let's do that with a systray item."
msgid "A :ref:`systray <frontend/registries/systray>` item is an element that appears in the system tray, which is a small area located on the right-hand side of the navbar. The systray is used to display notifications and provide access to certain features."
msgid "Bonus point: avoid making the initial RPC by adding the information to the session info. The session info is given to the web client by the server in the initial response."
msgid "`Example: Reading the session information <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/barcodes/static/src/barcode_service.js#L5>`_"
msgid "So far, the systray item from above does not update unless the user refreshes the browser. Let us do that by calling periodically (for example, every minute) the server to reload the information."
msgid "Now, the question arises: how is the systray item notified that it should re-render itself? It can be done in various ways but, for this training, we choose to use the most *declarative* approach:"
msgid "Modify the `tshirt` service to return a `reactive <https://github.com/odoo/owl/blob/master/doc/reference/reactivity.md#reactive>`_ object. Reloading data should update the reactive object in place."
msgid "The systray item can then perform a `useState <https://github.com/odoo/owl/blob/master/doc/reference/reactivity.md#usestate>`_ on the service return value."
msgid "`Example: Use of reactive in a service <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/core/debug/profiling/profiling_service.js#L30>`_"
msgid "Now, let us see how we can interact with the command palette. The command palette is a feature that allows users to quickly access various commands and functions within the application. It is accessed by pressing `CTRL+K` in the Odoo interface."
msgid "Modify the :ref:`image preview field <tutorials/master_odoo_web_framework/image_preview_field>` to add a command to the command palette to open the image in a new browser tab (or window)."
msgid "`Example: Using the useCommand hook <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/core/debug/debug_menu.js#L15>`_"
msgid "Often, we can achieve what we want by using existing extension points that allow for customization, such as registering something in a registry. Sometimes, however, it happens that we want to modify something that has no such mechanism. In that case, we must fall back on a less safe form of customization: monkey patching. Almost everything in Odoo can be monkey patched."
msgid "Bafien, our beloved leader, heard about employees performing better if they are constantly being watched. Since he cannot be there in person for each of his employees, he tasked you with updating the user interface to add a blinking red eye in the control panel. Clicking on that eye should open a dialog with the following message: \"Bafien is watching you. This interaction is recorded and may be used in legal proceedings if necessary. Do you agree to these terms?\""
msgid ":ref:`Inherit <reference/qweb/template_inheritance>` the `web.Breadcrumbs` template of the `ControlPanel component <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/search/control_panel>`_ to add an icon next to the breadcrumbs. You might want to use the `fa-eye` or `fa-eyes` icons."
msgid ":doc:`Patch </developer/reference/frontend/patching_code>` the component to display the message on click by using `the dialog service <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/core/dialog/dialog_service.js>`_. You can use `ConfirmationDialog <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js>`_."
msgid "Add the CSS class `blink` to the element representing the eye and paste the following code in a new CSS file located in your patch's directory."
msgid "`Code: The patch function <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/core/utils/patch.js#L16>`_"
msgid "`Example: Using the dialog service <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/board/static/src/board_controller.js#L88>`_"
msgid "Let's see how to use some standard components to build a powerful feature combining autocomplete, fetching data, and fuzzy lookup. We will add an input in our dashboard to easily search all orders from a given customer."
msgid "Update :file:`tshirt_service.js` to add a `loadCustomers` method, which returns a promise that returns the list of all customers (and only performs the call once)."
msgid "Add the `AutoComplete component <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/core/autocomplete>`_ to the dashboard, next to the buttons in the control panel."
msgid "Fetch the list of customers with the tshirt service, and display it in the AutoComplete component, filtered by the `fuzzyLookup <https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/core/utils/search.js>`_ method."
msgid "Let us add a special mode to Odoo: whenever the URL contains `kitten=1`, we will display a kitten in the background of Odoo, because we like kittens."
msgid "Create a `kitten` service, which should check the content of the active URL hash with the help of the :ref:`router service <frontend/services/router>`. If `kitten` is set in the URL, add the class `o-kitten-mode` to the document body."
msgid "Add a command to the command palette to toggle the kitten mode. Toggling the kitten mode should toggle the class `o-kitten-mode` and update the current URL accordingly."
msgid "This is not really necessary, but the exercise is interesting. Imagine that our awesome dashboard is a large application with potentially multiple external libraries and lots of code/styles/templates. Also, suppose that the dashboard is used only by some users in some business flows. It would be interesting to lazy load it in order to speed up the loading of the web client in most cases."
msgid "So far, we only removed the dashboard from the main bundle; we now want to lazy load it. Currently, no client action is registered in the action registry."
msgid "Register `AwesomeDashboard` as a `LazyComponent <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/core/assets.js#L265-L282>`_."
msgid "If you open the :guilabel:`Network` tab of your browser's dev tools, you should see that :file:`awesome_tshirt.dashboard.min.js` is now loaded only when the Dashboard is first accessed."
msgid "It is highly recommended that you complete :doc:`01_fields_and_views` before starting this chapter. The concepts introduced in Chapter 3, including views and examples, will be essential for understanding the material covered in this chapter."
msgid "We have gained an understanding of the numerous capabilities offered by the Odoo web framework. As a next step, we will customize a kanban view. This is a more complicated project that will showcase some non trivial aspects of the framework. The goal is to practice composing views, coordinating various aspects of the UI, and doing it in a maintainable way."
msgid "Bafien had the greatest idea ever: a mix of a kanban view and a list view would be perfect for your needs! In a nutshell, he wants a list of customers on the left of the task's kanban view. When you click on a customer on the left sidebar, the kanban view on the right is filtered to only display orders linked to that customer."
msgid "Create a new template extending (XPath) the kanban controller template to add the `CustomerList` next to the kanban renderer. Give it an empty function as `selectCustomer` for now."
msgid "To solve the previous two exercises, it is likely that you used an event listener on the inputs. Let us see how we could do it in a more declarative way, with the `t-model <https://github.com/odoo/owl/blob/master/doc/reference/input_bindings.md>`_ directive."
msgid "Make sure you have a reactive object that represents the fact that the filter is active (something like :code:`this.state = useState({ displayActiveCustomers: false, searchString: ''})`)."
msgid "This is actually pretty hard, in particular in combination with the filtering done in the previous exercise. There are many edge cases to take into account."
msgid "Let us see how one can create a new view, completely from scratch. In a way, it is not very difficult to do, but there are no really good resources on how to do it. Note that most situations should be solved by either customizing an existing view, or with a client action."
msgid "For this exercise, let's assume that we want to create a `gallery` view, which is a view that lets us represent a set of records with an image field. In our Awesome Tshirt scenario, we would like to be able to see a set of t-shirts images."
msgid "The problem could certainly be solved with a kanban view, but this means that it is not possible to have our normal kanban view and the gallery view in the same action."
msgid "To complete the tasks in this chapter, you will need to install the awesome_gallery addon. This addon includes the necessary server files to add a new view."
msgid "The solutions for each exercise of the chapter are hosted on the `official Odoo tutorials repository <https://github.com/odoo/tutorials/commits/16.0-solutions/awesome_gallery>`_."
msgid "It is probably a little overkill to do it like that, since we basically only need to read one attribute from the arch, but it is a design that is used by every other odoo views, since it lets us extract some upfront processing out of the controller."
msgid "Add a :code:`loadImages(domain) {...}` method to the `GalleryController`. It should perform a `webSearchRead` call from the orm service to fetch records corresponding to the domain, and use `imageField` received in props."
msgid "Real views are a little bit more organized. This may be overkill in this example, but it is intended to learn how to structure code in Odoo. Also, this will scale better with changing requirements."
msgid "`Code: The switchView function <https://github.com/odoo/odoo/blob/1f4e583ba20a01f4c44b0a4ada42c4d3bb074273/ addons/web/static/src/webclient/actions/action_service.js#L1329>`_"
msgid "We have a nice and useful view so far. But in real life, we may have issue with users incorrectly encoding the `arch` of their Gallery view: it is currently only an unstructured piece of XML."
msgid "Automatically testing code is important when working on a codebase. It helps ensure we don't introduce (too many) bugs or regressions. Let us see how to test our code."
msgid "The solutions for each exercise of the chapter are hosted on the `official Odoo tutorials repository <https://github.com/odoo/tutorials/commits/16.0-solutions>`_."
msgid "To make sure our application works as expected, we can perform :ref:`integration testing <reference/testing/integration-testing>` by creating a tour: this is a sequence of steps that we can execute. Each step wait until some desired DOM state is reached, then performs an action. If, at some point, it is unable to go to the next step for a long time, the tour fails."
msgid "It is also useful to test independently a component or a piece of code. :ref:`QUnit <reference/testing/qunit>` tests are useful to quickly locate an issue."
msgid "`Example: Testing a list view <https://github.com/odoo/odoo/blob/16.0/addons/web/static/tests/views/list_view_tests.js>`_"
msgstr ""
#: ../../content/developer/tutorials/mixins.rst:3
msgid "Reuse code with mixins"
msgstr ""
#: ../../content/developer/tutorials/mixins.rst:5
msgid "If you need to interface with common Odoo features such as the chatter, you can rely on :doc:`mixins <../reference/backend/mixins>`. They are Odoo models exposing useful methods through inheritance."
msgstr ""
#: ../../content/developer/tutorials/mixins.rst:9
msgid "To learn and play with mixins, visit `this repository <https://github.com/tivisse/odoodays-2018/>`_. This module for a plant nursery is training material developed for the OXP 2018. You don't need to code it on your side. But you can check the presentations in the :file:`/static/pdf` directory and play with the module to discover some magic features in Odoo."
msgid "We were previously :ref:`introduced to QWeb <tutorials/getting_started/15_qwebintro>` 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 at the top level of your module's directory. If a module has many or multiple long report templates, then they are often organized logically across different files named after the report(s) they contain. All actions for the reports are usually stored in the same file ending with ``_reports.xml``, regardless of the number of reports it contains."
msgid "Don't forget to add whatever files your template and action view will be into 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 the :doc:`define_module_data` tutorial (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/16.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/16.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 Font Awesome (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, and Odoo will auto-magically add it for you. Another common use case of the report action is to link it to a button as we learned in :ref:`tutorials/getting_started/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 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 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 of 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 "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 <tutorials/getting_started/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 limit 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 :doc:`master data <define_module_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 "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 "Where does that **category** comes from ? It's a *module category*. Here we used the category id ``base.module_category_real_estate_brokerage`` which was automatically generated by Odoo based on the `category` set in the ``__manifest__.py`` of the module. You can also find here the list of `default module categories <https://github.com/odoo/odoo/blob/71da80deb044852a2af6b111d695f94aad7803ac/odoo/addons/base/data/ir_module_category_data.xml>`_ provided by Odoo."
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 and update it, but not create or delete it."
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 "*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 recordset, 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 as well as the specific property the invoice is for."
msgid ":ref:`reference/howtos/company` for an overview of multi-company facilities in general, and :ref:`multi-company security rules <howto/company/security>` in particular."
msgid "For one reason or another we might need to manage our real-estate business as multiple companies e.g. we might have largely autonomous agencies, 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 of 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 multi-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 real-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 another part of the interface or by :doc:`performing operations remotely using RPC <../reference/external_api>`, 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 "**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 otherwise."
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 regardless of the modifications done. Correcting a typo in an error message or refactoring a whole module triggers the same tests. All modules will be installed as well. This means something might not work even if the Runbot is green, i.e. your changes depend on a module that the module the changes are in doesn'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 also be excluded."
msgid "There is a nightly build running additional tests: 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 to 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 into the main repositories."
msgid "When the last batch is green, the reviewer can ask robodoo to merge your PR (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 also modular. This means tests are defined in the module that adds the functionality you are adding in, and 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. Therefore, 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 in a ``tests`` folder at 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 "All the tests should extend ``odoo.tests.common.TransactionCase``. You usually define a ``setUpClass`` and the tests. After writing the `setUpClass`, you have an `env` available in the class and can start interacting with the ORM."
msgid "For better 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; this common class can define the whole setup for the module. For instance, in `account <https://github.com/odoo/odoo/blob/16.0/addons/account/tests/common.py>`__."
msgid "and create tests for both of these cases. Additionally check that selling a property that can be sold is correctly marked as sold after selling it."
msgid "Tip: remember the note about `Form` a little bit above."
msgstr ""
#: ../../content/developer/tutorials/web.rst:5
msgid "Customizing the web client"
msgstr ""
#: ../../content/developer/tutorials/web.rst:8
msgid "This tutorial is outdated."
msgstr ""
#: ../../content/developer/tutorials/web.rst:14
msgid "This guide is about creating modules for Odoo's web client."
msgstr ""
#: ../../content/developer/tutorials/web.rst:16
msgid "To create websites with Odoo, see :doc:`website`; to add business capabilities or extend existing business systems of Odoo, see :doc:`backend`."
msgid "Let's start with a simple Odoo module holding basic web component configuration and letting us test the web framework."
msgstr ""
#: ../../content/developer/tutorials/web.rst:35
msgid "The example module is available online and can be downloaded using the following command:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:42
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/tutorials/web.rst:47
msgid "If you browse the ``petstore`` folder, you should see the following content:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:73
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/tutorials/web.rst:77
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/tutorials/web.rst:82
msgid "``oepetstore/static/css/petstore.css``"
msgstr ""
#: ../../content/developer/tutorials/web.rst:83
msgid "Currently empty, will hold the CSS_ for pet store content"
msgstr ""
#: ../../content/developer/tutorials/web.rst:84
msgid "``oepetstore/static/xml/petstore.xml``"
msgstr ""
#: ../../content/developer/tutorials/web.rst:85
msgid "Mostly empty, will hold :ref:`reference/qweb` templates"
msgstr ""
#: ../../content/developer/tutorials/web.rst:104
msgid "``oepetstore/static/js/petstore.js``"
msgstr ""
#: ../../content/developer/tutorials/web.rst:87
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/tutorials/web.rst:106
msgid "Which only prints a small message in the browser's console."
msgstr ""
#: ../../content/developer/tutorials/web.rst:108
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/tutorials/web.rst:114
msgid "All JavaScript files are concatenated and :term:`minified` to improve application load time."
msgstr ""
#: ../../content/developer/tutorials/web.rst:117
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/tutorials/web.rst:131
msgid "This will reload the web client with optimizations disabled, making development and debugging significantly more comfortable."
msgstr ""
#: ../../content/developer/tutorials/web.rst:134
msgid "qweb files hooked via __manifest__.py, but js and CSS use bundles"
msgstr ""
#: ../../content/developer/tutorials/web.rst:137
msgid "Odoo JavaScript Module"
msgstr ""
#: ../../content/developer/tutorials/web.rst:139
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/tutorials/web.rst:144
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/tutorials/web.rst:147
msgid "``oepetstore/static/js/petstore.js`` contains a module declaration::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:153
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/tutorials/web.rst:157
msgid "When the web client loads your module it will call the root function and provide two parameters:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:160
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/tutorials/web.rst:164
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/tutorials/web.rst:171
msgid "Classes"
msgstr ""
#: ../../content/developer/tutorials/web.rst:173
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/tutorials/web.rst:177
msgid "For simplicity and developer-friendliness Odoo web provides a class system based on John Resig's `Simple JavaScript Inheritance`_."
msgstr ""
#: ../../content/developer/tutorials/web.rst:180
msgid "New classes are defined by calling the :func:`~odoo.web.Class.extend` method of :class:`odoo.web.Class`::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:189
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/tutorials/web.rst:193
msgid "Classes are instantiated using the ``new`` operator::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:199
msgid "And attributes of the instance can be accessed via ``this``::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:212
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/tutorials/web.rst:229
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/tutorials/web.rst:243
msgid "When overriding a method using inheritance, you can use ``this._super()`` to call the original method::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:259
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/tutorials/web.rst:282
msgid "Widgets Basics"
msgstr ""
#: ../../content/developer/tutorials/web.rst:284
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/tutorials/web.rst:289
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/tutorials/web.rst:296
msgid "Your First Widget"
msgstr ""
#: ../../content/developer/tutorials/web.rst:298
msgid "The initial demonstration module already provides a basic widget::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:306
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/tutorials/web.rst:310
msgid "This line at the end of the file::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:315
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/tutorials/web.rst:322
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/tutorials/web.rst:326
msgid "Display Content"
msgstr ""
#: ../../content/developer/tutorials/web.rst:328
msgid "Widgets have a number of methods and features, but the basics are simple:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:330
msgid "set up a widget"
msgstr ""
#: ../../content/developer/tutorials/web.rst:331
msgid "format the widget's data"
msgstr ""
#: ../../content/developer/tutorials/web.rst:332
msgid "display the widget"
msgstr ""
#: ../../content/developer/tutorials/web.rst:334
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/tutorials/web.rst:339
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/tutorials/web.rst:344
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/tutorials/web.rst:348
msgid "Let's add some content to the widget's root element, using jQuery::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:356
msgid "That message will now appear when you open :menuselection:`Pet Store --> Pet Store --> Home Page`"
msgstr ""
#: ../../content/developer/tutorials/web.rst:361
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/tutorials/web.rst:364
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/tutorials/web.rst:373
msgid "We can now add our ``GreetingsWidget`` to the ``HomePage`` by using the ``GreetingsWidget``'s :func:`~odoo.Widget.appendTo` method::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:384
msgid "``HomePage`` first adds its own content to its DOM root"
msgstr ""
#: ../../content/developer/tutorials/web.rst:385
msgid "``HomePage`` then instantiates ``GreetingsWidget``"
msgstr ""
#: ../../content/developer/tutorials/web.rst:386
msgid "Finally it tells ``GreetingsWidget`` where to insert itself, delegating part of its :attr:`~odoo.Widget.$el` to the ``GreetingsWidget``."
msgstr ""
#: ../../content/developer/tutorials/web.rst:389
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/tutorials/web.rst:394
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/tutorials/web.rst:408
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/tutorials/web.rst:420
msgid "Which clearly shows the two ``<div>`` elements automatically created by :class:`~odoo.Widget`, because we added some classes on them."
msgstr ""
#: ../../content/developer/tutorials/web.rst:423
msgid "We can also see the two message-holding divs we added ourselves"
msgstr ""
#: ../../content/developer/tutorials/web.rst:425
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/tutorials/web.rst:431
msgid "Widget Parents and Children"
msgstr ""
#: ../../content/developer/tutorials/web.rst:433
msgid "In the previous part, we instantiated a widget using this syntax::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:437
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/tutorials/web.rst:441
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/tutorials/web.rst:446
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/tutorials/web.rst:457
msgid ":func:`~odoo.Widget.getParent`"
msgstr ""
#: ../../content/developer/tutorials/web.rst:450
msgid "can be used to get the parent of a widget::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:469
msgid ":func:`~odoo.Widget.getChildren`"
msgstr ""
#: ../../content/developer/tutorials/web.rst:460
msgid "can be used to get a list of its children::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:471
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/tutorials/web.rst:482
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/tutorials/web.rst:488
msgid "Destroying Widgets"
msgstr ""
#: ../../content/developer/tutorials/web.rst:490
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/tutorials/web.rst:495
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/tutorials/web.rst:503
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/tutorials/web.rst:509
msgid "The QWeb Template Engine"
msgstr ""
#: ../../content/developer/tutorials/web.rst:511
msgid "In the previous section we added content to our widgets by directly manipulating (and adding to) their DOM::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:516
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/tutorials/web.rst:520
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/tutorials/web.rst:523
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/tutorials/web.rst:529
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/tutorials/web.rst:536
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/tutorials/web.rst:540
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/tutorials/web.rst:547
msgid "Using QWeb"
msgstr ""
#: ../../content/developer/tutorials/web.rst:549
msgid "First let's define a simple QWeb template in the almost-empty ``oepetstore/static/src/xml/petstore.xml`` file:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:561
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/tutorials/web.rst:571
msgid ":func:`QWeb.render` looks for the specified template, renders it to a string and returns the result."
msgstr ""
#: ../../content/developer/tutorials/web.rst:574
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/tutorials/web.rst:585
msgid "Although the result looks similar, there are two differences between these usages:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:588
msgid "with the second version, the template is rendered right before :func:`~odoo.Widget.start` is called"
msgstr ""
#: ../../content/developer/tutorials/web.rst:590
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/tutorials/web.rst:596
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/tutorials/web.rst:602
msgid "QWeb Context"
msgstr ""
#: ../../content/developer/tutorials/web.rst:604
msgid "QWeb templates can be given data and can contain basic display logic."
msgstr ""
#: ../../content/developer/tutorials/web.rst:606
msgid "For explicit calls to :func:`QWeb.render`, the template data is passed as second parameter::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:611
msgid "with the template modified to:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:619
msgid "will result in:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:625
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/tutorials/web.rst:656
msgid "Template Declaration"
msgstr ""
#: ../../content/developer/tutorials/web.rst:658
msgid "We've seen how to *render* QWeb templates, let's now see the syntax of the templates themselves."
msgstr ""
#: ../../content/developer/tutorials/web.rst:661
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/tutorials/web.rst:664
msgid "The most basic directive is ``t-name``, used to declare new templates in a template file:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:675
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/tutorials/web.rst:680
msgid "Escaping"
msgstr ""
#: ../../content/developer/tutorials/web.rst:682
msgid "The ``t-esc`` directive can be used to output text:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:688
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/tutorials/web.rst:697
msgid "or method calls:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:704
msgid "Outputting HTML"
msgstr ""
#: ../../content/developer/tutorials/web.rst:706
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/tutorials/web.rst:716
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"
msgstr ""
#: ../../content/developer/tutorials/web.rst:723
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/tutorials/web.rst:740
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/tutorials/web.rst:745
msgid "Iteration"
msgstr ""
#: ../../content/developer/tutorials/web.rst:747
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/tutorials/web.rst:761
msgid "``t-foreach`` can also be used with numbers and objects (dictionaries)"
msgstr ""
#: ../../content/developer/tutorials/web.rst:765
msgid "Defining attributes"
msgstr ""
#: ../../content/developer/tutorials/web.rst:767
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/tutorials/web.rst:772
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/tutorials/web.rst:783
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/tutorials/web.rst:796
msgid "Calling other templates"
msgstr ""
#: ../../content/developer/tutorials/web.rst:798
msgid "Templates can be split into sub-templates (for simplicity, maintainability, reusability or to avoid excessive markup nesting)."
msgstr ""
#: ../../content/developer/tutorials/web.rst:801
msgid "This is done using the ``t-call`` directive, which takes the name of the template to render:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:815
msgid "rendering the ``A`` template will result in:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:823
msgid "Sub-templates inherit the rendering context of their caller."
msgstr ""
#: ../../content/developer/tutorials/web.rst:826
msgid "To Learn More About QWeb"
msgstr ""
#: ../../content/developer/tutorials/web.rst:828
msgid "For a QWeb reference, see :ref:`reference/qweb`."
msgstr ""
#: ../../content/developer/tutorials/web.rst:831
#: ../../content/developer/tutorials/web.rst:1097
msgid "Exercise"
msgstr ""
#: ../../content/developer/tutorials/web.rst:833
msgid "Usage of QWeb in Widgets"
msgstr ""
#: ../../content/developer/tutorials/web.rst:835
msgid "Create a widget whose constructor takes two parameters aside from ``parent``: ``product_names`` and ``color``."
msgstr ""
#: ../../content/developer/tutorials/web.rst:838
msgid "``product_names`` should an array of strings, each one the name of a product"
msgstr ""
#: ../../content/developer/tutorials/web.rst:840
msgid "``color`` is a string containing a color in CSS color format (ie: ``#000000`` for black)."
msgstr ""
#: ../../content/developer/tutorials/web.rst:843
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/tutorials/web.rst:848
msgid "Use the widget in ``HomePage`` with half a dozen products."
msgstr ""
#: ../../content/developer/tutorials/web.rst:912
msgid "Widget Helpers"
msgstr ""
#: ../../content/developer/tutorials/web.rst:915
msgid "``Widget``'s jQuery Selector"
msgstr ""
#: ../../content/developer/tutorials/web.rst:917
msgid "Selecting DOM elements within a widget can be performed by calling the ``find()`` method on the widget's DOM root::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:922
msgid "But because it's a common operation, :class:`~odoo.Widget` provides an equivalent shortcut through the :func:`~odoo.Widget.$` method::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:933
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/tutorials/web.rst:941
msgid "Easier DOM Events Binding"
msgstr ""
#: ../../content/developer/tutorials/web.rst:943
msgid "We have previously bound DOM events using normal jQuery event handlers (e.g. ``.click()`` or ``.change()``) on widget elements::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:958
msgid "While this works it has a few issues:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:960
msgid "it is rather verbose"
msgstr ""
#: ../../content/developer/tutorials/web.rst:961
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/tutorials/web.rst:964
msgid "it requires dealing with ``this``-binding issues"
msgstr ""
#: ../../content/developer/tutorials/web.rst:966
msgid "Widgets thus provide a shortcut to DOM event binding via :attr:`~odoo.Widget.events`::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:978
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/tutorials/web.rst:981
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/tutorials/web.rst:986
msgid "the value is the action to perform when the event is triggered"
msgstr ""
#: ../../content/developer/tutorials/web.rst:988
msgid "It can be either a function::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:994
msgid "or the name of a method on the object (see example above)."
msgstr ""
#: ../../content/developer/tutorials/web.rst:996
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/tutorials/web.rst:1000
msgid "Widget Events and Properties"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1005
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/tutorials/web.rst:1025
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/tutorials/web.rst:1029
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/tutorials/web.rst:1033
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/tutorials/web.rst:1051
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/tutorials/web.rst:1070
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/tutorials/web.rst:1076
msgid "Properties"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1078
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/tutorials/web.rst:1091
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/tutorials/web.rst:1094
msgid ":func:`~odoo.Widget.get` retrieves the value of a property."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1099
msgid "Widget Properties and Events"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1101
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/tutorials/web.rst:1111
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/tutorials/web.rst:1117
msgid "Use QWeb to generate all HTML."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1190
msgid "Modify existing widgets and classes"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1192
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/tutorials/web.rst:1210
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/tutorials/web.rst:1213
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/tutorials/web.rst:1223
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/tutorials/web.rst:1230
msgid "These lines are simply used to import the translation functions in the current JavaScript module. They are used thus::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1235
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/tutorials/web.rst:1241
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/tutorials/web.rst:1246
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/tutorials/web.rst:1256
msgid "This makes translatable strings more readable to translators, and gives them more flexibility to reorder or ignore parameters."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1259
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/tutorials/web.rst:1263
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/tutorials/web.rst:1268
msgid "Communication with the Odoo Server"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1271
msgid "Contacting Models"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1273
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/tutorials/web.rst:1277
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/tutorials/web.rst:1282
msgid "To demonstrate this, the file ``petstore.py`` already contains a small model with a sample method:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1297
msgid "This declares a model with two fields, and a method ``my_method()`` which returns a literal dictionary."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1300
msgid "Here is a sample widget that calls ``my_method()`` and displays the result::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1313
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/tutorials/web.rst:1317
msgid ":func:`~odoo.web.Model.call` can be used to call any (public) method of an Odoo model. It takes the following positional arguments:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1321
msgid "The name of the method to call, ``my_method`` here"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1323
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/tutorials/web.rst:1327
msgid "Here is an other example with positional arguments:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1351
msgid "``kwargs``"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1340
msgid "a mapping of `keyword arguments`_ to pass. The example provides a single named argument ``context``."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1353
msgid ":func:`~odoo.Widget.call` returns a deferred resolved with the value returned by the model's method as first argument."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1357
msgid "CompoundContext"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1359
msgid "The previous section used a ``context`` argument which was not explained in the method call::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1364
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/tutorials/web.rst:1371
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/tutorials/web.rst:1376
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/tutorials/web.rst:1394
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/tutorials/web.rst:1400
msgid "Queries"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1402
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/tutorials/web.rst:1417
msgid "versus::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1427
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/tutorials/web.rst:1431
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/tutorials/web.rst:1436
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/tutorials/web.rst:1443
msgid "Exercises"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1445
msgid "Message of the Day"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1447
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/tutorials/web.rst:1451
msgid "Display the widget in the Pet Store home page."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1511
msgid "Pet Toys List"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1513
msgid "Create a ``PetToysList`` widget displaying 5 toys (using their name and their images)."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1516
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/tutorials/web.rst:1523
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/tutorials/web.rst:1527
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/tutorials/web.rst:1647
msgid "Existing web components"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1650
msgid "The Action Manager"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1652
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/tutorials/web.rst:1655
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/tutorials/web.rst:1660
msgid "In Odoo Web, the component responsible for handling and reacting to these actions is the *Action Manager*."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1664
msgid "Using the Action Manager"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1666
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/tutorials/web.rst:1670
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/tutorials/web.rst:1686
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:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1691
msgid "The model to display in views"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1693
msgid "For form views, a preselected record in ``res_model``"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1695
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."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1701
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/tutorials/web.rst:1704
msgid "Additional context data to use within the action."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1706
msgid "Jump to Product"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1708
msgid "Modify the ``PetToysList`` component so clicking on a toy replaces the homepage by the toy's form view."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1755
msgid "Client Actions"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1757
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/tutorials/web.rst:1762
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/tutorials/web.rst:1767
msgid "Our widget is registered as the handler for the client action through this::"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1772
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/tutorials/web.rst:1778
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/tutorials/web.rst:1782
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/tutorials/web.rst:1786
msgid "On the server side, we had simply defined an ``ir.actions.client`` action:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1794
msgid "and a menu opening the action:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1802
msgid "Architecture of the Views"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1804
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/tutorials/web.rst:1808
msgid "The View Manager"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1810
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/tutorials/web.rst:1820
msgid "The Views"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1822
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/tutorials/web.rst:1826
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/tutorials/web.rst:1830
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/tutorials/web.rst:1835
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/tutorials/web.rst:1839
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/tutorials/web.rst:1844
msgid "The Form View Fields"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1846
msgid "A common need is the extension of the web form view to add new ways of displaying fields."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1849
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/tutorials/web.rst:1856
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/tutorials/web.rst:1865
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/tutorials/web.rst:1868
msgid "and a given field (name) can not be used multiple times in the same form"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1869
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/tutorials/web.rst:1872
msgid "most of this should probably move to an advanced form view guide"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1874
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/tutorials/web.rst:1882
msgid "Here are some of the responsibilities of a field class:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1884
msgid "The field class must display and allow the user to edit the value of the field."
msgstr ""
#: ../../content/developer/tutorials/web.rst:1885
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/tutorials/web.rst:1895
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/tutorials/web.rst:1898
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/tutorials/web.rst:1901
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/tutorials/web.rst:1909
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/tutorials/web.rst:1923
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/tutorials/web.rst:1929
msgid "Creating a New Type of Field"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1931
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/tutorials/web.rst:1936
msgid "Simple Read-Only Field"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1938
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/tutorials/web.rst:1955
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/tutorials/web.rst:1961
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/tutorials/web.rst:1971
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/tutorials/web.rst:1976
msgid "Read-Write Field"
msgstr ""
#: ../../content/developer/tutorials/web.rst:1978
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/tutorials/web.rst:1985
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/tutorials/web.rst:2033
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/tutorials/web.rst:2042
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/tutorials/web.rst:2045
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/tutorials/web.rst:2048
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/tutorials/web.rst:2056
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/tutorials/web.rst:2059
msgid "Create a Color Field"
msgstr ""
#: ../../content/developer/tutorials/web.rst:2061
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/tutorials/web.rst:2069
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/tutorials/web.rst:2134
msgid "The Form View Custom Widgets"
msgstr ""
#: ../../content/developer/tutorials/web.rst:2136
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/tutorials/web.rst:2141
msgid "Custom form widgets can be added to a form view through the ``widget`` tag:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:2147
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/tutorials/web.rst:2154
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/tutorials/web.rst:2174
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/tutorials/web.rst:2179
msgid ":func:`~odoo.web.form.FieldManagerMixin.get_field_value(field_name)` which returns the value of a field."
msgstr ""
#: ../../content/developer/tutorials/web.rst:2181
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/tutorials/web.rst:2183
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/tutorials/web.rst:2186
msgid "Show Coordinates on Google Map"
msgstr ""
#: ../../content/developer/tutorials/web.rst:2188
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/tutorials/web.rst:2192
msgid "To display the map, use Google Map's embedding:"
msgstr ""
#: ../../content/developer/tutorials/web.rst:2199
msgid "where ``XXX`` should be replaced by the latitude and ``YYY`` by the longitude."
msgstr ""
#: ../../content/developer/tutorials/web.rst:2202
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/tutorials/web.rst:2234
msgid "Get the Current Coordinate"
msgstr ""
#: ../../content/developer/tutorials/web.rst:2236
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/tutorials/web.rst:2240
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/tutorials/web.rst:2243
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/tutorials/web.rst:2248
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/tutorials/web.rst:2299
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/tutorials/web.rst:2303
msgid "as well as papering over cross-browser differences, although this has become less necessary over time"
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)."
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."
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."
msgid "Create a template and ensure the template file is registered in the ``__manifest__.py`` manifest, and alter the controller to use our template:"
msgid "The templates iterates (``t-foreach``) on all the teachers (passed through the *template context*), and prints each teacher in its own paragraph."
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`."
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."
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)"
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:"
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."
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."
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``"
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)."
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."
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"
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, …)"
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`."
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."
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:"
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:"
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."
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:"
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."
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``:"
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."
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:"
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)."
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…"
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."
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."
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."
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:"
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)."
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:"
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:"
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."
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."
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."
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."
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)."
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."
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."
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."
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."
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)."
