Daily updates from Odoo
Friday, April 24, 2026
15 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where the PDF sign sidebar was overlapping important sign guidance elements, like the ‘Next’ button. The sidebar has been moved to the right, ensuring a clearer and more user-friendly experience for signing documents within the platform. This improves usability and reduces potential confusion.
Original PR description
The PDF sidebar is left-aligned, causing the panel to overlap sign guidance elements like the “Next” button when opened. This commit moves the sidebar to the right of the PDF viewer. task-6065586 Forward-Port-Of: odoo/enterprise#114695 Forward-Port-Of: odoo/enterprise#112722
This change updates the email address used to respond to automated emails from clients. Previously, clients responded to iap@odoo.com, which has now been updated to noreply@odoo.com for better management and to reduce potential misdirected responses. This is a minor improvement.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114097
This update resolves a bug where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The fix corrects a comparison issue within the system's logic, ensuring the button only appears for invoices requiring updates, improving the user experience for Mexican tax reporting.
Original PR description
backport of f41900a4353ea867b08f71ed64f8702a13411bac - Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114440
This update resolves two issues impacting how users manage manufacturing orders through the Barcode app. Specifically, it prevents the UoM from changing after confirmation and ensures that manually entered quantity producing values are saved correctly, improving data consistency and reducing user frustration.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114075
This update resolves an issue where the 'Time Remaining' value in the project timesheet 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 and accuracy 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 timesheet tasks. The fix involves simplifying 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 the 'cancel' button within the documents spreadsheet functionality wasn't properly triggering the confirmation process. The fix ensures that clicking the cancel button now correctly halts the operation, preventing unintended actions. This improves user experience and data integrity.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 Forward-Port-Of: odoo/enterprise#112987 Forward-Port-Of: odoo/enterprise#112304
This update ensures that VAT numbers in the VIES Summary Report XML files are formatted correctly, removing the country code. This is necessary to comply with Czech tax regulations and prevent errors when submitting reports to the tax authorities. The fix ensures accurate reporting and avoids potential issues with data validation.
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 prevents unauthorized users from viewing or modifying assets linked to invoices. Previously, users on certain groups could access assets, leading to potential data access issues. This change ensures that only users with appropriate accounting permissions can view associated assets, enhancing data security and accuracy.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#113858 Forward-Port-Of: odoo/enterprise#112890
This update resolves an issue where the 'In a Budget' filter wasn't accurately displaying budget records. The fix ensures the filter correctly checks for a valid budget analytic ID, improving the accuracy of budget reporting. This ensures users see all relevant budget data.
Original PR description
"In a budget" Filter is expected to show records with a related budget i.e. `'budget_analytic_id' != False`. Forward-Port-Of: odoo/enterprise#112872
This update fixes a data inconsistency in how deferred invoice moves are created. Previously, the partner ID could be incorrectly set, leading to mismatches between the original invoice and the deferred move lines. This change ensures the correct partner ID is always used, maintaining data accuracy and reliability for financial reporting.
Original PR description
When creating deferred move lines, the `partner_id` could be incorrectly influenced by the `default_partner_id` context key (e.g., when generating an invoice from a Sales Order). This led to inconsistencies where the deferred move lines did not match the partner on the original invoice line. This commit ensures the `partner_id` is explicitly taken from the source invoice line, guaranteeing data integrity across all deferred move lines. Steps: - Create a sale order for partner X, receive and confirm it - Create the invoice from the SO - Change partner to Y but keep X as delivery partner (not essential to reproduce bthough) - Set a deferred start date and a deferred end date on the invoice line, covering two full months - Confirm the invoice and open deferred moves via the smart button -> Note that one deferred move's lines get the partner id from the SO instead of the invoice opw-6095711 Forward-Port-Of: odoo/enterprise#114439
This update fixes a problem where opening the same restaurant order on multiple devices would cause errors with the Fiskaly payment system. The fix ensures that transaction details are properly shared between devices, preventing duplicate transaction attempts and associated API errors. This improves the reliability of the restaurant POS experience.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#114599
This update resolves an issue where the automated vendor invoice reporting process incorrectly handled multi-company setups. The fix ensures invoices are fetched from the correct company within each business, preventing errors and improving the reliability of reporting. This enhances the accuracy of financial data for businesses using multiple companies.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#113254
This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix involved updating a helper method to ensure users only see the button when they have the appropriate access, improving the user experience and preventing confusion.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#114818 Forward-Port-Of: odoo/enterprise#113481
This update corrects a previous error in Odoo's French reporting module. Accounts 657 and 757, introduced by a recent French accounting reform (PCG 2025), are now correctly classified as current operations, ensuring accurate profit and loss statements. This resolves a mismatch previously impacting financial reporting.
Original PR description
…tions As part of the PCG 2025 reform in France, accounts 657 and 757 were introduced to handle capital gains and losses on the disposal of tangible and intangible assets related to normal, current activities. Previously, Odoo incorrectly categorized these under exceptional items which led to mismatches in the P&L. Source: https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/PCG--1er-janvier-2025.pdf Relevant excerpts: <img width="630" height="372" alt="image" src="https://github.com/user-attachments/assets/88a66dac-1cc0-4a33-a902-edb6b626f18f" /> <img width="631" height="318" alt="image" src="https://github.com/user-attachments/assets/403b65dc-20ba-447e-937d-20575f1f45ab" /> opw-6105764 Forward-Port-Of: odoo/enterprise#114897 Forward-Port-Of: odoo/enterprise#114837