Daily updates from Odoo
Tuesday, November 25, 2025
27 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 an issue where the SAFT report incorrectly assigned the same account to both customers and suppliers. The change ensures customers are assigned the correct receivable account, resolving a discrepancy in the report's financial data. This improves the accuracy of the SAFT report for Romanian businesses.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update optimizes the way account reports are generated by removing unnecessary data transmission. Specifically, the 'column_group_key' is no longer sent in report configurations, leading to faster report loading times and improved system performance. This change enhances the overall user experience for financial reporting.
Original PR description
task-5164369
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
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view, A traceback will appear. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Configuration > Chart of Accounts - Group By: ``Status (audit_status)`` field Traceback: ```py SyntaxError: non-integer constant in ORDER BY LINE 1: ..."res_company_id" IN (1)) GROUP BY 'todo' ORDER BY 'todo' ASC... ``` https://github.com/odoo/enterprise/blob/289e837ff80e2697cf337fe453aab09
Original PR description
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view,
A traceback will appear.
Steps to reproduce the error:
- Install ``Accounting`` module
- Go to Accounting > Configuration > Chart of Accounts
- Group By: ``Status (audit_status)`` field
Traceback:
```py
SyntaxError: non-integer constant in ORDER BY
LINE 1: ..."res_company_id" IN (1)) GROUP BY 'todo' ORDER BY 'todo' ASC...
```
https://github.com/odoo/enterprise/blob/289e837ff80e2697cf337fe453aab09e4c569fe6/account_reports/models/account.py#L184-L189
In the main view of ``acount.account``, ``working_file_id`` is not available
in the context,
So, ``working_file`` becomes ``False`` and ``status_query`` will be empty,
and it returns ``SQL('%s', 'todo')``.
So, ordering by a string literal ``todo`` leads to the above traceback.
sentry-6944233306
Forward-Port-Of: odoo/enterprise#97490This update corrects a technical issue where stopping ringtone playback caused unnecessary HTTP requests. The fix resets the element's source instead of setting it to null, preventing the browser from attempting to load a non-existent file and improving performance. This ensures ringtones play correctly.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update ensures the commercial state field is only visible when processing transactions related to Colombian companies. Previously, it incorrectly appeared on moves for companies outside of Colombia, leading to potential confusion. This change improves data accuracy and simplifies the accounting process for users.
Original PR description
The commercial state field should only be visible on moves part of Colombian companies. Steps to reproduce: load the `l10n_co_dian` module and switch a non-Colombian company, then create a move -> the commercial event is visible. task: 5232473 Forward-Port-Of: odoo/enterprise#98750
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 ensures that filters applied to composite reports in the Odoo Enterprise accounting module work correctly across all sections of the report. Previously, filters weren't consistently applied, leading to inaccurate reporting results. This change aligns with standard Odoo reporting practices for filter behavior.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100240 Forward-Port-Of: odoo/enterprise#100148
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 users couldn't find UNSPSC codes by typing partial numbers. The system now uses a flexible search method, allowing users to enter any part of the code and receive relevant results. This improves the accuracy and usability of product categorization.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_mx** modules. * Open any product form view. * Navigate to the **Accounting** tab. * In the *UNSPSC Category* field, start typing a numerical code such as **'10101500'**. **Observed behavior:** * No results are returned, even though the corresponding UNSPSC code exists in the database. **Cause:** * The `_search_display_name` method used an exact match (`=`) on the `code` field, preventing any partial or prefix-based lookup during user input. **Fix:** * Replace the exact-match domain on `code` with a partial match using `ilike`, allowing users to find UNSPSC codes by typing any part of the numerical sequence. opw-5244705 Forward-Port-Of: odoo/enterprise#100367 Forward-Port-Of: odoo/enterprise#99651
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 shared Knowledge articles weren't displaying correctly for users accessing them through different website languages. The fix corrects a URL rewriting problem, ensuring articles are accessible regardless of the user's preferred language setting, improving website usability and knowledge sharing.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
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
A technical issue was preventing users from creating or copying recruitment stage reports. This fix addresses a problem with a specific model within the 'hr_recruitment_reports' module, ensuring users can now successfully duplicate reports. This improves the usability of the hiring velocity reporting feature.
Original PR description
When the user tries to perform create or copy operations on the ``hr.recruitment.stage.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_recruitment_reports`` module with demo data - Go to Recruitment > Reporting > Hiring Velocity > switch to cohort view > click on any record > select any record > duplicate Traceback: ```py ObjectNotInPrerequisiteState cannot insert into view 'hr_recruitment_stage_report' ``` ``hr.recruitment.stage.report`` model is ``_auto=False``, meaning that no database table is created for this model. When the user attempts to create or duplicate a record of that model, It will lead to the above traceback. sentry-7024266324 Forward-Port-Of: odoo/enterprise#99499
This update ensures that payroll officers, specifically those in the 'hr_payroll.group_hr_payroll_user' group, can now access the work entries menu within the Odoo Enterprise system. The issue was resolved by directly adding the group to the menu item, correcting a previous oversight that prevented access. The original, unused menu item has also been removed.
Original PR description
Payroll officers (group "hr_payroll.group_hr_payroll_user") have access to work entries and timeoffs but the menu item is not visible to them. This commit fixes this issue. Remarks: This task could have been done by prefixing the id of the menu item with the name of the module that originally defines it (hr_work_entry_enterprise) and the group in the new menu item would be able to see it. This was likely the intention when this menu item was introduced in this module but the author forgot to add the module prefix. However, this approach most likely will override the originally defined group in hr_work_entry_enterprise and this is not the intention. The current solution just appends the group to the menu item. The menu item was removed from the file as it serves no purpose and its introduction here was likely a mistake in the first place. Task-5149463
This update resolves a technical error preventing access to enrollment date information within the Odoo Enterprise system. The change adds necessary groups to correctly identify and retrieve this data, ensuring accurate reporting and payroll processing for users in the UAE. This fix improves data reliability and functionality.
Original PR description
add the groups for the version field runbot-error: 234072
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 an issue where new contract versions created through the configurator would lose the employee's work address and location. The change ensures that this critical information is consistently saved, improving data accuracy and streamlining contract management processes. This update primarily impacts the HR contract management module.
Original PR description
When a new version is created by the configurator, we need to keep the work address and location. Forward-Port-Of: odoo/enterprise#100344
This update resolves an issue where using the 'force capture' feature in Stripe payments could lead to the creation of duplicate expense records. The fix ensures that only one expense is generated per transaction, improving data accuracy and reducing potential accounting errors. This primarily impacts users utilizing the Stripe expense capture functionality.
Original PR description
It's possible for multiples expenses to be created when using force capture. - Setup a company in EU and do the account onboarding - create a card - simulate a test purchase with force capture - after the webhook event issuing_transaction.* is received, an expense should have been created - now send again this event to the server (from the stripe dashboard or any other way) - a second expense will be created with the same transaction_id Forward-Port-Of: odoo/enterprise#99647
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