Thursday, April 23, 2026
5 changes · saas-18.4
Resolved issues and error corrections
This update corrects a reporting error that incorrectly showed planned hours on public holiday days. The fix ensures the system accurately excludes public holidays, regardless of whether they're linked to a specific work schedule, and accounts for timezone differences to prevent date discrepancies.
Original PR description
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to…
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to 11:59PM with a calendar - Create a planning slot for a resource that overlap with the public holiday - Check the Timesheets / Planning analysis report - Group by employees > day **- Check the date of the public holiday and notice there are still planned hours shown** - Remove the calendar from the public holidays that we created previously - Check the report once again **- Notice the day of the public holiday and the day after has no planned hours** ### Cause: In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule. Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies ### Fix: We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves. opw-5027070 Forward-Port-Of: odoo/enterprise#111846
This update fixes an issue where the quantity of scanned packages was incorrectly displayed after re-entering a delivery order with full packaging enabled. The change ensures that the system accurately reflects the remaining quantity of a package after it's been picked, providing a more reliable view of stock levels. This improves the accuracy of inventory management.
Original PR description
Issue ----- When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages. Steps to reproduce ----- - Enable packages - Create…
Issue ----- When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages. Steps to reproduce ----- - Enable packages - Create a product with one package in stock - Operation Types > Delivery Orders, set Move Entire Packages to true - Create a delivery for a package - Scan the package barcode - Exit the delivery - Re-enter the delivery > Quantity for the line is 1/false Cause ----- The line is picked, so it is considered as not reserved https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289 when doing https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813 This leads to `qtyDemand` returning false instead of 1 https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18 ----- Ticket: opw-5960629 Forward-Port-Of: odoo/enterprise#114451 Forward-Port-Of: odoo/enterprise#113816
This update resolves an issue where unprivileged users received an Access Error when viewing vendor bills generated from emailed CFDI documents. The fix ensures that attachments related to these bills are correctly linked, granting all users access to the necessary information. This improves usability and prevents workflow disruptions.
Original PR description
When an unprivileged user attempts to view a vendor bill generated from an emailed CFDI, an Access Error is shown Steps to reproduce: - Set up an MX Company - Configure an incoming mail server - Set up an email alias for the Vendor Bill journal - Send/Receive a CFDI via the incoming mail server - Log in as an unprivileged user and check the newly created bill Issue: An Access Error is raised when the user attempts to view the bill Analysis: During the incoming mail processing, XML files are created as plain text documents and their association with the parent record may be stripped. Later on, if an `l10n_mx_edi.document` is successfully generated from the file, the underlying `ir.attachment` record remains without a `res_model` and `res_id`, creating the access issue when a standard users attempt to load the attachment data opw-5487905
This update clarifies French accounting reports by splitting an account to accurately separate social security charges from salaries. This change ensures compliance with French tax regulations (ANC PCG 2026) and provides more precise financial reporting. The old account remains for legacy systems but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/enterprise#112905 Forward-Port-Of: odoo/enterprise#111420
This update resolves an issue where downloading attachments from Odoo's mobile apps (18.4+) was failing due to incorrect URL formatting. The fix ensures that attachment URLs are correctly handled, allowing users to download files as expected. This improves the mobile user experience and prevents download failures.
Original PR description
In Odoo 18.4+, downloading attachments from the chatter is broken.
See: https://github.com/odoo/odoo/pull/200099
The `onClickDownload` function now passes an absolute URL to `downloadFile`.
The download function is implemented natively in the mobile apps.
The Android implementation always prefixes the provided URL with the
database origin (i.e.: `https://example.odoo.com`).
`download({url: "https://example.odoo.com/web/content"})` will try to
download `https://example.odoo.comhttps://example.odoo.com/web/content`.
This results in an UnknownHostException.
We can remove the origin from the url before calling the native method.
By doing this on the JS side, there is no need to update the Android app.
opw-6033150