Monday, March 23, 2026
13 changes · 19.0
Resolved issues and error corrections
This update corrects a visual inconsistency in accounting reports. Previously, the company header was grayed out only in light mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across both light and dark modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update removes the outdated 'short' option from the `format_datetime` and `format_time` functions. This change is necessary for the Odoo 19.0 release as the `short_time_format` and `short_date_format` fields have been deprecated. It ensures consistent date and time formatting across the appointment, data cleaning, planning, and sale-renting modules.
Original PR description
modules: appointment, data_cleaning, planning, sale_renting From this [commit], the methods `format_datetime` and `format_time` no longer handle `short` because the fields `short_time_format` and `short_date_format` are no longer available in 19.0. [commit]: https://github.com/odoo/odoo/commit/062b14097033afc19252cf3b8bb1fc541f8c868d#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition's spreadsheet functionality. The fix ensures accurate display of maps and charts generated from spreadsheet data, improving the user experience for business reporting. This change primarily impacts users relying on geographic visualizations within the Enterprise module.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page with header and footer content. The change optimizes the report layout to ensure it consistently appears on a single page for standard reports, improving readability and reducing unnecessary PDF sizes.
Original PR description
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and…
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number. The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner. **Steps to reproduce:** - Log to a Belgian company - Create a contact that is a person - Add the 281.50 tag to them - Create a credit note for any positive amount for that person and set the date to the previous year - Make sure the account used in the credit note has any 281.50 x tag assigned - Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note - When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact opw-5930339
This update fixes a technical error that occurred when users tried to take a picture without an IoT device connected to a quality control point. The fix prevents a system error and guides users to properly set up the device, ensuring a smoother workflow for quality checks.
Original PR description
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality >…
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality > Quality Control > Control points - Create a new Control point with - Type: Take A Picture - Operations: My Company: Receipts - Create and confirm a purchase order for a test product - Receipts > Quality Checks > Take A picture ## Observed behavior: TypeError: Cannot read properties of undefined (reading '0') ## Root cause: This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined. These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined. [1]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 [2]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 [3]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 [4]: https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32 ## Solution: Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4] opw-6010095
This update resolves an issue where the CFDI payment method '99' incorrectly displayed as '99 - False' on reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This improves report accuracy for invoices with payment method 99.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves a test issue caused by simultaneous requests for order tax details, which previously triggered errors. The fix ensures that backend processes complete before subsequent test steps are executed, improving the reliability of the POS tax test. This enhances the overall stability of the Odoo Enterprise Point of Sale module.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update corrects a bug where changes to view order within the Odoo Studio interface weren't consistently applied. The fix involved updating the code to properly set the default order for views using the designated attribute on the relational model. This ensures that view order changes made through the Studio are now correctly reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update resolves an issue where long tax amounts in Ke EDI reports were causing display problems. The fix ensures that tax totals are accurately and clearly presented, regardless of the numerical size. This improves the readability and usability of invoices generated using the l10n_ke_edi_oscu module.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
This update resolves an issue where the calculation of employee appraisal dates was inconsistent. The fix ensures test employees are created *after* company appraisal settings are configured, leading to accurate appraisal date calculations. This improves the reliability of appraisal scheduling within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111265
This update corrects a technical issue in how Odoo processes top-up payments for UK accounts. The data structure for UK accounts differs from the EU, requiring a change to the system's location data retrieval. This ensures accurate payment processing for UK customers.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground
This update ensures the 'mark as complete' button is always visible when closing a return flow, regardless of whether the user is using the API or a manual upload. This resolves an issue where the button was hidden for certain localization setups and temporary API connection problems, allowing users to consistently finalize return processes.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return.
This update relaxes a restriction that previously prevented leave creation when payroll data was active for an employee. Now, leave can be created under specific conditions – primarily when payroll impact is false, or when continued and disability payments are both 100% if payroll impact is true. This improves flexibility in managing employee time off.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847