Monday, June 2, 2025
24 changes · 18.0
Resolved issues and error corrections
This fixes a mail-sending issue where Odoo could raise an error if the SMTP connection had already been closed. The change helps email processing finish more reliably and reduces avoidable failures during outgoing mail handling.
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
Invoice PDFs now handle very long tax group names without pushing total amounts off the page. This keeps invoice totals visible and readable for customers and accounting teams.
Original PR description
**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary. **Fix** Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page. Opw-4795941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small configuration error in the self-order testing setup was corrected. This helps keep automated checks reliable so issues in the customer self-order flow can be caught before release.
Original PR description
The test for the self-order feature was failing due to a validation error in the web_tour registry. The issue comes from the use of an unrecognized key 'test' in the tour configuration of 'self_order_pricelist'. This change removes the invalid 'test' key from the tour definition.
Installing Point of Sale no longer resets customized warehouse operation settings such as delivery barcodes, source locations, or sequence prefixes. This protects existing stock configurations when adding PoS or related apps, reducing unexpected setup changes for users.
Original PR description
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error:…
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error: the barcode of Delivery is reset When installing PoS, it will execute a generic method that creates and updates all operation types: https://github.com/odoo/odoo/blob/0bc90e7d74bd0792b9af7464256ba8770d894a25/addons/point_of_sale/data/point_of_sale_data.xml#L4 https://github.com/odoo/odoo/blob/14e9a698e333c3d6d2f7830353c34311de9ecb2c/addons/point_of_sale/models/stock_warehouse.py#L45-L50 https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L350-L356 Thanks to this, the PoS operation type will be created. However, as said in its docstring, the method will also update the existing operation types. For instance, for Delivery: https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L1003-L1006 Its barcode and default source location will be reset. The update will also reset the sequence prefix. As said by the method name in PoS (`_create_missing_pos_picking_types`), the idea here is just to create missing PoS types. Similar issue with repair: the operations types of the user-created wh will be reset. OPW-4668505
The website shop payment form now consistently receives the related sales order information. This helps customizations and extensions work reliably when they depend on order details during checkout.
Original PR description
Before this commit, sale_order information were used in some payment form but only website_sale_order was available. This would cause issue in overrides. task 4808806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds test coverage for an issue where copying an invoice could unintentionally change the original invoice. This helps ensure future fixes protect existing accounting records from unwanted changes during duplication.
Original PR description
When duplicating an account move, the origin move shouldn't be modified. The reason for that is when `create` is called, operations are done on self, like check and sync balance, which is wrong. create is an `api.model` method and shouldn't alter the record if set. This PR doesn't include a fix, just tests that reproduces issue explained on ticket `#4823689` ping @william-andre --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Hungarian electronic invoice XMLs now use the currency conversion rate already stored for the invoice instead of an estimated rate. This prevents small rounding differences that could cause Hungary's NAV system to reject submitted invoices.
Original PR description
Problem --------- Currently, when generating the XML to send to NAV, the XML currency rate is computed using an MMSE estimator. This leads to approximation error itself leading to a slight difference from the rate applied and given by the MNB of Hungary for that day. This is noticed by the NAV upon submiting the invoice who returns an error. Objective --------- Make it so that the rate returned by the HU bank is used during the XML generation. Solution --------- Instead of computing a MMSE estimator, we get the conversion rate stored in the database at the time of the invoice. task-4707316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-ordering carousel test now uses the point-of-sale session's test mode instead of waiting for a timeout. This makes automated checks more stable and helps prevent false failures without changing the customer-facing experience.
Original PR description
In this commit: =============== - We use session.test_mode instead of relying on a timeout while testing the carousel in all self-ordering modes in test_self_order_pos_landing_page_carousel Runbot error: 226322
This fix makes an automated live chat check wait until the web client is fully ready before continuing. It reduces false failures in quality checks, helping keep live chat behavior stable without changing the user-facing experience.
Original PR description
runbot-error-108129 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 fixes an issue where certain online sales configuration options could be hidden when the system could not determine whether the related view was enabled. The intended behavior is restored so the option remains visible by default, helping avoid missing choices during website purchase configuration.
Original PR description
commit 163b337fce6d3d67412f0e34e8120fbd5d02f463 didn't take into consideration that is_view_enabled can return None and the intended default behavior should be to show it by default --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users switch companies and open an asset created in another company. It adds a safeguard so accounting setup data that is unavailable in the current company does not cause the asset screen to crash.
Original PR description
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with…
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with domain set to miscellaneous, applicability as mandatory and a prefix 4) Create an analytic account using the smart button on the plan. 5) Create an asset record in one company in a multi-company setup. 6) Switch to another company and try to access the asset created in the first company. **Issue:** A traceback occurs ``` AttributeError: 'bool' object has no attribute 'startswith' ``` **Cause:** - When switching companies, all the chart of accounts records code for the previous company, will set as False. - When accessing an asset record expects a account code to call .startswith(), but it fails when code is False. This leads to the above traceback. https://github.com/odoo/odoo/blob/5a321b2327e36f3250b33c669bdb8bb344ab4cbd/addons/account/models/account_analytic_plan.py#L64-L67 **Solution:** - Add a check to ensure that the account’s code exists before attempting to call .startswith(). This makes the code more robust across multi-company environments. opw-4745633
This update gives an internal messaging test more time to confirm websocket subscriptions, reducing occasional false failures when systems are under heavy load. It helps keep automated quality checks stable without changing customer-facing behavior.
Original PR description
The test "Message shows up even if channel data is incomplete" can occasionally fail, most likely due to high CPU usage. The websocket subscription check is timing out too early. Increase the timeout, as done in 18.1, to reduce the likelihood of such failures. runbot-224044
This update improves the spreadsheet tool by removing unused clipboard behavior and making moved rows or columns keep affected ranges aligned correctly. Users should see more reliable spreadsheet editing with fewer layout or formula range issues after reorganizing data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4cea5f8cd [FIX] clipboard: remove empty code Task: 4743039 https://github.com/odoo/o-spreadsheet/commit/1c33198f2 [FIX] MOVE_COLUMNS_ROWS: adapt range on col/row move Task: 4743039 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 sending and printing invoices, Odoo now attaches only the invoice template selected for the customer instead of adding both the standard invoice and the chosen template. This avoids duplicate invoice attachments and ensures customers receive the intended document.
Original PR description
[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report…
[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report and the one defined by the user are attached to the mail when he hits the Send & Print. We want the template chosen by the user to be the one sent & printed. The fix is to remove the default accounting action report from the dynamic attachments : before, we were just removing the default action report used for the current move. But e.g. if the partner had a default report set in the field invoice_template_pdf_report_id, the default report for the move was this one, and so we weren't removing the accounting default one. This was causing the duplicate placeholder because the default accounting report placeholder is already processed in another method. Also, we remove the configuration that sets the 'account.account_invoices' report as a default dynamic attachment. Task-4681142 Runbot : https://runbot.odoo.com/runbot/bundle/18-0-invoice-report-per-partner-roto-361127
This fixes an access rights error that could appear when users searched for tasks from Timesheets. The change prevents the system from using task stage information that the current user is not allowed to access, making task search work more reliably for permitted users.
Original PR description
The sudo function allowed the current user to fetch data (stage IDs) which were used to browse. The user does not have access to this data; therefore, an access error message is triggered task-4194357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes internal HTTP-related tests less likely to fail because of harmless differences in text or URL formatting. It improves confidence in automated checks without changing product behavior for users.
Original PR description
**[FIX] test_http: make test_webjson_list_args reliable** The domain in the query-string is quoted by werkzeug, but there are multiple possible equivalent quoting strategy and the test sometimes fails because it is quoted differently. The test is not about testing the different quoting strategy, use a proper url parser to make the test more resilient. **[FIX] test_http: more reliable test_models3** The quote in the returned text sometimes get escaped, sometimes not, sometimes with a different QP code. Remove the quote, since the test is not about them, to make the test more reliable.
This fix adds the missing 'Error' status for Romanian E-Factura records so users can correctly see when an electronic invoice has failed. This helps businesses identify failed submissions more clearly and take follow-up action without confusion.
Original PR description
Description of the issue/feature this PR addresses: add missing 'Error' status to E-Factura selection 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 improves how Uruguayan electronic vendor bills are created from uploaded XML files and Uruware synchronization. It helps prevent duplicate or ambiguous records, supports files containing multiple invoices, and improves reliability by processing scheduled imports in smaller batches.
Original PR description
Task Adhoc side: 43467 1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE. Create those CFE. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests.
The rental search feature now sends product attribute filters using the parameter expected by the shop page. This ensures visitors who choose a rental attribute see correctly filtered results, improving the website shopping experience.
Original PR description
When selecting an attribute value in the Rental Search snippet, the generated URL incorrectly uses the `attrib` parameter. However, the `/shop` route expects the parameter to be named `attribute_value`. As a result, the filter is not applied, and the search results are not correctly filtered. This fix ensures consistency between the snippet and the `/shop` route by replacing `attrib` with `attribute_value`, so the attribute filter works as expected. The change improves the user experience by ensuring that search filters behave consistently across the website. Steps to reproduce: - Add the "Rental Search" snippet to a website page. - Configure it by selecting an attribute value. - Observe the resulting URL using `attrib`, which fails to filter results on the `/shop` page.
Helpdesk ticket satisfaction ratings now display the correct emoji face and color. This makes customer feedback easier to understand at a glance and avoids misleading rating indicators.
Original PR description
### Issue: `helpdesk.ticket` ratings were converted to emojis in https://github.com/odoo/enterprise/pull/42972, but currently do not display the correct color or face. ### Solution: Correctly check the value of `rating_avg_text` to determine which face should be shown, and remove class decoration that was recently added that hides the proper color. opw-4703331
This fix ensures loans using the "skip until" option show the correct remaining balance by counting earlier skipped payments as already accounted for. This prevents overstated outstanding loan amounts and gives finance teams more accurate loan reporting.
Original PR description
When using the 'skip until' option, we assume the early entries have been already posted elsewhere and their value should be accounted for. However, the outstanding balance of the loan will not keep into account skipped entries, resulting in an incorrectly higher amount, Steps to reproduce: - Create a new loan with: - Amount Borrowed: 24000 - Loan Date: 01/01/2024 - Duration: 48 months - Skip Until: 01/01/2025 - Compute (Duration of 4 years, Interest 1%) - Confirm Issue: Outstanding balance should be 16,105.73 and not 22,016.71 This occurs because, from the amount borrowed, the system subtracts only the posted entries amount, not considering the 'skip until' option opw-4711642
Users can no longer save a blank name when renaming a document or folder from the side panel. If the field is left empty, Odoo shows an error notification and restores the previous name, helping avoid confusing unnamed items.
Original PR description
Fix the possibility to enter an empty document name when editing a file or folder name from the side panel. If the name is empty, a danger notification should be displayed and the previous name should be restored. Task-4794447
Edited vendor payments now keep their original payment number when reposted, instead of receiving a new sequence number. This helps accounting teams maintain consistent records and avoid confusion or audit issues after correcting a payment.
Original PR description
**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than…
**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than preserving the original. This issue only occurs when the Outstanding Payments account is configured for the journal. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Accounting > Configuration > Journals, and open a Bank journal. 3. In the Outgoing Payments tab, set an Outstanding Payments Account. 4. Go to Accounting > Vendors > Payments. 5. Create and post two vendor payments (e.g., 00001 and 00002). 6. Reset the first one (00001) to draft, change any field (e.g., amount), and repost it. 7. The number changes to 00003 instead of preserving 00001. **Root Cause** When a vendor payment is modified and reposted, Odoo cancels and regenerates the associated account.move. If an Outstanding Payments account is configured — or was configured at any point — this triggers additional logic causing the move name to be reset to '/'. This placeholder indicates that the move is treated as if it were new, prompting Odoo to assign it the next number in the journal’s sequence. As a result, the payment loses its original number even though it conceptually refers to the same transaction. **Fix** The fix ensures the original number is preserved by restoring the payment's previous name only when it's clear that the move is being regenerated, not newly created. This is determined by checking that the move is linked to exactly one payment (i.e., a one-to-one relationship) and that its name is '/', indicating the move was regenerated. Opw-4805870
Sending Colombian electronic invoices no longer fails when the Electronic Invoice Type field is left unset. This helps users complete invoice sending without encountering an unexpected error caused by missing optional invoice information.
Original PR description
Currently, sending an invoice can raise an error if the **Electronic Invoice Type** is not set on the invoice. **Steps to Reproduce:** - Install the `l10n_co_dian` module. - Change the default company to **CO Company**. - Create and confirm a customer invoice, but leave the **Electronic Invoice Type** unset. - Send the invoice. **Error:** `AttributeError - 'bool' object has no attribute 'rjust'` Here, an issue occurs because the system attempts to call `rjust()` on the field `l10n_co_edi_type` without ensuring it is a string. When the field is `False`, it results in an Attribute error. - [1] This commit ensures the right access to `rjust()` only when `l10n_co_edi_type` is a valid string, preventing the error. [1] - https://github.com/odoo/enterprise/blob/8d7a13822e9fd480a6e279ff93e29834a6668536/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L974-L975 Sentry - 6622171121