Current behaviour:
In the project update dashboard, invoices and bills that are created
directly (without sales order or purchase order) are not taken into account
in the calculations for profits/costs.
Expected behaviour:
They should be taken into account, as long as the line on them has the
analytic account line on it.
Steps to reproduce:
- Install Project, Sales, Purchase, Accounting
- Activate "Analytic Accounting" in Settings
- Create a new Project and create a new analytic account for the project
- Create a Bill with a product (storable/consumable) and the analytic account
on the line
- Post the bill
- Go to your project update dashboard and notice the cost of the bill
is not taken into account, but we do have a smart button that goes to the bills
Reason for the problem:
Profits/Costs calculations are done based on the sales/purchase orders,
missing the "orphaned" invoices and bills. A side effect of this problem,
storable products on sales are also not taken into account, since Sales Orders
don't have an analytic account per line before version 16, unless that product
is a service (all services intrinsically have an analytic account)
Fix:
Get all invoices/bills that have lines with the project's analytic account,
and removing from those the lines that were already accounted for.
Affected versions:
- saas-15.3
- 16.0
- master
opw-3058198
closesodoo/odoo#108176
X-original-commit: 3d3f4109a06445b6ce9606770085c763ea206b35
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Go to Request for quotation.
- Make any search that retrieves no values. (So we get the "no request
for quotation found." message)
- Open Filters dropdown menu. (or Any menu which lenghts will be over
this message)
Issue:
The dropdown menu will be under the message, the message is overlaping
the dropdown menu when it shouldn't be.
Solution:
We need to set the message to `position: relative` instead of
`position: static` so we take into account the right z-index for the
message.
opw-3080171
closesodoo/odoo#107409
X-original-commit: 47a6a555c5bcedffdfda7586ecbe4311d2a45e5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
Steps to reproduce
==================
- Use a mobile phone / mobile view in devtools
- Go to Purchase > Purchase Orders
- Click on one item
-> A traceback occurs, the uom is missing
Cause of the issue
==================
The field is declared as
`<field name="product_uom" groups="uom.group_uom"/>`
The raw value is accessed with
`<t t-esc="record.product_uom.value"/>`
Solution
========
Add the missing group
opw-3033650
closesodoo/odoo#105487
X-original-commit: bc6c2d8d15e22f6af720db6a28e21739defede94
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce the issue:
- Create a product P
- Enable packaging on Purchase
- Create a packaging PA such as 1 PA of P = 70 P
- Create a PO with P and set a quantity of 250 with PA as packaging
Bug:
A Warning was raised saying that we should purchase 280, PA was removed and a
quantity of 249.9 was set.
PS: PA was removed because the quantity was changed and function _onchange_suggest_packaging was triggered
opw:3007165
closesodoo/odoo#105065
X-original-commit: a9514d69006c8a389b64550dbcbf30b19160c300
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.
# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."
# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()
OPW-2982004
closesodoo/odoo#104549
X-original-commit: e99cdd6430bf85bcae8ec3b8febcf8e3719169a5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
This join is a leftover from https://github.com/odoo/odoo/pull/28248
and is not needed anymore since currency_rate is now stored on purchase.order.
Removing it allows to greatly speedup purchase.report queries.
On a database with 7000 purchase order and 1100 res_currency_rate:
From:
Planning Time: 4.411 ms
Execution Time: 19815.754 ms
To:
Planning Time: 16.914 ms
Execution Time: 77.433 ms
opw-2973044
closesodoo/odoo#104301
X-original-commit: 4ffa967eecfd930da7a0051122ed746af38ce709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, when the quantity of a PO line is changed, its unit
price is recomputed, which means it will be set to 0 if there is no
compatible vendor price for the selected partner/product.
It can be annoying because if the price unit was set manually by the
user, this info is lost.
To avoid that, we don't recompute the unit price if the PO line matches
the following conditions:
- The PO line has already a price unit;
- There is actually no vendor price list for the partner (in such case,
we prefer to avoid to stick to a price who doesn't match that list);
- The UoM wasn't changed, because if the UoM was changed, the price
should obviously recomputed (the price unit for 1 unit is not the same
than for 1 dozen).
How to reproduce:
- Install Stock and Purchase modules;
- In purchase settings, enable "Purchase Agreements";
- Create a product and in its vendor price list (in "Purchase" tab), add
a price for Partner A (e.g. 10$);
- Create a PO for Partner B, add a PO line for the created product and
set the `price_unit` higher than the created vendor price (e.g. 15$);
- Confirm the order and go in the "Alternatives" tab;
- Click on "Create Alternative" and select Partner A as the vendor;
- Click on "Compare Product Lines" and choose the line for Partner A;
- Go back in the first created PO (with Partner B as vendor)
-> the PO line's quantity is to 0, which is good, but its unit price
is also set to 0 which is annoying.
Additionnaly, in `_get_stock_move_price_unit`, `float_round` the value
just before it was returned because previously, the rouding was done
before the multiplication by the UoM's factor which can cause some
rounding issue if the rouding is not done after that.
closesodoo/odoo#104206
X-original-commit: f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Adapts the Purchase Order Line form to the new grid css system for
groups.
closesodoo/odoo#102760
X-original-commit: 91582733e413e28e9f26f16e7209f6d91ca546c4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Within Purchase tab:
- Make Quantity hidden by default.
- Move Currency right after Price.
Move Purchase Description to the right of Vendor Bills.
closesodoo/odoo#102702
Task: 3004014
X-original-commit: b3e78b5a8f825650123004a8b8677aaacfe6b43e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Avoids breaking the layout by hiding the label instead of fully removing
it from the DOM
Part of task-2985735
X-original-commit: 36eab7d034b52657bae988e5c35b0c429df2c05b
Part-of: odoo/odoo#102495
Since the usage of the `CSS Grid` some view are broken due to too much
CSS rules conflicting together.
The new form view system is less tolerant to missing colspan.
This commit, change the colspan when needed (e.g. no label)
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Some fields on the form view (in panel) are not aligned => BUG
closesodoo/odoo#102246
X-original-commit: 4813d1ebd4295c8be7ee6b6a892604f15cc43fce
Related: odoo/enterprise#32320
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- create a new product “p1”
- Create a purchase order with “P1” → confirm it
- Click on “Purchase history”
Problem:
No purchase order is displayed for this product, whereas we have a
confirmed PO.
Because the partner id is formatted as a string and added to the domain,
so when the `web_search_read` function is executed, it will return an
empty result because the id is supposed to be a number instead of a
string: https://github .com/odoo/odoo/blob/master/addons/web/models/models.py#L62
Solution:
The filter on the vendor can be removed because it's already added when
calling the action: https://github.com/odoo/odoo/blob/678bc958fafd5502a61ce54069b13160ad37d2d4/addons/purchase/models/purchase.py# L1240
opw-2976152
closesodoo/odoo#100892
X-original-commit: 9431adc5bfce525bd3a9ec4c3f7215f2ee312841
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Display the purchase order list instead of the analysis view
opw-2976152
closesodoo/odoo#100758
X-original-commit: be438c80aaceed80b808945cadcc30fd8aba3a86
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
"mail_notification_paynow" mail template layout has been renamed to
"mail_notification_responsible_signature_layout" as it now only differ by the
signature. It allows to use it more widely.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
Steps to reproduce:
- create two products
- create two analytic accounts
- create two new analytic rules by assigning an account to a product
- Create a new PO and select on of the product
- On the same line, change the product to the other one
Issue:
- The analytic account won't be updated
Cause:
Bypass of the `account_analytic_id` whenever there is already on defined
Solution:
For the `Sale` fix, I added the `line.state == 'draft'`.
The reason? Because the compute is triggered after confirmation of the order due to:
https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L931-L935
Therefore, the compute won't also be triggered after confirmation of the SO.
opw-2948950
closesodoo/odoo#99858
X-original-commit: 61604e18128c1cfd0e6d4e510852f780491d6e4e
Signed-off-by: William André (wan) <wan@odoo.com>
To Reporduce
=============
- Create RFQ and send it by mail
Problem
=======
The received mail contains the amount which we don't want to show when it's just a RFQ
Solution
=========
to solve the issue a condition was added to show the amount only on Purchase Order
opw-2955758
closesodoo/odoo#99684
X-original-commit: 6c3c2ce3c8deb5a04a97efb82d1d3ab6acbb81ae
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Steps to reproduce:
- Install purchase
- Go to Settings and activate `Variant Grid Entry`
- Create a new Requests for Quotation
- Add a customer and add a product that has a variant min 2 variant
- Wizard should ask for the variant
- Select 1 variant by increasing quantity in the grid and confirm
- Confirm order
- Add again a product variant with the wizard
Issue:
Price unit is not set on the new line.
Cause:
In `_onchange_quantity` (triggered by the purchase_product_matrix
module), we do not update price unit if order line
is in state `purchase` or `done`.
Solution:
Replace condition to not perform `_onchange_quantity` if order line
has an invoice line.
opw-2956755
closesodoo/odoo#99522
X-original-commit: 8f92146b2d4996be724213345567291f045aad85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a sale order with a product that's invoiced on delivered
quantities.
- Set delivered quantity (partial delivery) and create an invoice based
on the delivered quantity. Set the "Invoice Date" to sometime in the
past.
- Go to the settings and set "Invoicing Switch Threshold" to any date
in the future (so that the invoice you created has a date BEFORE the
new threshold)
- The invoice will get the label "invoicing app legacy".
- Go back to the sales order and change the delivered quantity.
You should see that the invoiced quantity is automatically set to 0.
A similar behavior can be observed with purchase orders.
Why this is happening:
When a new “Invoicing Switch Threshold” is set, all posted invoices
before the threshold are marked as `canceled`. In v15, changing the
delivered quantities triggers the invoiced quantities to be
recalculated as well. However, computing invoiced quantities doesn't
take into account invoices that are marked as `canceled`. This mean
that the newly computed invoiced quantities won't include invoices
posted before threshold.
opw-2896797
closesodoo/odoo#98909
X-original-commit: cc979734bd7ef3f2a94b411cb7b4f3e782b7ddab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
By observing the slowest queries in our servers, we find some indexes
to add (and verify the pertinence of each) :
- Add a index on `sale_id` of `stock_picking` because, it has a one2many inverse highly used.
- Add a index on `product_id` of `purchase_order_line` because, it has a one2many inverse in purchase_stock and there are some search with it (in `_compute_purchased_product_qty`).
- Add a index on `product_id` of `sale_order_line` to improve the `sale.report` view and it is also called by `_compute_sales_count`.
- Add a index `btree_not_null` on `created_purchase_line_id` of `stock.move` because its one2many inverse `move_dest_ids` is highly used.
- `key` on `ir_ui_view`: Backport of https://github.com/odoo/odoo/pull/97478closesodoo/odoo#99130
X-original-commit: da55c8d88b846d9d1841712b6bd96799e2768a5b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
This commit converts the purchase dashboard to owl component
and removes its legacy code.
closesodoo/odoo#97590
Taskid: 2920812
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Minor UX updates in purchase and stock:
Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
"Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
(i.e. "Quantity Updated / Confirmed") so that the scheduled date is
no longer included
Removed (from purchase):
- Duplicated menuitems, i.e. "Purchase > Reporting > Purchase" showed
the same thing as Enterprise menuitem and both were being displayed in
Enterprise version. Also updated the no records found help message
since old message appeared to be slightly out of date.
ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539
Part-of: odoo/odoo#97109
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
The widget `account-tax-totals-field` needs the value of the
`currency_id` field, even when not in multi-currency mode.
The widget is used in `sale.order`, `account.move` and
`purchase.order`. The only place where the field
was not included when not in multi-currency mode
was the purchase.order.
A traceback was raised when attempting
to open the purchase order form when
not in multi-currency.
This is an oversight of odoo/odoo#95729closesodoo/odoo#98597
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Victor Piryns (pivi)