mirror of
https://github.com/odoo/documentation.git
synced 2026-01-04 02:36:32 +07:00
Victor Feyens
@@ -370,7 +370,7 @@ Some good examples:
|
||||
* `l10n_ch_reports/data/account_financial_html_report_data.xml <{GITHUB_ENT_PATH}/l10n_ch_reports/data/account_financial_html_report_data.xml>`_
|
||||
* `l10n_be_reports/data/account_financial_html_report_data.xml <{GITHUB_ENT_PATH}/l10n_be_reports/data/account_financial_html_report_data.xml>`_
|
||||
|
||||
You can check the meaning of the fields here:
|
||||
You can check the meaning of the fields here:
|
||||
|
||||
* :doc:`/developer/reference/standard_modules/account/account_report`
|
||||
* :doc:`/developer/reference/standard_modules/account/account_report_line`
|
||||
|
||||
@@ -239,7 +239,7 @@ An example of a view inheritance extension can be found
|
||||
Add the ``property_ids`` field to the ``base.view_users_form`` in a new notebook page.
|
||||
|
||||
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>`__.
|
||||
`here <https://github.com/odoo/odoo/blob/691d1f087040f1ec7066e485d19ce3662dfc6501/addons/gamification/views/res_users_views.xml#L5-L14>`__.
|
||||
|
||||
Inheritance is extensively used in Odoo due to its modular concept. Do not hesitate to read
|
||||
the corresponding documentation for more info!
|
||||
|
||||
@@ -8,8 +8,8 @@ Every day we hear about data leaks and attacks in the newspapers.
|
||||
We expect you to be aware and careful about how to avoid security breaches in your future
|
||||
developments.
|
||||
|
||||
You already defined new models in your training. Did you check the access rights and define record
|
||||
rules on it ? Are you sure your module is not an open door to SQL injections ? Did you use getattr
|
||||
You already defined new models in your training. Did you check the access rights and define record
|
||||
rules on it ? Are you sure your module is not an open door to SQL injections ? Did you use getattr
|
||||
or t-raw in your code?
|
||||
|
||||
- No or wrong access rules on models.
|
||||
|
||||
@@ -277,7 +277,7 @@ the template, such as data from additional models:
|
||||
|
||||
Custom fonts
|
||||
============
|
||||
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.
|
||||
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.
|
||||
|
||||
Example::
|
||||
|
||||
@@ -422,7 +422,7 @@ Calendar
|
||||
--------
|
||||
|
||||
Calendar views display records as events in a daily, weekly, monthly or yearly
|
||||
calendar.
|
||||
calendar.
|
||||
|
||||
.. note:: 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
|
||||
|
||||
@@ -53,10 +53,10 @@ Bundles
|
||||
=======
|
||||
|
||||
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
|
||||
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.
|
||||
you can declare several asset files using a single line.
|
||||
|
||||
The bundles are defined in each module's :file:`__manifest__.py`,
|
||||
with a dedicated `assets` key which contains a dictionary. The dictionary maps
|
||||
|
||||
@@ -44,11 +44,11 @@ on the web client.
|
||||
Code structure
|
||||
==============
|
||||
|
||||
The ``web/static/src`` folder contains all the ``web/`` javascript (and css and
|
||||
The ``web/static/src`` folder contains all the ``web/`` javascript (and css and
|
||||
templates) codebase. Here is a list of the most important folders:
|
||||
|
||||
- ``core/`` most of the low level features
|
||||
- ``fields/`` all field components
|
||||
- ``fields/`` all field components
|
||||
- ``views/`` all javascript views components (``form``, ``list``, ...)
|
||||
- ``search/`` control panel, search bar, search panel, ...
|
||||
- ``webclient/`` the web client specific code: navbar, user menu, action service, ...
|
||||
@@ -57,7 +57,7 @@ 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``:
|
||||
|
||||
.. code-block:: javascript
|
||||
.. code-block:: javascript
|
||||
|
||||
import { memoize } from "@web/core/utils/functions";
|
||||
|
||||
@@ -86,7 +86,7 @@ all active actions (represented in the breadcrumbs), and coordinates each
|
||||
change.
|
||||
|
||||
Another interesting thing to note is the ``MainComponentsContainer``: it is
|
||||
simply a component that displays all components registered in the
|
||||
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.
|
||||
|
||||
@@ -197,14 +197,14 @@ Components and Hooks
|
||||
|
||||
: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.
|
||||
Odoo components are simply owl components that are part of the web client.
|
||||
|
||||
`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.
|
||||
as a kind of mixin.
|
||||
|
||||
.. code-block:: javascript
|
||||
.. code-block:: javascript
|
||||
|
||||
function useCurrentTime() {
|
||||
const state = useState({ now: new Date() });
|
||||
@@ -222,7 +222,7 @@ 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,
|
||||
as letting the Odoo server know that a model rpc comes from a specific form view,
|
||||
or activating/disabling some features in a component.
|
||||
|
||||
There are two different contexts in the Odoo web client: the *user context* and
|
||||
@@ -258,7 +258,7 @@ It contains the following information:
|
||||
:widths: 20 20 60
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
* - `allowed_company_ids`
|
||||
@@ -269,7 +269,7 @@ It contains the following information:
|
||||
- the user language code (such as "en_us")
|
||||
* - `tz`
|
||||
- `string`
|
||||
- the user current timezone (for example "Europe/Brussels")
|
||||
- the user current timezone (for example "Europe/Brussels")
|
||||
|
||||
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
|
||||
@@ -405,11 +405,11 @@ class:
|
||||
domain.contains({ a: -1, b: 2, c: 3 }); // false
|
||||
|
||||
// next expression returns ["|", ("a", "=", 1), ("b", "<=", 3)]
|
||||
Domain.or([[["a", "=", 1]], "[('b', '<=', 3)]"]).toString();
|
||||
Domain.or([[["a", "=", 1]], "[('b', '<=', 3)]"]).toString();
|
||||
|
||||
Here is the `Domain` class description:
|
||||
|
||||
.. js:class:: Domain([descr])
|
||||
.. js:class:: Domain([descr])
|
||||
|
||||
:param descr: a domain description
|
||||
:type descr: string | any[] | Domain
|
||||
@@ -568,7 +568,7 @@ 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.
|
||||
|
||||
It contains the following content:
|
||||
It contains the following content:
|
||||
|
||||
.. list-table::
|
||||
|
||||
@@ -617,7 +617,7 @@ The `debug` mode current value can be read in the :ref:`environment<frontend/fra
|
||||
|
||||
To show menus, fields or view elements only in debug mode, you should target
|
||||
the group `base.group_no_one`:
|
||||
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<field name="fname" groups="base.group_no_one"/>
|
||||
|
||||
@@ -6,7 +6,7 @@ Hooks
|
||||
|
||||
`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
|
||||
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.
|
||||
|
||||
|
||||
@@ -37,11 +37,11 @@ Plain javascript files can contain arbitrary content. It is advised to use the
|
||||
})();
|
||||
|
||||
The advantages of such files is that we avoid leaking local variables to the
|
||||
global scope.
|
||||
global scope.
|
||||
|
||||
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).
|
||||
execute them precisely in that order).
|
||||
|
||||
.. note::
|
||||
In Odoo, all external libraries are loaded as plain javascript files.
|
||||
|
||||
@@ -9,7 +9,7 @@ Introduction
|
||||
============
|
||||
|
||||
In Odoo 10.0 we released a mobile app which allows you to access all **Odoo apps**
|
||||
(even your customized modules).
|
||||
(even your customized modules).
|
||||
|
||||
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.
|
||||
@@ -21,7 +21,7 @@ access all available mobile features.
|
||||
|
||||
.. warning:: These features work with **Odoo Enterprise 10.0+** only
|
||||
|
||||
How does it work?
|
||||
How does it work?
|
||||
=================
|
||||
|
||||
Internal workings of the mobile application:
|
||||
@@ -53,7 +53,7 @@ Just like the Odoo Web Framework, the Mobile API can be used anywhere by getting
|
||||
.. image:: mobile/odoo_mobile_api.png
|
||||
|
||||
The mobile RPC object provides a list of methods that are available (this only works with the mobile
|
||||
app).
|
||||
app).
|
||||
|
||||
Check if the method is available and then execute it.
|
||||
|
||||
@@ -136,7 +136,7 @@ area and the notification drawer are system-controlled areas that the user can
|
||||
view at any time.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
||||
mobile.showNotification({'title': 'Simple Notification', 'message': 'This is a test for a simple notification'})
|
||||
|
||||
.. image:: mobile/mobile_notification.png
|
||||
@@ -152,7 +152,7 @@ Create contact in device
|
||||
Create a new device contact with the given contact details.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
||||
var contact = {
|
||||
'name': 'Michel Fletcher',
|
||||
'mobile': '9999999999',
|
||||
@@ -205,7 +205,7 @@ Switching account in device
|
||||
Use switchAccount to switch from one account to another on the device.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
||||
mobile.methods.switchAccount();
|
||||
|
||||
.. image:: mobile/mobile_switch_account.png
|
||||
|
||||
@@ -7,7 +7,7 @@ Owl Components
|
||||
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
|
||||
specific directives. The official
|
||||
`Owl documentation <https://github.com/odoo/owl/blob/master/doc/readme.md>`_
|
||||
contains a complete reference and a tutorial.
|
||||
|
||||
@@ -28,7 +28,7 @@ page will only provide Odoo specific information. But first, let us see how we
|
||||
can make a simple component in Odoo.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
||||
const { useState } = owl.hooks;
|
||||
const { xml } = owl.tags;
|
||||
|
||||
@@ -66,7 +66,7 @@ loading the javascript/css files, and loading the templates into Owl.
|
||||
Here is how the component above should be defined:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
||||
const { useState } = owl.hooks;
|
||||
|
||||
class MyComponent extends Component {
|
||||
@@ -133,7 +133,7 @@ in Odoo directly uses the constructor method. Instead, components should use the
|
||||
}
|
||||
}
|
||||
|
||||
Another good practice is to use a consistent convention for template names:
|
||||
Another good practice is to use a consistent convention for template names:
|
||||
`addon_name.ComponentName`. This prevents name collision between odoo addons.
|
||||
|
||||
Reference List
|
||||
@@ -175,7 +175,7 @@ Description
|
||||
~~~~~~~~~~~
|
||||
|
||||
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.
|
||||
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
|
||||
half of its width.
|
||||
|
||||
@@ -191,7 +191,7 @@ and would not want to duplicate the template. It is possible to do just that.
|
||||
|
||||
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 or not.
|
||||
element might be swipable or not.
|
||||
|
||||
You can use the component to interact easily with records, messages, items in lists and much more.
|
||||
|
||||
@@ -200,18 +200,18 @@ You can use the component to interact easily with records, messages, items in li
|
||||
:alt: Example of ActionSwiper usage
|
||||
:align: center
|
||||
|
||||
The following example creates a basic ActionSwiper component.
|
||||
The following example creates a basic ActionSwiper component.
|
||||
Here, the swipe is enabled in both directions.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<ActionSwiper
|
||||
|
||||
<ActionSwiper
|
||||
onRightSwipe="
|
||||
{
|
||||
action: '() => Delete item',
|
||||
icon: 'fa-delete',
|
||||
bgColor: 'bg-danger',
|
||||
}"
|
||||
}"
|
||||
onLeftSwipe="
|
||||
{
|
||||
action: '() => Star item',
|
||||
@@ -233,7 +233,7 @@ Props
|
||||
:widths: 20 20 60
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
* - `onLeftSwipe`
|
||||
@@ -246,7 +246,7 @@ Props
|
||||
You can use both `onLeftSwipe` and `onRightSwipe` props at the same time.
|
||||
|
||||
Those `Object`'s must contain:
|
||||
|
||||
|
||||
- `action`, which is the callable `Function` serving as a callback.
|
||||
Once the swipe has been completed in the given direction, that action
|
||||
is performed.
|
||||
@@ -258,7 +258,7 @@ Those `Object`'s must contain:
|
||||
`info`, `secondary`, `success` or `warning`).
|
||||
|
||||
Those values must be given to define the behavior and the visual aspect
|
||||
of the swiper.
|
||||
of the swiper.
|
||||
|
||||
Example: Extending existing components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -268,7 +268,7 @@ in the ActionSwiper component. Here, a swiper has been added to mark
|
||||
a message as read in mail.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
||||
<xpath expr="//*[hasclass('o_Message')]" position="after">
|
||||
<ActionSwiper
|
||||
onRightSwipe="messaging.device.isMobile and messageView.message.isNeedaction ?
|
||||
@@ -312,7 +312,7 @@ Props
|
||||
:widths: 20 20 60
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
* - `value`
|
||||
@@ -330,7 +330,7 @@ Dropdown
|
||||
Location
|
||||
~~~~~~~~
|
||||
|
||||
`@web/core/dropdown/dropdown` and `@web/core/dropdown/dropdown_item`
|
||||
`@web/core/dropdown/dropdown` and `@web/core/dropdown/dropdown_item`
|
||||
|
||||
Description
|
||||
~~~~~~~~~~~
|
||||
|
||||
@@ -33,7 +33,7 @@ The patch function is located in `@web/core/utils/patch`:
|
||||
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`.
|
||||
|
||||
|
||||
The only option is `pure (boolean)`. If set to `true`, the patch operation
|
||||
does not bind the `_super` property.
|
||||
|
||||
|
||||
@@ -231,7 +231,7 @@ exists in 3 different forms:
|
||||
.. tip::
|
||||
There are two equivalent syntaxes for format strings: ``"plain_text {{code}}"`` (aka
|
||||
jinja-style) and ``"plain_text #{code}"`` (aka ruby-style).
|
||||
|
||||
|
||||
:samp:`t-att=mapping`
|
||||
if the parameter is a mapping, each (key, value) pair generates a new
|
||||
attribute and its value::
|
||||
|
||||
@@ -10,7 +10,7 @@ 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.
|
||||
|
||||
.. code-block:: javascript
|
||||
.. code-block:: javascript
|
||||
|
||||
import { Registry } from "@web/core/registry";
|
||||
|
||||
@@ -25,7 +25,7 @@ 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`.
|
||||
|
||||
.. code-block:: javascript
|
||||
.. code-block:: javascript
|
||||
|
||||
import { registry } from "@web/core/registry";
|
||||
|
||||
@@ -58,7 +58,7 @@ Registry API
|
||||
also triggers an `UPDATE` event.
|
||||
|
||||
Returns the same registry, so `add` method calls can be chained.
|
||||
|
||||
|
||||
.. js:method:: get(key[, defaultValue])
|
||||
|
||||
:param string key: key for the entry
|
||||
@@ -67,7 +67,7 @@ Registry API
|
||||
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.
|
||||
|
||||
|
||||
.. js:method:: contains(key)
|
||||
|
||||
:param string key: key for the entry
|
||||
@@ -78,21 +78,21 @@ Registry API
|
||||
.. js:method:: getAll()
|
||||
|
||||
:returns: any[]
|
||||
|
||||
|
||||
Returns the list of all elements in the registry. It is ordered
|
||||
according to the sequence numbers.
|
||||
|
||||
.. js:method:: remove(key)
|
||||
|
||||
:param string key: the key for the entry that should be removed
|
||||
|
||||
|
||||
Removes a key/value pair from the registry. This operation triggers an
|
||||
`UPDATE` event.
|
||||
|
||||
.. js:method:: category(subcategory)
|
||||
|
||||
:param string subcategory: the name for the sub category
|
||||
:returns: Registry
|
||||
:returns: Registry
|
||||
|
||||
Returns the sub registry associated with the `subcategory`. If it does not
|
||||
exist yet, the sub registry is created on the fly.
|
||||
@@ -135,7 +135,7 @@ for more details.
|
||||
Formatter registry
|
||||
------------------
|
||||
|
||||
The `formatters` registry contains functions to format values. Each formatter
|
||||
The `formatters` registry contains functions to format values. Each formatter
|
||||
has the following API:
|
||||
|
||||
.. js:function:: format(value[, options])
|
||||
@@ -166,7 +166,7 @@ API
|
||||
interface {
|
||||
Component: Owl Component class
|
||||
props?: any
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
For example, the `LoadingIndicator` component can be added in the registry like
|
||||
@@ -183,7 +183,7 @@ this:
|
||||
Parser registry
|
||||
---------------
|
||||
|
||||
The `parsers` registry contains functions to parse values. Each parser
|
||||
The `parsers` registry contains functions to parse values. Each parser
|
||||
has the following API:
|
||||
|
||||
.. js:function:: parse(value[, options])
|
||||
@@ -192,7 +192,7 @@ has the following API:
|
||||
:param value: a string representing a value
|
||||
:type value: string
|
||||
:param Object options: various options (parser specific)
|
||||
:returns: T a valid value
|
||||
:returns: T a valid value
|
||||
|
||||
Parses a string and returns a value. If the string does not represent a valid
|
||||
value, parsers can fail and throw errors.
|
||||
|
||||
@@ -47,7 +47,7 @@ Defining a service
|
||||
A service needs to implement the following interface:
|
||||
|
||||
.. js:data:: dependencies
|
||||
|
||||
|
||||
Optional list of strings. It is the list of all dependencies (other services)
|
||||
that this service needs
|
||||
|
||||
@@ -56,7 +56,7 @@ A service needs to implement the following interface:
|
||||
:param Environment env: the application environment
|
||||
:param Object deps: all requested dependencies
|
||||
:returns: value of service or Promise<value of service>
|
||||
|
||||
|
||||
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.
|
||||
@@ -66,7 +66,7 @@ A service needs to implement the following interface:
|
||||
set to ``null`` in ``env.services``.
|
||||
|
||||
.. js:data:: async
|
||||
|
||||
|
||||
Optional value. If given, it should be `true` or a list of strings.
|
||||
|
||||
Some services need to provide an asynchronous API. For example, the `rpc`
|
||||
@@ -166,7 +166,7 @@ API
|
||||
:param number ttl: optional. the time in seconds before the cookie will be deleted (default=1 year)
|
||||
|
||||
Sets the cookie `name` to the value `value` with a max age of `ttl`
|
||||
|
||||
|
||||
.. js:function:: deleteCookie(name)
|
||||
|
||||
:param string name: name of the cookie
|
||||
@@ -204,7 +204,7 @@ Here's how this can be displayed:
|
||||
message: "Boom! Team record for the past 30 days.",
|
||||
});
|
||||
|
||||
.. warning ::
|
||||
.. warning ::
|
||||
The hook `useEffect` is not related to the effect service.
|
||||
|
||||
API
|
||||
@@ -242,7 +242,7 @@ RainbowMan
|
||||
:widths: 20 40 40
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
* - `params.Component`
|
||||
@@ -274,7 +274,7 @@ RainbowMan
|
||||
|
||||
`"fast"` will make rainbowman dissapear quickly.
|
||||
|
||||
`"medium"` and `"slow"` will wait little longer before disappearing (can be used when `params.message` is longer).
|
||||
`"medium"` and `"slow"` will wait little longer before disappearing (can be used when `params.message` is longer).
|
||||
|
||||
`"no"` will keep rainbowman on screen until user clicks anywhere outside rainbowman.
|
||||
|
||||
@@ -302,13 +302,13 @@ The function must follow this API:
|
||||
|
||||
:returns: `({Component, props} | void)` A component and its props or nothing.
|
||||
|
||||
This function must create a component and return it. This component is mounted inside the
|
||||
This function must create a component and return it. This component is mounted inside the
|
||||
effect component container.
|
||||
|
||||
Example
|
||||
~~~~~~~
|
||||
|
||||
Let's say we want to add an effect that add a sepia look at the page.
|
||||
Let's say we want to add an effect that add a sepia look at the page.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
@@ -340,7 +340,7 @@ Let's say we want to add an effect that add a sepia look at the page.
|
||||
effectRegistry.add("sepia", sepiaEffectProvider);
|
||||
|
||||
|
||||
And then, call it somewhere you want and you will see the result.
|
||||
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.
|
||||
|
||||
.. code-block:: javascript
|
||||
@@ -396,7 +396,7 @@ Example
|
||||
|
||||
const httpService = useService("http");
|
||||
const data = await httpService.get("https://something.com/posts/1");
|
||||
// ...
|
||||
// ...
|
||||
await httpService.post("https://something.com/posts/1", { title: "new title", content: "new content" });
|
||||
|
||||
.. _frontend/services/notification:
|
||||
@@ -411,17 +411,17 @@ Overview
|
||||
* Dependencies: None
|
||||
|
||||
The `notification` service allows to display notifications on the screen.
|
||||
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
const notificationService = useService("notification");
|
||||
notificationService.add("I'm a very simple notification");
|
||||
|
||||
notificationService.add("I'm a very simple notification");
|
||||
|
||||
API
|
||||
~~~
|
||||
|
||||
.. js:function:: add(message[, options])
|
||||
|
||||
|
||||
:param string message: the notification message to display
|
||||
:param object options: the options of the notification
|
||||
:returns: a function to close the notification
|
||||
@@ -481,7 +481,7 @@ Examples
|
||||
A notification for when a sale deal is made with a button to go some kind of commission page.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
||||
// in setup
|
||||
this.notificationService = useService("notification");
|
||||
this.actionService = useService("actionService");
|
||||
@@ -538,16 +538,16 @@ API
|
||||
|
||||
The current route can be accessed with the ``current`` key. It is an object
|
||||
with the following information:
|
||||
|
||||
|
||||
* `pathname (string)`: the path for the current location (most likely `/web` )
|
||||
* `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
|
||||
* `hash (object)`: same as above, but for values described in the hash.
|
||||
* `hash (object)`: same as above, but for values described in the hash.
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: javascript
|
||||
.. code-block:: javascript
|
||||
|
||||
// url = /web?debug=assets#action=123&owl&menu_id=174
|
||||
const { pathname, search, hash } = env.services.router.current;
|
||||
@@ -590,10 +590,10 @@ For example:
|
||||
Finally, the `redirect` method will redirect the browser to a specified url:
|
||||
|
||||
.. js:function:: redirect(url[, wait])
|
||||
|
||||
|
||||
:param string url: a valid url
|
||||
:param boolean wait: if true, wait for the server to be ready, and redirect after
|
||||
|
||||
|
||||
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
|
||||
@@ -620,14 +620,14 @@ argument and optionally, a ``params`` object can be given as a second argument.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
// in setup
|
||||
// in setup
|
||||
this.rpc = useService("rpc");
|
||||
|
||||
// somewhere else, in an async function:
|
||||
const result = await this.rpc("/my/route", { some: "value" });
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
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
|
||||
@@ -641,9 +641,9 @@ API
|
||||
:param string route: route targeted by the request
|
||||
:param Object params: parameters sent to the server
|
||||
:param Object settings (optional): request settings (see below)
|
||||
|
||||
|
||||
The ``settings`` object can contain:
|
||||
|
||||
|
||||
- ``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.
|
||||
@@ -673,7 +673,7 @@ When a rpc fails, then:
|
||||
|
||||
* the promise representing the rpc is rejected, so the calling code will crash,
|
||||
unless it handles the situation
|
||||
*
|
||||
*
|
||||
an event ``RPC_ERROR`` is triggered on the main application bus. The event payload
|
||||
contains a description of the cause of the error:
|
||||
|
||||
@@ -683,10 +683,10 @@ When a rpc fails, then:
|
||||
|
||||
* ``type = 'server'``
|
||||
* ``message(string)``
|
||||
*
|
||||
*
|
||||
``code(number)``
|
||||
|
||||
*
|
||||
*
|
||||
``name(string)`` (optional, used by the error service to look for an appropriate
|
||||
dialog to use when handling the error)
|
||||
|
||||
@@ -715,13 +715,13 @@ Whenever the user clicks on an anchor in the web client, this service automatica
|
||||
to the target (if appropriate).
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
An event `SCROLLER:ANCHOR_LINK_CLICKED` is triggered on the main application bus if the click seems to be
|
||||
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
|
||||
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.
|
||||
|
||||
API
|
||||
@@ -733,7 +733,7 @@ The following values are contained in the `anchor-link-clicked` custom event exp
|
||||
:widths: 25 25 50
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
* - `element`
|
||||
@@ -796,7 +796,7 @@ Its API is:
|
||||
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)
|
||||
|
||||
|
||||
.. js:function:: getParts
|
||||
|
||||
:returns: Parts the current `Parts` object maintained by the title service
|
||||
@@ -835,9 +835,9 @@ Overview
|
||||
~~~~~~~~
|
||||
|
||||
* Technical name: `user`
|
||||
* Dependencies: `rpc`
|
||||
* Dependencies: `rpc`
|
||||
|
||||
The `user` service provides a bunch of data and a few helper functions concerning
|
||||
The `user` service provides a bunch of data and a few helper functions concerning
|
||||
the connected user.
|
||||
|
||||
|
||||
@@ -848,7 +848,7 @@ API
|
||||
:widths: 25 25 50
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
* - ``context``
|
||||
@@ -868,7 +868,7 @@ API
|
||||
- Whether the user is part of the system group (`base.group_system`)
|
||||
* - ``lang``
|
||||
- ``string``
|
||||
- language used
|
||||
- language used
|
||||
* - ``name``
|
||||
- ``string``
|
||||
- Name of the user
|
||||
|
||||
@@ -43,7 +43,7 @@ Chart Template
|
||||
|
||||
|
||||
.. automodel:: odoo.addons.l10n_multilang.models.account.AccountChartTemplate
|
||||
|
||||
|
||||
Multi language support for Chart of Accounts, Taxes, Tax Codes, Journals,
|
||||
Accounting Templates, Analytic Chart of Accounts and Analytic Journals.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user