This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With Rounding Method set to 'Round Globally'
Create a Quotation with 2 lines:
- Price 6.7, Tax 15%
- Price 6.7, Tax 15%
Total is 15.41, Tax amount 2.01
When sending the quotation via email or in list view the amount total
shown is 15.42.
This occurs because:
- order total is computed as sum of the lines `price_total` field,
which, defined as Monetary, store already rounded values
- line total is computed via `_compute_taxes`, where
tax amount is always rounded per line
opw-3113851
closesodoo/odoo#113026
X-original-commit: c677f45dcb050ce7e6f755b71e56c9b9120bf613
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
- Install stock, purchase
- Create a product with a long name without whitespace
- Create a purchase order with that product
- Go to portal and access the purchase order
Current behavior:
- Product description overflows when accessing the PO from the portal
Behavior after the PR:
- To fix the problem in the Portal we add table-responsive to the table
opw-3133407
closesodoo/odoo#112672
X-original-commit: 5abccc5efc6e333c8a889a1c24419dadc9c6e7f0
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the case where portal_customer is not added in the
recipients group by the portal mixin.
Steps to reproduce:
- Go on a purchase
- Log a note and tag a user who handles notification by email
- Traceback:
```
File "/home/odoo/src/odoo/addons/purchase/models/purchase.py",
line 346, in _notify_get_recipients_groups
customer_portal_group = next(group for group in groups if group[0] == 'portal_customer')
StopIteration
```
Current Behavior:
- Traceback StopIteration
Expected Behavior:
- Log a note with the tagged (boomer) user.
See odoo/odoo@f879cf2867closesodoo/odoo#112465
X-original-commit: 7b9dd53a5573141275d41436189c782bccb96c3d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
To reproduce the issue:
1. Install [Inventory], [Purchase] on Apps
2. [Settings]>[Inventory]>[Storage Locations]: enable
3. On [Purchase], Create. 'Deliver to' field is ill-positioned
Desired view: use the full width of the row
Applicable versions: 16.0 - master
opw-314167
closesodoo/odoo#111759
X-original-commit: 46700f12b0b4e64029bccf3abb791fe95400331d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Steps to reproduce:
- Create an analytic plan with the domain as a Bill
- Create an analytic account for the above plan
- Create an analytic distribution model and include condition as account prefix, and product.
Issue:
The analytic distribution model doesn't apply to the bill created via purchase order
Solution:
Make sure we set the analytic_distribution only if present in order
to trigger the compute during invoice creation.
opw-3160041
closesodoo/odoo#111717
X-original-commit: ce5cae1da3f453ce1aad0915189e0e305d7e55e0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
When a vendor bill document is uploaded (EDI, PDF,..) the link with
the purchase order is often lost.
We want to reuse the purchase.order OCR' matching logic to enhance
vendor bill extracted from documents.
To sum up the logic;
- if we find a partner or reference match (invoice_origin)
AND the same amount, we use autocomplete and replace the line in the vendor
bill with the purchase order one.
- if we find a match with the reference and some line in the purchase order
sum up to the vendor bill total, we add those line in the vendor bill
but we set the qty to zero (the accountant can manually remove the XML
line and link the new one afterwards).
task-id: 2828521
[community](https://github.com/odoo/odoo/pull/109093)
[enterprise](https://github.com/odoo/enterprise/pull/35436)
update master: make _find_matching_subset_invoice_lines private
closesodoo/odoo#111491
X-original-commit: ebc8b007ecb375d20c566b6e6ecc3f6749ebaa2a
Related: odoo/enterprise#36545
Signed-off-by: Josse Colpaert <jco@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Currently notification process called notably by message_{post,notify} does
not notify message's author by default. Rationale is that as he typed the
message he is already aware of it.
However in some cases we want to skip this step, notably when messages are
generated in the name of the author and when we want him to be notified if
he should.
This is currently controllable through a context key 'mail_notify_author'.
In this commit we add an explicit parameter propagated through the notify
process, allowing to remove some context key usage and instead use real
parameters.
Note that all context keys usage cannot be removed as it is not always
possible to propagate this parameter.
Followup of odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Steps to reproduce:
- increase price_precision in decimal accuracy (in debug mode)
- create a product with multiple digits
- create a PO with that product
- unit price is rounded to 2 digits (currency pricision)
Bug:
in previous versions conversion was only done if currency
was different
Fix:
do not round during conversion and round to the highest digits
(alternatively we could revert to only converting if currecy is
different and accept the loss of precission in that case)
the wrong currency was used also for the conversion
opw-3050044
closesodoo/odoo#111223
X-original-commit: 2e46bf073c2251ce3d3ab5d5184feceb741df6db
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
If user would add addictional field in one of reports it could break other
reports as other models do not share all the same fields. Now modules inherit
template and create their version of field.
task-2858097
closesodoo/odoo#106140
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The tax totals computation requires a currency to be provided. When a user removes the currency deliberately and tries to add a line, an uncaught error is thrown.
The currency_id is required, and the user will not be able to save the move anyway.
To reproduce:
New Invoice or Purchase
Clear the currency field
Add a line
Stack Trace
After this PR:
tax totals are computed based on the journal currency or company currency when not available
No task, discovered thanks to #110920closesodoo/odoo#111021
X-original-commit: f74f9bc04ed8f18746eb509f3c8dc598b1618230
Signed-off-by: William André (wan) <wan@odoo.com>
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
before this commit, when try to create a purchase order without inputting currency field it was showing exception like "The operation cannot be completed:
- Create/update: a mandatory field is not set."
after this commit, user cannot save the record without filling currency field
closesodoo/odoo#110786
X-original-commit: 34b24e4e3d34470bcbeb28f0b89b59cea84b7c7d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
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>
Raphael Collet