Monday, December 8, 2025
12 changes · saas-18.3
Resolved issues and error corrections
This update simplifies the appointment calendar by showing only one period at a time (day, week, month, etc.) instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments, improving usability.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091 Forward-Port-Of: odoo/enterprise#98796
This update resolves a minor visual glitch in the Email Marketing app when creating campaigns with plain text templates. The fix ensures the snippet menu is initially folded, preventing a brief, distracting appearance. This improves the overall user experience and consistency within the application.
Original PR description
**Steps to reproduce:** - Go to the Email Marketing app - Create a new campaign and select the "Plain Text" Mail body for the template - Change between Mail body and Settings tabs - On Mail body tab, the right-hand building block section appears briefly (1 second) and then disappears **Issue:** Default state of the snippet menu has `snippetsMenuFolded` set to False before being inserted. **Fix:** As described in the comment just after the insert: ``` // Hide the snippetsMenu at first, other code will handle // if it should be shown or not. ``` So the fix ensure the menu is folded by default (not sure as to why the state was changed after inserting, so maybe it's expected). opw-5130191 Forward-Port-Of: odoo/odoo#238766
This update resolves an issue where a warning banner appeared during SEPA batch payments if a linked employee lacked an address. The change ensures the system correctly uses the employee's address, eliminating the misleading warning and streamlining the payment process. This improves user experience and data accuracy.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update prevents errors during Peppol invoice sending caused by invalid characters in invoice data. The system now filters out control characters that are not compatible with XML, ensuring invoices can be successfully transmitted to Peppol. This resolves a technical issue that could have disrupted Peppol integration.
Original PR description
## Issue: When a character that's not compatible with XML is in an invoice, and you send it to Peppol, a traceback was raised: `ValueError: All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters` ## Cause: `dict_to_xml` converts each invoice field into XML, but certain control characters (e.g., `\x02`) are not allowed in XML according to the specification: https://www.w3.org/TR/xml/#charsets If such a character appears in the data (e.g., imported through a product CSV), the XML generation crashes ## Steps to produce: - Install `account_peppol` and `l10n_be` (to get the BE Company CoA) - Import a product containing a control character: `echo -e "name,default_code\nTest\x02Product,ABC123" > products.csv` - Create an invoice for the BE company using the product `Test\x02Product` - Send it via Send > by Peppol - A traceback is raised opw-5114648 Forward-Port-Of: odoo/odoo#236836
This update resolves an issue preventing users from adding products from the parent company to quotation templates within a multi-company setup. Previously, this was allowed in standard sales orders, but not quotation templates. The change ensures consistent functionality across sales processes, simplifying product selection for users.
Original PR description
### Issue In this issue, having multi-company setup, we cannot make a quotation template with a product from the parent company. While this is allowed in sale order. #### To reproduce: 1- Create a product and in the product form, set the the company field to the parent company. 2- Create a quotation template and set the company field to the child branch. 3- In the quotation template, add a line and use the created product from the parent company. 4- Saving the form will raise an error. Talked with PO about the issue and he agreed that the quotation template should allow product from the parent company. This is already the flow in the quotation itself. opw-5177590 Forward-Port-Of: odoo/odoo#237732
This update fixes an issue that prevented the generation of SAFT files when a journal entry lacked a partner but included a receivable account. The fix ensures that SAFT exports now function correctly for companies using this reporting standard, resolving a potential reporting error. This improves compliance and data accuracy.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100960
Forward-Port-Of: odoo/enterprise#100296A test related to filtering work orders by user was intermittently failing. This fix addresses a timing issue where the test checked for record visibility too early after a user switch. By splitting the test into two steps – verifying the user switch and then confirming the presence of new records – the test now consistently passes.
Original PR description
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:…
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps: https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed. #### Fix: Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks. #### runbot-226734 Forward-Port-Of: odoo/enterprise#100908 Forward-Port-Of: odoo/enterprise#100746
This update corrects a technical issue preventing users from successfully revoking trusted devices within the security settings. The problem stemmed from a typo in the system's dynamic content, which blocked the revocation process. This ensures users can properly manage their 2FA security settings.
Original PR description
After public widgets have been rewritten as Interactions [1], there were 2 typos in `dynamicContent` that led to the wrong behavior. Because of that, we couldn't revoke a trusted device, or all of them. Steps to see the issue, - Turn the 2FA on - Add a trusted device, for example, by checking `Don't ask again on this device` when prompted to enter the authentication code while logging in. - Go to /my/security - Try to revoke a trusted device, either just by clicking on the trash icon button, or the 'Revoke all' button. => Nothing happens. [1]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Forward-Port-Of: odoo/odoo#238830
This update fixes an issue where the keyboard unexpectedly appeared on mobile date fields, causing a frustrating user experience. The change now prevents the keyboard from opening and hides the cursor, resulting in a smoother and more intuitive date selection on smaller screens.
Original PR description
Before this commit:
- The cursor was shown inside the date/datetime input field on mobile,
which triggered the keyboard unnecessarily and degraded the user
experience.
Steps to reproduce:
1. Add a form snippet.
2. Add a Date/Datetime field.
3. Click on the Date field.
- The virtual keyboard appears and the datepicker popover may be
clipped or partially hidden.
After this commit:
- The virtual keyboard is now prevented from opening on date/datetime
inputs, and the text cursor within these fields is also hidden.
task-[4745714](https://www.odoo.com/odoo/project/974/tasks/4745714)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238771
Forward-Port-Of: odoo/odoo#212053This update corrects an issue where shipping labels for FedEx deliveries weren't including the company name entered during checkout. The fix ensures that the correct company name is used on shipping labels, improving order accuracy and customer experience. This was triggered by a discrepancy in how contact information is handled during ecommerce checkout.
Original PR description
Steps to reproduce: - install ecommerce (i.e. website_sale) and delivery_fedex_rest - setup demo payment + fedex delivery method (including publishing it) - open the db while not logged in (i.e. in private browsing) - add something in the ecommerce page to cart + checkout > checkout - type in random contact info INCLUDING "Company Name" - continue checkout > select FEDEX as delivery method > pay now - go to Sales App > Sale orders > open the SO generated by ecommerce - open delivery + validate Expected result: - Shipping label with the name + company name from the ecommerce form Actual result: - company name is missing Issue is due to a company not being generated by ecommerce. Instead a string field is filled in (which is not visible when creating a contact directly via the contacts app). Code has been adapted to consider this use case. opw-5119089 Forward-Port-Of: odoo/enterprise#101376
This update fixes an issue where Vimeo video settings (loop and hide controls) weren't being applied after saving a website page. The fix removes a redundant escaping process that was incorrectly altering Vimeo video URLs, ensuring the desired settings are now consistently applied.
Original PR description
When setting options like "Loop" or "Hide Player Controls" on an embedded Vimeo video, these settings were not applied on the final page after saving. Steps to reproduce: =================== - Go to…
When setting options like "Loop" or "Hide Player Controls" on an embedded Vimeo video, these settings were not applied on the final page after saving. Steps to reproduce: =================== - Go to the Website editor. - Drag and drop a "Media List" or similar snippet. - Double-click the video placeholder to open the media dialog. - In the "Video" tab, paste a Vimeo URL. - Enable "Loop" and/or "Hide Player Controls". - Save the page. -> Observe that the video does not loop and the controls are still visible. Cause: ====== When rebuilding the iframe, `generateVideoIframe` was processing the video's `src` URL through using `escape()` function. This function is designed to prevent XSS by converting characters like `&` into their HTML entity equivalent, `&`. However, Vimeo video URLs use the `&` character to separate query parameters (e.g., `?loop=1&controls=0`). The `escape()` function was converting this URL to `?loop=1&controls=0`. but `setAttribute` already handles URL values safely. so Vimeo player will receive url containing &. This broke the URL's structure. The Vimeo player received a malformed URL, could not parse the parameters correctly, and therefore ignored the options for looping and controls. escape was used before cause The original code was adding the iframe using `.html(...)` see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33 side note 1: before saving the vimeo video works because we render it without the double escaping of & (as will be the case for saved video if this PR is applied) side note 2: the issue of double escaping also apply to youtube, but it seems to be ok with superfluous & in URL while in vimeo: https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1 has the video that doesn't loop, is not muted (so doesn't auto play in an iframe on most browser) and show controls https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1: all option works Solution: ========= The unnecessary `escape()` call has been removed. since the video should be only added using media dialog and the `setAttribute(...)` will escape it by default opw-5225261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238040 Forward-Port-Of: odoo/odoo#236677
This update resolves an issue where freezing a spreadsheet with empty lists didn't accurately represent the data. Specifically, it corrects how ODOO.LIST is processed when there are no records, ensuring that the frozen spreadsheet displays the correct data. This improves the reliability of spreadsheet sharing and reporting.
Original PR description
Steps to reproduce: - insert a list - expand the list beyond the number of records in order to have ODOO.LIST with no result - add =ISTEXT( <a reference to an empty ODOO.LIST> ) -> the result is TRUE - Freeze and share the spreadsheet => the result of ISTEXT is FALSE in the frozen version task-5360561 opw-5359100 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#237970 Forward-Port-Of: odoo/odoo#237511