Daily updates from Odoo
Monday, December 8, 2025
15 changes · saas-18.3
Resolved issues and error corrections
This update resolves an error that occurred when users attempted to send invoices through the Taiwan Electronic Invoicing module for ECpay. The issue stemmed from a system attempt to access a field that was no longer present in the customer record. This change ensures the system correctly handles invoices without this missing data, preventing the sending process from failing.
Original PR description
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a…
This error occurs when the user try to send invoice. Steps to reproduce: - Install `l10n_tw_edi_ecpay` module > Switch to `Taiwan` company - SetUp `Taiwan Electronic Invoicing` in settings - Create a New Customer with `Email` and `Tax ID` (eg: 12345678) - and no `phone` number. - Create New Invoice with created Customer > Confirm > Send > `Send to Ecpay` > Generate Traceback: `AttributeError: 'res.partner' object has no attribute 'mobile'` This issue occurs at [1] because when the `phone` field is not set, the system tries to fall back to the `mobile` field. However, the `mobile` field was removed from `res.partner` (see related reference), and it was reintroduced in the referenced [commit]. This commit cleans up the logic to avoid referencing a non-existent field. [1]: https://github.com/odoo/odoo/blob/f1deed16e2355a74fea522439826625535eb7052/addons/l10n_tw_edi_ecpay/models/account_move.py#L677-L678 reference- https://github.com/odoo/odoo/pull/189739 [commit]: https://github.com/odoo/odoo/pull/236938/commits/c7404dff58f232103af4271a445d3841a82be8a3 sentry-7086174794 Forward-Port-Of: odoo/odoo#238657
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 resolves an issue where the automatic link between purchase orders and repair orders breaks when a purchase order is confirmed. The fix ensures the smart link remains active, streamlining the process of managing stock and related orders. This prevents disruptions in the workflow between purchase and repair operations.
Original PR description
The link between purchase order and a repair order break at when the PO is confirmed. ### Steps to reproduce: * Install the Repair and Purchase modules * Activate multi-steps routes * Unarchive the…
The link between purchase order and a repair order break at when the PO is confirmed. ### Steps to reproduce: * Install the Repair and Purchase modules * Activate multi-steps routes * Unarchive the MTO route * Create a product with the MTO route enabled * Create a Repair * On the Repair Order, in part add: - type : ADD - product : mto product * Save the RO * Go to Purchase Order * Confirm the PO -> Issue Smart link between PO and RO broken. ### Observation: The smart link is defined on: RO -> PO: https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/repair_order.py#L15-L17 PO -> RO: https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/purchase_order.py#L15-L17 When we confirm the PO, from the picking information it will create new moves: https://github.com/odoo/odoo/blob/2c87f3b2b397f268f0e50cb73cd81de992ddd42e/addons/purchase_stock/models/purchase_order.py#L293-L298 To create those stock moves, we go into_create_stock_moves where, for each POL, we will generate their values and erase the smart link: https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_stock/models/purchase_order_line.py#L362-L365 ### Origin: In this commit https://github.com/odoo/odoo/commit/9d98c43581e2579f43b35541b43264866dede5a5: "`created_purchase_line_id` is cleared after confirming the RFQ. This allows to merge more in `_merge_moves`." This breaks the link between PO <-> RO to maybe merge the move in the future. This issue is not present in 19.0 since it was solve in this commit : https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a ### About the fix: The root cause of this issue remains ambiguous despite the analysis. Therefore, in the interest of stability and caution, we opted to implement the fix in a safer location. opw-5121816 Forward-Port-Of: odoo/odoo#232999
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 &amp;. 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 fixes a bug where customers could select past time slots when ordering through the self-order system. Now, the system only allows selecting pickup times that are on or after the current time, ensuring accurate order scheduling and preventing confusion for customers. This improves the user experience and operational efficiency.
Original PR description
Task: [#5365003](https://www.odoo.com/odoo/project/1737/tasks/5365003) --- before this commit selecting a time slot in self-order, the customer can still pick time slots that are already in the past. For example, if the current time is 14:05, the system still allows selecting 12:00, 12:20, 13:00, etc. This should not be possible. When choosing a pickup time for today, all time slots earlier than the current time should not be generated Forward-Port-Of: odoo/odoo#237923
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