[MERGE] Forward-port of branch 13.0 to 14.0
This commit is contained in:
Victor Feyens
commit
a1e7024fa0
2
conf.py
2
conf.py
@ -131,7 +131,7 @@ github_project = 'documentation'
|
||||
|
||||
locale_dirs = ['../locale/']
|
||||
|
||||
# custom docname_to_domain to devide the translations of applications in subdirectories
|
||||
# custom docname_to_domain to divide the translations of applications in subdirectories
|
||||
sphinx.transforms.i18n.docname_to_domain = (
|
||||
sphinx.util.i18n.docname_to_domain
|
||||
) = lambda docname, compact: docname.split('/')[1 if docname.startswith('applications/') else 0]
|
||||
|
||||
@ -14,7 +14,7 @@ button.
|
||||
:align: center
|
||||
|
||||
Make sure you are connected as the administrator of the database you
|
||||
want to manage - many operations depends on indentifying you remotely to that
|
||||
want to manage - many operations depends on identifying you remotely to that
|
||||
database.
|
||||
|
||||
Several actions are available:
|
||||
@ -113,7 +113,7 @@ receive an e-mail with the URL of the test database.
|
||||
|
||||
**Testing your database is the most important step of the upgrade process!**
|
||||
Even though we test all upgrades manually, we do not know your work processes.
|
||||
A change in standard worfklows of Odoo in new versions might require you to
|
||||
A change in standard workflows of Odoo in new versions might require you to
|
||||
change internal processes, or some of the customizations you made through Odoo
|
||||
Studio might not work properly. *It is up to you to make sure that everything
|
||||
works as it should!* You can report issues with your test database through our
|
||||
|
||||
@ -69,7 +69,7 @@ in ``/etc/odoo.conf`` set:
|
||||
of securing your deployment.
|
||||
Once it is correctly working and only matching a single database per hostname, it
|
||||
is strongly recommended to block access to the database manager screens,
|
||||
and to use the ``--no-database-list`` startup paramater to prevent listing
|
||||
and to use the ``--no-database-list`` startup parameter to prevent listing
|
||||
your databases, and to block access to the database management screens.
|
||||
See also security_.
|
||||
|
||||
@ -171,7 +171,7 @@ SSL Between Odoo and PostgreSQL
|
||||
|
||||
Since Odoo 11.0, you can enforce ssl connection between Odoo and PostgreSQL.
|
||||
in Odoo the db_sslmode control the ssl security of the connection
|
||||
with value choosed out of 'disable', 'allow', 'prefer', 'require', 'verify-ca'
|
||||
with value chosen out of 'disable', 'allow', 'prefer', 'require', 'verify-ca'
|
||||
or 'verify-full'
|
||||
|
||||
`PostgreSQL Doc <https://www.postgresql.org/docs/current/static/libpq-ssl.html>`_
|
||||
@ -386,7 +386,7 @@ notifications.
|
||||
|
||||
The solutions to support livechat/motifications in a WSGI application are:
|
||||
|
||||
* Deploy a threaded version of Odoo (instread of a process-based preforking
|
||||
* Deploy a threaded version of Odoo (instead of a process-based preforking
|
||||
one) and redirect only requests to URLs starting with ``/longpolling/`` to
|
||||
that Odoo, this is the simplest and the longpolling URL can double up as
|
||||
the cron instance.
|
||||
|
||||
@ -346,7 +346,7 @@ for this document type, the invoice number takes the first folio in the sequence
|
||||
|
||||
.. important::
|
||||
In case you have used some folios in your previous system, make sure you set the next valid
|
||||
folio when the first transation is created.
|
||||
folio when the first transaction is created.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1358,7 +1358,7 @@ generic one with no explanation.
|
||||
'{http://www.sat.gob.mx/sitio_internet/cfd/catalogos}c_TipoRelacion' does
|
||||
not resolve to a(n) simple type definition., line 36``
|
||||
|
||||
This can be caused by a database backup restored in anothe server,
|
||||
This can be caused by a database backup restored in another server,
|
||||
or when the XSD files are not correctly downloaded. Follow the same steps
|
||||
as above but:
|
||||
|
||||
|
||||
@ -74,8 +74,8 @@ The chart of accounts for Peru is based on the most updated version of the :abbr
|
||||
Contable General Empresarial)`, which is grouped in several categories and is compatible with NIIF
|
||||
accounting.
|
||||
|
||||
Accouting Seetings
|
||||
------------------
|
||||
Accounting Settings
|
||||
-------------------
|
||||
|
||||
Once the modules are installed and the basic information of your company is set, you need to
|
||||
configure the elements required for Electronic Invoice. For this, go to :menuselection:`Accounting
|
||||
@ -476,8 +476,8 @@ The price list in the IAP is always displayed in EUR.
|
||||
Special Use cases
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Cancelation process
|
||||
*******************
|
||||
Cancellation process
|
||||
********************
|
||||
|
||||
Some scenarios require an invoice cancellation, for example, when an invoice was created by mistake.
|
||||
If the invoice was already sent and validated by the SUNAT, the correct way to proceed is by
|
||||
@ -512,8 +512,8 @@ chatter indicating the correct Government validation.
|
||||
.. warning::
|
||||
One credit is consumed on each cancellation request.
|
||||
|
||||
Cancelation process
|
||||
*******************
|
||||
Cancellation process
|
||||
********************
|
||||
|
||||
When creating exportation invoices, take into account the next considerations:
|
||||
|
||||
|
||||
@ -147,7 +147,7 @@ This form is the same as :ref:`the one presented in the Accounting onboarding ba
|
||||
Invoice Layout
|
||||
--------------
|
||||
|
||||
With this tool, you can design the appearance of your documents by selecting which layout tamplate,
|
||||
With this tool, you can design the appearance of your documents by selecting which layout template,
|
||||
paper format, colors, font, and logo you want to use.
|
||||
|
||||
You can also add your *Company Tagline* and the content of the documents’ *footer*. Note that Odoo
|
||||
|
||||
@ -183,8 +183,8 @@ automatic recharging of the services to the customer at the end of the
|
||||
month. To invoice customers, just link the analytic account to a sale
|
||||
order and sell products that manage timesheet or expenses .
|
||||
|
||||
Case 3: IT Services Company: perfomance analysis
|
||||
------------------------------------------------
|
||||
Case 3: IT Services Company: performance analysis
|
||||
-------------------------------------------------
|
||||
|
||||
Most IT service companies face the following problems:
|
||||
|
||||
|
||||
@ -117,9 +117,9 @@ Troubleshooting
|
||||
The bank refuses my SEPA file
|
||||
-----------------------------
|
||||
|
||||
Ask your bank if they support the **SEPA Credit Transfer specification**
|
||||
Ask your bank if they support the **SEPA Credit Transfer specification**
|
||||
(the SEPA pain version depends on the country set on your company). If
|
||||
they don't, or cannot provide relevant informations, please forward the
|
||||
they don't, or cannot provide relevant information, please forward the
|
||||
error message to your Odoo partner.
|
||||
|
||||
There is no Bank Identifier Code recorded for bank account ...
|
||||
|
||||
@ -15,7 +15,7 @@ Set up Snailmail
|
||||
|
||||
.. image:: media/setup_snailmail.png
|
||||
:align: center
|
||||
:alt: Under settings enable the snailmail feauture in Odoo Accounting
|
||||
:alt: Under settings enable the snailmail feature in Odoo Accounting
|
||||
|
||||
Send your invoices by post
|
||||
--------------------------
|
||||
|
||||
@ -40,7 +40,7 @@ Configuration
|
||||
|
||||
- Create a journal **Checks**
|
||||
|
||||
- Set **Undeposited Checks** as a defaut credit/debit account
|
||||
- Set **Undeposited Checks** as a default credit/debit account
|
||||
|
||||
- Set the bank account related to this journal as **Allow Reconciliation**
|
||||
|
||||
|
||||
@ -51,7 +51,7 @@ Salestax is calculated in Odoo based on fiscal positions
|
||||
A Fiscal Position for the United States is created when installing *TaxCloud*.
|
||||
Everything works out-of-the-box.
|
||||
|
||||
You can configure Odoo to automtically detect which Customers should use this fiscal
|
||||
You can configure Odoo to automatically detect which Customers should use this fiscal
|
||||
position. Go to :menuselection:`Accounting --> Configuration --> Fiscal Positions`
|
||||
to open and edit the record.
|
||||
|
||||
|
||||
@ -228,7 +228,7 @@ Can I import several times the same record?
|
||||
-------------------------------------------
|
||||
|
||||
If you import a file that contains one of the column "External ID" or "Database ID", records that
|
||||
have already been imported will be modified instead of being created. This is very usefull as it
|
||||
have already been imported will be modified instead of being created. This is very useful as it
|
||||
allows you to import several times the same CSV file while having made some changes in between two
|
||||
imports. Odoo will take care of creating or modifying each record depending if it's new or not.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ How to generate an Unsplash access key
|
||||
=======================================================
|
||||
|
||||
.. tip::
|
||||
**As an SaaS user**, you are ready to use Unsplash. You won't need to follow this guide to set up Unsplash informations, since you will use our own Odoo Unsplash key in a transparent way.
|
||||
**As an SaaS user**, you are ready to use Unsplash. You won't need to follow this guide to set up Unsplash information, since you will use our own Odoo Unsplash key in a transparent way.
|
||||
|
||||
Generate an Unsplash access key for **non-Saas** users
|
||||
======================================================
|
||||
|
||||
@ -266,7 +266,7 @@ Profit&Loss section to your assets.
|
||||
===================================== ===== ======
|
||||
|
||||
If the stock value decreased, the **Inventory** account is credited
|
||||
and te **Inventory Variations** debited.
|
||||
and the **Inventory Variations** debited.
|
||||
|
||||
.. raw:: html
|
||||
|
||||
|
||||
@ -69,7 +69,7 @@ are triggered until a transfer between the *Stock* and the *Picking
|
||||
Area* is created.
|
||||
|
||||
.. note::
|
||||
All theses transfers are pre-generated by Odoo, starting from the end and going backwards.
|
||||
All these transfers are pre-generated by Odoo, starting from the end and going backwards.
|
||||
While working, the operator process these transfers in the opposite order: first the picking,
|
||||
then the packing, then the delivery order.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ In order to use the Odoo UPS API, you will need:
|
||||
|
||||
- An Access Key
|
||||
|
||||
An Access Key is a 16 character alpha-numeric code that allows access to
|
||||
An Access Key is a 16 character alphanumeric code that allows access to
|
||||
the UPS Developer Kit API Development and Production servers.
|
||||
|
||||
Create a UPS Account
|
||||
|
||||
@ -17,7 +17,7 @@ Start generating leads
|
||||
==========================
|
||||
You will now have a new button **Generate Leads** available in your pipeline.
|
||||
You are also able to create lead mining requests from the
|
||||
:menuselection:`Configuration --> Lead Mining Requests` and trough
|
||||
:menuselection:`Configuration --> Lead Mining Requests` and through
|
||||
:menuselection:`Leads --> Leads` where you have the **Generate Leads** button.
|
||||
|
||||
.. image:: media/LM2.png
|
||||
|
||||
@ -3,7 +3,7 @@ Assign leads based on scoring
|
||||
=============================
|
||||
|
||||
With *Leads Scoring* you can automatically rank your leads based on
|
||||
selected criterias.
|
||||
selected criteria.
|
||||
|
||||
For example you could score customers from your country higher or the
|
||||
ones that visited specific pages on your website.
|
||||
@ -24,7 +24,7 @@ You now have a new tab in your *CRM* app called *Leads Management*
|
||||
where you can manage your scoring rules.
|
||||
|
||||
Here's an example for a Canadian lead, you can modify for whatever
|
||||
criteria you wish to score your leads on. You can add as many criterias
|
||||
criteria you wish to score your leads on. You can add as many criteria
|
||||
as you wish.
|
||||
|
||||
.. image:: media/lead_scoring02.png
|
||||
|
||||
@ -24,7 +24,7 @@ Configure the Lane/5000 for Ingenico BENELUX
|
||||
Click on the F button of the terminal, then go in the
|
||||
:menuselection:`PoS Menu --> Settings` and enter the settings password.
|
||||
|
||||
Now, click on connexion change and TCP/IP. Type the IP of your *IoT
|
||||
Now, click on connection change and TCP/IP. Type the IP of your *IoT
|
||||
Box* (you can find it on the form view of your IoT Box). Then, enter
|
||||
9000 as port. The terminal will restart. Once it is done, go on your
|
||||
*IoT Box* form in Odoo and verify that the terminal has been found.
|
||||
@ -66,12 +66,12 @@ still retry to send the payment request.
|
||||
|
||||
If there is any issue with the payment terminal, you can still force the
|
||||
payment using the *Force Done*. This will allow you to validate the
|
||||
order in Odoo even if the connexion between the terminal and Odoo has
|
||||
order in Odoo even if the connection between the terminal and Odoo has
|
||||
issues.
|
||||
|
||||
.. note::
|
||||
This option will only be available if you received an error message
|
||||
telling you the connexion failed.
|
||||
telling you the connection failed.
|
||||
|
||||
Once your payment is processed, on the payment record, you’ll find the
|
||||
type of card that has been used and the transaction ID.
|
||||
|
||||
@ -50,5 +50,5 @@ Successful*. You can always reverse the last transaction by clicking on
|
||||
|
||||
If there is any issue with the payment terminal, you can still force the
|
||||
payment using the *Force Done*. This will allow you to validate the
|
||||
order in Odoo even if the connexion between the terminal and Odoo
|
||||
order in Odoo even if the connection between the terminal and Odoo
|
||||
encounters issues.
|
||||
|
||||
@ -24,7 +24,7 @@ Listing with variations
|
||||
=======================
|
||||
|
||||
When the **use eBay** on a product with variations is checked and with **Fixed
|
||||
Price** as **Listing Type**, the eBay form is sligthly different. In the
|
||||
Price** as **Listing Type**, the eBay form is slightly different. In the
|
||||
variants array, you can choose which variant will be listed on eBay as well as
|
||||
set the price and the quantity for each variant.
|
||||
|
||||
@ -47,4 +47,4 @@ Products identifiers such as EAN, UPC, Brand or MPN are required in most of the
|
||||
The module manages the EAN and UPC identifiers with the **Barcode** field of the product variant.
|
||||
If the **Barcode** field is empty or is value is not valid, the EAN and UPC values will be set as 'Does not apply' as recommended by eBay.
|
||||
The Brand and MPN values are working as item specifics and should be define in the **Variants** tab on the product form.
|
||||
If theses values are not set, 'Does not apply' will be used for the eBay listing.
|
||||
If these values are not set, 'Does not apply' will be used for the eBay listing.
|
||||
|
||||
@ -42,7 +42,7 @@ Using the updated synchronisation method
|
||||
If you have a lot of products, the eBay API can sometimes refuse some synchronization
|
||||
calls due to a time-based limit on the number of requests that eBay enforces.
|
||||
|
||||
To fix this issue, a new implementation mechanism has been developped; however this
|
||||
To fix this issue, a new implementation mechanism has been developed; however this
|
||||
updated mechanism is disabled by default to avoid having the 2 systems running in
|
||||
parallel in existing installations.
|
||||
|
||||
|
||||
@ -66,12 +66,12 @@ Prices per minimum quantity
|
||||
Discounts, margins, roundings
|
||||
=============================
|
||||
|
||||
*Advanced pricing based on formula* allows to set price change rules.
|
||||
Changes can be relative to the product list/catalog price, the product cost price,
|
||||
or to another pricelist. Changes are calculated via discounts or surcharges and can be
|
||||
forced to fit within floor (minumum margin) and ceilings (maximum margins).
|
||||
Prices can be rounded to the nearest cent/dollar or multiple of either
|
||||
(nearest 5 cents, nearest 10 dollars).
|
||||
*Advanced pricing based on formula* allows to set price change rules.
|
||||
Changes can be relative to the product list/catalog price, the product cost price,
|
||||
or to another pricelist. Changes are calculated via discounts or surcharges and can be
|
||||
forced to fit within floor (minimum margin) and ceilings (maximum margins).
|
||||
Prices can be rounded to the nearest cent/dollar or multiple of either
|
||||
(nearest 5 cents, nearest 10 dollars).
|
||||
|
||||
Once installed go to
|
||||
:menuselection:`Sales --> Configuration --> Pricelists`
|
||||
|
||||
@ -23,7 +23,7 @@ to get a specific tracked URL based on the campaign, medium, and source being us
|
||||
|
||||
.. image:: media/link_tracker_fields.png
|
||||
:align: center
|
||||
:alt: View of the link traker fields for Odoo Website
|
||||
:alt: View of the link tracker fields for Odoo Website
|
||||
|
||||
- **URL**: url of the page you want to track (e.g. the home page or a product's page).
|
||||
- **Campaign**: context of your link (e.g. a special promotion).
|
||||
|
||||
@ -84,7 +84,7 @@ Dump stack
|
||||
|
||||
Sending the SIGQUIT signal to an Odoo process (only available on POSIX) makes
|
||||
this process output the current stack trace to log, with info level. When an
|
||||
odoo process seems 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.
|
||||
|
||||
Tracing code execution
|
||||
|
||||
@ -286,7 +286,7 @@ on the value of other fields thanks to the ``attrs`` attribute. Note that ``invi
|
||||
to other elements of the view such as ``button`` or ``group``.
|
||||
|
||||
The ``attrs`` is a dictionary with the property as a key and a domain as a value. The domain gives
|
||||
the conditon in which the property applies. For example:
|
||||
the condition in which the property applies. For example:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
||||
@ -72,7 +72,7 @@ Create your working branch:
|
||||
|
||||
$ git checkout -b master-my_first_branch-xyz
|
||||
|
||||
Your branch name must follow the following name strucutre : <targetVersion>-<feature>-<trigram>
|
||||
Your branch name must follow the following name structure : <targetVersion>-<feature>-<trigram>
|
||||
|
||||
Example: The branch master-sale-fixes-abc on odoo-dev/odoo is a branch containing fixes for the
|
||||
sales app in the odoo/odoo repository, to be deployed in master and done by ABC.
|
||||
|
||||
@ -172,12 +172,12 @@ while one with B and C will be able to read or update, but not search or read.
|
||||
|
||||
.. note::
|
||||
|
||||
* The group of an access right can be ommitted, this means the ACL applies
|
||||
* 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.
|
||||
* If no access right applies to a user, they are not granted access
|
||||
(default-deny).
|
||||
* If a menu item points to a model to which a user doesn't have acces and
|
||||
* 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.
|
||||
|
||||
.. exercise:: Update the access rights file to:
|
||||
@ -412,7 +412,7 @@ another.
|
||||
Odoo can be used to manage multiple companies inside the same system, however
|
||||
the actual handling is up to individual modules: Odoo itself provides the tools
|
||||
to manage the issue like company-dependent fields and *multi-company rules*,
|
||||
which is what we're going to concern outselves with.
|
||||
which is what we're going to concern ourselves with.
|
||||
|
||||
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
|
||||
|
||||
@ -76,7 +76,7 @@ Integration Bots
|
||||
`github.com/odoo`. We highly recommend having your own CI if it is not the case.
|
||||
|
||||
When a test is written, it is important to make sure it always passes when modifications are
|
||||
applied to the source code. To automatize this task, we use a development practice called
|
||||
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`,
|
||||
|
||||
@ -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
|
||||
|
||||
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
|
||||
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``
|
||||
|
||||
@ -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
|
||||
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
|
||||
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
|
||||
|
||||
* ``multi``: Executes serveral actions given through the ``child_ids`` argument.
|
||||
* ``multi``: Executes several actions given through the ``child_ids`` argument.
|
||||
|
||||
State fields
|
||||
------------
|
||||
|
||||
@ -165,7 +165,7 @@ Database
|
||||
.. option:: --db_sslmode
|
||||
|
||||
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'
|
||||
Default value is 'prefer'
|
||||
|
||||
|
||||
@ -330,7 +330,7 @@ should have a real naming as it is used as display name.
|
||||
</record>
|
||||
|
||||
<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>
|
||||
|
||||
<!-- menus and sub-menus -->
|
||||
|
||||
@ -177,7 +177,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
|
||||
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
|
||||
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
|
||||
@ -1556,7 +1556,7 @@ integer (FieldInteger)
|
||||
- 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
|
||||
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.
|
||||
|
||||
.. code-block:: xml
|
||||
@ -1597,7 +1597,7 @@ float (FieldFloat)
|
||||
- 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
|
||||
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.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
@ -109,7 +109,7 @@ to manage followers on your record:
|
||||
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 `\**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
|
||||
|
||||
@ -251,11 +251,11 @@ Subtypes are created as data in your module; the model has the following fields:
|
||||
``res_model`` - :class:`~odoo.fields.Char`
|
||||
model the subtype applies to; if False, this subtype applies to all models
|
||||
``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`
|
||||
used to order subtypes in the notification customization popup
|
||||
``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
|
||||
@ -378,7 +378,7 @@ yourself by overriding the function ``_notification_recipients``.
|
||||
following the thread). True by default for new groups, False for
|
||||
portal / customer.
|
||||
- button_follow
|
||||
dict with url adn title of the button
|
||||
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.
|
||||
@ -575,7 +575,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
|
||||
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
|
||||
|
||||
The ``_get_alias_values()`` override is particularly interesting as it allows you
|
||||
@ -638,7 +638,7 @@ you to make your alias easily configurable from the record's form view.
|
||||
def _get_alias_values(self):
|
||||
""" Specify some default values that will be set in the alias at its creation """
|
||||
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
|
||||
#
|
||||
# in this case, we want all expense records sent to a trip alias
|
||||
@ -703,7 +703,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
|
||||
do a regex match to find the amount of the 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
|
||||
# to encode on the expense. If not, take 1.0 instead
|
||||
amount_pattern = '(\d+(\.\d*)?|\.\d+)'
|
||||
@ -755,7 +755,7 @@ widgets, respectively).
|
||||
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
|
||||
|
||||
@ -778,7 +778,7 @@ You can find concrete examples of integration in the following models:
|
||||
|
||||
* ``crm.lead`` in the CRM (*crm*) 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:
|
||||
@ -868,7 +868,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
|
||||
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
|
||||
|
||||
|
||||
@ -60,7 +60,7 @@ Check if the method is available and then execute it.
|
||||
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
|
||||
|
||||
Show Toast in device
|
||||
|
||||
@ -191,7 +191,7 @@ Date / Datetime comparison best practices:
|
||||
date string, therefore this practice is **heavily**
|
||||
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
|
||||
:class:`~odoo.fields.Date` and :class:`~odoo.fields.Datetime`.
|
||||
These helpers are also available by importing `odoo.tools.date_utils`.
|
||||
|
||||
@ -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
|
||||
to any number of groups, and security mechanisms are associated to groups,
|
||||
thus applying security mechamisms to users.
|
||||
thus applying security mechanisms to users.
|
||||
|
||||
.. class:: res.groups
|
||||
|
||||
@ -32,7 +32,7 @@ thus applying security mechamisms to users.
|
||||
|
||||
Other groups to set on the user alongside this one. This is a
|
||||
convenience pseudo-inheritance relationship: it's possible to
|
||||
explicitely remove implied groups from a user without removing the
|
||||
explicitly remove implied groups from a user without removing the
|
||||
implier.
|
||||
|
||||
.. attribute:: comment
|
||||
|
||||
@ -153,7 +153,7 @@ default you can remove the ``standard`` tag:
|
||||
...
|
||||
|
||||
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
|
||||
|
||||
@ -181,7 +181,7 @@ ones:
|
||||
|
||||
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 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
|
||||
they're not going to get run:
|
||||
|
||||
@ -200,7 +200,7 @@ Special tags
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- ``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``.
|
||||
|
||||
That means untagged test will be executed by default when tests are enabled.
|
||||
@ -214,7 +214,7 @@ Special tags
|
||||
will generally not want both ``post_install`` is usually paired with
|
||||
``-at_install`` when tagging a test class.
|
||||
- *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
|
||||
specific modules when testing e.g. if you want to only run tests from
|
||||
``stock_account``:
|
||||
@ -344,7 +344,7 @@ 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).
|
||||
|
||||
At the same time, our testing sytem is good, because it can detect whenever
|
||||
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.
|
||||
|
||||
|
||||
@ -984,7 +984,7 @@ take the following attributes:
|
||||
``consolidation``
|
||||
field name to display consolidation value in record cell
|
||||
``consolidation_max``
|
||||
dictionnary with the "group by" field as key and the maximum consolidation
|
||||
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}``)
|
||||
``consolidation_exclude``
|
||||
@ -1924,7 +1924,7 @@ Possible children elements of the search view are:
|
||||
2018
|
||||
2017
|
||||
|
||||
Muti selection of options is allowed.
|
||||
Multi selection of options is allowed.
|
||||
|
||||
``default_period`` (optional)
|
||||
only makes sense for a filter with non empty ``date`` attribute.
|
||||
|
||||
@ -62,7 +62,7 @@ Request Body
|
||||
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*.
|
||||
``user_infos`` (required)
|
||||
Information concerning the person to whom the invoice is intended. This informations is not required in order for the service to work but it greatly improves the quality of the result.
|
||||
Information concerning the person to whom the invoice is intended. This information is not required in order for the service to work but it greatly improves the quality of the result.
|
||||
|
||||
``user_company_vat`` (optional)
|
||||
VAT number of the client.
|
||||
@ -120,7 +120,7 @@ Response
|
||||
status_code status_msg
|
||||
============= ==============================================================
|
||||
0 Success
|
||||
2 An error occured
|
||||
2 An error occurred
|
||||
3 You don't have enough credit
|
||||
6 Unsupported file format
|
||||
9 Server is currently under maintenance. Please try again later.
|
||||
@ -208,7 +208,7 @@ Response
|
||||
============= ==============================================================
|
||||
0 Success
|
||||
1 Not ready
|
||||
2 An error occured
|
||||
2 An error occurred
|
||||
9 Server is currently under maintenance. Please try again later.
|
||||
============= ==============================================================
|
||||
|
||||
|
||||
@ -134,7 +134,7 @@ on Odoo (https://iap.odoo.com/my/home) and select *In-App Services*.
|
||||
on sandbox to ease the tests.
|
||||
|
||||
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:
|
||||
@ -688,7 +688,7 @@ care how they are implemented.
|
||||
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
|
||||
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.
|
||||
Returns an :class:`~odoo.addons.iap.tools.iap_tools.InsufficientCreditError` on authorize attempt.
|
||||
* 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.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -9,7 +9,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
|
||||
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
|
||||
"hierarchical" server structure (e.g. ``odoo.res.partner.read()``)
|
||||
* uses its own own manual auth system instead of basic auth or sessions
|
||||
@ -885,7 +885,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
|
||||
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
|
||||
"computed" updates (where the value being set depends on an existing value of
|
||||
a record).
|
||||
|
||||
@ -132,7 +132,7 @@ Here are 2 examples of database upgrade request creation using:
|
||||
|
||||
* one in the python programming language using the requests library
|
||||
* 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
|
||||
|
||||
@ -244,7 +244,7 @@ should be empty if everything went fine.
|
||||
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 will create a temporary SFTP server where you can connect to and allow you
|
||||
@ -320,7 +320,7 @@ explanation about the JSON dictionary returned in case of failure.
|
||||
'''''''''''
|
||||
|
||||
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
|
||||
* ``sftp_port``: the port to connect to
|
||||
@ -638,7 +638,7 @@ Beside downloading your migrated database using the URL provided by the
|
||||
protocol as described in the :ref:`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.
|
||||
|
||||
Your database upgrade request should be in the ``done`` state.
|
||||
|
||||
@ -110,7 +110,7 @@ def add_doc_link(app, pagename, templatename, context, doctree):
|
||||
return
|
||||
|
||||
# FIXME: find other way to recover current document's source suffix
|
||||
# in Sphinx 1.3 it's possible to have mutliple source suffixes and that
|
||||
# in Sphinx 1.3 it's possible to have multiple source suffixes and that
|
||||
# may be useful in the future
|
||||
source_suffix = app.config.source_suffix
|
||||
source_suffix = next(iter(source_suffix))
|
||||
|
||||
@ -71,7 +71,7 @@
|
||||
//
|
||||
// When borders are added on all sides of the cells, the corners can render odd when
|
||||
// these borders do not have the same color or if they are semi-transparent.
|
||||
// Therefor we add top and border bottoms to the `tr`s and left and right borders
|
||||
// Therefore we add top and border bottoms to the `tr`s and left and right borders
|
||||
// to the `td`s or `th`s
|
||||
|
||||
.table-bordered {
|
||||
|
||||
@ -160,7 +160,7 @@
|
||||
],
|
||||
configuration: [
|
||||
"Revenue: defined on the product, or the product category if not on the product, field Income Account",
|
||||
"Defered Tax Liabilities: defined on the tax used on the invoice line",
|
||||
"Deferred Tax Liabilities: defined on the tax used on the invoice line",
|
||||
"Accounts Receivable: defined on the customer (property)",
|
||||
"Inventory: defined on the category of the related product (property)",
|
||||
"Expenses: defined on the product, or the category of product (property)",
|
||||
|
||||
Loading…
Reference in New Issue
Block a user