[FIX] content/developer/*: typos
Found with codespell
This commit is contained in:
parent
4483a86907
commit
e96bc804d3
@ -10,7 +10,7 @@ Profiling Odoo code
|
|||||||
Graph a method
|
Graph a method
|
||||||
==============
|
==============
|
||||||
|
|
||||||
Odoo embeds a profiler of code. This embeded profiler output can be used to
|
Odoo embeds a profiler of code. This embedded profiler output can be used to
|
||||||
generate a graph of calls triggered by the method, number of queries, percentage
|
generate a graph of calls triggered by the method, number of queries, percentage
|
||||||
of time taken in the method itself as well as the time that the method took and
|
of time taken in the method itself as well as the time that the method took and
|
||||||
its sub-called methods.
|
its sub-called methods.
|
||||||
@ -85,7 +85,7 @@ Dump stack
|
|||||||
|
|
||||||
Sending the SIGQUIT signal to an Odoo process (only available on POSIX) makes
|
Sending the SIGQUIT signal to an Odoo process (only available on POSIX) makes
|
||||||
this process output the current stack trace to log, with info level. When an
|
this process output the current stack trace to log, with info level. When an
|
||||||
odoo process seems stucked, sending this signal to the process permit to know
|
odoo process seems stuck, sending this signal to the process permit to know
|
||||||
what the process is doing, and letting the process continue his job.
|
what the process is doing, and letting the process continue his job.
|
||||||
|
|
||||||
Tracing code execution
|
Tracing code execution
|
||||||
|
@ -394,7 +394,7 @@ So here are the steps to create a robust and consistent style for your theme:
|
|||||||
|
|
||||||
\(1) Set the values for Odoo-provided SCSS variables
|
\(1) Set the values for Odoo-provided SCSS variables
|
||||||
|
|
||||||
Odoo declares many CSS rules, most being entirely customizable by overridding
|
Odoo declares many CSS rules, most being entirely customizable by overriding
|
||||||
the related SCSS variables. First, create a new file called primary_variables.scss
|
the related SCSS variables. First, create a new file called primary_variables.scss
|
||||||
and add it the same way as the style.scss file. The only difference it that
|
and add it the same way as the style.scss file. The only difference it that
|
||||||
you won't add it in the ``assets_frontend`` template but in the ``_assets_primary_variables``
|
you won't add it in the ``assets_frontend`` template but in the ``_assets_primary_variables``
|
||||||
|
@ -1782,7 +1782,7 @@ 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
|
in the registry, walks the specified path and displays the widget it finds at
|
||||||
the end.
|
the end.
|
||||||
|
|
||||||
.. note:: a client action handler can also be a regular function, in whch case
|
.. note:: 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
|
it'll be called and its result (if any) will be interpreted as the
|
||||||
next action to execute.
|
next action to execute.
|
||||||
|
|
||||||
|
@ -236,7 +236,7 @@ corresponding behaviors) are shared between states:
|
|||||||
|
|
||||||
* ``object_write``: Updates the current record(s) following ``fields_lines`` specifications
|
* ``object_write``: Updates the current record(s) following ``fields_lines`` specifications
|
||||||
|
|
||||||
* ``multi``: Executes serveral actions given through the ``child_ids`` argument.
|
* ``multi``: Executes several actions given through the ``child_ids`` argument.
|
||||||
|
|
||||||
State fields
|
State fields
|
||||||
------------
|
------------
|
||||||
|
@ -154,7 +154,7 @@ Database
|
|||||||
.. option:: --db_sslmode
|
.. option:: --db_sslmode
|
||||||
|
|
||||||
Control the SSL security of the connection between Odoo and PostgreSQL.
|
Control the SSL security of the connection between Odoo and PostgreSQL.
|
||||||
Value should bve one of 'disable', 'allow', 'prefer', 'require',
|
Value should be one of 'disable', 'allow', 'prefer', 'require',
|
||||||
'verify-ca' or 'verify-full'
|
'verify-ca' or 'verify-full'
|
||||||
Default value is 'prefer'
|
Default value is 'prefer'
|
||||||
|
|
||||||
|
@ -280,7 +280,7 @@ Odoo supports custom tags acting as syntactic sugar:
|
|||||||
- report: use to declare a :ref:`report action <reference/actions/report>`
|
- report: use to declare a :ref:`report action <reference/actions/report>`
|
||||||
- act_window: use it if the record notation can't do what you want
|
- act_window: use it if the record notation can't do what you want
|
||||||
|
|
||||||
The 4 first tags are prefered over the *record* notation.
|
The 4 first tags are preferred over the *record* notation.
|
||||||
|
|
||||||
|
|
||||||
XML IDs and naming
|
XML IDs and naming
|
||||||
@ -330,7 +330,7 @@ should have a real naming as it is used as display name.
|
|||||||
</record>
|
</record>
|
||||||
|
|
||||||
<record id="model_name_action_child_list" model="ir.actions.act_window">
|
<record id="model_name_action_child_list" model="ir.actions.act_window">
|
||||||
<field name="name">Model Access Childs</field>
|
<field name="name">Model Access Children</field>
|
||||||
</record>
|
</record>
|
||||||
|
|
||||||
<!-- menus and sub-menus -->
|
<!-- menus and sub-menus -->
|
||||||
@ -572,7 +572,7 @@ So, you can write ``if some_collection:`` instead of ``if len(some_collection):`
|
|||||||
for element in iterable:
|
for element in iterable:
|
||||||
values.setdefault(element, []).append(other_value)
|
values.setdefault(element, []).append(other_value)
|
||||||
|
|
||||||
- As a good developper, document your code (docstring on methods, simple
|
- As a good developer, document your code (docstring on methods, simple
|
||||||
comments for tricky part of code)
|
comments for tricky part of code)
|
||||||
- In additions to these guidelines, you may also find the following link
|
- In additions to these guidelines, you may also find the following link
|
||||||
interesting: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
|
interesting: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
|
||||||
|
@ -178,7 +178,7 @@ to add a file from that addon. In that case, it should be done in three steps:
|
|||||||
|
|
||||||
Note that the files in a bundle are all loaded immediately when the user loads the
|
Note that the files in a bundle are all loaded immediately when the user loads the
|
||||||
odoo web client. This means that the files are transferred through the network
|
odoo web client. This means that the files are transferred through the network
|
||||||
everytime (except when the browser cache is active). In some cases, it may be
|
every time (except when the browser cache is active). In some cases, it may be
|
||||||
better to lazyload some assets. For example, if a widget requires a large
|
better to lazyload some assets. For example, if a widget requires a large
|
||||||
library, and that widget is not a core part of the experience, then it may be
|
library, and that widget is not a core part of the experience, then it may be
|
||||||
a good idea to only load the library when the widget is actually created. The
|
a good idea to only load the library when the widget is actually created. The
|
||||||
@ -1148,7 +1148,7 @@ may need to directly call a controller (available on some route).
|
|||||||
Notifications
|
Notifications
|
||||||
==============
|
==============
|
||||||
|
|
||||||
The Odoo framework has a standard way to communicate various informations to the
|
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.
|
user: notifications, which are displayed on the top right of the user interface.
|
||||||
|
|
||||||
There are two types of notifications:
|
There are two types of notifications:
|
||||||
@ -1499,7 +1499,7 @@ integer (FieldInteger)
|
|||||||
- type: setting the input type (*text* by default, can be set on *number*)
|
- type: setting the input type (*text* by default, can be set on *number*)
|
||||||
|
|
||||||
On edit mode, the field is rendered as an input with the HTML attribute type
|
On edit mode, the field is rendered as an input with the HTML attribute type
|
||||||
setted on *number* (so user can benefit the native support, especially on
|
set on *number* (so user can benefit the native support, especially on
|
||||||
mobile). In this case, the default formatting is disabled to avoid incompability.
|
mobile). In this case, the default formatting is disabled to avoid incompability.
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: xml
|
||||||
@ -1531,7 +1531,7 @@ float (FieldFloat)
|
|||||||
- type: setting the input type (*text* by default, can be set on *number*)
|
- type: setting the input type (*text* by default, can be set on *number*)
|
||||||
|
|
||||||
On edit mode, the field is rendered as an input with the HTML attribute type
|
On edit mode, the field is rendered as an input with the HTML attribute type
|
||||||
setted on *number* (so user can benefit the native support, especially on
|
set on *number* (so user can benefit the native support, especially on
|
||||||
mobile). In this case, the default formatting is disabled to avoid incompability.
|
mobile). In this case, the default formatting is disabled to avoid incompability.
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: xml
|
||||||
|
@ -109,7 +109,7 @@ to manage followers on your record:
|
|||||||
Helper method to send a mail with a template
|
Helper method to send a mail with a template
|
||||||
|
|
||||||
:param template_id: the id of the template to render to create the body of the message
|
:param template_id: the id of the template to render to create the body of the message
|
||||||
:param `\**kwargs`: parameter to create a mail.compose.message wizzard (which inherit from mail.message)
|
:param `\**kwargs`: parameter to create a mail.compose.message wizard (which inherit from mail.message)
|
||||||
|
|
||||||
.. rubric:: Receiving messages
|
.. rubric:: Receiving messages
|
||||||
|
|
||||||
@ -254,11 +254,11 @@ Subtypes are created as data in your module; the model has the following fields:
|
|||||||
``res_model`` - :class:`~odoo.fields.Char`
|
``res_model`` - :class:`~odoo.fields.Char`
|
||||||
model the subtype applies to; if False, this subtype applies to all models
|
model the subtype applies to; if False, this subtype applies to all models
|
||||||
``default`` - :class:`~odoo.fields.Boolean`
|
``default`` - :class:`~odoo.fields.Boolean`
|
||||||
wether the subtype is activated by default when subscribing
|
whether the subtype is activated by default when subscribing
|
||||||
``sequence`` - :class:`~odoo.fields.Integer`
|
``sequence`` - :class:`~odoo.fields.Integer`
|
||||||
used to order subtypes in the notification customization popup
|
used to order subtypes in the notification customization popup
|
||||||
``hidden`` - :class:`~odoo.fields.Boolean`
|
``hidden`` - :class:`~odoo.fields.Boolean`
|
||||||
wether the subtype is hidden in the notification customization popup
|
whether the subtype is hidden in the notification customization popup
|
||||||
|
|
||||||
|
|
||||||
Interfacing subtypes with field tracking allows to subscribe to different kind
|
Interfacing subtypes with field tracking allows to subscribe to different kind
|
||||||
@ -381,7 +381,7 @@ yourself by overriding the function ``_notification_recipients``.
|
|||||||
following the thread). True by default for new groups, False for
|
following the thread). True by default for new groups, False for
|
||||||
portal / customer.
|
portal / customer.
|
||||||
- button_follow
|
- button_follow
|
||||||
dict with url adn title of the button
|
dict with url and title of the button
|
||||||
- has_button_unfollow
|
- has_button_unfollow
|
||||||
whether to display Unfollow in email (if recipient is currently following the thread).
|
whether to display Unfollow in email (if recipient is currently following the thread).
|
||||||
True by default for new groups, False for portal / customer.
|
True by default for new groups, False for portal / customer.
|
||||||
@ -578,7 +578,7 @@ some default values these records may have depending on the parent object:
|
|||||||
tasks getting created in the right project) by setting a dictionary of
|
tasks getting created in the right project) by setting a dictionary of
|
||||||
default values in the alias' ``alias_defaults`` field.
|
default values in the alias' ``alias_defaults`` field.
|
||||||
|
|
||||||
:return: dictionnary of values that will be written to the new alias
|
:return: dictionary of values that will be written to the new alias
|
||||||
:rtype: dict
|
:rtype: dict
|
||||||
|
|
||||||
The ``get_alias_values()`` override is particularly interesting as it allows you
|
The ``get_alias_values()`` override is particularly interesting as it allows you
|
||||||
@ -641,7 +641,7 @@ you to make your alias easily configurable from the record's form view.
|
|||||||
def get_alias_values(self):
|
def get_alias_values(self):
|
||||||
""" Specify some default values that will be set in the alias at its creation """
|
""" Specify some default values that will be set in the alias at its creation """
|
||||||
values = super(BusinessTrip, self).get_alias_values()
|
values = super(BusinessTrip, self).get_alias_values()
|
||||||
# alias_defaults holds a dictionnary that will be written
|
# alias_defaults holds a dictionary that will be written
|
||||||
# to all records created by this alias
|
# to all records created by this alias
|
||||||
#
|
#
|
||||||
# in this case, we want all expense records sent to a trip alias
|
# in this case, we want all expense records sent to a trip alias
|
||||||
@ -706,7 +706,7 @@ you to make your alias easily configurable from the record's form view.
|
|||||||
of the expense, try to find a partner with this email address and
|
of the expense, try to find a partner with this email address and
|
||||||
do a regex match to find the amount of the expense."""
|
do a regex match to find the amount of the expense."""
|
||||||
name = msg_dict.get('subject', 'New Expense')
|
name = msg_dict.get('subject', 'New Expense')
|
||||||
# Match the last occurence of a float in the string
|
# Match the last occurrence of a float in the string
|
||||||
# Example: '50.3 bar 34.5' becomes '34.5'. This is potentially the price
|
# Example: '50.3 bar 34.5' becomes '34.5'. This is potentially the price
|
||||||
# to encode on the expense. If not, take 1.0 instead
|
# to encode on the expense. If not, take 1.0 instead
|
||||||
amount_pattern = '(\d+(\.\d*)?|\.\d+)'
|
amount_pattern = '(\d+(\.\d*)?|\.\d+)'
|
||||||
@ -758,7 +758,7 @@ widgets, respectively).
|
|||||||
name = fields.Char()
|
name = fields.Char()
|
||||||
# [...]
|
# [...]
|
||||||
|
|
||||||
We modify the form view of our trips to display their next activites:
|
We modify the form view of our trips to display their next activities:
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: xml
|
||||||
|
|
||||||
@ -781,7 +781,7 @@ You can find concrete examples of integration in the following models:
|
|||||||
|
|
||||||
* ``crm.lead`` in the CRM (*crm*) Application
|
* ``crm.lead`` in the CRM (*crm*) Application
|
||||||
* ``sale.order`` in the Sales (*sale*) Application
|
* ``sale.order`` in the Sales (*sale*) Application
|
||||||
* ``project.task`` in the Project (*poject*) Application
|
* ``project.task`` in the Project (*project*) Application
|
||||||
|
|
||||||
|
|
||||||
.. _reference/mixins/website:
|
.. _reference/mixins/website:
|
||||||
@ -871,7 +871,7 @@ case for this mixin is any object that has a frontend-page; being able to contro
|
|||||||
the visibility of the page allows you to take your time while editing the page
|
the visibility of the page allows you to take your time while editing the page
|
||||||
and only publish it when you're satisfied.
|
and only publish it when you're satisfied.
|
||||||
|
|
||||||
To include the functionnality, you only need to inherit ``website.published.mixin``:
|
To include the functionality, you only need to inherit ``website.published.mixin``:
|
||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
@ -998,13 +998,13 @@ The behaviour of the mixin adapts to your model:
|
|||||||
* The ``rating.rating`` record will be linked to the ``partner_id`` field of your
|
* The ``rating.rating`` record will be linked to the ``partner_id`` field of your
|
||||||
model (if the field is present).
|
model (if the field is present).
|
||||||
|
|
||||||
- this behaviour can be overriden with the function ``rating_get_partner_id()``
|
- this behaviour can be overridden with the function ``rating_get_partner_id()``
|
||||||
if you use another field than ``partner_id``
|
if you use another field than ``partner_id``
|
||||||
|
|
||||||
* The ``rating.rating`` record will be linked to the partner of the ``user_id``
|
* 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)
|
field of your model (if the field is present) (i.e. the partner who is rated)
|
||||||
|
|
||||||
- this behaviour can be overriden with the function ``rating_get_rated_partner_id()``
|
- 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
|
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
|
``res.partner``, for ``user_id`` the system automatically fetches the partner
|
||||||
of the user)
|
of the user)
|
||||||
|
@ -61,7 +61,7 @@ Check if the method is available and then execute it.
|
|||||||
Methods
|
Methods
|
||||||
-------
|
-------
|
||||||
|
|
||||||
.. note:: Each of the methods returns a JQuery Deffered object which returns
|
.. note:: Each of the methods returns a JQuery Deferred object which returns
|
||||||
a data JSON dictionary
|
a data JSON dictionary
|
||||||
|
|
||||||
Show Toast in device
|
Show Toast in device
|
||||||
|
@ -974,7 +974,7 @@ Date / Datetime comparison best practices:
|
|||||||
date string, therefore this practice is **heavily**
|
date string, therefore this practice is **heavily**
|
||||||
discouraged.
|
discouraged.
|
||||||
|
|
||||||
Common operations with dates and datetimes such as addition, substraction or
|
Common operations with dates and datetimes such as addition, subtraction or
|
||||||
fetching the start/end of a period are exposed through both
|
fetching the start/end of a period are exposed through both
|
||||||
:class:`~odoo.fields.Date` and :class:`~odoo.fields.Datetime`.
|
:class:`~odoo.fields.Date` and :class:`~odoo.fields.Datetime`.
|
||||||
These helpers are also available by importing `odoo.tools.date_utils`.
|
These helpers are also available by importing `odoo.tools.date_utils`.
|
||||||
@ -1395,7 +1395,7 @@ decorating the old-style method:
|
|||||||
will automatically prepend the current cursor to explicitly provided
|
will automatically prepend the current cursor to explicitly provided
|
||||||
parameters, positionally
|
parameters, positionally
|
||||||
:func:`~odoo.api.cr_uid`
|
:func:`~odoo.api.cr_uid`
|
||||||
will automatically prepend the current cursor and user's id to explictly
|
will automatically prepend the current cursor and user's id to explicitly
|
||||||
provided parameters
|
provided parameters
|
||||||
:func:`~odoo.api.cr_uid_ids`
|
:func:`~odoo.api.cr_uid_ids`
|
||||||
will automatically prepend the current cursor, user's id and recordset's
|
will automatically prepend the current cursor, user's id and recordset's
|
||||||
|
@ -56,7 +56,7 @@ can take the following attributes:
|
|||||||
for example)
|
for example)
|
||||||
``attachment``
|
``attachment``
|
||||||
python expression that defines the name of the report; the record is
|
python expression that defines the name of the report; the record is
|
||||||
acessible as the variable ``object``
|
accessible as the variable ``object``
|
||||||
``paperformat``
|
``paperformat``
|
||||||
external id of the paperformat you wish to use (defaults to the company's
|
external id of the paperformat you wish to use (defaults to the company's
|
||||||
paperformat if not specified)
|
paperformat if not specified)
|
||||||
|
@ -10,7 +10,7 @@ data-driven mechanisms to manage or restrict access to data.
|
|||||||
|
|
||||||
Both mechanisms are linked to specific users through *groups*: a user belongs
|
Both mechanisms are linked to specific users through *groups*: a user belongs
|
||||||
to any number of groups, and security mechanisms are associated to groups,
|
to any number of groups, and security mechanisms are associated to groups,
|
||||||
thus applying security mechamisms to users.
|
thus applying security mechanisms to users.
|
||||||
|
|
||||||
.. _reference/security/acl:
|
.. _reference/security/acl:
|
||||||
|
|
||||||
|
@ -148,7 +148,7 @@ default you can remove the ``standard`` tag:
|
|||||||
...
|
...
|
||||||
|
|
||||||
This test will not be selected by default, to run it the relevant tag will
|
This test will not be selected by default, to run it the relevant tag will
|
||||||
have to be selected explicitely:
|
have to be selected explicitly:
|
||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
@ -176,7 +176,7 @@ ones:
|
|||||||
|
|
||||||
When you write a test that does not inherit from the
|
When you write a test that does not inherit from the
|
||||||
:class:`~odoo.tests.common.BaseCase`, this test will not have the default tags,
|
:class:`~odoo.tests.common.BaseCase`, this test will not have the default tags,
|
||||||
you have to add them explicitely to have the test included in the default test
|
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
|
suite. This is a common issue when using a simple ``unittest.TestCase`` as
|
||||||
they're not going to get run:
|
they're not going to get run:
|
||||||
|
|
||||||
@ -193,7 +193,7 @@ Special tags
|
|||||||
^^^^^^^^^^^^
|
^^^^^^^^^^^^
|
||||||
|
|
||||||
- ``standard``: All Odoo tests that inherit from
|
- ``standard``: All Odoo tests that inherit from
|
||||||
:class:`~odoo.tests.common.BaseCase` are implicitely tagged standard.
|
:class:`~odoo.tests.common.BaseCase` are implicitly tagged standard.
|
||||||
:option:`--test-tags <odoo-bin --test-tags>` also defaults to ``standard``.
|
:option:`--test-tags <odoo-bin --test-tags>` also defaults to ``standard``.
|
||||||
|
|
||||||
That means untagged test will be executed by default when tests are enabled.
|
That means untagged test will be executed by default when tests are enabled.
|
||||||
@ -207,7 +207,7 @@ Special tags
|
|||||||
will generally not want both ``post_install`` is usually paired with
|
will generally not want both ``post_install`` is usually paired with
|
||||||
``-at_install`` when tagging a test class.
|
``-at_install`` when tagging a test class.
|
||||||
- *module_name*: Odoo tests classes extending
|
- *module_name*: Odoo tests classes extending
|
||||||
:class:`~odoo.tests.common.BaseCase` are implicitely tagged with the
|
:class:`~odoo.tests.common.BaseCase` are implicitly tagged with the
|
||||||
technical name of their module. This allows easily selecting or excluding
|
technical name of their module. This allows easily selecting or excluding
|
||||||
specific modules when testing e.g. if you want to only run tests from
|
specific modules when testing e.g. if you want to only run tests from
|
||||||
``stock_account``:
|
``stock_account``:
|
||||||
|
@ -966,7 +966,7 @@ take the following attributes:
|
|||||||
if set to true it displays a striped zone in the consolidation line
|
if set to true it displays a striped zone in the consolidation line
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
The dictionnary definition must use double-quotes, ``{'user_id': 100}`` is
|
The dictionary definition must use double-quotes, ``{'user_id': 100}`` is
|
||||||
not a valid value
|
not a valid value
|
||||||
``create``, ``edit``
|
``create``, ``edit``
|
||||||
allows *dis*\ abling the corresponding action in the view by setting the
|
allows *dis*\ abling the corresponding action in the view by setting the
|
||||||
|
@ -135,7 +135,7 @@ on Odoo (https://iap.odoo.com/my/home) and select *In-App Services*.
|
|||||||
on sandbox to ease the tests.
|
on sandbox to ease the tests.
|
||||||
|
|
||||||
Log in then go to :menuselection:`My Account --> Your In-App Services`, click
|
Log in then go to :menuselection:`My Account --> Your In-App Services`, click
|
||||||
Create and provide the informations of your service.
|
Create and provide the information of your service.
|
||||||
|
|
||||||
|
|
||||||
The service has *seven* important fields:
|
The service has *seven* important fields:
|
||||||
@ -415,7 +415,7 @@ The :class:`~odoo.addons.iap.models.iap.charge` helper will:
|
|||||||
if the account does not have enough credits it will raise the relevant
|
if the account does not have enough credits it will raise the relevant
|
||||||
error
|
error
|
||||||
2. execute the body of the ``with`` statement
|
2. execute the body of the ``with`` statement
|
||||||
3. if the body of the ``with`` executes succesfully, update the price
|
3. if the body of the ``with`` executes successfully, update the price
|
||||||
of the transaction if needed
|
of the transaction if needed
|
||||||
4. capture (confirm) the transaction
|
4. capture (confirm) the transaction
|
||||||
5. otherwise, if an error is raised from the body of the ``with``, cancel the
|
5. otherwise, if an error is raised from the body of the ``with``, cancel the
|
||||||
@ -688,7 +688,7 @@ care how they are implemented.
|
|||||||
Test the API
|
Test the API
|
||||||
------------
|
------------
|
||||||
|
|
||||||
In order to test the developped app, we propose a sandbox platform that allows you to:
|
In order to test the developed app, we propose a sandbox platform that allows you to:
|
||||||
|
|
||||||
1. Test the whole flow from the client's point of view - Actual services and transactions
|
1. Test the whole flow from the client's point of view - Actual services and transactions
|
||||||
that can be consulted. (again this requires to change the endpoint, see the danger note
|
that can be consulted. (again this requires to change the endpoint, see the danger note
|
||||||
@ -702,7 +702,7 @@ The latter consists in specific tokens that will work on **IAP-Sandbox only**.
|
|||||||
* Token ``000111``: Represents an account without sufficient credits to perform any service.
|
* Token ``000111``: Represents an account without sufficient credits to perform any service.
|
||||||
Returns an :class:`~odoo.addons.iap.models.iap.InsufficientCreditError` on authorize attempt.
|
Returns an :class:`~odoo.addons.iap.models.iap.InsufficientCreditError` on authorize attempt.
|
||||||
* Token ``111111``: Represents an account with enough credits to perform any service.
|
* Token ``111111``: Represents an account with enough credits to perform any service.
|
||||||
An authorize attempt will return a dummy transacion token that is processed by the capture
|
An authorize attempt will return a dummy transaction token that is processed by the capture
|
||||||
and cancel routes.
|
and cancel routes.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
@ -12,7 +12,7 @@ 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
|
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.
|
easily available over XML-RPC_ and accessible from a variety of languages.
|
||||||
|
|
||||||
.. Odoo XML-RPC idiosyncracies:
|
.. Odoo XML-RPC idiosyncrasies:
|
||||||
* uses multiple endpoint and a nested call syntax instead of a
|
* uses multiple endpoint and a nested call syntax instead of a
|
||||||
"hierarchical" server structure (e.g. ``odoo.res.partner.read()``)
|
"hierarchical" server structure (e.g. ``odoo.res.partner.read()``)
|
||||||
* uses its own own manual auth system instead of basic auth or sessions
|
* uses its own own manual auth system instead of basic auth or sessions
|
||||||
@ -852,7 +852,7 @@ 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
|
a list of records to update and a mapping of updated fields to values similar
|
||||||
to :meth:`~odoo.models.Model.create`.
|
to :meth:`~odoo.models.Model.create`.
|
||||||
|
|
||||||
Multiple records can be updated simultanously, but they will all get the same
|
Multiple records can be updated simultaneously, but they will all get the same
|
||||||
values for the fields being set. It is not currently possible to perform
|
values for the fields being set. It is not currently possible to perform
|
||||||
"computed" updates (where the value being set depends on an existing value of
|
"computed" updates (where the value being set depends on an existing value of
|
||||||
a record).
|
a record).
|
||||||
|
@ -135,7 +135,7 @@ Here are 2 examples of database upgrade request creation using:
|
|||||||
|
|
||||||
* one in the python programming language using the requests library
|
* one in the python programming language using the requests library
|
||||||
* one in the bash programming language using `curl <https://curl.haxx.se>`_ (tool
|
* one in the bash programming language using `curl <https://curl.haxx.se>`_ (tool
|
||||||
for transfering data using http) and `jq <https://stedolan.github.io/jq>`_ (JSON processor):
|
for transferring data using http) and `jq <https://stedolan.github.io/jq>`_ (JSON processor):
|
||||||
|
|
||||||
.. rst-class:: setup doc-aside
|
.. rst-class:: setup doc-aside
|
||||||
|
|
||||||
@ -247,7 +247,7 @@ should be empty if everything went fine.
|
|||||||
The ``request_sftp_access`` method
|
The ``request_sftp_access`` method
|
||||||
----------------------------------
|
----------------------------------
|
||||||
|
|
||||||
This method is recommanded for big database dumps.
|
This method is recommended for big database dumps.
|
||||||
It uses the SFTP protocol and supports resuming.
|
It uses the SFTP protocol and supports resuming.
|
||||||
|
|
||||||
It will create a temporary SFTP server where you can connect to and allow you
|
It will create a temporary SFTP server where you can connect to and allow you
|
||||||
@ -323,7 +323,7 @@ explanation about the JSON dictionary returned in case of failure.
|
|||||||
'''''''''''
|
'''''''''''
|
||||||
|
|
||||||
If the call is successful, the value associated to the *request* key
|
If the call is successful, the value associated to the *request* key
|
||||||
will be a dictionary containing your SFTP connexion parameters:
|
will be a dictionary containing your SFTP connection parameters:
|
||||||
|
|
||||||
* ``hostname``: the host address to connect to
|
* ``hostname``: the host address to connect to
|
||||||
* ``sftp_port``: the port to connect to
|
* ``sftp_port``: the port to connect to
|
||||||
@ -641,7 +641,7 @@ Beside downloading your migrated database using the URL provided by the
|
|||||||
protocol as described in the :ref:`request_sftp_access method
|
protocol as described in the :ref:`request_sftp_access method
|
||||||
<upgrade-api-request-sftp-access-method>`
|
<upgrade-api-request-sftp-access-method>`
|
||||||
|
|
||||||
The diffence is that you'll only be able to download the migrated database. No
|
The difference is that you'll only be able to download the migrated database. No
|
||||||
uploading will be possible.
|
uploading will be possible.
|
||||||
|
|
||||||
Your database upgrade request should be in the ``done`` state.
|
Your database upgrade request should be in the ``done`` state.
|
||||||
|
Loading…
Reference in New Issue
Block a user