Daily updates from Odoo
Thursday, May 22, 2025
26 changes
3 changes
Resolved issues and error corrections
Helpdesk users can now open the sales order line linked to a ticket without triggering an error. The change ensures the correct sales line form is used while still allowing the ticket flow to open the appropriate sales order form when creating a new order.
Original PR description
Before this commit, when the user would like to go to the form view of SOL linked to a ticket (when he is on ticket form view and click on the arrow right next to the sale_line_id field), a traceback…
Before this commit, when the user would like to go to the form view of SOL linked to a ticket (when he is on ticket form view and click on the arrow right next to the sale_line_id field), a traceback is occurred because a field is undefined in `sale.order.line` model. The reason is because the form view loaded is the one of the SO. This commit changes `form_view_ref` into `so_form_view_ref` because the `so_line_create_button` could need to use another form view of SO than the default one when the user clicks on `fa-plus` button to create a new SO. Steps to reproduce the issue ---------------------------- 0. Install `helpdesk_sale_timesheet` module 1. Create a billable helpdesk team 2. Create a new ticket inside that helpdesk team 3. In the form view of that ticket, clicks on the `+` button displayed next to the SOL field to create a new SO 4. Create the SO with at least one service product in the SO and save 5. In the ticket form view, open the form view of the SOL set on the ticket. Expected behavior ----------------- The SOL form view should be opened without any issue. Current Behavior ---------------- A traceback is occurred because a field does not exist in SOL model, the reason is because we open the form view of SO instead of the SOL one. task-4781247
The Avatax Brazil connection test now shows a clearer warning-style message instead of an “Invalid Operation” error when the test completes. This reduces confusion for users, especially when the connection is successful, and guides them back to continue their accounting configuration.
Original PR description
The previous connection test window showed up as an UserError with the title "Invalid Operation", as seen bellow, which can be confusing to users if the connection ends up as successful similar to what was done for AR.
Replace the UserError with a RedirectWarning that has a better title message ("Odoo Warning"). As it needs to redirect to somewhere, we redirect back to the current accounting page in settings, and show the button "Continue Configurations".
task-4772548Bank statement reconciliation rules now search across the label, transaction details, and narration together, so users no longer need to choose where the rule should look. This makes automatic matching more reliable and simplifies setup by removing an unnecessary option.
Original PR description
We don't want the user to differentiate the places where to apply the regex search (reco model) on statement lines. We thus apply it on the label, the transaction details and the narration altogether, returning on the first match. We don't need the "from_transaction_details" selection option anymore. task-4749338
23 changes
Resolved issues and error corrections
This update adjusts an automated live chat test so it waits for browser history updates before moving back and forward. It helps reduce false test failures and improves confidence in live chat quality checks without changing end-user functionality.
Original PR description
The tour fixed implicitly checks the browser's history. In Odoo, and history entry is pushed after a setTimeout(0) to allow multiple calls to be aggregated. The fix aknowledges this by introducing delays before executing the action. runbot-error-108129 runbot-error-223364 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents phone number errors from appearing too early when companies activate PEPPOL electronic invoicing. Phone numbers are now auto-formatted after editing and only validated during activation, reducing setup friction and avoiding accidental company data changes when users discard the wizard.
Original PR description
Steps to reproduce on runbot: 1. Select company "My Belgian Company" (`l10n_be` and `account_peppol`) should be installed 2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Activate…
Steps to reproduce on runbot: 1. Select company "My Belgian Company" (`l10n_be` and `account_peppol`) should be installed 2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Activate Electronic Invoicing 3. Ensure `+32470123456` is given as the phone number 4. Remove the country prefix from the phone number 5. A validation error is raised complaining about the phone number format The validation should only be performed when we click on the "Activate Peppol" button.. When editing the phone number the wizard should try to auto-format the given phone number before validating. In case there is no country prefix it should assume the phone number is from the country of the company. Since commit 7cd8c87e3fcacfefa6c789449eec32a3c5577089 the validation is performed before the auto-formating. There a call to the validation logic (`_sanitize_peppol_phone_number`) was added before the auto-formatting logic. (It was mainly just done to ensure that an external dependency is installed.) But there we do not (and should not) assume the country prefix of the phone number. The phone number is used during the registration process. A missing country prefix could lead to a failed registration. After this commit - the validation is only performed when we click on the "Activate Peppol" button. - the auto-formatting is performed after editing the phone number - the changes are not stored on the company when clicking on "Discard" - fix a `self` in a `for ... in self` part of task-4791098
This fixes an accounting screen issue where the 'Accounting Entries' section was always shown, even when it was not relevant. Users should now see a cleaner, more accurate interface with that section appearing only when appropriate.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a Saudi e-invoicing journal is re-onboarded with ZATCA and receives a new compliance identifier, Odoo now resets its invoice counter to the starting value. This prevents old numbering from carrying over and helps keep Saudi e-invoicing records aligned with expected ZATCA onboarding behavior.
Original PR description
…ew PCSID When a journal is re-onboarding on ZATCA and a new PCSID is generated, the Invoice Counter Value (ICV) should be reset > Currently, the system does not reset the ICV when a journal is re-onboarded. The fix resets the sequence back to 1 on re-onboarding task-4652483 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The product quantity selector setting now works the same way on product pages and configurator flows. This prevents shoppers from seeing different quantity controls depending on where they configure a product or combo, creating a more consistent buying experience.
Original PR description
Currently the show quantity setting visible on /product page does not apply on the product and combo configurator. We want to uniformize the behavior and if the setting is enabled then view the quantity selector everywhere depending on whether its visible on /product opw-4716312 opw-4781159 Backport of https://github.com/odoo/odoo/pull/209116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The blog page heading can now be customized instead of being locked to a fixed title. This lets website managers translate or adjust the wording for different audiences, improving localization and content control.
Original PR description
Following [1], the blog page reverted to using the first blog post as the cover. However, the title of the page ("Our Latest Posts") was made non-editable and, consequently, non-translatable, which is not ideal.
This commit addresses the issue by making the title editable, ensuring it can also be translated.
[1]: https://github.com/odoo/odoo/commit/05ef95d3f13ac42713bb8d8a3002f149345cc08b
opw-4289735This update removes obsolete hidden setup fields from Chilean and Latin American invoicing screens. It prevents unnecessary Odoo.sh build warnings without changing how users create or manage invoices, refunds, journals, or bank records.
Original PR description
## Description of the issue/feature this PR addresses: Starting in 18.0, it is no longer mandatory to define invisible fields in views so that other expressions (domains, modifiers) can work…
## Description of the issue/feature this PR addresses:
Starting in 18.0, it is no longer mandatory to define invisible fields
in views so that other expressions (domains, modifiers) can work correctly,
as they are now added automatically to views.
However, their presence in the codebase causes issues when building
development branches in Odoo SH, which is why this commit removes
the reported fields that are throwing warnings.
```
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_cl'
View: view_move_form_inherit_l10n_cl
Fields:
<field name="l10n_latam_internal_type" invisible="1"/>
View: view_complete_invoice_refund_tree
Fields:
<field name="currency_id" column_invisible="True" readonly="state in ['cancel', 'posted']"/>
View: view_res_bank_form
Fields:
<field name="fiscal_country_codes" invisible="1"/>
Addon: 'l10n_latam_invoice_document'
View: view_account_journal_form
Fields:
<field name="country_code" invisible="1"/>
View: view_move_form
Fields:
<field name="l10n_latam_available_document_type_ids" invisible="1"/>
<field name="l10n_latam_manual_document_number" invisible="1"/>
View: view_account_move_reversal
Fields:
<field name="l10n_latam_use_documents" invisible="1"/>
<field name="l10n_latam_available_document_type_ids" invisible="1"/>
```
In the case of the view "l10n_cl.view_move_form_inherit_l10n_cl,"
since it only contains one field, the entire view will be removed.
No other views inherit from it.
Related enterprise PR: https://github.com/odoo/enterprise/pull/85904
## Current behavior before PR:
SH branches throw a warning because invisible fields are present in views, which is no longer needed after linked commit.
## Desired behavior after PR is merged:
SH branches won't become red or warn about invisible fields present in views because they have been added automatically to the view.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes an issue where changing a discount pricing rule to another pricing type and back could silently switch the discount to use the product list price instead of the selected base pricelist. This helps ensure sales quotations calculate expected discounted prices and makes the pricing rule state clearer to users.
Original PR description
**Problem:** When changing the price type of a Discount pricelist rule to "formula" and going back to the original price type "discount" the rule does not take into account the base pricelist anymore…
**Problem:** When changing the price type of a Discount pricelist rule to "formula" and going back to the original price type "discount" the rule does not take into account the base pricelist anymore and uses the list price of the product to compute the discount **Steps to reproduce:** - Navigate to Sales/Products/Pricelists - Create a new pricelist, click on Add a line - In "Price Type" select Fixed Price and set a Fixed Price of 10 - Save and Close > create a second new price list - Click on "Add a line" and select a Price Type Discount - Set a 50% discount percent and select your first pricelist as the base price (next to "on") - Save and Close > save the form - Open the rule again and change the Price Type to formula - Change the Price Type back to Discount and set a discount percentage of 50% again - Save and Close - Create a new quotation with a product and select the second pricelist you created > click on Update Prices **Current behavior:** Amount is 50% of the price of the product **Expected behavior:** It should be 50% of 10 because our second pricelist is based on the first one which has a fixed price of 10 **Cause of the issue:** when _onchange_compute_price is triggeredwhen going back to discount value, base will be set to list_price https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/product/models/product_pricelist_item.py#L334-L342 because of this, the base price will not be computed based on the base pricelist https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/product/models/product_pricelist_item.py#L580-L583 **fix:** By resetting the base_pricelist_id, it's now visible to the user on the form that the computation is no more based on a pricelist. If the user enters a pricelist, the correct value will be computerd for base and base_pricelist_id at that time. opw-4757951
Loyalty point history now correctly adds together the cost of all rewards used on the same order. This prevents sales orders and loyalty card histories from showing too few points spent when customers redeem multiple rewards at checkout.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a loyalty card program applying on future orders; 2. add 2 rewards: free shipping (100 points) & discount (200 points); 3. create a loyalty card for current user with 500 points; 4. apply both rewards on an eCommerce order & pay to confirm. Issue ----- In the back end, the sale order displays the loyalty points cost as 200 instead of 300. The same applies to the points history on the loyalty card view. Cause ----- The loyalty history model introduced by 17ef5c57a5c1 does not sum up the total cost of the points used on an order, instead it only saves the points used of the last reward line per coupon. Solution -------- Sum up the points per coupon. opw-4783518
This fixes an issue where adding a document to a new email template could duplicate content or break the layout after saving. Email templates with embedded media should now save more reliably, preserving the intended content and appearance.
Original PR description
Problem: Adding a document when creating a new email template using `/media` results in duplicated content on save. Cause: During HTML processing on save, `flattenBackgroundImages` wraps elements…
Problem: Adding a document when creating a new email template using `/media` results in duplicated content on save. Cause: During HTML processing on save, `flattenBackgroundImages` wraps elements with inline background images (`style*=background-image`) in MSO-specific comments: `<!--[if mso]><![endif]-->`. However, if multiple such elements are nested, they are each wrapped, resulting in invalid nested comments and broken layout. Solution: Since the two conditions are opposites, we remove completely the content of the nested comment if it has oppisite condition otherwise we just remove the comment tags since they will be replaced with the upper comment Fixed in `web_editor` in https://github.com/odoo/odoo/commit/fcedeb63f5b5da6758e75d02f0c1d4f3b965adc1 Steps to reproduce: 1. Create a new email template. 2. Add a document using `/media`. 3. Save. → The content is duplicated or layout is broken. opw-4775908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where a delivery in one company could be incorrectly reserved because a product was treated as a kit from another company. This helps keep multi-company inventory availability checks accurate and prevents unintended stock assignments.
Original PR description
### Steps to reproduce: - Have 2 companies: COMP1 and COMP2 - Create a storable product P with a kit bom for attached to COMP1. - With COMP2 create a delivery for 1 unit of P. > If you click on check…
### Steps to reproduce: - Have 2 companies: COMP1 and COMP2 - Create a storable product P with a kit bom for attached to COMP1. - With COMP2 create a delivery for 1 unit of P. > If you click on check availability the move should not be assigned. - As COMP1 and with COMP2 active, click on check availability once more #### > The move is assigned. ### Cause of the issue: Checking the availability will launch a call of the `action_assign` of the stock picking. During this call, the moves that shoudl by pass the reservation process will automatically be reserved: https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/stock/models/stock_move.py#L1852-L1853 However, kit products are flagged to bypass the reservation process by these lines: https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/mrp/models/stock_move.py#L521-L522 The issue with this line being that the product is a kit form COMP1 and not for COMP2 (the context is used to determine this in the compute method): https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/mrp/models/product.py#L38-L40 ### Note: The issue can not be reproduced prior to 18.0, since the override of the `_should_bypass_reservation` was introduced by commit 4e1d46869e6c2d1ff473317179393007522a10a3 opw-4660233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Stripe express checkout now correctly accounts for free shipping discounts, including taxes, when calculating cart totals. This prevents checkout errors and avoids showing negative or incorrect amounts when customers use delivery rewards.
Original PR description
Steps to reproduce: 1) Create a free shipping reward 2) Enable standard delivery and set price to 100 3) Configure stripe provider with express checkout 4) Go to /shop 5) Add a product to the cart with the price less than 100 6) Go to the checkout and apply reward 7) Go back to the cart and observe a traceback Reason: delivery_amount was calculated without a discount and in express checkout form `_getOrderDetails` this amount was subtracted from the order total which resulted in negative value Solution: Add discount if any opw-4648641
Point of Sale now still adds a weighed product when the scale cannot respond, such as when an IoT box is disconnected, so staff can enter the weight manually. Closing the scale popup still cancels the product as intended, preventing accidental default weights.
Original PR description
In odoo/odoo#208571, a fix was made to prevent 1 unit of weight from added when cancelling weighing. However, this also changed the behaviour when a scale error (such as IoT box being disconnected) occurs, preventing the product from being manually entered. In this commit, we amend the condition to only stop adding the order line if the user closes the scale popup, but still add it on error. opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor bills now prioritize the prices set for each vendor on product records instead of defaulting to the product cost. This makes bill creation, including catalog-based entry, more consistent with what users see and expect, while preserving prices coming from purchase or sales flows when quantities change.
Original PR description
When creating a vendor bill, the vendor prices defined on the product is not used. This is very evident when using the catalog option on the vendor bill. The price displayed is the seller's price, but the product's cost price is used instead. This commit gives preference to the vendor price. No Task (18.0 Bug pad) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A4 statement reports now keep their header details visible when printed. This prevents important information from being covered by the folder-style layout, improving the reliability of customer-facing accounting documents.
Original PR description
Before this PR: In A4 statement format reports, the folder layout was overwriting header information, causing important header details to be obscured in the printed output. After this PR: Fixed folder layout rendering to preserve header information in A4 statement format reports, ensuring all header details are properly displayed. Solution: Adapted the A4 statement format implementation to work with the new report margin approach that replaces paperformat spacing with $o-default-report-margins CSS variable, preventing layout conflicts that were causing header overwrites. OPW-4741128
List views now highlight selected rows consistently, whether they are even or odd striped rows. This removes a small visual inconsistency so users can more clearly see which record they have selected.
Original PR description
Current behavior before PR: When selecting an even row by clicking on it (if it's not opening a record) or by selecting the checkbox and then unchecking it, it will highlight this row. This is only working on even rows but not on odd rows. Desired behavior after PR is merged: This fix aims to make even and odd rows work correctly by being highlighted. task-4809597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when users downloaded a PDF for a draft invoice that had not yet been confirmed. This prevents a crash and allows the download flow to handle draft invoices more reliably.
Original PR description
When the user downloads the pdf of a draft invoice, a traceback will appear. Steps to reproduce the error: - Create a new invoice > Don't confirm it - Go to list view of invoices - Select that…
When the user downloads the pdf of a draft invoice,
a traceback will appear.
Steps to reproduce the error:
- Create a new invoice > Don't confirm it
- Go to list view of invoices
- Select that invoice > Download > PDF
Traceback:
```
File "addons/account/controllers/download_docs.py", line 52, in download_invoice_documents_filetype
doc_data = invoice._get_invoice_legal_documents(filetype, allow_fallback=allow_fallback)
File "addons/account_edi_ubl_cii/models/account_move.py", line 45, in _get_invoice_legal_documents
return super()._get_invoice_legal_documents(filetype, allow_fallback=allow_fallback)
File "addons/account/models/account_move.py", line 5712, in _get_invoice_legal_documents
return self._get_invoice_pdf_proforma()
File "addons/account/models/account_move.py", line 5686, in _get_invoice_pdf_proforma
filename = self._get_invoice_proforma_pdf_report_filename()
File "addons/account/models/account_move.py", line 5744, in _get_invoice_proforma_pdf_report_filename
return f"{self.name.replace('/', '_')}_proforma.pdf"
AttributeError: 'bool' object has no attribute 'replace'
```
https://github.com/odoo/odoo/blob/36e4b6f93bf2123557947e910e1be651c5357319/addons/account/models/account_move.py#L5744
When the customer downloads the pdf a draft invoice, ``self.name`` will be False,
So it will lead to the above traceback.
sentry-6191644587
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPayslips now stay in sync when an employee's legal name is corrected after the payslip was created. This prevents outdated or misspelled employee names from remaining on payroll documents, improving record accuracy.
Original PR description
Currently if you make a mistake in the name of your employee and create a payslip, it's name will never be corrected since there is no direct dependency on the field.
The customer statement page now keeps its navigation breadcrumb visible on smaller screens. Action buttons adjust their placement instead, making it easier for users to understand where they are and move around on mobile devices.
Original PR description
Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817
This update removes outdated hidden fields from Chilean electronic invoicing and stock document screens. It prevents unnecessary warnings in Odoo SH development builds without changing normal user workflows or visible functionality.
Original PR description
## Description of the issue/feature this PR addresses: Starting in 18.0, it is no longer mandatory to define invisible fields in views so that other expressions (domains, modifiers) can work…
## Description of the issue/feature this PR addresses:
Starting in 18.0, it is no longer mandatory to define invisible fields
in views so that other expressions (domains, modifiers) can work correctly,
as they are now added automatically to views.
However, their presence in the codebase causes issues when building
development branches in Odoo SH, which is why this commit removes
the reported fields that are throwing warnings.
```
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_cl_edi'
View: view_account_move_debit_note
Fields:
<field name="country_code" invisible="1"/>
View: view_invoice_form
Fields:
<field name="l10n_cl_dte_acceptation_status" invisible="1"/>
<field name="l10n_cl_reference_doc_internal_type" invisible="True"/>
View: view_account_move_reversal
Fields:
<field name="country_code" invisible="1"/>
<field name="l10n_cl_edi_reference_doc_code" readonly="1" force_save="1" invisible="1"/>
View: l10n_cl_latam_document_type_view
Fields:
<field name="l10n_cl_show_caf_button" invisible="1"/>
Addon: 'l10n_cl_edi_stock'
View: view_picking_edi_form
Fields:
<field name="l10n_cl_sii_send_file" invisible="1"/>
<field name="l10n_cl_dte_file" invisible="1"/>
<field name="l10n_cl_draft_status" invisible="1"/>
View: view_picking_edi_tree
Fields:
<field name="country_code" column_invisible="True"/>
```
Related community PR: https://github.com/odoo/odoo/pull/210616
## Current behavior before PR:
SH branches throw a warning because invisible fields are present in views, which is no longer needed after linked commit.
## Desired behavior after PR is merged:
SH branches won't become red or warn about invisible fields present in views because they have been added automatically to the view.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prAnalytic accounting reports now avoid creating very large temporary data copies when users open or refine reports. This prevents timeouts on high-volume databases and makes affected reporting screens usable again, reducing upgrade blockers for customers moving to 18.0.
Original PR description
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the…
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.
In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.
Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count |
|----------|
| 60669759 |
+----------+
```
The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.
Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
-> Subquery Scan on "*SELECT*" (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
-> Result (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
-> ProjectSet (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
-> Merge Left Join (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
-> Index Scan using account_analytic_line__move_line_id_index on account_analytic_line (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
Filter: (general_account_id IS NOT NULL)
Rows Removed by Filter: 136994
-> Materialize (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
Functions: 78
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```
Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
-> Subquery Scan on account_move_line (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
Rows Removed by Filter: 2617642
-> Gather (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Result (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
-> ProjectSet (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
-> Parallel Hash Join (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
-> Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1 (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
-> Parallel Hash (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
Buckets: 1048576 Batches: 1 Memory Usage: 54880kB
-> Parallel Index Scan using account_analytic_line__date_index on account_analytic_line (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
Rows Removed by Filter: 57954
-> Hash (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Index Scan using account_account__account_type_index on account_account account_move_line__account_id (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
Functions: 51
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```
OPW-4782916Currency rate inputs in accounting reports now validate the number before processing, preventing errors caused by letters or other invalid characters. Users can also enter amounts using the decimal and thousands separators that match their language settings, making the report easier and safer to use.
Original PR description
Update on the filterExchangeRate function. The text input allowed users to enter non-numeric characters, which led to float conversion errors during processing. Now we parse the string into a float, catch errors and notify the user that the number was not valid. It also enables the user to use the thousands and decimal separators based on the language of the user. opw-4788246
The point of sale IoT scale test has been updated to match a related correction made in the main Odoo codebase. This helps ensure scale integration checks remain accurate and avoids false test failures after the upstream fix.
Original PR description
This commit simply amends the expected scale checksum after the fix that was carried out in the community PR (odoo/odoo#209815) opw-4643243