Monday, June 2, 2025
40 changes · 18.0
Enhancements to existing features
This update speeds up processing of historical point-of-sale orders when upgrading to Odoo 18 or enabling French POS certification on an existing database. Large databases that previously spent close to an hour preparing order links can now complete the same step in about a minute, reducing upgrade downtime and deployment risk.
Original PR description
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to…
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to `v18.0` because field `previous_order_id` got introduced in `v18.0` or when installing the `l10n_fr_pos_cert` module on an existing db with many POS orders in `v18.0`. - In both cases, the compute method is triggered for all `pos.order` records to assign the `previous_order_id`, causing significant delay due to per-record lookups. **Example from a real DB with ~113k orders:** ```sql apan_2840187=> select count(*) from pos_order; count -------- 113342 (1 row) ``` **Observation:** - Before the fix (compute took nearly 50 minutes): ```py 2025-05-29 06:31:12,587 28 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 2025-05-29 06:31:12,799 28 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id 2025-05-29 07:17:37,855 28 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml ``` - After the fix (completed within 1 min): ```py 2025-05-30 06:56:59,510 24 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 2025-05-30 06:56:59,584 24 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id 2025-05-30 06:57:12,531 24 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml ``` **Note:** The issue reported in the OPW was not originally about perf, but it was clearly exposed during the upgrade of the mentioned db. opw-4812874 upg-2840187 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Miscellaneous changes
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
Original PR description
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
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
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 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 Forward-Port-Of: odoo/odoo#209471 Forward-Port-Of: odoo/odoo#208850
**Issue:** when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events **Steps to reproduce:** - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 Forward-Port-Of: odoo/odoo#210100
Original PR description
**Issue:** when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events **Steps to reproduce:** - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 Forward-Port-Of: odoo/odoo#210100
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice t
Original PR description
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's…
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice to be considered a TD05 instead of a TD01. The debit note used to take the document id of the original customer invoice, which is TD01. So `l10n_it_document_type` field is set as non-copy. A `debit_note` key is added in the mapping of invoice features to document features if the invoice is a debit note. - The tag in the XML template with the invoice linked to the debit note was changed based on requirements. Also, reference invoice name and date were added in XML if invoice is debit note. tasks-4744444 Current behavior before PR: - When uploading TD05 in the Purchase journal, it's considered a Vendor Credit Note. - When creating a debit note from a customer invoice, the new invoice has TD01 document type Desired behavior after PR is merged: - When uploading TD05 in the Purchase journal, it's considered a Vendor Bill. - When creating a debit note from a customer invoice, the new invoice has TD05 document type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209072
Requested by @cima-odoo Forward-Port-Of: odoo/odoo#211848
Original PR description
Requested by @cima-odoo Forward-Port-Of: odoo/odoo#211848
Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since readi
Original PR description
Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since reading `employee_ids` returns an empty list -> all employees. This commit adds a context key to take archived records when regenerating work entries. Reference --------- opw-4813590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212117 Forward-Port-Of: odoo/odoo#211748
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2. Select or create a product 3. Select or create an attribute and values 4. Archive the product 5. Go to the attribute page 6. Click on related products smart button 7. Set Archived filter 8. Observe that the archived product is not displayed. Expected Behavior: After applying the Archived
Original PR description
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2.…
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2. Select or create a product 3. Select or create an attribute and values 4. Archive the product 5. Go to the attribute page 6. Click on related products smart button 7. Set Archived filter 8. Observe that the archived product is not displayed. Expected Behavior: After applying the Archived filter, related products, including archived ones, should be displayed. Actual Behavior: Archived related products are not shown, even when the Archived filter is applied. **Root Cause** When the related products smart button is clicked, the action_open_related_products method is triggered. In this method, when applying the domain for related products, an implicit active_test=True filter is applied by default. This filter excludes archived records, meaning only active (unarchived) products are displayed. **Fix** The issue was resolved by explicitly modifying the context to include archived products by setting active_test=False when querying the related products. This ensures that both active and archived related products are shown, even when the Archived filter is applied. opw-4565133 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201248 Forward-Port-Of: odoo/odoo#197513