Thursday, April 23, 2026
9 changes · saas-18.4
Resolved issues and error corrections
Helpdesk tickets will no longer automatically record chatter messages when the linked sales order’s status changes. This reduces unnecessary activity in the ticket conversation and keeps the discussion focused on support work.
Original PR description
Before this commit: - The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/enterprise#114078
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 ensures that the VIES summary reports generated for Czech companies include only the numeric VAT number, as required by official regulations. Previously, the reports incorrectly included the country code ('CZ'), which could cause issues with data processing and compliance. This change corrects the report format to meet VIES standards.
Original PR description
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable…
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable it from the optional columns if needed). - Navigate to Reporting > VIES Summary Report. - Observe the value in the `VAT Number` column (includes country code). - From the dropdown, export the report as XML. **Observation:** In the generated XML file, the `c_vat` field contains the VAT number including the country code (e.g., `CZ12345679`) instead of only the numeric part (`12345679`). **Root cause:** At [1], the VAT number is directly taken from the report lines without removing the country code. **Fix:** This commit ensures that the `c_vat` field contains only the VAT number without the country code, complying with the official VIES XML format requirements. Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part) [1]: https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62 opw-6093259 Forward-Port-Of: odoo/enterprise#114730 Forward-Port-Of: odoo/enterprise#113083
This update resolves an issue where the 'Time Remaining' value in the project timesheet view wasn't consistently displayed in red, even when the value was negative. The fix ensures that both the label and the numerical value are correctly highlighted in red for negative time remaining, improving clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update resolves an issue where users with limited permissions were encountering errors when modifying subscription timesheets. The fix involves bypassing data fetching to prevent privilege-related access problems, ensuring smoother operation for users with restricted access.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
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