Wednesday, June 10, 2026
14 changes · 19.0
Resolved issues and error corrections
This update resolves a test failure caused by incorrectly formatted data being passed to the system. Specifically, the system was receiving raw PDF content instead of the expected base64 encoded data, leading to an error. This ensures the tests run successfully and maintains data integrity.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#119786 Forward-Port-Of: odoo/enterprise#118523
This update corrects a technical issue with the Stripe integration for expense cards, ensuring accurate address formatting. The previous implementation incorrectly used ISO 3166-2 codes, causing failures when processing US payments. This fix ensures compatibility with Stripe's requirements and prepares for the upcoming US release.
Original PR description
Stripe says that address.state is "State, county, province, or region (ISO 3166-2)". There didn't seems to be any issues since it seems that it's not checked for the EU. However, this is still wrong and could raise an issue if Stripe decide to start checking them. Also, with the US coming soon, it's being checked and failed.
This update fixes an issue where planned dates were lost when converting projects to project templates. The change ensures that the original planned dates are retained in the new template, streamlining project management and preventing data loss. This improves the accuracy of project timelines.
Original PR description
Steps to reproduce: -------- - Open a project with a planned date set. - Create Template of that project. - Observe the created project template. Issue: ---------- The planned dates of the project are lost when converting the project into a template. Cause: ----- When we create a project template from a project, the project gets archived.Because a new project template record is created, and the start and expiration fields have copy=False, those dates are not being copied. Fix: ------- Explicitly pass the planned date when copying the project, so the project template keeps the original planned date. task-5872500 Forward-Port-Of: odoo/enterprise#115035
This update corrects a reporting issue where tax reports for Moroccan companies were incorrectly including entries with zero balances. The fix filters out these zero-balance lines, ensuring the reports accurately reflect financial data. This improves the reliability of tax reporting for our Moroccan clients.
Original PR description
When generating the tax report for a Moroccan company, entries with a zero balance were appearing in the report. Steps to reproduce: ------------------- * Create a Moroccan company * Create a bill with a tax to pay * Change the bill date and accounting date to a past date * Make a first payment of the bill, with a date to today * Unreconcile the payment, and make a second payment with a date in the past (the same one as the bill date for example) * Now generate the tax report for the period of today > Observation: The report contains useless entries with a zero balance. Why the fix: ------------ We add `HAVING SUM(account_move_line.balance) != 0` to filter out the line that have a zero balance. opw-5911669
This update fixes an issue where adding a recurring product to a confirmed sales order without a linked subscription plan would cause an error. The change prevents this by validating the product type and displaying a user-friendly error message, ensuring correct recurring product setup.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700 Forward-Port-Of: odoo/enterprise#119942 Forward-Port-Of: odoo/enterprise#107691
This update resolves an error that occurred when confirming DHL deliveries. The system now automatically sets a future delivery date (one hour ahead) to avoid the 'date must be in the future' error, which previously prevented successful order confirmations. This ensures DHL delivery confirmations can always be processed.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927 Forward-Port-Of: odoo/enterprise#116211
This update resolves an issue in the Data Cleaning app where record IDs were incorrectly summed and displayed alongside group names, causing truncation and misrepresentation of data. The fix removes the default 'sum' aggregator for integer fields, ensuring group headers accurately show the count of records.
Original PR description
## Issue In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which: 1. truncates the name and count of the groups 2. does…
## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)
<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />
## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
- Any name
- Model: *Contact*
- Rule:
- Field to Clean: *Name (Contact)*
- Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**
## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:
https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23
This causes the IDs to be summed up and appear in the group headers.
## After
<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />
related: https://github.com/odoo/odoo/pull/265163
opw-6166623This update fixes a misleading error message displayed when a shift template's start time was set after its end time. The message has been corrected to accurately state that the start time must be before the end time, ensuring correct shift template creation.
Original PR description
Before this commit, when the user set a start hour after end hour, the error message raised said: "The start hour cannot be before the end hour for a one-day shift template.". Which does not make sense since the start hour has to be before the end hour to be valid. This commit fixes the error message to say the start hour cannot be after the end hour. Forward-Port-Of: odoo/enterprise#119637
This update resolves a potential error in the Hong Kong payroll calculations. Specifically, it now checks for a missing resource calendar or zero hours per week, preventing a division-by-zero issue that could have disrupted payroll processing. This ensures accurate and reliable payroll calculations for Hong Kong businesses.
Original PR description
. Add a check for a null resource calendar and zero hours per week. task-6229271 Forward-Port-Of: odoo/enterprise#117685
This update resolves a problem where users couldn't archive employees after installing the 'l10n_be_hr_payroll_dimona_auto' module. The fix adds necessary access rights, ensuring users can correctly archive employees without encountering errors. This improves the stability and usability of the employee archiving process.
Original PR description
In the test `test_user_can_archive_another_employee`, the user is given the group `hr.group_hr_user` to be able to archive an employee. However when the module `l10n_be_hr_payroll_dimona_auto` is installed, some fields need the group `hr_payroll.group_hr_payroll_user` to be read. This leads to an access error. This commit adds sudo access when archiving an employee, Similar to how it is done here: https://github.com/odoo/enterprise/blob/5b3806d78a7998f130d87e56b649e4f4a8cf2bca/l10n_be_hr_payroll/models/hr_employee.py#L398 to avoid access right issues. Runbot error: [error-233177](https://runbot.odoo.com/odoo/error/233177)
This update fixes an issue where purchase transactions were incorrectly identified as intra-state, leading to inaccurate reporting. The change separates sales and purchase transactions during computation, ensuring the correct transaction type is assigned. A migration script has also been added to update existing databases.
Original PR description
Previously, for purchase journals, `l10n_in_state_id` was always computed using the current company `state_id`. However, in `_compute_l10n_in_transaction_type`, the `l10n_in_state_id` was compared with the company `state_id` for both sales and purchases. As a result, all purchase transactions were always computed as intra-state, including inter-state vendor bills. This commit handles sales and purchase transactions separately while computing `l10n_in_transaction_type` to ensure the correct transaction type is assigned. Migration also added to update it in existing dbs.
This update fixes a technical issue in the French VAT reporting module that was causing errors due to incorrect data formatting. Specifically, when the street address was short, a "False" value was incorrectly included in the XML, leading to processing problems. This change ensures accurate VAT report generation.
Original PR description
When the street field is shorter than 30 char and street 2 is false, we end up with " False" in the xml, which will return an error in aspone. no task id Forward-Port-Of: odoo/enterprise#119718
This update resolves an issue where placeholder images were unnecessarily included in the menu synchronization process. By only sending actual image URLs, we've reduced data transfer and improved the speed and efficiency of menu updates, particularly for products with images. This results in a smoother user experience.
Original PR description
This commit prevents placeholder images from being included in the menu sync payload and only sends `img_url` when an actual image is configured on the product or category. Task-6251430 Forward-Port-Of: odoo/enterprise#119883 Forward-Port-Of: odoo/enterprise#119482
This update resolves a technical issue where the journal report's multi-country tax grids were incorrectly displaying country names when multiple countries were selected. The fix ensures that all country options are correctly shown, improving the accuracy of financial reporting across various international operations. This update corrects a display error impacting multi-currency reporting.
Original PR description
When more than 2 country are used in the taxes, the colspan of the header is wrong. When more than 2 country are used in tax grids, the country isn't displayed anymore. Forward-Port-Of: odoo/enterprise#119348