Thursday, July 3, 2025
17 changes · saas-18.1
Resolved issues and error corrections
This fix ensures the automated sales signature flow waits until the signature area is ready before accepting and signing. It prevents false error messages about a missing signature during testing, helping keep the sales signing process reliably validated.
Original PR description
In commit, we make sure that the signature is present in the modal before reaching the step where we click on "accept & sign". If the canvas is not yet loaded at this step, then there is an error message "Signature is missing". 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#217099
Product option buttons on eCommerce product pages now display correctly on iOS devices when using the Pills display style. This removes an unwanted space before option names, improving the shopping experience for mobile customers.
Original PR description
Before this commit, the pills attributes on a eCommerce product page on iOS has misaligned text That was caused by an iOS inconstancy with 'appearance: none;' A 'position: aboslute !important;' was added to force hiding the input like in saas-18.4 Expected:  Issue:  ## Steps to reproduce: - Add a product with attributes in eCommerce - Set the Attribute's Display Type to Pills - Go to the eCommerce product's page - Open the page on iPhone or iPad (using BrowserStack) - The selection for the attributes have a space before option's name opw-4854158 Forward-Port-Of: odoo/odoo#215520
Fixed a printed invoice layout problem where boxed templates could show unwanted vertical lines at the bottom when an invoice spans two pages. This keeps customer-facing invoices cleaner and more professional without changing invoice content or accounting behavior.
Original PR description
Before this commit, a print invoice that's on 2 pages with a boxed template left 2 vertical lines on the page bottom A negative margin top in applied that push the table top to the first page I…
Before this commit, a print invoice that's on 2 pages with a boxed template left 2 vertical lines on the page bottom A negative margin top in applied that push the table top to the first page I change the layout of `report_invoice_document` to avoid a negative margin. The negative margin-top to `total` was there to move the float div higher to compensate the ´table` margin-bottom. I remove the `table` margin-bottom and replace that by a `payment term` margin-top. The margin were collapsed for `total` and `payment term` so I had to add an overflow-hidden on the parent div. ## Before :  ## After :  ## Steps to reproduce : - Change the document layout to a boxed one in the Settings - Create products with long descriptions (example can be found in the linked ticket) - Create an invoice with the products - Print the invoice (the total should be on the second page top) - The vertical lines should be there opw-4841652 Forward-Port-Of: odoo/odoo#215778
The accounting test checks now verify XML namespaces when validating generated electronic invoice files. This helps catch incorrect e-invoice formatting earlier, reducing the risk of compliance or interoperability issues in localization-specific invoice flows.
Original PR description
At the moment, the `assertXmlTreeEqual` test method doesn't check that the namespaces in the generated XML match the ones in the expected XML. This is a 'feature', but in practice it prevents us from ensuring that our generated XMLs are correct. From now on, we also check namespace equality. Enterprise PR: https://github.com/odoo/enterprise/pull/87950 task-none Forward-Port-Of: odoo/odoo#214764
This fixes an issue where manufacturing orders created in batches could receive an incorrect planned finish date. The change ensures each order uses its own expected work order duration, improving scheduling accuracy for batch-created production orders and custom workflows.
Original PR description
If you create mrp.production in batch, date_finished is wrong. Note: it probably works as is in standard flow because always used on a single record (ex: form view) but it might break custom code. opw-4629270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216550
Users with view-only access to shared documents will no longer see the option to split PDF files. This prevents an error and makes the available actions match the user's permissions.
Original PR description
When a user with only view permissions attempts to split a PDF, an error occurs: Unexpected token '<', "<!doctype "... is not valid JSON **Steps to Reproduce:** - Go to Documents. - Choose a PDF file. - Click on Share and select Internal Users with Viewer permission. - Copy the generated link. - Open the link in another window as a non-manager user. - Click on split PDF then split The fix consists in hiding the pdf split functionality for users without edit permission. opw-4354451 Forward-Port-Of: odoo/enterprise#75803
The update corrects test reference files so electronic payment and invoicing XML checks now validate official namespace information. This helps ensure country-specific electronic documents for Colombia, Mexico, Peru, and ISO 20022 payment files are tested more accurately before release.
Original PR description
Before, we weren't asserting XML namespaces when calling `assertXmlTreeEqual`. As a result, many expected XMLs in EDI tests had incorrect namespaces. Now that we change the test method to check namespaces, we also need to fix the expected XMLs. Community PR: https://github.com/odoo/odoo/pull/214764 task-none Forward-Port-Of: odoo/enterprise#87950
A Knowledge app automated test was adjusted so it correctly finds the clipboard copy button in all expected layouts. This helps keep validation runs stable and reduces false failures during release checks.
Original PR description
This commit fixes an issue with the embedded clipboard steps in the commands tour. The selector for the problematic steps was too specific as the copy button isn't always the 1st button. runbot-114522 task-4748626
Partner Ledger XLSX exports now correctly include entries without an assigned partner when users search for "Unknown Partner". This ensures downloaded reports match what users see on screen and prevents missing accounting lines in exports.
Original PR description
### Issue: When searching for "Unknown Partner" in the Partner Ledger to get the lines with no partner, nothing shows on the downloaded XLSX. ### Steps to reproduce: - Have a partner Ledger with -…
### Issue:
When searching for "Unknown Partner" in the Partner Ledger to get the lines with no partner, nothing shows on the downloaded XLSX.
### Steps to reproduce:
- Have a partner Ledger with
- Search for "unknown Partner" in the search bar, only the lines grouped under "Unknown Partner" are shown.
- Click on the button "XLSX"
- The downloaded document does not include "Unknown Partner"
### Cause:
When `filter_search_bar` has a value, the domain used to query the partners/lines will check if the names of the partner match the search text. The resulting SQL query excludes the lines where `partner_id` is `NULL`.
### Solution:
Add a new condition in the domain: `('partner_id', '=', False)` This way the lines with no partner are returned by the query
When searching another existing partner these lines are excluded by an [already existing filter](https://github.com/odoo/enterprise/blob/8eff9194618a1d181c57820829e53aa23c7759d5/account_reports/models/account_partner_ledger.py#L55-L58). It excludes the lines if the search test does not match "Unknown Partner".
opw-4772529
Forward-Port-Of: odoo/enterprise#88139The salary configurator will no longer show Belgium-specific minimum wage warnings for employees in companies from other countries. This avoids confusing or incorrect alerts when Belgian payroll localization is installed alongside other country setups.
Original PR description
The warning for a basic wage below minimum level appears for non Belgian employees, such as L10N_US, because the L10N_BE was installed. The logic for the warning has been limited to be applied only on Belgian companies. Task #4907771 Forward-Port-Of: odoo/enterprise#88939
This fix makes the Brazilian point-of-sale automated test flow wait for product searches to finish in a more dependable way. It reduces false test failures in build checks, helping teams validate changes with fewer interruptions.
Original PR description
The tours regularly fail in single app builds because the "No other products found" notification is not found. Waiting on that notification is necessary because the product search happens asynchronously. I was not able to reproduce the test failure locally. But in an attempt to improve the situation this changes the approach to use the little "loading" spinner to wait on the search to finish by using Chrome.isSynced(). This method is used elsewhere in POS tests and should hopefully be less flaky. builx_error-224202
This fix updates internal tests so product units match the expected time-based units used in purchase approvals, timesheets, sales, and stock flows. It helps ensure future validation catches real unit mismatches without failing because of outdated test data.
Original PR description
The product uom in versions <= 18.0 used the same category as the default Unit uom, even if its name 'fortnight' suggests otherwise [[1]](https://github.com/odoo/enterprise/commit/d23ca81b24d8ddba873b2deba32b82f631a73390#diff-018a0b818adfb374f38eff32afab75e827e33f808f9ae6f920056d354069308eR57-L74). With the removal of the categories, the fortnight unit used on the product should be relative to the unit used on the PO, which is now 'days'. This error is caught when the validation of uom compatibility is readded.
The bank reconciliation report now shows amounts with the correct currency when journal entries come from journals using a different currency than the company. This avoids confusing totals where a company-currency amount was previously displayed with the journal currency symbol.
Original PR description
…eport Currently in bank reconciliation report we expect all the entries to have the balance encoded in journal currency However it may not be the case if an entry is posted in a misc journal set in another currency Steps to reproduce: - Create a new journal in another currency (€) than the company's ($) - Create a new journal entry using the journal main account - Go to the account dashboard > click on the 3 dots of the journal - Open the Reconciliation report Issue: The journal entry amount is in company curreny (balance), but with the journal currency symbol (€) opw-4701349 Forward-Port-Of: odoo/enterprise#87635 Forward-Port-Of: odoo/enterprise#87313
Miscellaneous changes
# Context : By design the CRON “Mail Marketing: Process queue” handling the email marketing campaigns is expected to time out for large mailing list. By default it tries to generate and commit batches (default 50) of `mail.mail` records while working through the total list of remaining recipients. See `_action_send_mail_mass_mail` method https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mail/wizard/mail_compose_message.py#L752 In practice, for large mailing
Original PR description
# Context : By design the CRON “Mail Marketing: Process queue” handling the email marketing campaigns is expected to time out for large mailing list. By default it tries to generate and commit…
# Context : By design the CRON “Mail Marketing: Process queue” handling the email marketing campaigns is expected to time out for large mailing list. By default it tries to generate and commit batches (default 50) of `mail.mail` records while working through the total list of remaining recipients. See `_action_send_mail_mass_mail` method https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mail/wizard/mail_compose_message.py#L752 In practice, for large mailing lists this will take longer than 15 mins (the default real time limit for CRON jobs) and thus implicitly we expect the worker to time out, re-initiate and continue where it left off. But since Odoo 18, the new refactor of `ir.cron` tries to penalize jobs that time out too often (>3) and don’t report at least a partial progress (`_notify_progress()`). See https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/odoo/addons/base/models/ir_cron.py#L361C1-L367C39 While `_process_mass_mailing_queue` does use the notify progress method (https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mass_mailing/models/mailing.py#L1167), it does so at a higher level or granularity (the `mailing.mailing` records in queue). But it will never called as long as the CRON keeps timing out while processing the mails for the remaining recipients (that get committed by batches). Which leads to the CRON being flagged as timing out to many times, and the `nextcall` date of the job being incremented by it’s default value of 1 day. So in practice: - mail marketing starts processing - will time out 3 times after 15 mins (default real time) - new system kicks in and increments the next execution date + 1 day - cron does not run until next day (so no new mail batches created) → artificially low sending rate of the campaign even-though everything is in order # Proposed solution: One could argue that the real unit of work is the committed mail records done in `_action_send_mail_mass_mail`. So we count the processed recipients/mails and call _notify_progress()` before the auto commit (which will be active when the method is called during the CRON). This should ensure that the CRON will not be penalized for timing out too often as long as the recipients are defacto being processed by batches. opw-4633353 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200909
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashie
Original PR description
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038 Forward-Port-Of: odoo/odoo#215543
Before this commit, there was a traceback error when importing Winbooks having a different sign on the balance in company currency and foreign currency. There was a frozendict error in the `import_wizard/_import_move()`. ### Steps to reproduce: - Choose a Belgium company - Import a Winbooks file having a different sign on the balance in company currency and foreign currency - Adapt account in Chart of Account if needed - The traceback should be triggered What happens is that the record
Original PR description
Before this commit, there was a traceback error when importing Winbooks having a different sign on the balance in company currency and foreign currency. There was a frozendict error in the `import_wizard/_import_move()`. ### Steps to reproduce: - Choose a Belgium company - Import a Winbooks file having a different sign on the balance in company currency and foreign currency - Adapt account in Chart of Account if needed - The traceback should be triggered What happens is that the record where added to a list, then the app tries to change `'CURRAMOUNT'` value to 0. But it was a frozendict item, so it create an error. I replace the record added to the list with a copy version that can be mutated. opw-4794471 Forward-Port-Of: odoo/enterprise#87484
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias. The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question. steps to reproduce: 1. clean DB with documents_account installed 2. create a 2nd company "company 2" 3. create an alias domain
Original PR description
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with…
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias. The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question. steps to reproduce: 1. clean DB with documents_account installed 2. create a 2nd company "company 2" 3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com" 4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2 5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company 6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com) 7. send an email with attachment to that alias -> you will get a multi-company error After this commit ------------------ Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected. opw-4727873 opw-4655559 opw-4746321 opw-4766895 Forward-Port-Of: odoo/enterprise#84997