Daily updates from Odoo
Monday, June 1, 2026
25 changes · master
Resolved issues and error corrections
This update enhances the way Odoo handles errors when communicating with external payment systems (IAP). By improving exception handling, the system is now more resilient to potential issues, leading to more reliable transactions and reduced disruption for users. This change focuses on internal stability and doesn't directly impact the user experience.
Original PR description
See the commit in the community repository for more information about this change. task-none
This update corrects a minor issue in the product barcode lookup test data. Previously, the test included an unnecessary 'color' attribute due to a change in how product colors are defined. The fix replaces the 'Purple' color value with 'Invisible' to ensure the test consistently validates the color guard logic without relying on demo data.
Original PR description
The Issue: The barcode lookup flow in `_update_product_by_barcodelookup` searches for an attribute by name and links a matching value to the new product, but it never auto creates a missing color value because of the explicit `if not (attribute_value or attr_name == 'color'):`. Previous to 3181721 `product_barcodelookup` had a `color` attr which was removed in favor of the standard `Color` attr in `product` with demo values such as Purple, that's why now we get an extra attribute line. The Fix: Replace `"color": "Purple"` in the mock with `"color": "Invisible"`, a value not present in demo data. This ensures the test always exercises the color guard logic, but remains stable and independent of demo data. runbot-937747
This update re-enabled a previously skipped test related to the planning_field_service_sale_timesheet module. This change is necessary to ensure the continued stability and functionality of the system following the recent migration to the 'owl3' version. It's a routine maintenance step to maintain test coverage.
Original PR description
This commit unskips a test that has been skipped during the migration to owl3.
This update resolves a technical issue where the confirmation button in the AI tool was failing. The change updates the button's functionality to align with the new Owl 3 interface, ensuring the button now functions correctly and reliably. This improves the user experience for AI tool interactions.
Original PR description
Prior to this commit, the tool confirmation button would throw an error when clicked. This commit change the `on-click` call to match the new Owl 3 interface (using `this.onClick` instead of `onClick`)
This update fixes inconsistencies in how contract types are defined across Odoo modules. Specifically, the contract type ID was standardized and redundant entries were removed to ensure data accuracy and prevent future issues. This change is limited to version 17 and will be addressed in a separate update.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717 Forward-Port-Of: odoo/enterprise#118069 Forward-Port-Of: odoo/enterprise#113244
This update fixes a potential issue where users could select inactive Intrastat codes on products. Now, a warning message will appear if a user attempts to select an invalid or expired code, preventing incorrect data entry and ensuring accurate reporting for Intrastat purposes. This improves data integrity and compliance.
Original PR description
Problem: When choosing an intrastat code on a product, all the codes are shown, even the ones that are expired or not yet active. Users can select an intrastat code that is not active. Steps to reproduce: 1. Check the intrastat code list and find a code with a start date in the future or an expiry date in the past 2. Note the code description 3. Open a product form view and try to set/change the intrastat code 4. Search for the code description noted in step 2 5. Note that the code is proposed while it should not be proposed Solution: When an intrastat code is selected, if the code is not active, a warning message is shown to the user. opw-6217915 Forward-Port-Of: odoo/enterprise#118569 Forward-Port-Of: odoo/enterprise#117884
This update fixes an issue where selecting the start date first would incorrectly set both the start and end dates for deferred accounting periods. The change ensures the end date is correctly set first, resolving a display error where periods appeared reversed (e.g., 2026-2025).
Original PR description
The issue is when selecting deferred dates, if the start date is selected first, the system will set both the start and end dates. However, when selecting the end date first, the period appears backwards example ( 2026 - 2025 ). task: 6140024 Forward-Port-Of: odoo/enterprise#114866
This update addresses a problem where bank statement KPIs weren't being updated correctly when no statements were processed. Now, if no bank statements are reported, the KPIs will be reset to an empty state, ensuring accurate reporting and data integrity within the account module.
Original PR description
The aim of this commit is to update the integer kpis when those aren't received. ### Context: The account module report the bank statement in draft to process. When all bank statement have been processed, there isn't any and thus, the module send back an empty list. ### Before this commit: The bank statement kpi wasn't updated as we didn't received anything about that specific kpi. ### After this commit: Any kpi that wouldn't be reported would get it's column emptied. opw-6170973 Forward-Port-Of: odoo/enterprise#115695
This update resolves an error that prevented users from adding multiple loan lines to a record after the initial creation. The fix ensures that date comparisons within the system are handled correctly, allowing users to accurately manage loan line details. This improves the usability of the loan management feature.
Original PR description
**Steps to reproduce:** - Install the `l10n_fr_account_loans` module and switch to a `FR Company`. - Navigate to Accounting > Accounting > Assets & Liabilities > Loans. - Create a new loan record. -…
**Steps to reproduce:** - Install the `l10n_fr_account_loans` module and switch to a `FR Company`. - Navigate to Accounting > Accounting > Assets & Liabilities > Loans. - Create a new loan record. - Click `Add a line`, set a `Date`, and `save` the record. - Click `Add a line` again. **Error:** `TypeError: '>' not supported between instances of 'datetime.date' and 'bool'` **Root Cause:** At [1], when adding a line after the record has already been saved with at least one existing line, the existing line has a valid `datetime.date` value for `l.date`, while the newly created unsaved line still has `line.date` set to `False`. This results in a comparison between a `datetime.date` object and a boolean value, causing an error. **Fix:** This commit prevents the errors when adding multiple lines after saving the record by applying a fix similar to [2]. [1]: https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/l10n_fr_account_loans/models/account_loan_line.py#L21 [2]: https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/account_loans/models/account_loan_line.py#L61-L63 opw-6244973 Forward-Port-Of: odoo/enterprise#118354
This update streamlines the timesheet setup process for users. Previously, users had to manually start the activity watch server each login. This change removes that step, thanks to an updated installer, making timesheet setup much simpler and more convenient.
Original PR description
Before this commit, the wizard to onboard the user to correctly install activity watch for timesheet assistant, mentioned the user has to start the server each time he logs in on his computer. This step is not longer needed thanks to an update on the odoo activity watch installer. This commit removes the line saying the user has to start the server each time he starts his working day. task-6081636 Forward-Port-Of: odoo/enterprise#118664 Forward-Port-Of: odoo/enterprise#115373
This update corrects a technical error in the US reporting module that prevented the correct formatting of negative account balances. The issue stemmed from a duplicate file structure, and this fix consolidates the necessary configurations within a single, dedicated file for US reporting. This ensures accurate reporting for US-based financial data.
Original PR description
In 19.1, when `account_reports_negative_format` was introduced, the PR created a new `template_us` file for `l10n_us_reports` to set the new field, not realizing that `account_chart_template` already existed. Since both files were to the same template and had the exact same method name, one shadowed the other which means all this time the `negative_format` was not properly set for US CoA. Since most other countries keep their CoA in a `template_TEMPLATE_NAME.py` file, move the deferred accounts to `template_us` and remove the `account_chart_template` file. task-none Forward-Port-Of: odoo/enterprise#118712
This update ensures that work entry data exported to Acerta adheres to their specific formatting requirements. The export now correctly pads the external reference number to 17 digits with 3 spaces and the work entry type code to 4 digits with 2 spaces, resolving potential data discrepancies with the Acerta system. This ensures accurate data transmission and processing.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106 Forward-Port-Of: odoo/enterprise#118568 Forward-Port-Of: odoo/enterprise#118124
This update fixes an issue where commission plans were incorrectly listed in the 'Other Plans' section for salespeople, even when their assignment periods didn't overlap. The system now accurately checks for overlapping salesperson assignments, ensuring that only relevant plans are displayed, improving the accuracy of commission calculations.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118769 Forward-Port-Of: odoo/enterprise#112694
This update resolves an issue that caused errors when sending shifts involving multiple resources. The fix ensures the system correctly handles shifts with multiple assigned employees, preventing a traceback and improving the reliability of shift scheduling. This change enhances the overall stability of the Planning module.
Original PR description
Steps to reproduce: - Install Planning - Create two resources - Enable "Employee Unavailabilities > Unassign themselves from shifts - Create a shift with multiple resources - Send the shift Issue: A traceback occurred when sending a shift linked to multiple resources. Cause: The unavailability URL was generated using `employees.token`, which expects a single employee record. Fix: Handle shifts with multiple resources correctly when generating the unavailability URL to avoid the traceback when sending shifts. issue commit-https://github.com/odoo/enterprise/pull/106700/commits Forward-Port-Of: odoo/enterprise#118292
This update fixes an issue where unreconciling a payment on a recurring invoice would automatically generate a new draft invoice for the following month. The change adds a context flag to prevent this behavior, ensuring invoices are created correctly after reconciliation. This improves invoice management and reduces potential errors.
Original PR description
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly…
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the invoice 3. Create a batch payment and add the payment created in step 2 then validate it 4. Create a bank statement line and reconcile it with the batch payment created in step 3 5. Unreconcile the payment from the invoice from the invoice form view 6. Notice that a draft invoice for the next month’s recurring invoice is created Cause: When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period Solution: Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line” opw-6158881 Forward-Port-Of: odoo/enterprise#117011
This update corrects a technical issue that could cause the DMFA report PDF generation to fail when non-numerical characters were entered for work addresses. The change adds a validation check to ensure only numbers are used, improving the reliability of the report and preventing potential disruptions.
Original PR description
Added a validation error in the _get_code function in case the code contains non-numerical characters. This prevents non-numerical characters input from breaking the DMFA report PDF generation. Task: 6231125 Forward-Port-Of: odoo/enterprise#118367 Forward-Port-Of: odoo/enterprise#117889
This update resolves an error that occurred when the Salary Increase wizard was used with a past date for the salary increase. The fix prevents a crash by handling cases where no matching employee versions are found for the specified date, ensuring the wizard functions correctly.
Original PR description
Currently, an error will occur when user puts Date of Salary Increase in the past on the salary increase wizard. Steps to replicate: - Install `hr_payroll` and create a new employee. - From the cog…
Currently, an error will occur when user puts Date of Salary Increase in the past on the salary increase wizard.
Steps to replicate:
- Install `hr_payroll` and create a new employee.
- From the cog menu click `Salary Increase`.
- Put any date from the past in the `Date of Salary Increase` field.
Error:
```py
File '/home/odoo/src/enterprise/saas-19.3/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py', line 43, in _get_affected_version_ids
increase_base_version = employee.version_ids.filtered_domain([('date_version', '<=', self.increase_date)])[-1]
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 6135, in __getitem__
ids = (self._ids[key],)
IndexError: tuple index out of range
```
Cause:
- When the user changes the salary increase date, it triggers the [compute], which calls `_get_affected_version_ids()`. In this method, employee versions [1] are filtered to keep only those whose `date_version` is less than or equal to the selected increase date.
- For newly created employees, version_ids typically contain only an initial version with date_version set to today's date. Therefore, when the selected salary increase date is earlier than today, the filter returns an empty recordset, which later causes the crash when accessing the last record of that recordset.
Solution:
- Early returned empty recordsets when no matching employee versions are found for the selected increase date.
[compute]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L34-L39
[1]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L43
sentry-7498213478
Forward-Port-Of: odoo/enterprise#118309This update resolves a technical issue where the system incorrectly accessed bike color information when creating new bikes. The fix ensures that color data is only retrieved when a new bike is being added, improving data accuracy and preventing potential errors.
Original PR description
- Cause: for a new bike we try to access color attribute on fleet.vehicle.model (using fleet.vehicle for old bike) - Solution: access color attribute only if not a new bike Task: 6245895
This update fixes a previous accounting error in Odoo's Hong Kong payroll system. The Employer Paid Rent rule was incorrectly only recording a debit, resulting in an imbalance. The change now uses the correct credit account (221004) for rent payments, ensuring accurate financial reporting for employees receiving housing allowances.
Original PR description
The Employer Paid Rent rule (HEPR) only had a debit account (5220 Employee Benefits/Staff Costs), leaving the journal entry unbalanced. Set account 221004 (Staff Housing Accrued) as the credit account for the HEPR rule in both CAP57 Monthly Employee Pay and CAP57 Casual Employee Pay structures. Community PR: https://github.com/odoo/odoo/pull/266863 task-6219303 Forward-Port-Of: odoo/enterprise#118629
This update prevents users from creating new work entry types directly within the payrun calendar view. Previously, this could lead to misconfigured payroll settings, causing errors in payrun calculations. This change ensures accurate payroll processing by restricting the ability to manually define these types.
Original PR description
_ ## Short functional explanation As creating new time off type can not be done blindly or it will not be correctly configured (no payroll categories ...), this option is removed from the holidays gantt view __ task-6193813
This update clarifies the meaning of the 'Basic' access right within the Documents app. Previously, 'No' was used, which created confusion about user access. The term has been changed to 'Basic' to accurately reflect that users retain access to their documents and the app itself.
Original PR description
In the Documents app, the lowest tier access right was called "No", which implies the user has no access. However, this is not the case. The user still has access to the app, their own documents, and shared documents. To resolve this confusion, "No" is changed to "Basic" and the relevant descriptions are updated. task-6099135 Forward-Port-Of: odoo/enterprise#113660
This update corrects a technical issue where a GOSI configuration warning was incorrectly displayed multiple times on payslips. The change ensures that this warning only appears once, streamlining the payroll process and improving data accuracy. This resolves a potential reporting discrepancy.
Original PR description
With this change, we prevent the GOSI configuration warning from appearing twice on a payslip task-6241149
This update removes a misleading warning message about a missing identification number from the payroll dashboard. The identification number field is no longer used in the payroll process, so the warning was unnecessary. This improves the user experience and simplifies payroll reporting.
Original PR description
Remove the "Missing Identification Number" warning from the dashboard. The identification number field is not used in the payroll workflow, making this banner redundant. Task: 6254734
This update prevents users from unintentionally opening employee views during pay run selection. By disabling clicks on data rows (except the avatar), it reduces the risk of users being forced to restart the pay run process. This enhances the user experience and efficiency.
Original PR description
This disables opening the employee form view when clicking anywhere on the data row, except when clicking directly on the avatar. The goal is to prevent accidental clicks on the row that force users to start over again. Task:6251741
A technical issue causing a traceback when users accessed the tax declaration feature in the Odoo Enterprise system has been resolved. The fix corrects a problem where a template was incorrectly referencing a missing variable, ensuring the tax declaration button functions without errors. This improves the user experience for employees.
Original PR description
Version: - saas-19.4 Steps to reproduce: - install l10n_in_hr_payroll - open employee form view - click on the tax declaration button - occur traceback Issue: - Getting a traceback when clicking on the tax declaration button. Cause: - template was reading `declarations` as a template variable, which was never defined, so its value was undefined. Fix: - use `this.declarations` instead of `declarations` in t-set so It correctly reads the data loaded from the component. task-6246920