Compare commits
7 Commits
master-tre
...
master-che
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
e5e57f07f3 | [IMP] *: adapt to the new check_access API | ||
|
|
cab5ad8532 |
[ADD] Inventory: product catalog
closes odoo/documentation#10998
X-original-commit:
|
||
|
|
e7b777bebd |
[IMP] accounting: inalterability update
To avoid confusion between lock dates and "locking" with hash
we now speak of "securing" (with hash) instead.
In the related community PR we introduce new inalterability features.
* On account move form view:
* An indicator next to the 'posted' state whether a move is hashed or not.
* A checkbox "Secured" in the "Other Info" tab for the same reason.
* A "Not Secured" filter for account move list views (and account
move line list views) to find moves (and move lines) that are posted but not hashed.
* A new wizard to hash all journals (independent of journal settings).
They are invisible by default; the wizard is visible in debug mode.
They can be made visible for a user by activating a special user group
(similar to multi-currency).
This happens automatically for all users in case the "Hash on Post"
option is activated on any journal or the new wizard is used to secure moves.
This commit updates the documentation accordingly.
The inalterability report pictures and description are updated.
I.e. it now checks all journals independent of whether they are restricted ("Hash on Post") or not.
This is since the wizard can be used to hash any journal.
task-4095970
closes odoo/documentation#10906
Related: odoo/odoo#178915
Related: odoo/enterprise#69324
Related: odoo/upgrade#6458
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
|
||
|
|
707b5842cb |
[IMP] accounting: back to hash journal entries on post
In the related community PR we move from hash on send (back) to hash on post See community PR. This commit adapts related documentation. task-4095970 Part-of: odoo/documentation#10906 Related: odoo/odoo#178915 Related: odoo/enterprise#69324 Related: odoo/upgrade#6458 Signed-off-by: Sven Führ (svfu) <svfu@odoo.com> |
||
|
|
abdb31b852 |
[IMP] Subscriptions: Report format update
closes odoo/documentation#10938
X-original-commit:
|
||
|
|
769793b56c |
[IMP] payment_providers: PCI DSS compliance, payment methods on portal
task-4042449
task-2949379
closes odoo/documentation#10989
X-original-commit:
|
||
|
|
f8a114b334 |
[IMP] all: replace <tree> in <list>
Remove historical error from semantically incorrect <tree>. Viewtiverse task-3599136 task-27709 task-3414068 closes odoo/documentation#8446 Related: odoo/odoo#159909 Related: odoo/enterprise#59787 Related: odoo/upgrade#5884 Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com> |
|
|
@@ -3,10 +3,10 @@ Data inalterability check report
|
|||
================================
|
||||
|
||||
Tax authorities in some countries require companies to **prove their posted accounting entries are
|
||||
inalterable**, meaning that once an entry has been posted, it can no longer be changed.
|
||||
unaltered**, meaning that once an entry has been secured, it can no longer be changed.
|
||||
|
||||
To do so, Odoo can use the **SHA-256 algorithm** to create a unique fingerprint for each posted
|
||||
entry. This fingerprint is called a hash. The hash is generated by taking an entry's essential data
|
||||
To do so, Odoo creates a unique fingerprint for each secured entry thanks to the **SHA-256 algorithm**.
|
||||
This fingerprint is called a hash. The hash is generated by taking an entry's essential data
|
||||
(the values of the `name`, `date`, `journal_id`, `company_id`, `debit`, `credit`, `account_id`, and
|
||||
`partner_id` fields), concatenating it, and inputting it to the SHA-256 hash function, which then
|
||||
outputs a fixed size (256-bit) string of characters. The hash function is deterministic (:dfn:`the
|
||||
|
|
@@ -15,7 +15,7 @@ completely change the resulting hash. Consequently, the SHA-256 algorithm is oft
|
|||
others, for data integrity verification purposes.
|
||||
|
||||
In addition, the previous entry's hash is always added to the next entry to form a **hash chain**.
|
||||
This is used to ensure a new entry is not added afterward between two posted entries, as doing so
|
||||
This is used to ensure a new entry is not added afterward between two secured entries, as doing so
|
||||
would break the hash chain.
|
||||
|
||||
.. note::
|
||||
|
|
@@ -24,27 +24,70 @@ would break the hash chain.
|
|||
bigger than the number of atoms in the known universe. This is why hashes are considered unique
|
||||
in practice.
|
||||
|
||||
.. _data-inalterability/lock:
|
||||
.. _data-inalterability/inalterability_features:
|
||||
|
||||
Lock entries with hash
|
||||
======================
|
||||
Inalterability features
|
||||
=======================
|
||||
|
||||
To start using the hashing function, go to :menuselection:`Accounting --> Configuration > Journals`.
|
||||
Open the journal for which you want to activate the feature, go to the :guilabel:`Advanced Settings`
|
||||
tab, and enable :guilabel:`Lock Sent Invoices with Hash` for sale journals, or
|
||||
:guilabel:`Lock Entries Manually` for purchase and general journals.
|
||||
Inalterability features can be enabled by activating the :ref:`secure posted entries with hash
|
||||
<data-inalterability/restricted>` option on any journal or using the :ref:`secure entries wizard
|
||||
<data-inalterability/wizard>`.
|
||||
|
||||
For sale journals, the entry is automatically locked once it is sent. You can also click on the
|
||||
button :guilabel:`Lock` on the invoice to lock it without sending it. For sale, purchase, and
|
||||
general journals, the locking is always done manually using the same button.
|
||||
- Two indicators are added to the journal entry's form view.
|
||||
They show whether the entry is secured or not.
|
||||
|
||||
- A :icon:`fa-lock` or :icon:`fa-unlock` (:guilabel:`lock icon`) next to the :guilabel:`Posted` state.
|
||||
- A :guilabel:`Secured` checkbox in the :guilabel:`Other info` tab.
|
||||
|
||||
- A :guilabel:`Not Secured` filter is available on journal entries and journal items' list views.
|
||||
It can be used to find posted journal entries that are not secured yet.
|
||||
- The option to open the :ref:`secure entries wizard <data-inalterability/wizard>` is displayed in the
|
||||
:guilabel:`Accounting` menu.
|
||||
|
||||
.. _data-inalterability/restricted:
|
||||
|
||||
Secure posted entries with hash
|
||||
===============================
|
||||
|
||||
To activate the hashing function on a specific journal, go to :menuselection:`Accounting -->
|
||||
Configuration --> Journals`. Open a sales, purchase, or miscellaneous journal, go to the
|
||||
:guilabel:`Advanced Settings` tab, and enable :guilabel:`Secure Posted Entries with Hash`.
|
||||
Journals for which the feature is activated are called "restricted".
|
||||
|
||||
To compute the hash of an entry, Odoo retrieves the predecessor entries of the chain (i.e., the
|
||||
entries with the same sequence prefix) and hashes them in a continuous way from the last hashed
|
||||
entry to the new entry to hash.
|
||||
|
||||
.. warning::
|
||||
Once you lock an entry in a locked journal, you cannot disable the feature anymore, nor edit any
|
||||
locked entry.
|
||||
Once you post an entry in a restricted journal, you cannot disable the feature anymore, nor edit
|
||||
any secured entry.
|
||||
|
||||
.. _data-inalterability/wizard:
|
||||
|
||||
Secure entries wizard
|
||||
=====================
|
||||
|
||||
You can also use the :guilabel:`Secure Entries` Wizard to secure all journal entries,
|
||||
in **all** journals, up to a specific date.
|
||||
|
||||
.. note::
|
||||
The wizard operates independently of the journal settings and journal types.
|
||||
|
||||
To open it, activate the :ref:`developer mode <developer-mode>`, go to :menuselection:`Accounting
|
||||
--> Accounting`, and click on :guilabel:`Secure Entries`. If the :ref:`inalterability features
|
||||
<data-inalterability/inalterability_features>` are activated, it is also visible outside the debug
|
||||
mode.
|
||||
|
||||
To secure entries, select a date up to which all entries should be secured and press
|
||||
:guilabel:`Secure Entries`.
|
||||
|
||||
.. warning::
|
||||
After securing the entries, you can no longer edit them.
|
||||
|
||||
.. note::
|
||||
It can happen that entries that are past the selected date are secured.
|
||||
This is possible since the hash chain corresponds to the sequence prefix,
|
||||
ordered by sequence number.
|
||||
|
||||
.. _data-inalterability/report:
|
||||
|
||||
|
|
@@ -54,17 +97,18 @@ Report download
|
|||
To download the data inalterability check report, go to :menuselection:`Accounting --> Configuration
|
||||
--> Settings --> Reporting` and click on :guilabel:`Download the Data Inalterability Check Report`.
|
||||
|
||||
The report's first section is an overview of all your journals and their configuration. Under the
|
||||
inalterability check column, you can see whether or not a journal's entries are locked with a hash
|
||||
(V) or not (X). The coverage column tells you when a journal's entries started being locked.
|
||||
The report's first section is an overview of all journal sequence prefixes containing hashed entries.
|
||||
In the :guilabel:`Restricted` column, you can see whether or not a journal has the :ref:`secure
|
||||
posted entries with hash <data-inalterability/restricted>` option (V) activated or not (X). The
|
||||
:guilabel:`Check` column tells you whether all entries are correctly hashed.
|
||||
|
||||
.. image:: data_inalterability/journal-overview.png
|
||||
:align: center
|
||||
:alt: Configuration report for two journals
|
||||
|
||||
The second section gives you the result of the data consistency check for each hashed journal. You
|
||||
can view the first hashed entry and its corresponding hash and the last hashed entry and its
|
||||
corresponding hash.
|
||||
The second section gives a more detailed result of the data consistency check for each hashed
|
||||
journal sequence prefix. You can view the first hashed entry and its corresponding hash,
|
||||
as well as the last hashed entry and its corresponding hash.
|
||||
|
||||
.. image:: data_inalterability/data-consistency-check.png
|
||||
:align: center
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 16 KiB |
|
|
@@ -177,8 +177,8 @@ Bank payments
|
|||
|
||||
.. _payment_providers/add_new:
|
||||
|
||||
Enable a payment provider
|
||||
=========================
|
||||
Enabling a payment provider
|
||||
===========================
|
||||
|
||||
To add a new payment provider and make its related payment methods available to your customers,
|
||||
proceed as follows:
|
||||
|
|
@@ -284,10 +284,19 @@ In this case, a **payment token** is created in Odoo to be used as a payment met
|
|||
payments without the customer having to enter their payment method details again. This is
|
||||
particularly useful for the eCommerce conversion rate and subscriptions that use recurring payments.
|
||||
|
||||
.. note::
|
||||
You remain fully PCI-compliant when you enable this feature because Odoo does not store the card
|
||||
details directly. Instead, it creates a payment token that only references the card details
|
||||
stored on the payment provider's server.
|
||||
.. tip::
|
||||
To add or delete their saved payment method details, customers can click :guilabel:`Manage
|
||||
payment methods` in the :ref:`customer portal <users-portal-payment-methods>`.
|
||||
|
||||
.. admonition:: PCI DSS and Attestation of Compliance
|
||||
|
||||
Odoo is not `PCI <https://www.pcisecuritystandards.org>`_ DSS-certified because it does not
|
||||
store cardholder data or process payments. Instead, it outsources tokenization and payment to
|
||||
:ref:`external payment providers <payment_providers/online_providers>`, which means that as an
|
||||
Odoo customer, you only need to complete the minimal Self-Assessment Questionnaire (SAQ) with
|
||||
the provider to obtain the Attestation of Compliance (AoC) and achieve PCI compliance. Odoo
|
||||
should not be mentioned as a payment processor or a third-party service provider in the
|
||||
:abbr:`SAQ (Self-Assessment Questionnaire)`.
|
||||
|
||||
.. _payment_providers/manual_capture:
|
||||
|
||||
|
|
|
|||
|
|
@@ -156,6 +156,8 @@ on :guilabel:`Confirm Password`. Next, activate :abbr:`2FA (two-factor authentic
|
|||
|
||||
Finally, click :guilabel:`Enable two-factor authentication` to complete the setup.
|
||||
|
||||
.. _users-portal-payment-methods:
|
||||
|
||||
Change payment info
|
||||
-------------------
|
||||
|
||||
|
|
|
|||
|
|
@@ -138,4 +138,4 @@ provide helpful context, and distinguish between internal and external locations
|
|||
inventory_management/count_products
|
||||
inventory_management/cycle_counts
|
||||
inventory_management/scrap_inventory
|
||||
|
||||
inventory_management/product_catalog
|
||||
|
|
|
|||
|
|
@@ -0,0 +1,106 @@
|
|||
===============
|
||||
Product catalog
|
||||
===============
|
||||
|
||||
.. |SO| replace:: :abbr:`SO (sales order)`
|
||||
.. |SOs| replace:: :abbr:`SOs (sales orders)`
|
||||
.. |BoM| replace:: :abbr:`BoM (bill of materials)`
|
||||
.. |RfQ| replace:: :abbr:`RfQ (request for quotation)`
|
||||
|
||||
The product *catalog* is a feature integrated with any Odoo app that allows users to add products or
|
||||
components to an order. This includes the **Inventory**, **Manufacturing**, **Sales**, **Purchase**,
|
||||
and **Repairs** apps, among others.
|
||||
|
||||
The product catalog can be accessed from the first tab of a quotation, request for quotation (RfQ),
|
||||
order, or bill of materials (BoM) form, and opens in a new page when selected. The catalog displays
|
||||
products and components in a user-friendly, POS-style format, from which they can be selected and
|
||||
added to forms.
|
||||
|
||||
The product catalog simplifies the creation of new sales orders (SOs), purchase orders (POs),
|
||||
manufacturing orders (MOs), bill of materials (BoMs), and more, by providing a visual interface
|
||||
through which products and components can be quickly selected.
|
||||
|
||||
Use product catalog
|
||||
===================
|
||||
|
||||
To use the product catalog, begin by creating or opening a quotation, |RfQ|, order, or |BoM| to
|
||||
which products or components can be added. For example, create a new sales quotation by navigating
|
||||
to :menuselection:`Sales app`, and clicking :guilabel:`New`.
|
||||
|
||||
On the form (quotation, |RfQ|, order, |BoM|), make sure the first tab on the bottom is selected.
|
||||
Depending on the form being configured, this tab may be titled *Order Lines*, *Components*,
|
||||
*Products*, or *Parts*.
|
||||
|
||||
On the first blank line of the tab, click the :guilabel:`Catalog` link to open the catalog in a new
|
||||
page.
|
||||
|
||||
.. image:: product_catalog/catalog-button.png
|
||||
:align: center
|
||||
:alt: The "Catalog" button on the "Order Lines" tab of a sales quotation.
|
||||
|
||||
The product catalog displays a card for each product added to Odoo. Each card displays a few key
|
||||
details about the corresponding product:
|
||||
|
||||
- Product photo
|
||||
- Product title
|
||||
- Price or cost of the product, depending on whether it is bought, sold, or used as a
|
||||
component
|
||||
- Reference code (e.g. *DESK0005*)
|
||||
- On-hand quantity
|
||||
- Variant attributes (e.g. *Color: White*)
|
||||
|
||||
.. image:: product_catalog/product-card.png
|
||||
:align: center
|
||||
:alt: A product card in the product catalog.
|
||||
|
||||
Products can be filtered using the search bar at the top of the page, or the sidebar on the left
|
||||
side of the page.
|
||||
|
||||
To filter by product type, click the :icon:`fa-caret-down` :guilabel:`(down arrow)` button on the
|
||||
right side of the search bar to open the search menu. In the :guilabel:`Filters` section, select the
|
||||
:guilabel:`Services` filter to only show service products, or the :guilabel:`Products` filter to
|
||||
only show physical products.
|
||||
|
||||
When creating or configuring a quotation or |SO|, specifically, an :guilabel:`In the Order` filter
|
||||
appears in the :guilabel:`Filters` section of the search bar. Select this filter to only show
|
||||
products that have already been added to the form.
|
||||
|
||||
In the sidebar on the left side of the page, select an option in the :icon:`fa-th-list`
|
||||
:guilabel:`PRODUCT CATEGORY` section to filter by product category, or an option in the
|
||||
:icon:`fa-th-list` :guilabel:`ATTRIBUTES` section to filter by variant attribute.
|
||||
|
||||
.. image:: product_catalog/filter-sidebar.png
|
||||
:align: center
|
||||
:alt: The filter sidebar in the product catalog.
|
||||
|
||||
To add a product, click on the product's card, or click the :icon:`fa-shopping-cart` :guilabel:`Add`
|
||||
button in the bottom-right corner of the card. Doing so adds one unit of the product, which is
|
||||
displayed in a field in the bottom-left corner of the card.
|
||||
|
||||
Once a product has been added, clicking the product card continues to add units of the product in
|
||||
increments of one.
|
||||
|
||||
To adjust the quantity of the product added, click the :icon:`fa-minus` :guilabel:`(minus)` button
|
||||
to reduce the quantity by one, or the :icon:`fa-plus` :guilabel:`(plus)` button to increase it by
|
||||
one.
|
||||
|
||||
Alternatively, a specific quantity can be entered by selecting the field between the
|
||||
:icon:`fa-minus` :guilabel:`(minus)` and :icon:`fa-plus` :guilabel:`(plus)` buttons, and typing in
|
||||
the desired quantity.
|
||||
|
||||
To remove a product from the order or |BoM| entirely, either click the :icon:`fa-trash`
|
||||
:guilabel:`Remove` button in the bottom-right corner of the product card, or click the
|
||||
:icon:`fa-minus` :guilabel:`(minus)` button until the quantity has been reduced to zero.
|
||||
|
||||
.. image:: product_catalog/added-product.png
|
||||
:align: center
|
||||
:alt: A product card for a product that has been added.
|
||||
|
||||
Once the desired quantity of each product has been added, return to the form by clicking the
|
||||
:guilabel:`Back to [X]` button at the top of the screen. This button differs depending on the type
|
||||
of form being configured (quotation, |BoM|, etc.).
|
||||
|
||||
.. important::
|
||||
Products appear in the product catalog, and can be added to orders, even if there
|
||||
are zero units of the product on hand. As a result, it is important to confirm the quantity of a
|
||||
product being added to an order is actually available, or inventory inconsistencies may arise.
|
||||
|
After Width: | Height: | Size: 4.4 KiB |
|
After Width: | Height: | Size: 2.9 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 4.3 KiB |
|
|
@@ -2,75 +2,70 @@
|
|||
Subscription reports
|
||||
====================
|
||||
|
||||
The Odoo *Subscriptions* application provides a series of reporting pages to help companies analyze
|
||||
how subscriptions are performing.
|
||||
.. |MRR| replace:: :abbr:`MRR (Monthly Recurring Revenue)`
|
||||
.. |ARR| replace:: :abbr:`ARR (Annual Recurring Revenue)`
|
||||
|
||||
The Odoo **Subscriptions** app provides a series of reporting pages to help companies analyze how
|
||||
subscriptions are performing.
|
||||
|
||||
On the *Subscriptions Analysis* reporting page, users can view specific data related to recurring
|
||||
subscriptions, quantity of subscriptions, how many subscriptions are in progress or paused, and so
|
||||
much more.
|
||||
subscriptions, quantity of subscriptions, in-progress or paused subscriptions, and more.
|
||||
|
||||
The *Retention Analysis* reporting page provides an organized table of subscription retention
|
||||
percentages over any period of time.
|
||||
|
||||
The *MRR Breakdown* reporting page clearly divides MRR (Monthly Recurring Revenue) and ARR (Annual
|
||||
Recurring Revenue) metrics for subscriptions into various graphs, lists, and charts.
|
||||
The *MRR Breakdown* reporting page clearly divides |MRR| and |ARR| metrics for subscriptions into
|
||||
various graphs, lists, and charts.
|
||||
|
||||
And the *MRR Analysis* reporting page offers a time-based collection of analytics showcasing how
|
||||
subscription MRR and ARR has changed over the course of any given period of time.
|
||||
subscription |MRR| and |ARR| have changed over the course of any given period of time.
|
||||
|
||||
Reporting page elements
|
||||
=======================
|
||||
|
||||
All subscription-based reporting pages can be accessed via the :guilabel:`Reporting` header menu in
|
||||
the *Subscriptions* application.
|
||||
All subscriptions-based reporting pages can be accessed via the :guilabel:`Reporting` header menu in
|
||||
the **Subscriptions** app.
|
||||
|
||||
The following describes elements found on each reporting page.
|
||||
The following sections describe elements found on each reporting page.
|
||||
|
||||
Filters and Group By
|
||||
--------------------
|
||||
|
||||
Filters are used to narrow down metrics to show specific analytics, whereas groupings (via the
|
||||
:guilabel:`Group By` option) are used to gather specific sections' data into groups for more
|
||||
*Filters* are used to narrow down metrics to show specific analytics, whereas groupings (via the
|
||||
*Group By* option) are used to gather the data from specific sections into groups for more
|
||||
organized analysis.
|
||||
|
||||
This section refers to both filters and groupings, as a combination of the two can be saved in the
|
||||
:guilabel:`Favorites` section.
|
||||
*Favorites* section.
|
||||
|
||||
To modify the results being shown on any reporting page, click the :guilabel:`▼ (downward facing
|
||||
arrow)` icon to the right of the search bar. Doing so reveals a drop-down menu of detailed filter
|
||||
and grouping options.
|
||||
|
||||
.. note::
|
||||
Multiple filter options and grouping options can be selected at once.
|
||||
|
||||
.. image:: reports/reporting-filter-options-dropdown.png
|
||||
:align: center
|
||||
:alt: The reporting filter drop-down menu of options in the Odoo Subscriptions application.
|
||||
To modify the results being shown on any reporting page, click the :icon:`fa-caret-down`
|
||||
:guilabel:`(down arrow)` icon to the right of the search bar. Doing so reveals a drop-down menu of
|
||||
detailed filter and grouping options.
|
||||
|
||||
If desired, a filter or grouping (or combination of filters and/or groupings) can be saved in the
|
||||
:guilabel:`Favorites` section of that drop-down menu. To do that, click the :guilabel:`▼ (downward
|
||||
facing arrow)` icon beside :guilabel:`Save current search`, located beneath the
|
||||
:guilabel:`Favorites` section of that drop-down menu. To do so, click the :icon:`fa-caret-down`
|
||||
:guilabel:`(down arrow)` icon beside :guilabel:`Save current search`, located beneath the
|
||||
:guilabel:`Favorites` section.
|
||||
|
||||
That reveals a field to assign a title to the favorite filter. There are also two options beneath
|
||||
the title field, as well: :guilabel:`Default filter` and :guilabel:`Shared`.
|
||||
This reveals a field to assign a title to the favorite filter. Two options are also found beneath
|
||||
the title field: :guilabel:`Default filter` and :guilabel:`Shared`.
|
||||
|
||||
Ticking the check box beside :guilabel:`Default filter` makes the newly-favorited filter the default
|
||||
Ticking the checkbox beside :guilabel:`Default filter` makes the newly-favorited filter the default
|
||||
option for that reporting page.
|
||||
|
||||
Ticking the box beside :guilabel:`Shared` makes the newly-favorited filter available to other users
|
||||
in the database.
|
||||
Ticking the checkbox beside :guilabel:`Shared` makes the newly-favorited filter available to other
|
||||
users in the database.
|
||||
|
||||
.. note::
|
||||
The :guilabel:`Default filter` and :guilabel:`Shared` options are **not** required. Only *one* of
|
||||
those options can be selected at a time.
|
||||
The :guilabel:`Default filter` and :guilabel:`Shared` options are **not** required, and only
|
||||
*one* of these options can be selected at a time.
|
||||
|
||||
To save that filter(s), click :guilabel:`Save` in the :guilabel:`Favorites` section of the drop-down
|
||||
To save the filter, click :guilabel:`Save` in the :guilabel:`Favorites` section of the drop-down
|
||||
filter menu.
|
||||
|
||||
When clicked, that saved filter appears beneath the :guilabel:`Favorites` column of the drop-down
|
||||
filter menu, and a :guilabel:`⭐ (gold star)` icon appears beside the favorite filter's name in the
|
||||
search bar.
|
||||
filter menu, and a :icon:`fa-star` :guilabel:`(gold star)` icon appears beside the favorite filter's
|
||||
name in the search bar.
|
||||
|
||||
Views
|
||||
-----
|
||||
|
|
@@ -84,8 +79,8 @@ reporting pages, three different view options are located in the upper-right cor
|
|||
The available view options, from left to right, are:
|
||||
|
||||
- :guilabel:`Graph`
|
||||
- :guilabel:`Pivot`
|
||||
- :guilabel:`List`
|
||||
- :guilabel:`Pivot`
|
||||
|
||||
.. image:: reports/subscriptions-analysis-page-view-options.png
|
||||
:align: center
|
||||
|
|
@@ -102,35 +97,48 @@ representation of the data. These graph-specific options are located to the righ
|
|||
|
||||
.. image:: reports/subscriptions-graph-specific-options.png
|
||||
:align: center
|
||||
:alt: The different graph view options in the Odoo Subscriptions application.
|
||||
:alt: The different graph view options in the Odoo Subscriptions app.
|
||||
|
||||
The first three options, from left to right, represent different graph-related views. The remaining
|
||||
options represent different ways to organize and visualize that specific graph-related data.
|
||||
|
||||
From left to right, the specific graph-related view options are:
|
||||
|
||||
- :guilabel:`Bar Chart`: showcases the data in a bar chart format.
|
||||
- :guilabel:`Line Chart`: showcases the data in a line chart format.
|
||||
- :guilabel:`Pie Chart`: showcases the data in a pie chart format.
|
||||
- :icon:`fa-bar-chart` :guilabel:`Bar Chart`: showcases the data in a bar chart format.
|
||||
- :icon:`fa-line-chart` :guilabel:`Line Chart`: showcases the data in a line chart format.
|
||||
- :icon:`fa-pie-chart` :guilabel:`Pie Chart`: showcases the data in a pie chart format.
|
||||
|
||||
Each graph view option has its own series of specific visual options, which are represented by the
|
||||
available buttons that appear to the right of the selected graph-related view option.
|
||||
|
||||
When the :guilabel:`Bar Chart` graph view is selected, the following visual options are available:
|
||||
When the :icon:`fa-bar-chart` :guilabel:`Bar Chart` graph view is selected, the following visual
|
||||
options are available:
|
||||
|
||||
- :guilabel:`Stacked`: showcases the data in a stacked visual format.
|
||||
- :guilabel:`Descending`: showcases the data in descending order.
|
||||
- :guilabel:`Ascending`: showcases the data in ascending order.
|
||||
- :icon:`fa-database` :guilabel:`Stacked`: showcases the data in a stacked visual format.
|
||||
- :icon:`fa-sort-amount-desc` :guilabel:`Descending`: showcases the data in descending order.
|
||||
- :icon:`fa-sort-amount-asc` :guilabel:`Ascending`: showcases the data in ascending order.
|
||||
|
||||
When the :guilabel:`Line Chart` graph view is selected, the following visual options are available:
|
||||
|
||||
- :guilabel:`Stacked`: showcases the data in a stacked visual format.
|
||||
- :guilabel:`Cumulative`: showcases the data in accumulated, increasing format.
|
||||
- :guilabel:`Descending`: showcases the data in descending order.
|
||||
- :guilabel:`Ascending`: showcases the data in ascending order.
|
||||
- :icon:`fa-database` :guilabel:`Stacked`: showcases the data in a stacked visual format.
|
||||
- :icon:`fa-signal` :guilabel:`Cumulative`: showcases the data in accumulated, increasing format.
|
||||
- :icon:`fa-sort-amount-desc` :guilabel:`Descending`: showcases the data in descending order.
|
||||
- :icon:`fa-sort-amount-asc` :guilabel:`Ascending`: showcases the data in ascending order.
|
||||
|
||||
When the :guilabel:`Pie Chart` graph view is selected, there are no additional visual options.
|
||||
|
||||
List view
|
||||
~~~~~~~~~
|
||||
|
||||
With the list view selected, the subscription metrics being analyzed are displayed in a simple list,
|
||||
which can be fully customized by using any of the available filters or groupings in the drop-down
|
||||
filter menu (accessible via the :icon:`fa-caret-down` :guilabel:`(down arrow)` icon to the right of
|
||||
the search bar).
|
||||
|
||||
.. note::
|
||||
With list view selected, the :guilabel:`Measures` drop-down menu and :guilabel:`Insert in
|
||||
Spreadsheet` button are *not* available.
|
||||
|
||||
Pivot view
|
||||
~~~~~~~~~~
|
||||
|
||||
|
|
@@ -138,47 +146,39 @@ With the pivot view selected, the subscription metrics are displayed in a data t
|
|||
fully customized.
|
||||
|
||||
The pivot data table can be customized using the options available in the :guilabel:`Measures`
|
||||
drop-down menu and/or the filter options available in the filter drop-down menu (accessible via the
|
||||
:guilabel:`▼ (downward facing arrow)` icon to the right of the search bar).
|
||||
drop-down menu, and/or the filter grouping options available in the filter drop-down menu
|
||||
(accessible via the :icon:`fa-caret-down` :guilabel:`(down arrow)` icon to the right of the search
|
||||
bar).
|
||||
|
||||
There are three pivot-specific options available, located to the right of the :guilabel:`Measures`
|
||||
Three pivot-specific options are available, located to the right of the :guilabel:`Measures`
|
||||
drop-down menu and :guilabel:`Insert in Spreadsheet` button.
|
||||
|
||||
.. image:: reports/subscriptions-pivot-view-options.png
|
||||
:align: center
|
||||
:alt: The pivot-specific view options available in the Odoo Subscriptions application.
|
||||
:alt: The pivot-specific view options available in the Odoo Subscriptions app.
|
||||
|
||||
From left to right, those pivot-specific view options are:
|
||||
|
||||
- :guilabel:`Flip axis`: the `x` and `y` axis of the pivot data table flip.
|
||||
- :guilabel:`Expand all`: all the available rows and columns of the pivot data table expand fully.
|
||||
- :guilabel:`Download xlsx`: the pivot data table is downloaded as an .xlsx file.
|
||||
|
||||
List view
|
||||
~~~~~~~~~
|
||||
|
||||
With the list view selected, the subscription metrics being analyzed are displayed in a simple list,
|
||||
which can be fully customized by using any of the available filters in the drop-down filter menu
|
||||
(accessible via the :guilabel:`▼ (downward facing arrow)` icon to the right of the search bar).
|
||||
|
||||
.. note::
|
||||
With list view selected, the :guilabel:`Measures` drop-down menu and :guilabel:`Insert in
|
||||
Spreadsheet` button are *not* available.
|
||||
- :icon:`fa-exchange` :guilabel:`Flip axis`: the `x` and `y` axis of the pivot data table flip.
|
||||
- :icon:`fa-arrows` :guilabel:`Expand all`: all the available rows and columns of the pivot data
|
||||
table expand fully.
|
||||
- :icon:`fa-download` :guilabel:`Download .xlsx`: the pivot data table is downloaded as an
|
||||
:file:`.xlsx` file.
|
||||
|
||||
Measures
|
||||
--------
|
||||
|
||||
Each reporting page has its own metric-specific :guilabel:`Measures` drop-down menu of data-related
|
||||
options to choose from, located in the upper-left corner, above the visual representation of
|
||||
metrics.
|
||||
The graph and pivot reporting pages have their own metric-specific :guilabel:`Measures` drop-down
|
||||
menu of data-related options to choose from, located in the upper-left corner, above the visual
|
||||
representation of metrics.
|
||||
|
||||
.. image:: reports/subscriptions-measures-drop-down.png
|
||||
:align: center
|
||||
:alt: The standard measures drop-down menu in the Odoo Subscriptions application.
|
||||
:alt: The standard measures drop-down menu in the Odoo Subscriptions app.
|
||||
|
||||
When clicked, a series of selectable measures become available, via a drop-down menu. When any of
|
||||
the options are selected from a :guilabel:`Measures` drop-down menu, the chosen metrics related to
|
||||
that specific measure appear on the reporting page.
|
||||
When the :guilabel:`Measures` button is clicked, a series of selectable measures becomes available,
|
||||
via a drop-down menu. When any of the options are selected from the :guilabel:`Measures` drop-down
|
||||
menu, the chosen metrics related to that specific measure appear on the reporting page.
|
||||
|
||||
.. note::
|
||||
For more information on the different measures that can be utilized on each reporting page, refer
|
||||
|
|
@@ -205,14 +205,11 @@ Select the desired option from this pop-up window, then click :guilabel:`Confirm
|
|||
Reporting pages
|
||||
===============
|
||||
|
||||
In the Odoo *Subscriptions* application, there are four different reporting pages available.
|
||||
In the Odoo **Subscriptions** app, there are four different reporting pages available.
|
||||
|
||||
To access, analyze, and customize various reports related to subscriptions, navigate to
|
||||
:menuselection:`Subscriptions app`, and click the :guilabel:`Reporting` drop-down menu in the
|
||||
header.
|
||||
|
||||
Clicking :guilabel:`Reporting` in the header menu reveals a drop-down menu of the following
|
||||
reporting pages:
|
||||
header to reveal the following reporting pages:
|
||||
|
||||
- :guilabel:`Subscriptions`
|
||||
- :guilabel:`Retention`
|
||||
|
|
@@ -240,8 +237,8 @@ The following filters are also present in the search bar: :guilabel:`In Progress
|
|||
:align: center
|
||||
:alt: The default view of the Subscriptions Analysis reporting page in Odoo Subscriptions.
|
||||
|
||||
When the :guilabel:`Measures` drop-down menu on the :guilabel:`Subscriptions Analysis` page is
|
||||
clicked, a series of metric-related options become available.
|
||||
When the :guilabel:`Measures` button on the :guilabel:`Subscriptions Analysis` page is
|
||||
clicked, a series of metric-related options becomes available as a drop-down menu.
|
||||
|
||||
.. image:: reports/subscriptions-analysis-measures.png
|
||||
:align: center
|
||||
|
|
@@ -269,9 +266,9 @@ Retention analysis
|
|||
To access the :guilabel:`Retention Analysis` reporting page, navigate to
|
||||
:menuselection:`Subscriptions app --> Reporting --> Retention`.
|
||||
|
||||
The :guilabel:`Retention Analysis` reporting page differs from the other *Subscriptions* app
|
||||
reporting pages, in that it does *not* provide any additional view options. The data on this page is
|
||||
only presented in a customizable data chart.
|
||||
The :guilabel:`Retention Analysis` reporting page differs from the other **Subscriptions** app
|
||||
reporting pages, in that it does **not** provide any additional view options. The data on this page
|
||||
is only presented in a customizable data chart.
|
||||
|
||||
.. image:: reports/subscriptions-retention-analysis-page-default.png
|
||||
:align: center
|
||||
|
|
@@ -328,9 +325,9 @@ To access the :guilabel:`MRR Breakdown` reporting page, navigate to :menuselecti
|
|||
app --> Reporting --> MRR Breakdown`.
|
||||
|
||||
By default, the data displayed on the :guilabel:`MRR Breakdown` reporting page is in graph view,
|
||||
with the :guilabel:`Bar Chart` option and the :guilabel:`Stacked` option selected.
|
||||
with the :guilabel:`Bar Chart` option and :guilabel:`Stacked` option selected.
|
||||
|
||||
There is also a default filter in the search bar for :guilabel:`Event Date: Month > Event Type`.
|
||||
A default filter is also available in the search bar for :guilabel:`Event Date: Month > Event Type`.
|
||||
|
||||
.. image:: reports/subscriptions-mrr-breakdown-default.png
|
||||
:align: center
|
||||
|
|
@@ -356,14 +353,14 @@ Breakdown` reporting page are:
|
|||
|
||||
.. tip::
|
||||
To make a different measure option the default, first, select the desired measure from the
|
||||
:guilabel:`Measures` drop-down menu. Then, click the :guilabel:`(downward facing arrow)` icon in
|
||||
the search bar to open the mega menu of filters and groupings.
|
||||
:guilabel:`Measures` drop-down menu. Then, click the :icon:`fa-caret-down` :guilabel:`(down
|
||||
arrow)` icon in the search bar to open the mega menu of filters and groupings.
|
||||
|
||||
In the :guilabel:`Favorites` column, click the :guilabel:`(downward facing arrow)` icon beside
|
||||
:guilabel:`Save current search` to reveal a field, where a title can be entered, along with two
|
||||
checkboxes::guilabel:`Default filter` and :guilabel:`Shared`.
|
||||
In the :guilabel:`Favorites` column, click the :icon:`fa-caret-down` :guilabel:`(down arrow)`
|
||||
icon beside :guilabel:`Save current search` to reveal a field, where a title can be entered,
|
||||
along with two checkboxes::guilabel:`Default filter` and :guilabel:`Shared`.
|
||||
|
||||
Tick the box for :guilabel:`Default filter`, and click :guilabel:`Save`.
|
||||
Tick the checkbox for :guilabel:`Default filter`, and click :guilabel:`Save`.
|
||||
|
||||
That newly-chosen measure option is now the default option that appears when this reporting page
|
||||
is accessed.
|
||||
|
|
@@ -378,7 +375,7 @@ By default, the data displayed on the :guilabel:`MRR Analysis` reporting page is
|
|||
the :guilabel:`Line Chart` option, :guilabel:`Stacked` option, and :guilabel:`Cumulative` option
|
||||
selected.
|
||||
|
||||
There is also a default filter in the search bar for :guilabel:`Event Date: Month`.
|
||||
A default filter is also found in the search bar for :guilabel:`Event Date: Month`.
|
||||
|
||||
.. image:: reports/subscriptions-mrr-analysis-default.png
|
||||
:align: center
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 16 KiB |
|
|
@@ -263,10 +263,10 @@ To declare a record in XML, the **record** notation (using *<record>*) is recomm
|
|||
<field name="model">object_name</field>
|
||||
<field name="priority" eval="16"/>
|
||||
<field name="arch" type="xml">
|
||||
<tree>
|
||||
<list>
|
||||
<field name="my_field_1"/>
|
||||
<field name="my_field_2" string="My Label" widget="statusbar" statusbar_visible="draft,sent,progress,done" />
|
||||
</tree>
|
||||
</list>
|
||||
</field>
|
||||
</record>
|
||||
|
||||
|
|
@@ -288,7 +288,7 @@ Use the following pattern :
|
|||
|
||||
* For a menu: :samp:`{<model_name>}_menu`, or :samp:`{<model_name>}_menu_{do_stuff}` for submenus.
|
||||
* For a view: :samp:`{<model_name>}_view_{<view_type>}`, where *view_type* is
|
||||
``kanban``, ``form``, ``tree``, ``search``, ...
|
||||
``kanban``, ``form``, ``list``, ``search``, ...
|
||||
* For an action: the main action respects :samp:`{<model_name>}_action`.
|
||||
Others are suffixed with :samp:`_{<detail>}`, where *detail* is a
|
||||
lowercase string briefly explaining the action. This is used only if
|
||||
|
|
|
|||
|
|
@@ -72,7 +72,7 @@ Its fields are:
|
|||
model to present views for
|
||||
``views``
|
||||
a list of ``(view_id, view_type)`` pairs. The second element of each pair
|
||||
is the category of the view (tree, form, graph, ...) and the first is
|
||||
is the category of the view (list, form, graph, ...) and the first is
|
||||
an optional database id (or ``False``). If no id is provided, the client
|
||||
should fetch the default view of the specified type for the requested
|
||||
model (this is automatically done by
|
||||
|
|
@@ -105,7 +105,7 @@ list and form views::
|
|||
{
|
||||
"type": "ir.actions.act_window",
|
||||
"res_model": "res.partner",
|
||||
"views": [[False, "tree"], [False, "form"]],
|
||||
"views": [[False, "list"], [False, "form"]],
|
||||
"domain": [["customer", "=", true]],
|
||||
}
|
||||
|
||||
|
|
@@ -123,7 +123,7 @@ dialog::
|
|||
In-database window actions have a few different fields which should be ignored
|
||||
by clients, mostly to use in composing the ``views`` list:
|
||||
|
||||
``view_mode`` (default= ``tree,form`` )
|
||||
``view_mode`` (default= ``list,form`` )
|
||||
comma-separated list of view types as a string (/!\\ No spaces /!\\). All of these types will be
|
||||
present in the generated ``views`` list (with at least a ``False`` view_id)
|
||||
``view_ids``
|
||||
|
|
@@ -139,7 +139,7 @@ by clients, mostly to use in composing the ``views`` list:
|
|||
|
||||
<record model="ir.actions.act_window.view" id="test_action_tree">
|
||||
<field name="sequence" eval="1"/>
|
||||
<field name="view_mode">tree</field>
|
||||
<field name="view_mode">list</field>
|
||||
<field name="view_id" ref="view_test_tree"/>
|
||||
<field name="act_window_id" ref="test_action"/>
|
||||
</record>
|
||||
|
|
|
|||
|
|
@@ -9,6 +9,9 @@ Odoo version 18.0
|
|||
|
||||
- Searching by name is now implemented as `_search_display_name` like all other fields.
|
||||
See `#174967 <https://github.com/odoo/odoo/pull/174967>`_.
|
||||
- New methods to check access rights and rules now combine both access rights
|
||||
and rules: `check_access`, `has_access` and `_filtered_access`.
|
||||
See `#179148 <https://github.com/odoo/odoo/pull/179148>`_.
|
||||
|
||||
|
||||
Odoo Online version 17.4
|
||||
|
|
|
|||
|
|
@@ -324,27 +324,26 @@ Each call to ``execute_kw`` takes the following parameters:
|
|||
|
||||
.. example::
|
||||
|
||||
For instance, to see if we can read the ``res.partner`` model, we can call
|
||||
``check_access_rights`` with ``operation`` passed by position and
|
||||
``raise_exception`` passed by keyword (in order to get a true/false result
|
||||
rather than true/error):
|
||||
For instance, to search for records in the ``res.partner`` model, we can call
|
||||
``name_search`` with ``name`` passed by position and ``limit`` passed by
|
||||
keyword (in order to get maximum 10 results):
|
||||
|
||||
.. tabs::
|
||||
|
||||
.. code-tab:: python
|
||||
|
||||
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(url))
|
||||
models.execute_kw(db, uid, password, 'res.partner', 'check_access_rights', ['read'], {'raise_exception': False})
|
||||
models.execute_kw(db, uid, password, 'res.partner', 'name_search', ['foo'], {'limit': 10})
|
||||
|
||||
.. code-tab:: ruby
|
||||
|
||||
models = XMLRPC::Client.new2("#{url}/xmlrpc/2/object").proxy
|
||||
models.execute_kw(db, uid, password, 'res.partner', 'check_access_rights', ['read'], {raise_exception: false})
|
||||
models.execute_kw(db, uid, password, 'res.partner', 'name_search', ['foo'], {limit: 10})
|
||||
|
||||
.. code-tab:: php
|
||||
|
||||
$models = ripcord::client("$url/xmlrpc/2/object");
|
||||
$models->execute_kw($db, $uid, $password, 'res.partner', 'check_access_rights', array('read'), array('raise_exception' => false));
|
||||
$models->execute_kw($db, $uid, $password, 'res.partner', 'name_search', array('foo'), array('limit' => 10));
|
||||
|
||||
.. code-tab:: java
|
||||
|
||||
|
|
@@ -355,9 +354,9 @@ Each call to ``execute_kw`` takes the following parameters:
|
|||
}};
|
||||
models.execute("execute_kw", asList(
|
||||
db, uid, password,
|
||||
"res.partner", "check_access_rights",
|
||||
asList("read"),
|
||||
new HashMap() {{ put("raise_exception", false); }}
|
||||
"res.partner", "name_search",
|
||||
asList("foo"),
|
||||
new HashMap() {{ put("limit", 10); }}
|
||||
));
|
||||
|
||||
.. code-tab:: go
|
||||
|
|
@@ -369,9 +368,9 @@ Each call to ``execute_kw`` takes the following parameters:
|
|||
var result bool
|
||||
if err := models.Call("execute_kw", []any{
|
||||
db, uid, password,
|
||||
"res.partner", "check_access_rights",
|
||||
[]string{"read"},
|
||||
map[string]bool{"raise_exception": false},
|
||||
"res.partner", "name_search",
|
||||
[]string{"foo"},
|
||||
map[string]bool{"limit": 10},
|
||||
}, &result); err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
|
|
|||
|
|
@@ -265,11 +265,11 @@ The `field` element can have the following attributes:
|
|||
:noindex:
|
||||
|
||||
The comma-separated list of display modes (view types) to use for the field's linked records.
|
||||
Allowed modes are: `tree`, `form`, `kanban`, and `graph`.
|
||||
Allowed modes are: `list`, `form`, `kanban`, and `graph`.
|
||||
|
||||
:requirement: Optional
|
||||
:type: str
|
||||
:default: `tree`
|
||||
:default: `list`
|
||||
:scope: :class:`~odoo.fields.One2many` and :class:`~odoo.fields.Many2many` fields
|
||||
|
||||
.. include:: view_architectures/generic_attribute_class.rst
|
||||
|
|
@@ -321,9 +321,9 @@ The `field` element can have the following attributes:
|
|||
.. code-block:: xml
|
||||
|
||||
<field name="children_ids">
|
||||
<tree>
|
||||
<list>
|
||||
<field name="name"/>
|
||||
</tree>
|
||||
</list>
|
||||
<form>
|
||||
<field name="id"/>
|
||||
<field name="name"/>
|
||||
|
|
@@ -1154,7 +1154,7 @@ The `<setting>` element can have the following attributes:
|
|||
List
|
||||
====
|
||||
|
||||
The root element of list views is `tree`\ [#treehistory]_.
|
||||
The root element of list views is `list` (the previous name was `tree`).
|
||||
|
||||
.. admonition:: Possible structure and representation of its rendering
|
||||
|
||||
|
|
@@ -1166,16 +1166,16 @@ The root element of list views is `tree`\ [#treehistory]_.
|
|||
|
||||
* - .. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
...
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. _reference/view_architectures/list/root:
|
||||
|
||||
Root attributes
|
||||
---------------
|
||||
|
||||
Optional attributes can be added to the root element `tree` to customize the view.
|
||||
Optional attributes can be added to the root element `list` to customize the view.
|
||||
|
||||
.. include:: view_architectures/root_attribute_string.rst
|
||||
|
||||
|
|
@@ -1269,9 +1269,9 @@ Optional attributes can be added to the root element `tree` to customize the vie
|
|||
.. example::
|
||||
.. code-block:: xml
|
||||
|
||||
<tree decoration-danger="field_qty > field_limit">
|
||||
<list decoration-danger="field_qty > field_limit">
|
||||
...
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
:requirement: Optional
|
||||
:type: :ref:`Python expression <reference/view_architectures/python_expression>`
|
||||
|
|
@@ -1336,9 +1336,9 @@ Using the same field multiple times in a list view is not supported
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<field name="FIELD_NAME"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
The `field` element can have the following attributes:
|
||||
|
||||
|
|
@@ -1466,12 +1466,12 @@ The `field` element can have the following attributes:
|
|||
|
||||
* - .. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<field name="name" string="My Custom Name"/>
|
||||
<field name="amount" sum="Total"/>
|
||||
<field name="currency_id"/>
|
||||
<field name="tax_id"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. _reference/view_architectures/list/button:
|
||||
|
||||
|
|
@@ -1480,10 +1480,10 @@ The `field` element can have the following attributes:
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<button type="object" name="ACTION" string="LABEL"/>
|
||||
<button type="object" name="ACTION" icon="FONT_AWESOME"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
The `button` element can have the following attributes:
|
||||
|
||||
|
|
@@ -1517,14 +1517,14 @@ The `button` element can have the following attributes:
|
|||
|
||||
* - .. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<field name="name"/>
|
||||
<button type="edit" name="edit" icon="fa-edit" title="Edit"/>
|
||||
<button type="object" name="my_method" string="Button1" column_invisible="context.get('hide_button')" invisible="amount > 3"/>
|
||||
<field name="amount"/>
|
||||
<field name="currency_id"/>
|
||||
<field name="tax_id"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. _reference/view_architectures/list/groupby:
|
||||
|
||||
|
|
@@ -1539,13 +1539,13 @@ thus belong on the Many2one co-model. These extra fields are fetched in batch.
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
...
|
||||
<groupby name="FIELD_NAME">
|
||||
<BUTTONS/>
|
||||
<FIELDS/>
|
||||
</groupby>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
The `groupby` element can have the following attributes:
|
||||
|
||||
|
|
@@ -1570,7 +1570,7 @@ The `groupby` element can have the following attributes:
|
|||
|
||||
* - .. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<field name="name"/>
|
||||
<field name="amount"/>
|
||||
<field name="currency"/>
|
||||
|
|
@@ -1581,7 +1581,7 @@ The `groupby` element can have the following attributes:
|
|||
<field name="email"/>
|
||||
<button type="object" name="my_method" string="Button1" invisible="email == 'jhon@conor.com'"/>
|
||||
</groupby>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. note::
|
||||
Fields inside the `groupby` element are used only to fetch and store the value, but they are
|
||||
|
|
@@ -1594,12 +1594,12 @@ The `groupby` element can have the following attributes:
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<header>
|
||||
<BUTTONS/>
|
||||
</header>
|
||||
...
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
The `header` element accepts the following children elements:
|
||||
|
||||
|
|
@@ -1640,7 +1640,7 @@ The `header` element accepts the following children elements:
|
|||
|
||||
* - .. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<header>
|
||||
<button type="object" name="to_draft" string="Button1" invisible="context.get('hide_button')"/>
|
||||
</header>
|
||||
|
|
@@ -1648,7 +1648,7 @@ The `header` element accepts the following children elements:
|
|||
<field name="amount"/>
|
||||
<field name="currency"/>
|
||||
<field name="tax_id"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. _reference/view_architectures/list/control:
|
||||
|
||||
|
|
@@ -1660,13 +1660,13 @@ defined through a `create` element.
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<control>
|
||||
<create string="LABEL"/>
|
||||
<BUTTONS/>
|
||||
</control>
|
||||
...
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
The `control` element takes no attributes.
|
||||
|
||||
|
|
@@ -1700,7 +1700,7 @@ The `create` element can have the following attributes:
|
|||
|
||||
* - .. code-block:: xml
|
||||
|
||||
<tree>
|
||||
<list>
|
||||
<field name="name"/>
|
||||
<field name="amount"/>
|
||||
<field name="currency"/>
|
||||
|
|
@@ -1710,16 +1710,13 @@ The `create` element can have the following attributes:
|
|||
<create string="Add a section" context="{'default_type': 'section'}"/>
|
||||
<create string="Add a note" context="{'default_type': 'note'}"/>
|
||||
</control>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. note::
|
||||
Using the `control` element makes sense only if the list view is inside a
|
||||
:class:`~odoo.fields.One2many` or :class:`~odoo.fields.Many2many` field. If any `create` element
|
||||
is defined, it overwrites the default :guilabel:`add a line` button.
|
||||
|
||||
.. [#treehistory] For historical reasons, it has its origin in tree-type views later repurposed to a
|
||||
more table/list-type display
|
||||
|
||||
.. _reference/view_architectures/search:
|
||||
|
||||
Search
|
||||
|
|
|
|||
|
|
@@ -11,10 +11,10 @@
|
|||
<form>
|
||||
<field name="tag_ids" widget="many2many_tags"/>
|
||||
</form>
|
||||
<tree>
|
||||
<list>
|
||||
<field name="sequence" widget="handle"/>
|
||||
<field name="level_progress" widget="progressbar"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
:requirement: Optional
|
||||
:type: str
|
||||
|
|
|
|||
|
|
@@ -9,9 +9,9 @@
|
|||
.. example::
|
||||
.. code-block:: xml
|
||||
|
||||
<tree default_order="sequence,name desc">
|
||||
<list default_order="sequence,name desc">
|
||||
...
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
:requirement: Optional
|
||||
:type: str
|
||||
|
|
|
|||
|
|
@@ -273,7 +273,7 @@ action more easily.
|
|||
<record model="ir.actions.act_window" id="action_list_ideas">
|
||||
<field name="name">Ideas</field>
|
||||
<field name="res_model">idea.idea</field>
|
||||
<field name="view_mode">tree,form</field>
|
||||
<field name="view_mode">list,form</field>
|
||||
</record>
|
||||
<menuitem id="menu_ideas" parent="menu_root" name="Ideas" sequence="10"
|
||||
action="action_list_ideas"/>
|
||||
|
|
@@ -321,7 +321,7 @@ is implied by the root element of the ``arch`` field:
|
|||
<field name="model">object_name</field>
|
||||
<field name="priority" eval="16"/>
|
||||
<field name="arch" type="xml">
|
||||
<!-- view content: <form>, <tree>, <graph>, ... -->
|
||||
<!-- view content: <form>, <list>, <graph>, ... -->
|
||||
</field>
|
||||
</record>
|
||||
|
||||
|
|
@@ -330,20 +330,20 @@ is implied by the root element of the ``arch`` field:
|
|||
|
||||
The ``arch`` field must thus be declared as ``type="xml"`` to be parsed correctly.
|
||||
|
||||
Tree views
|
||||
list views
|
||||
----------
|
||||
|
||||
Tree views, also called list views, display records in a tabular form.
|
||||
list views, also called list views, display records in a tabular form.
|
||||
|
||||
Their root element is ``<tree>``. The simplest form of the tree view simply
|
||||
Their root element is ``<list>``. The simplest form of the list view simply
|
||||
lists all the fields to display in the table (each field as a column):
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree string="Idea list">
|
||||
<list string="Idea list">
|
||||
<field name="name"/>
|
||||
<field name="inventor_id"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
.. _howtos/module/views/form:
|
||||
|
||||
|
|
@@ -716,7 +716,7 @@ field whenever some of its dependencies have been modified::
|
|||
.. exercise:: Computed fields
|
||||
|
||||
* Add the percentage of taken seats to the *Session* model
|
||||
* Display that field in the tree and form views
|
||||
* Display that field in the list and form views
|
||||
* Display the field as a progress bar
|
||||
|
||||
Default values
|
||||
|
|
@@ -845,10 +845,10 @@ and ``message`` is the error message.
|
|||
Advanced Views
|
||||
==============
|
||||
|
||||
Tree views
|
||||
list views
|
||||
----------
|
||||
|
||||
Tree views can take supplementary attributes to further customize their
|
||||
list views can take supplementary attributes to further customize their
|
||||
behavior:
|
||||
|
||||
``decoration-{$name}``
|
||||
|
|
@@ -872,20 +872,20 @@ behavior:
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree string="Idea Categories" decoration-info="state=='draft'"
|
||||
<list string="Idea Categories" decoration-info="state=='draft'"
|
||||
decoration-danger="state=='trashed'">
|
||||
<field name="name"/>
|
||||
<field name="state"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
``editable``
|
||||
Either ``"top"`` or ``"bottom"``. Makes the tree view editable in-place
|
||||
Either ``"top"`` or ``"bottom"``. Makes the list view editable in-place
|
||||
(rather than having to go through the form view), the value is the
|
||||
position where new rows appear.
|
||||
|
||||
.. exercise:: List coloring
|
||||
|
||||
Modify the Session tree view in such a way that sessions lasting less than
|
||||
Modify the Session list view in such a way that sessions lasting less than
|
||||
5 days are colored blue, and the ones lasting more than 15 days are
|
||||
colored red.
|
||||
|
||||
|
|
@@ -1173,7 +1173,7 @@ action may be triggered via a menu item, but is more generally triggered by a
|
|||
button.
|
||||
|
||||
An other way to launch wizards is through the :menuselection:`Action` menu of
|
||||
a tree or form view. This is done through the ``binding_model_id`` field of the
|
||||
a list or form view. This is done through the ``binding_model_id`` field of the
|
||||
action. Setting this field will make the action appear on the views of the model
|
||||
the action is "bound" to.
|
||||
|
||||
|
|
@@ -1282,7 +1282,7 @@ A report is a combination two elements:
|
|||
|
||||
Because it largerly a standard action, as with :ref:`howto/module/wizard`
|
||||
it is generally useful to add the report as a *contextual item* on the
|
||||
tree and / or form views of the model being reported on via the
|
||||
list and / or form views of the model being reported on via the
|
||||
``binding_model_id`` field.
|
||||
|
||||
Here we are also using ``binding_type`` in order for the report to be in
|
||||
|
|
|
|||
|
|
@@ -355,21 +355,15 @@ Explicit security checks can be performed by:
|
|||
specific models or records.
|
||||
* Checking that the current user has specific groups hard-coded to allow or deny
|
||||
an operation (``self.env.user.has_group``).
|
||||
* Calling the ``check_access_rights(operation)`` method on a recordset, this
|
||||
verifies whether the current user has access to the model itself.
|
||||
* Calling ``check_access_rule(operations)`` on a non-empty recordset, this
|
||||
verifies that the current user is allowed to perform the operation on *every*
|
||||
record of the set.
|
||||
|
||||
.. warning:: Checking access rights and checking record rules are separate
|
||||
operations, if you're checking record rules you usually want to
|
||||
also check access rights beforehand.
|
||||
* Calling ``check_access(operations)`` on a recordset, this verifies that the
|
||||
current user is allowed to perform the operation on *every* record of the set.
|
||||
As a special case, when the recordset is empty, it verifies that the current
|
||||
user has some access rights to perform the operation on the model in general.
|
||||
|
||||
.. exercise::
|
||||
|
||||
Before creating the invoice, use ``check_access_rights`` and
|
||||
``check_access_rule`` to ensure that the current user can update properties
|
||||
in general as well as the specific property the invoice is for.
|
||||
Before creating the invoice, use ``check_access`` to ensure that the current
|
||||
user can update the property the invoice is for.
|
||||
|
||||
Re-run the bypass script, check that the error occurs before the print.
|
||||
|
||||
|
|
|
|||
|
|
@@ -75,7 +75,7 @@ A basic action for our `test_model` is:
|
|||
<record id="test_model_action" model="ir.actions.act_window">
|
||||
<field name="name">Test action</field>
|
||||
<field name="res_model">test_model</field>
|
||||
<field name="view_mode">tree,form</field>
|
||||
<field name="view_mode">list,form</field>
|
||||
</record>
|
||||
|
||||
- ``id`` is an :term:`external identifier`. It can be used to refer to the record
|
||||
|
|
@@ -83,7 +83,7 @@ A basic action for our `test_model` is:
|
|||
- ``model`` has a fixed value of ``ir.actions.act_window`` (:ref:`reference/actions/window`).
|
||||
- ``name`` is the name of the action.
|
||||
- ``res_model`` is the model which the action applies to.
|
||||
- ``view_mode`` are the views that will be available; in this case they are the list (tree) and form views.
|
||||
- ``view_mode`` are the views that will be available; in this case they are the list and form views.
|
||||
We'll see :doc:`later <14_qwebintro>` that there can be other view modes.
|
||||
|
||||
Examples can be found everywhere in Odoo, but
|
||||
|
|
|
|||
|
|
@@ -12,7 +12,7 @@ Views are defined in XML files with actions and menus. They are instances of the
|
|||
|
||||
In our real estate module, we need to organize the fields in a logical way:
|
||||
|
||||
- in the list (tree) view, we want to display more than just the name.
|
||||
- in the list view, we want to display more than just the name.
|
||||
- in the form view, the fields should be grouped.
|
||||
- in the search view, we must be able to search on more than just the name. Specifically, we want a
|
||||
filter for the 'Available' properties and a shortcut to group by postcode.
|
||||
|
|
@@ -31,17 +31,17 @@ List
|
|||
:align: center
|
||||
:alt: List view
|
||||
|
||||
List views, also called tree views, display records in a tabular form.
|
||||
List views, also called list views, display records in a tabular form.
|
||||
|
||||
Their root element is ``<tree>``. The most basic version of this view simply
|
||||
Their root element is ``<list>``. The most basic version of this view simply
|
||||
lists all the fields to display in the table (where each field is a column):
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree string="Tests">
|
||||
<list string="Tests">
|
||||
<field name="name"/>
|
||||
<field name="last_seen"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
A simple example can be found
|
||||
`here <https://github.com/odoo/odoo/blob/6da14a3aadeb3efc40f145f6c11fc33314b2f15e/addons/crm/views/crm_lost_reason_views.xml#L46-L54>`__.
|
||||
|
|
|
|||
|
|
@@ -72,7 +72,7 @@ In practice a many2one can be seen as a dropdown list in a form view.
|
|||
========================= ========================= =========================
|
||||
|
||||
- Add the menus as displayed in this section's **Goal**
|
||||
- Add the field ``property_type_id`` into your ``estate.property`` model and its form, tree
|
||||
- Add the field ``property_type_id`` into your ``estate.property`` model and its form, list
|
||||
and search views
|
||||
|
||||
This exercise is a good recap of the previous chapters: you need to create a
|
||||
|
|
@@ -179,7 +179,7 @@ operations like ``recs1 | recs2``.
|
|||
========================= ========================= =========================
|
||||
|
||||
- Add the menus as displayed in this section's **Goal**
|
||||
- Add the field ``tag_ids`` to your ``estate.property`` model and in its form and tree views
|
||||
- Add the field ``tag_ids`` to your ``estate.property`` model and in its form and list views
|
||||
|
||||
Tip: in the view, use the ``widget="many2many_tags"`` attribute as demonstrated
|
||||
`here <https://github.com/odoo/odoo/blob/5bb8b927524d062be32f92eb326ef64091301de1/addons/crm_iap_lead_website/views/crm_reveal_views.xml#L36>`__.
|
||||
|
|
@@ -196,7 +196,7 @@ One2many
|
|||
|
||||
**Goal**: at the end of this section:
|
||||
|
||||
- a new ``estate.property.offer`` model should be created with the corresponding form and tree view.
|
||||
- a new ``estate.property.offer`` model should be created with the corresponding form and list view.
|
||||
- offers should be added to the ``estate.property`` model:
|
||||
|
||||
.. image:: 07_relations/property_offer.png
|
||||
|
|
@@ -244,7 +244,7 @@ that accessing the data must be done in a loop::
|
|||
property_id Many2one (``estate.property``) required
|
||||
========================= ================================ ============= =================
|
||||
|
||||
- Create a tree view and a form view with the ``price``, ``partner_id`` and ``status`` fields. No
|
||||
- Create a list view and a form view with the ``price``, ``partner_id`` and ``status`` fields. No
|
||||
need to create an action or a menu.
|
||||
- Add the field ``offer_ids`` to your ``estate.property`` model and in its form view as
|
||||
depicted in this section's **Goal**.
|
||||
|
|
|
|||
|
|
@@ -70,10 +70,10 @@ a form view. For example:
|
|||
<form>
|
||||
<field name="description"/>
|
||||
<field name="line_ids">
|
||||
<tree>
|
||||
<list>
|
||||
<field name="field_1"/>
|
||||
<field name="field_2"/>
|
||||
</tree>
|
||||
</list>
|
||||
</field>
|
||||
</form>
|
||||
|
||||
|
|
@@ -352,9 +352,9 @@ complete list):
|
|||
|
||||
.. code-block:: xml
|
||||
|
||||
<tree decoration-success="is_partner==True">
|
||||
<list decoration-success="is_partner==True">
|
||||
<field name="name"/>
|
||||
</tree>
|
||||
</list>
|
||||
|
||||
The records where ``is_partner`` is ``True`` will be displayed in green.
|
||||
|
||||
|
|
|
|||
|
|
@@ -698,10 +698,10 @@ let's also add views so we can see and edit a course's teacher:
|
|||
<field name="name">Academy courses: list</field>
|
||||
<field name="model">academy.courses</field>
|
||||
<field name="arch" type="xml">
|
||||
<tree string="Courses">
|
||||
<list string="Courses">
|
||||
<field name="name"/>
|
||||
<field name="teacher_id"/>
|
||||
</tree>
|
||||
</list>
|
||||
</field>
|
||||
</record>
|
||||
<record id="academy_course_form" model="ir.ui.view">
|
||||
|
|
@@ -761,9 +761,9 @@ model:
|
|||
<field name="name"/>
|
||||
<field name="biography"/>
|
||||
<field name="course_ids">
|
||||
<tree Sstring="Courses" editable="bottom">
|
||||
<list string="Courses" editable="bottom">
|
||||
<field name="name"/>
|
||||
</tree>
|
||||
</list>
|
||||
</field>
|
||||
</sheet>
|
||||
</form>
|
||||
|
|
|
|||