Daily updates from Odoo
Tuesday, November 25, 2025
14 changes · master
Resolved issues and error corrections
This update resolves an error that occurred when the system automatically cleaned up data related to withhold taxes. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update automatically registers products with eTIMS before invoices are sent, resolving issues with incorrect product registration and view displays. It now uses the correct company context for accurate eTIMS registration, particularly important when handling multiple invoices across different companies. This ensures proper compliance with Kenyan e-invoicing regulations.
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
This update enhances account reporting by ensuring that when a company views a report with multi-ledger access, it only displays journals from the company with access, improving data accuracy and usability. It resolves an issue where reports were unintentionally showing data from other companies' ledgers. This change primarily impacts multi-company accounting workflows.
Original PR description
When multi-company, if multi-ledger is visible to one company, exclude journals of other companies when opening the report. task-5180393 Forward-Port-Of: odoo/enterprise#98546
This update fixes a bug where drag-and-drop functionality in Gantt views could inadvertently modify readonly fields, particularly within MRP planning. The change ensures that Gantt views respect the 'readonly' status of fields, preventing accidental data updates and maintaining data integrity. This impacts users working with MRP planning and related workflows.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#100209 Forward-Port-Of: odoo/enterprise#94166
This update resolves a recent problem where variant availability wasn't correctly reflected in reports. The fix ensures that reports accurately display variant availability based on defined conditions, improving data accuracy for financial reporting. Comprehensive tests have been added to prevent this issue from recurring.
Original PR description
…n tests previous commit: https://github.com/odoo/enterprise/commit/a01cac65346eee4ff78925e53036c01b83feaa8b The previous commit added urgently a fix to restore variants availability when their conditions are met. This test suite ensure the issue no longer occurs in the future. task-5262958 Forward-Port-Of: odoo/enterprise#99876
This update resolves an issue where creating a new invoice on a subscription order would fail if the original invoiced line was deleted. The fix ensures that the system correctly handles deleted lines during invoice creation, preventing errors related to unit of measure mismatches. This improves the reliability of subscription invoicing processes.
Original PR description
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video:…
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view **Steps to Reproduce** 1. Create and confirm a subscription with a recurring product (e.g., Car Leasing) 2. Generate and post the invoice for the subscription 3. Add a new product line to the subscription (e.g., Office Cleaning Service) 4. Delete the original invoiced line (Car Leasing) 5. Attempt to create an invoice for the new product line → Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category." (https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view) **Root Cause** Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation. **Fix** Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation. Forward-Port-Of: odoo/enterprise#99598 Forward-Port-Of: odoo/enterprise#99231
This update fixes an issue where the client nihil option for Belgian VAT returns was accidentally removed. The system now accurately determines if a client is eligible for nihilization based on invoiced amounts, ensuring correct VAT reporting. The temporary module is being integrated into the main l10n_be_reports module.
Original PR description
Since the new return system, the client nihil option that was inside the vat export xml was removed. We used a too simple mechanism which only checks if the tax report was empty or not. This was completely wrong, now we added the checkbox back for finer tuning and we precomputed it. The precompute is checking if any partner is exceeding 250€ invoiced for the current year. This commit adds a new module l10n_be_report_client_nihil which will be removed in master. It will be integrated with l10n_be_reports directly. task-5217079 Forward-Port-Of: odoo/enterprise#99496
This update resolves an issue where the invoice report incorrectly displayed currency symbols and incorrect total amounts when a company's taxes were set to 'included'. The fix ensures accurate reporting of prices, including tax, for all company tax settings, improving invoice clarity and financial reporting.
Original PR description
When the company is "tax included" for all taxes, after signing to eTims, the invoice report: - shows the currency symbol twice for "Taxable Amount". - The xpath for 'td_subtotal' is also doubled for no reason. - The "Total" columns is always price excluded instead of being price included. task_id: 5252530 Forward-Port-Of: odoo/enterprise#100050
This update resolves several display issues within the mobile Kanban view for documents, specifically gaps in folder layouts and scrolling problems within the 'Recent' folder. These changes enhance the user experience and ensure documents are displayed correctly on mobile devices.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#100134 Forward-Port-Of: odoo/enterprise#90647
This update ensures that the Annual Corporate Tax Return accurately reflects custom fiscal year periods. Previously, the system incorrectly identified the fiscal year, leading to inaccurate closing dates. This fix now correctly uses the defined fiscal year start and end dates for tax return reporting.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432 Forward-Port-Of: odoo/enterprise#100254 Forward-Port-Of: odoo/enterprise#100034
This update fixes an issue where users without administrative access were encountering access errors when creating projects based on templates with field service. The fix involves adding a necessary security check to ensure proper access rights are enforced, preventing errors and allowing project creation for authorized users.
Original PR description
--- ## Short functional explanation of the error Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign…
---
## Short functional explanation of the error
Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign an employee, their schedule will be retrieved to see if it matches the start and end date of the project.
If we try to create a project based on this template as an employee who's not an admin (only has rights for the project and services apps, for example), this will result in the error
This operation is allowed for the following groups:
- Employees/Administrator
- Employees/Officer: Manage all employees
Contact your administrator to request access if necessary.
Explanation: as we try to retrieve the employee schedule with an employee who doesn't have access rights to the Employee infos, it raises an access error.
## Reproduction Steps
1. As an admin, go to Projects and create a new project with a new stage and a new task. Assign an employee to this task.
2. Enable debug mode and go to the settings of the project. Under field service, check Field Service, then save.
3. Click on the small cog next to the project name and click Convert to Template.
4. Set a planned start and end date for the project and for its task. Assign a customer on the task.
5. Go to Users and select a different user than the one you assigned to the task.
6. Set this user administrator for Project and Field Service.
7. Make sure that this user also has an employee profile. Log in with this user and create a project based on this
### Expected behavior
The project is created without the entries the employee doesn't have access to
### Unexpected behavior
An access error is raised
## Origin of the issue
A sudo() was missing in the code.
__
opw-5263024
Forward-Port-Of: odoo/enterprise#100055This update corrects a critical error in how payroll versions are determined, which previously led to inaccurate pay calculations. By removing a flawed default date calculation, the system now correctly identifies payroll versions, ensuring accurate payments for employees. This resolves a potential issue impacting payroll accuracy across multiple countries.
Original PR description
Current version_id computation does not depend on payslip dates, which could very often lead to wrong calculations, in this PR we solve this by removing the cyclic dependency between dates and version compute by removing the default computation of the date_start, which is often wrong anyway in the case of a single manual payslip Forward-Port-Of: odoo/enterprise#99722 Forward-Port-Of: odoo/enterprise#95257
This update corrects a problem where payslip dates were incorrectly linked to the salary configuration month, leading to inaccurate tax calculations (ATN). The change ensures payslip dates align with the actual contract dates, guaranteeing correct ATN application. This improves payroll accuracy and compliance.
Original PR description
The payslip date is in the current month of when the salary configurator is used which may be different from the date on the version. That would lead to have the payslip outside of the contracts date and not take the ATN into account. Forward-Port-Of: odoo/enterprise#99909
This update fixes a potential issue where rental orders could incorrectly record more returned products than were actually picked up. The change ensures that returned quantities never exceed the initially picked-up quantity, improving the accuracy of rental order tracking and reducing potential discrepancies. This impacts the rental process and reporting.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100303 Forward-Port-Of: odoo/enterprise#100015