Monday, December 8, 2025
16 changes · saas-18.4
Resolved issues and error corrections
This update resolves an error that occurred when sending invoices for Taiwan customers who didn't have a phone number listed. The fix prevents the system from attempting to access a missing field, ensuring invoices can be successfully generated and sent to Ecpay. This improves the reliability of the Taiwan Electronic Invoicing process.
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 (day, week, month, quarter, or year) at a time, 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
A recent change to exclude US-specific report variants from account_reports tests has inadvertently introduced a bug in the 18.4 version. This fix removes the variant exclusions from the tests, resolving the issue. This change was originally intended for the 19.0 release.
Original PR description
In this commit f030cbefb8885ad023d40dcc5a023a04014f6715, we decided to exclude all the report variant in some account_reports test, because we only want to test with the generic tax report, and not the specific localizations variants. This has been merged in 19.0, but it's breaking tests in 18.4 as well, since this change https://github.com/odoo/enterprise/pull/100063 This commit remove the variants from the tests as well. runbot-234444
A recent test failure related to task scheduling was caused by incorrect timezone calculations. This update corrects the system to use UTC for interval computation, ensuring accurate task planning and preventing scheduling discrepancies. This resolves a potential issue impacting task scheduling accuracy.
Original PR description
The test `test_plan_task_in_calendar` failed with a one-hour difference in `planned_date_begin`. The error occurred because the work intervals were computed using the resource's timezone (`Europe/Brussels`) instead of `UTC`, leading to a shifted planned date. Setting the resource timezone to `UTC` ensures consistent interval computation and resolves the test failure. [RB-227059](https://runbot.odoo.com/odoo/error/227059)
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 improving the payment process. This change was made to enhance 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 resolves a technical issue within the HTML editor that prevented users from successfully coloring text when selecting a link containing a specific character (feff). The fix ensures the editor accurately handles selections and avoids a traceback, improving the overall coloring functionality. This change was made to enhance the stability and reliability of the HTML editor.
Original PR description
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the…
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247 and then call `getFonts()`, which internally uses `this.dependencies.split.splitAroundUntil()`. If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws: `The offset x is larger than the node's length (y).` Solution: After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid. Steps to reproduce: It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`. A test case replicating the situation can be based on the original failing template in the customer’s database. opw-4953943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238450 Forward-Port-Of: odoo/odoo#234328
This update fixes a bug where form fields without labels were not being submitted correctly. Now, all form fields, even those without labels, are reliably captured and sent when the 'send' button is clicked. Additionally, the system now prevents users from removing labels on form fields, ensuring data integrity.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575 Forward-Port-Of: odoo/odoo#237805 Forward-Port-Of: odoo/odoo#225545
This update corrects a bug where inactive accounts were hidden from reports. The change reflects a new setting ('active') for account status, which previously caused the reporting engine to ignore inactive accounts. This ensures all accounts, active or inactive, are accurately reflected in reports.
Original PR description
In replacing the deprecated field with the special `active` field the account_codes prefix engine no longer displays values for accounts that are inactive.
This disables the active test in:
- computing the domain for accounts
- auditing the value (since the domain is `('account_id.code', 'in'...)`
opw-5226153
Forward-Port-Of: odoo/enterprise#100885This 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 information is used on shipping labels, improving order accuracy and customer experience. This resolves a problem where the system wasn't properly capturing company names from the ecommerce form.
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 resolves an issue preventing the payroll demo data installation from working correctly at the start of the year. The fix sets a fixed past year for Mitchell Admin's contract, ensuring accurate demo data generation. This resolves a technical error reported by automated testing.
Original PR description
Before this commit, the relative date used to generate Mitchell Admin's contract was always at January 1st of the current year, making the payroll demo data install fail when at the start of the year. This commit sets a fixed year in the past for Mitchell's contract. runbot error 234623 and 234612
This update resolves an issue where setting image field widths in list views caused a system crash during development. The change clarifies that image field widths should be controlled through list view configurations, not the image field itself, ensuring stability and proper functionality.
Original PR description
Before this commit, if one set the `width` attribute on an image field in a list view arch, there was a props validation crash (in debug mode). The `width` attribute is relevant to be set in list view archs as it allows to specify the width of the column. That attribute isn't meant to be used by the image field itself, where the option `size` can be used to specify the size of the image as a pair `[width, height]`. opw~5392068 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 update fixes an issue where Vimeo video settings (loop and hide controls) weren't being applied after saving a website page. The problem stemmed from an unnecessary escaping of URL characters in the video source, which was preventing Vimeo from correctly interpreting the settings. Now, these settings work as expected.
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 fixes an issue where invoices containing special characters would fail to send to Peppol, causing errors. The change ensures that all invoice data conforms to XML standards, preventing these failures and guaranteeing successful Peppol invoice transmissions. This improves the reliability of our 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#238978 Forward-Port-Of: odoo/odoo#236836
This update corrects an issue in the l10n_ar_stock delivery guide report where a critical disclaimer about invoice validity was missing. Additionally, the report's name and number were being duplicated, causing potential confusion. This ensures the report accurately reflects invoice status and improves data consistency.
Original PR description
The mention "Document not valid as an invoice" is missing in the delivery guide report. And we shouldn't duplicatethe report name and number. opw-5004345
A recent test was failing due to timing issues when switching users in the MRP work order system. This fix addresses this by splitting the test steps to ensure records are fully loaded before checks are performed, improving overall test reliability.
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#101268 Forward-Port-Of: odoo/enterprise#100746