Daily updates from Odoo
Tuesday, February 17, 2026
250 changes
17 changes
Enhancements to existing features
This update adjusts the calculations for CP200 seizable amounts in the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new 2026 valuation factor, ensuring accurate tax calculations for Belgian employees. This change aligns with updated Belgian tax regulations.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
Resolved issues and error corrections
This update resolves an issue where the journal filter wasn't correctly applied when viewing journal items within the general ledger report. Now, when you select a journal in the report, the list of related transactions will include that journal, providing more accurate reporting. This enhancement improves the clarity and reliability of financial data analysis.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a technical issue in the account reports module that was causing errors related to falsy IDs. The fix ensures that reports accurately reflect data by filtering out invalid IDs, preventing errors and improving report reliability. This change was triggered by a recent update to Odoo's browsing functionality.
Original PR description
Previously, get_unknown_partner_aml_ids collected AML IDs and included falsy IDs from the total lines. For a while, this had no side effects. However, in commit 4290724, the odoo/orm/models.py browse method was changed to disallow browsing for falsy IDs. get_unknown_partner_aml_ids has been caught by this and needs to not include total lines to prevent adding lines with no res_id. A simple option to ignore total lines fixes this issue. Steps to replicate: Create and post a journal entry with a line for accounts receivable Open Accounting > Tax Returns > Error (Invalid falsy real id) task: 5919319 Browse Change PR: 227477
This update corrects a problem where payment reference data from a third-party system (Codabox) was incorrectly formatted, often with extra spaces. The change ensures payment references are clean and accurate, preventing potential errors in financial processing. This improves data reliability and reduces the risk of manual intervention.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update fixes a reporting issue where VAT numbers were incorrectly excluded from INF reports for businesses without a country setting. The changes now include partners with no VAT number and harmonize warning messages, ensuring more accurate reporting and compliance for Estonian companies using Odoo Enterprise.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
A recent update to Odoo's IoT device functionality caused a traceback when users attempted to change keyboard layouts. This fix resolves the issue, ensuring that keyboard layouts are now updated successfully as expected. This prevents disruptions for users managing IoT devices through the Odoo backend.
Original PR description
Steps to reproduce: - Connect an IoT box - Connect a USB keyboard to the IoT box - In the Odoo backend, attempt to change the keyboard layout of the keyboard device EXPECTED behaviour: Layout is updated successfully ACTUAL behaviour: Traceback occurs Forward-Port-Of: odoo/enterprise#107483
This update resolves an issue where incorrect data formatting in certain locales (like the Netherlands) caused problems with Stripe account creation. To ensure accuracy and compliance, the automated KYC pre-filling process has been replaced with a fully manual process, reducing potential errors and improving the user experience.
Original PR description
Context:
When creating a livemode account, the data pre-sent by the database to stripe may cause issues in some localizations. e.g. the Netherland where people are forced to use a zip in the "\d{4} ?[A-Z]{2}" pattern, which they do not alway do
Solution:
Pre-filling KYC was deemed too error-prone and this would be switched to a fully manual KYC
OPW-5899276
Linked (but not depending on) https://github.com/odoo/iap-apps/pull/1431
Forward-Port-Of: odoo/enterprise#107115This update resolves a technical issue where duplicate labels within KPIs were causing sorting errors. The fix ensures that KPIs are correctly sorted based on priority and label, preventing data inconsistencies and improving data synchronization. This improves the reliability of KPI reporting.
Original PR description
When two KPIs have different identifiers but the same label, the call to `sorted` on a list of (priority, label, dict) tuples was wrong. As the two first criteria were the same, the comparison was made on the dict, which is not comparable, leading to the following error:
TypeError: '<' not supported between instances of 'dict' and 'dict'
With this commit, we instead use the `key=` argument to `sorted` in order to build the `(priority, label)` tuples, which is cleaner.
OPW-[5932549](https://www.odoo.com/odoo/project.task/5932549)
Forward-Port-Of: odoo/enterprise#107481This update fixes a technical error that prevented employees from correctly deferring leave when no 'Working Time' entries were available. The change replaces direct dictionary access with a safer method, ensuring a user-friendly error message is displayed instead of a crash. This ensures leave deferral functionality works reliably for all employees.
Original PR description
When deferring a leave via 'Report to Next Month,' a `KeyError` occurs if the employee has no 'Working Time' entries (e.g., they are already converted to 'Absence'). The method searches for 'working_time' entries and fails when accessing the empty result dictionary for the employee. This commit replaces the direct dictionary access with `.get()`, raising a proper `UserError` when no eligible work entries are found. task-5912512
This update resolves a technical issue that was causing a performance slowdown in the payroll processing. The fix prevents an infinite loop by strategically managing data prefetching, ensuring smoother and more reliable payroll calculations. This improves the overall efficiency of the HR module.
Original PR description
The new implementation uses a prefetch object that makes the union of prefetch ids. This commit fixes an infinite loop by imposing the prefetching with `records.with_prefetch()`
This update corrects a bug where changing a bank account in the salary settings would incorrectly add multiple accounts to an employee's profile, leading to incorrect allocation percentages. The fix now replaces all existing bank accounts with the new one, ensuring accurate payroll processing.
Original PR description
When changing a bank account in the salary configurator, the system was adding the new bank account to the employee's existing bank accounts list, ending up having multiple bank accounts where the first retained 100% allocation and subsequent ones had 0% allocation. The fix replaces all existing bank accounts with only the new one. task-5905542 Forward-Port-Of: odoo/enterprise#106333
This update corrects a technical issue where the contract template was being unnecessarily duplicated during salary configuration. This duplication prevented certain calculations from running correctly. The fix ensures the template data is now correctly sourced, improving the reliability of the HR contract process.
Original PR description
Writing the contract template on the new version created by the salary configurator is not necessary and caused some computes to not trigger. The contract template values are already included in the `_get_version` method. task-5324222 Forward-Port-Of: odoo/enterprise#99781
This update adjusts the calculation of sickness relapse periods for Belgian payroll, aligning with new tax regulations. Starting January 1, 2026, the allowed relapse period between sick leaves will be increased from 14 to 56 days. This ensures accurate reporting and compliance with Belgian tax laws.
Original PR description
Spec :- Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. Implementation :- . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add leave work_entry type where work_entry use date_start . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#107294 Forward-Port-Of: odoo/enterprise#104782
This update fixes a problem where the system was creating multiple, empty pay runs when generating payslips. The change ensures that only one temporary pay run is created during the selection dialog process, preventing data duplication and improving system stability. This resolves a potential issue with data integrity.
Original PR description
When generating payslips from the selection dialog the UI previously created a new hr.payslip.run on every attempt; server-side validation can fail and each failed attempt left an empty pay run in the database. Fixed by allowing the dialog to create at most one temporary pay run per dialog lifecycle, reuses it on retries, and removes it if generation fails or the dialog is closed. task-5920710 Forward-Port-Of: odoo/enterprise#106857
This update resolves a critical issue (274XX) within the Belgian payroll module. The fix ensures accurate calculations for employee compensation, preventing potential errors in payroll processing. This update improves the reliability of the HR payroll functionality.
This update corrects a problem where the CDI - Experienced Developer (BE) contract template couldn't be saved due to an incorrect inventory car setting. The change removes the pre-selected inventory car from the template, allowing users to successfully save the contract. This ensures proper contract creation functionality.
Original PR description
Before this commit, when the CDI - Experienced Developer (BE) contract template is loaded, the inventory car is checked, but no car is selected, so you can't save. This commits unchecks the inventory car on the template to avoid this issue. Task: 5892344 Forward-Port-Of: odoo/enterprise#105992
Features or functions removed from Odoo
This update removes the 'New' button from the DIMONA Declaration List view in the accounting module. This simplifies the process for users creating new DIMONA declarations, aligning with a streamlined workflow and reducing potential user confusion.
Original PR description
. Remove the New button on DIMONA Declaration List view task-5471873 Forward-Port-Of: odoo/enterprise#105783
7 changes
Enhancements to existing features
This update adjusts the calculations for the CP200 seizable amount in the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new valuation (2026) and updates the relevant percentage parameters to ensure accurate payroll processing according to Belgian tax regulations. This ensures compliance and correct salary deductions for Belgian employees.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
Resolved issues and error corrections
This update resolves an issue where the journal filter wasn't correctly applied when viewing journal items within the general ledger report. Now, when you select a journal in the report, the 'Journal Items' view accurately displays both the related invoices and the corresponding journal entry. This ensures accurate reporting and analysis of financial data.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a problem where payment reference data from a financial system (Codabox) was incorrectly formatted, often with extra spaces. The change automatically removes these spaces before creating reco models, ensuring data accuracy and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update ensures that all VAT reports (inf-a and inf-b) accurately include business partners without VAT numbers, addressing a previous reporting issue. The report warnings have also been standardized to better align with the main query, providing clearer guidance on potential VAT discrepancies.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update clarifies the visibility of specific fields within the Belgian payroll and fleet modules. Previously, generic fields were consolidated across all countries, but this change restores the original design, hiding BE-specific fields while maintaining their functionality within the Belgian version. This ensures accurate reporting and compliance for our Belgian clients.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update resolves a technical error that was causing a crash when creating new payroll records. The fix utilizes a standard Odoo method to handle virtual records, ensuring the payroll module functions correctly and reliably. This prevents disruptions to business processes.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303
This update resolves an issue where Odoo couldn't successfully process Fedex delivery requests due to a missing piece of information required by the Fedex API. Specifically, the system was failing with an 'INVALID' error. By adding a necessary field to the API request, we now ensure accurate delivery rate calculations and validation for Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
5 changes
Enhancements to existing features
This update adjusts the calculations for CP200 seizable amounts in the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new valuation (2026) and updates the relevant percentage parameters to ensure accurate payroll processing according to Belgian tax regulations. This change improves the accuracy of payroll reporting for Belgian employees.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
Resolved issues and error corrections
This update resolves an issue where the journal filter selected in the general ledger report wasn't carried over when viewing journal items. Now, when you select a journal in the report, the 'Journal Items' view correctly displays both the related invoices and the corresponding journal entry, providing a more complete financial overview.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update fixes a reporting issue where VAT numbers were incorrectly excluded from INF reports for Estonian businesses. Now, the reports include partners without VAT numbers, and a clearer warning is displayed when VAT information is missing, ensuring more accurate financial reporting. This improves compliance and data reliability.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update clarifies the visibility of country-specific fields within the Belgian payroll and fleet modules. Previously, generic fields were moved to a common module, but this change now ensures that the unique Belgian fiscal logic remains contained within the dedicated Belgian module. This maintains the correct functionality for Belgian businesses.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update resolves an issue where Fedex freight delivery requests were failing due to missing information required by the Fedex API. The fix adds a necessary field, 'expressFreightDetail', to the API request, allowing delivery rates to be retrieved and validated. This ensures users can accurately process Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
8 changes
Enhancements to existing features
This update adjusts the calculation of CP200 seizable amounts for Belgian payroll, incorporating a new valuation (2026) to ensure accurate tax reporting. This change improves the precision of payroll deductions for employees in Belgium, aligning with updated tax regulations.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
This update enhances the integration with Fiskaly for accurate VAT export mapping, addressing previous performance issues and expanding business case coverage. The changes improve transaction processing speed and ensure correct tax calculations, leading to more reliable financial reporting for German POS operations.
Original PR description
*: pos, pos_cert In this commit: ------------------ - The transactions were shown to be processed within 0-1 seconds as we were used to call start and finish transaction calls on validation so in the case of retails it won't give actual data of start and end time so we need to improve this and called now for `start transaction` when first orderline added to a new order, calling `cancelled` if the order is deleted or all the orderlines are removed manually, and `finished` on validation of the order. - we have also now handle correct tax mapping by backporting pr: https://github.com/odoo/enterprise/pull/83300 and many other business cases are handled. task: 5184287 Forward-Port-Of: odoo/enterprise#99216
Resolved issues and error corrections
This update fixes a reporting issue where the inf-a and inf-b reports weren't correctly including businesses without VAT numbers. The changes also standardize warning messages on these reports to align with the main query, ensuring clearer identification of potential data discrepancies. This improves the accuracy of financial reporting for businesses operating under VAT exemptions.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update clarifies the visibility of certain fields within the Belgian payroll and fleet modules. Previously, generic fields were consolidated across all countries, but this change restores the specific Belgian-related fields to their original location. This ensures the correct fiscal logic and reporting for Belgian companies within the Odoo Enterprise system.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update enhances the accuracy of payment reference checks by tailoring the validation process to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validation. Now, the system verifies the reference format against the bank's country, with a backup to a standard format if needed, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107116
This update resolves an issue where Odoo couldn't successfully process Fedex freight requests due to missing information required by the Fedex API. The fix adds a necessary field, 'expressFreightDetail', to the API request, allowing rate retrieval to succeed. This ensures users can accurately get delivery estimates for Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
This update resolves issues preventing early bill printing with the Italian fiscal printer. The fix addresses data synchronization errors and incorrect printing attempts, ensuring bills are now correctly printed when the 'early print' option is enabled. This improves the restaurant's order fulfillment process.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#105511This update corrects a technical issue preventing timesheet approval reminder emails from functioning properly. The change reflects a recent update to Odoo 17.3 that consolidated several actions, and a subsequent fix was applied to ensure the email templates now correctly reference the updated action.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107385
34 changes
New functionality added to Odoo
This update adds the ability to configure time off benefits directly within new employee contracts. During offer signing, users can now select the type of leave and the number of days, which are automatically applied once the contract is approved. This streamlines the onboarding process and ensures accurate leave entitlements from the start.
Original PR description
Version: master - Introduce a Time Off Allocation Benefit that allows users to choose whether paid leave should be included during the offer signing process. - Users can select the required Time Off Type and define the number of leave days as part of the offer benefits. - Once the offer is signed, the system will automatically allocate the selected leave entitlement to the employee. Task-5452900
This update adds more detailed information for Brazilian tax calculations within the Odoo Enterprise system. While a more sophisticated solution is planned for the future, this immediate change improves reporting accuracy for Brazilian sales and invoices. It addresses a growing need for granular tax data.
Original PR description
In the long run we want to replace this field with something nicer, because it's only going to keep growing. But it will need to be something more complex that: - Groups Brazilian info per line (probably in some popup/wizard), and - Keeps it available to be added to sale and invoice reports for end customers In the meantime we just add these two additional fields. The newline is also removed since it has no effect. task-5234294 Closes https://github.com/odoo/enterprise/pull/102538
Enhancements to existing features
This update adjusts the percentages used in the CP200 seizable amount calculation within the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new valuation for 2026, ensuring accurate payroll calculations for Belgian employees. This change improves the accuracy of reported payroll figures.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
This update improves the performance of the Gantt page when managing teams with 1000+ employees. By optimizing how employee data is loaded and reducing unnecessary data retrieval, the page now loads significantly faster, enhancing user experience.
Original PR description
The Gantt page was taking a long time to load when having a 1000+ employees I enabled pagination for the gantt view to make it load less fields (and not everything at once). Previously, active employees were loaded separately, with a second get_gantt_data() call. Merging the two calls into one was already an improvement. Also, the previous way of calling get_gantt_data() twice did not respect the limit and offset logic. In community, _read_group_employee_id would return all employees when "gantt_start_date" was in the context. This was the line slowing the request the most. Moreover, the result of _read_group_employee_id would just be discarded if the length of the result was greater than the limit. So it would be just slowing the request for nothing. Removing entirely that logic and moving it up in the call chain (in get_gantt_data) allowed me to add those employees without any record, while also respecting the limit and offset parameters. task-4762235
This update adjusts the calculation of sickness relapse periods for Odoo's Belgian payroll module. Starting January 1, 2026, the allowed gap between sick leave periods to be considered a relapse has increased from 14 to 56 days. This change aligns with updated Belgian tax regulations.
Original PR description
Spec :- Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Update the gap check between leaves from 14 to 56 days if the leave starts from 2026 . Add corresponding tests task-5476174
This update enhances the payroll dashboard for Swiss users by adding specific warnings. These warnings alert administrators to missing or incorrect information within employee and company records, ensuring accurate payroll calculations and compliance with Swiss regulations. This improves data integrity and reduces potential errors.
Original PR description
This PR improves the payroll dashboard for Switzerland by: 1- Disabling the generic warnings as they are currently irrelevant to Switzerland. 2- Add new warnings for the missing/invalidity of some needed fields in swiss employees and companies. Task: 5856084 Forward-Port-Of: odoo/enterprise#105148
This update allows users to directly edit the content and styling of their portal cards within the website editor. This enhances flexibility and provides a better user experience for customizing their portal views. The change impacts several Odoo modules related to portal customization.
Original PR description
create a new model `portal.entry` to manage customization portal cards. Users can now edit card content (text, image) and styling (background color, border, border-radius) directly from the website editor, improving flexibility and user experience. task-3894113
This update enhances the accounting report review process by now including posted entries flagged for review. Previously, only draft entries were considered. This change provides accountants with a more complete view of entries requiring attention, improving accuracy and efficiency.
Original PR description
entries can now have several states so the accountants know which ones need to be reviewed, are abnormal, are reviewed or supervised before the change only draft entries are included, now posted entries that are flagged to review are also included. task: 5404220
This update clarifies how bank accounts are displayed in financial reports. Previously, changing a bank account automatically linked it to a partner, showing all partner accounts. Now, users can select a specific partner, and only the bank accounts associated with that partner will be shown, streamlining the account selection process.
Original PR description
Before the change the partner and the bank account are related in a way that changing the bank account would change the partner which also makes all the bank accounts visible for whatever partner is selected. So this change allows the user to select the partner and then only shows the bank accounts related to this partner. Which is more logic for choosing a bank account. task: 5881257
This update ensures that users accessing sales orders through the portal are automatically directed to the subscription portal view, providing a consistent and streamlined experience. This change improves usability and prevents discrepancies in the user interface when managing subscription orders.
Original PR description
When accessing a sales order from the portal, ensure that subscription orders are rendered using the subscription portal view instead of the standard sales order portal. This guarantees consistent behavior and UI when a subscription is opened via the sales portal URL, while keeping the default sales portal view for non-subscription orders. task-5441334
This update enhances Odoo's HR payroll reporting by adding key information to the EPF and ESIC reports. Specifically, the reports now include Establishment Name, ID, and member details, improving compliance and accuracy of financial reporting. This change ensures proper reporting for Indian payroll requirements.
Original PR description
### After: - In the EPF Report, we are adding new values such as Establishment Name, Establishment ID, Total Members, and Serial No. Additionally, we are adding a main header for the report. - In the ESIC Report and Summary, we are adding a main header along with new values such as Establishment Name and Establishment ID, and renaming the selection label from “ESIC” to “ESIC Report.” Task: 5886135
This update adds a new test to verify the generation of work entries for a month within the Hong Kong payroll module. The test ensures that each day's work entry is correctly identified, improving the reliability and accuracy of payroll calculations. This is an important improvement for ensuring correct financial reporting.
Original PR description
Add a simple test that generates the work entries for a month and validate the work entry type of each day
This update enhances the employee experience by streamlining the review process and improving the user interface for personal information. Specifically, new employees are automatically flagged for review, and pay slips can no longer be validated if an anomaly is detected in the employee's review status. This ensures a more efficient and accurate payroll workflow.
Original PR description
This commit improves the employee UX and to review flow: - The personal situation fields are refactored to improve the UX - You cannot validate a payslip if the employee has a review state of anomaly - When you create a new employee with the HR officer of payroll assistant rights, the employee is marked as to review task-5401454
This update automatically calculates the `no_onss` field for employee payroll in Belgium, based on the employee's dimona code. Previously, this value was manually entered, which has now been replaced with an automated calculation to ensure accuracy and reduce potential errors. This improves payroll processing efficiency and compliance.
Original PR description
We can compute the value of `no_onss` field directly from the dimona code, no need to let the user decide. Task: 5480182
This update enhances the way starred messages are shown in the Discuss interface with Bookmark. Previously, a technical string was used; now, it utilizes the more user-friendly 'Bookmark' string. This improves the overall clarity and consistency of the Discuss experience for users.
Original PR description
This commit updates the string used for starred messages in Discuss with Bookmark. task-5873789 https://github.com/odoo/odoo/pull/245898 https://github.com/odoo/upgrade/pull/9363
This update simplifies the MyHR Payroll system by transitioning data from a list of input types to defined salary rules. This change improves the system's organization and makes it easier to manage payroll calculations. The update ensures greater accuracy and stability of the payroll processing.
Original PR description
- removed the records in `hr.payslip.input.type` and converted them into corresponding salary rules task-id: 5892647
This update sets a standard payment account for expense reimbursements processed through the Hong Kong payroll system. This ensures consistent and accurate accounting for these payments, simplifying financial reporting and compliance. The change improves the clarity and reliability of expense reimbursement accounting within the Odoo Enterprise platform.
Original PR description
. Add Other Payable account as default debit_account for expense reimbursement task-5719543
This update allows managers to view and modify their employees' Next Appraisal Date, regardless of their access permissions to the Employee app. This simplifies the appraisal process and ensures managers can consistently manage schedules, improving efficiency and accuracy.
Original PR description
Before this commit: When an employee's manager does not have access rights to the Employee app, they cannot view the Next Appraisal Date. After this commit: Allow managers to view and edit the Next Appraisal Date even if they do not have access rights to the Employee app, ensuring smoother appraisal handling. task-5413110
Resolved issues and error corrections
This update adjusts the timeframe considered a 'relapse' for sick leave calculations, aligning with new Belgian tax regulations. Starting January 1, 2026, the period between sick leave occurrences will be 56 days instead of 14, ensuring accurate payroll reporting. The change includes updated logic and testing to reflect this new standard.
Original PR description
Spec :- Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. Implementation :- . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add leave work_entry type where work_entry use date_start . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#107294 Forward-Port-Of: odoo/enterprise#104782
This update resolves a bug that prevented invoices with lines having a product price of zero from being saved correctly. The fix ensures that required tax object fields are properly populated, allowing invoices with zero-priced items to be saved without errors. This improves invoice creation functionality for Mexican clients.
Original PR description
**PROBLEM** If you create an invoice, and add a line with a product with a price of 0, you cannot save the invoice. **STEP TO REPRODUCE** 1. On a mx company, create an invoice for a mx client. 2. Add a line with a product with a price of 0. 3. Try saving the invoice, it will fails. **CAUSE** Field `l10n_mx_edi_tax_object` is required on invoice line with mx company. However, for lines with a price of 0, it is not set by `_compute_l10n_mx_edi_tax_object` because `_l10n_mx_edi_cfdi_invoice_line_ids()` filters them. opw-5402045 Forward-Port-Of: odoo/enterprise#103981
This update resolves an issue where feedback wasn't properly recorded when approving approvals through activities. Recent changes inadvertently broke the feature, preventing feedback from being posted. Now, feedback is correctly attached as a message when an approval is completed.
Original PR description
Approving an approval via an activity with feedback did not work properly as the feedback was never posted. This was due to the consecutive refactoring that broke the feature. After this commit, the feedback is posted as a message opw-5782803 Forward-Port-Of: odoo/enterprise#106185
This update corrects an issue where payslip calculations were sometimes inaccurate, particularly after updates to payroll data. The fix ensures that net pay is computed correctly, resolving a technical problem identified through automated testing. This improves the reliability of payroll reporting for our Chinese clients.
Original PR description
Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/237852 Task-5881260 Forward-Port-Of: odoo/enterprise#106341
This update fixes an issue with how withholding taxes are reported in Spanish accounting. Specifically, the 'type for 347' field in certain accounting moves has been corrected to be blank, aligning with Spanish tax regulations. This ensures accurate reporting and compliance.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#106889 Forward-Port-Of: odoo/enterprise#105597
This update fixes an issue where invoices generated for Ecuador (l10n_ec) were incorrectly creating discount lines due to rounding differences during tax calculations. The change aligns the XML generation process with Mexico (l10n_mx) to ensure accurate negative line handling and proper discount application, improving invoice accuracy.
Original PR description
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can…
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased. ## Steps to reproduce With **l10n_ec**: 1. Change the decimal accuracy to 6 digits. 2. Set the rounding method to *global rounding*. 3. Create an invoice with the following lines: | Quantity | Price | Taxes | |-----------|----------|-----------| | 20 | 1.4235 | VAT 0% G | | 20 | 1.6425 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.4235 | VAT 0% G | | 6 | 3.747768 | VAT 15% G | | 6 | 3.747768 | VAT 15% G | In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`. This happens due to rounding differences in how the `descuento` is computed in the `common_details_info_template` from **l10n_ec_edi**: format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount']) where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere. This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**. Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed. opw-5128612 Forward-Port-Of: odoo/enterprise#104659 Forward-Port-Of: odoo/enterprise#97337
A minor bug in the knowledge calendar tour was preventing it from finishing correctly. This PR corrects a reference to a button, ensuring the tour completes as intended. This resolves a test failure and improves the overall user experience for the knowledge calendar feature.
Original PR description
In test_knowledge_calendar_command_tour there was a miss-referenced button towards the end. This caused the tour to fail because it didn't find the button to click. With this PR we correctly reference the button and allow the tour to finish. Runbot Error: 234898 Forward-Port-Of: odoo/enterprise#105354
This update resolves a potential issue in the HR payroll system where validated work entries could incorrectly trigger conflicts. A new conflict state has been added to accurately reflect situations where days have been validated, streamlining payroll processing and reducing manual intervention. This ensures more reliable and accurate payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#101803
This update resolves an issue where users selecting time off by hours were seeing "InvalidDateTime" instead of the correct start and end times. This was caused by a recent change in how date/time formatting is handled. Now, the system correctly displays the selected time off hours.
Original PR description
**Issue:** - When users selected time off based on hours, "InvalidDateTime" was shown instead of the correct "From" and "To" time. This happened after a recent refactor:https://github.com/odoo/odoo/pull/240555/changes#diff-0beecbb730e1c7762f2a8d5f7038c02e123da10a85dec2e5d16a02748373f2fe of getFormatValue, which now returns DateTime in a different format than before. **Fix:** - Updated the method and adapt the new refactored format. **Impact:** - The correct DateTime values are now displayed instead of "InvalidDateTime". Task-5940185
This update adjusts how Odoo checks for product tracking, specifically for service products. A recent change allows service products to have tracking set to 'False' instead of 'none'. This update ensures that checks previously targeting 'none' now correctly identify service products without tracking, preventing inaccurate tracking assignments.
Original PR description
Adapt tracking checks to handle the new tracking=False value for service products. After the change in odoo/odoo that allows tracking to be False for non-storable products, we need to update all checks that were comparing tracking to 'none'. Service products now have tracking=False instead of tracking='none', so checks like `tracking != 'none'` were incorrectly treating them as tracked products. Updated checks in: - industry_fsm_stock: serial_missing compute, action_assign_serial - mrp_workorder: UI visibility logic for tracked products Task-5446456
This update resolves an issue where Amazon FBM pickings wouldn't validate properly, leading to delays and errors. Now, deliveries can be validated regardless of missing carrier information, and any resulting sync issues are handled efficiently with error reporting. This ensures smoother integration with Amazon.
Original PR description
Before this commit: - Amazon FBM pickings fail to validate if carrier or tracking reference is missing, blocking test flows, and causing infinite delivery retry loops. After this commit: - Pickings can be validated regardless of missing carrier or tracking info. - Sync issues are deferred to `sync_feed` and flagged via error reporting. - Supports retryable and observable sync logic, enabling test and edge-case flows. task-4789260 SEE also: Community PR:https://github.com/odoo/odoo/pull/213908
This update resolves an issue where users encountered an error when editing reconciled invoice lines within the Bank journal. The fix initializes necessary variables to avoid a runtime error, ensuring users can now successfully adjust these lines without disruption.
Original PR description
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting`…
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting` module. - Create an `invoice` with an `invoice line` having an amount greater than zero. - `Confirm` the invoice. - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice. - Click `Reconcile` on that `statement line` and select the newly `created invoice line`. - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save. `UnboundLocalError: local variable 'original_base_lines' referenced before assignment` The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2]. This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error. [1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394 [2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411 sentry-7189027839 Forward-Port-Of: odoo/enterprise#107454 Forward-Port-Of: odoo/enterprise#104432
This update corrects a technical issue in the account reports module that was causing errors related to invalid record IDs. The fix filters out incorrect 'falsy' IDs, ensuring the reports display accurate data and prevents potential system instability. This improves the reliability of financial reporting.
Original PR description
Previously, get_unknown_partner_aml_ids collected AML IDs and included falsy IDs from the total lines. For a while, this had no side effects. However, in commit 4290724, the odoo/orm/models.py browse method was changed to disallow browsing for falsy IDs. get_unknown_partner_aml_ids has been caught by this and needs to not include total lines to prevent adding lines with no res_id. A simple option to ignore total lines fixes this issue. Steps to replicate: Create and post a journal entry with a line for accounts receivable Open Accounting > Tax Returns > Error (Invalid falsy real id) task: 5919319 Browse Change PR: 227477 Forward-Port-Of: odoo/enterprise#107458
This pull request restores the previous calculation of holiday accrual based on a two-week period in the Belgian HR payroll module. The removal of this feature was previously implemented, and this change reverts that change, ensuring accurate and compliant holiday calculations for Belgian employees. This ensures consistent payroll processing.
This update corrects a recent issue where uploading new templates disrupted the connection between activities and their associated sign requests. The fix ensures that sign requests remain properly linked to activities, streamlining the workflow for users managing document signatures. This resolves a disruption in the activity revamp feature.
Original PR description
This hotfix resolves an issue introduced in the activity revamp feature that caused the link between the activity and its sign request to break when a new template was uploaded via the upload button. task-5379922
Features or functions removed from Odoo
This update simplifies the reporting of work orders and manufacturing orders by removing the 'Employee Cost per hour' and 'Worksheet page' measures from pivot views. Additionally, the 'employee_cost' measure has been removed from the OEE pivot view, streamlining data analysis for operational efficiency.
Original PR description
This commit removes the following measures in WO pivot views: - Employee Cost per hour - Worksheet page The commit also removes employee_cost from OEE pivot view measures (Overall Equipment Effectiveness). Task-5384708
18 changes
Enhancements to existing features
This update adjusts the calculations for the CP200 seizable amount in the Odoo Enterprise payroll system for Belgium. Specifically, it incorporates a new valuation (2026) and updates the percentage parameters used in these calculations, ensuring accurate tax and social security deductions for Belgian employees. This change improves payroll compliance and reporting.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
This update adapts Odoo's US payroll to comply with the new 'One Big Beautiful Bill Act' (OB3), which impacts overtime tax deductions. The system now allows for qualified overtime deductions, capped at $12,500 for singles and $25,000 for married couples, ensuring accurate tax calculations based on updated federal regulations. This change primarily affects US-based employees and payroll processing.
Original PR description
Purpose: In July 2025, the US Federal Government passed the "One Big Beautiful Bill Act" (OB3), which incurred policy changes around taxes, spending, and economic incentives. Odoo will need to adapt…
Purpose: In July 2025, the US Federal Government passed the "One Big Beautiful Bill Act" (OB3), which incurred policy changes around taxes, spending, and economic incentives. Odoo will need to adapt data and features to be compliant with the following changes: - No tax on overtime: Qualified overtime can be deducted, capped at $12,500 for singles and $25,000 if married filing jointly. The deduction is not avaiable if MAGI is over $150,000 for singles and $300,000 if married filing jointly. To adapt to the changes, the following salary rule and rule parameters were added: - l10n_us_hr_payroll_structure_us_employee_qualified_overtime (hr.salary.rule) - rule_parameter_federal_qualified_overtime_deduction_cap (hr.rule.parameter) - rule_parameter_federal_qualified_overtime_deduction_cap_2025 (hr.rule.parameter.value) The new salary rule is meant for informational purposes only. It will always show on the employee payslips if they inputted overtime work entries for the month and if the deduction cap has not been met yet. task-4964361
Resolved issues and error corrections
This update resolves an issue where journal filters weren't correctly reflected when viewing journal items within the general ledger report. Now, when selecting a journal filter, the corresponding journal entry details are accurately displayed alongside the related invoices. This ensures users can easily analyze financial data by journal.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a problem where payment reference data from Codabox was incorrectly formatted, often with extra spaces. The change automatically removes these spaces before creating reco models, ensuring data accuracy and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update ensures that essential products like 'Settle Due' and 'Deposit' are automatically configured for all Point of Sale (POS) settings within the Odoo Enterprise system. Previously, these products were only added when a POS session wasn't active, causing potential issues. Now, all POS configurations will have these products available, streamlining the user experience.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074 Forward-Port-Of: odoo/enterprise#95789
This update resolves an error that occurred when generating timesheet reports grouped by employee, specifically when filtering by billing time. The fix corrects a data structure issue within the reporting module, ensuring accurate reporting functionality for users.
Original PR description
## Short functional explanation of the error In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs. ## Reproduction Steps 1. Go to Timesheets. 2. Click on the…
## Short functional explanation of the error
In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs.
## Reproduction Steps
1. Go to Timesheets.
2. Click on the Reporting tab > By Billing type.
3. Click on the search bar and click on Employee under the Group By section.
### Expected behavior
A report shows the different hours worked on billing time for each employee.
### Unexpected behavior
An error occurs:
```TypeError: data.forEach is not a function```
## Origin of the issue
When retrieving the data to show in the report after having grouped
it by employee, this piece of code is called:
https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/sale_timesheet_enterprise/static/src/views/timesheet_analysis_pivot/timesheet_analysis_pivot_model.js#L23-L36
However, the variable (data) on which we perform the forEach isn't
an array: it's an object of structure:
```
{ "group": { "rowValues": [], "colValues": [] }, "rowGroupBy": [ "employee_id" ], "colGroupBy": [], "subGroupIndex": 2, "subGroups": [ { "employee_id": [ 1, "Administrator" ], "__extra_domain": [ [ "employee_id", "=", 1 ] ], "unit_amount:sum": 0, "__count": 2, "__domain": [ "&", [ "project_id", "!=", false ], [ "employee_id", "=", 1 ] ] } ] }
```
on which we can't perform a forEach. The data we want to access to
use in the report is actually the `subGroups` element of data.
__
opw-5864458This update fixes an issue where the inf-a and inf-b reports were incorrectly excluding partners without VAT numbers. The changes now include these partners and harmonize warning messages, ensuring more accurate reporting of VAT obligations. This improves the reliability of key financial reports.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update fixes a problem where the system was creating multiple, empty pay runs when generating payslips through the selection dialog. The fix ensures only one temporary pay run is created per dialog, preventing data clutter and improving system stability. This avoids unnecessary database entries and simplifies payroll processing.
Original PR description
When generating payslips from the selection dialog the UI previously created a new hr.payslip.run on every attempt; server-side validation can fail and each failed attempt left an empty pay run in the database. Fixed by allowing the dialog to create at most one temporary pay run per dialog lifecycle, reuses it on retries, and removes it if generation fails or the dialog is closed. task-5920710 Forward-Port-Of: odoo/enterprise#106857
This pull request reverses a recent change that granted Invoicing and Banks users access to accounting features. This rollback restores the original security restrictions, ensuring that only authorized users can access sensitive accounting data. It's a corrective action to maintain data integrity and compliance.
Original PR description
* Revert commit 6cf8eef51e9c0de9b21d10a512e53a4456cbead6 that introduced having Accounting features, menu items and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports task-5925567
This update fixes a bug preventing embedded videos from appearing in shopfloor work order instructions. The issue stemmed from a previous fix being lost during a code refactor. Now, users can successfully view and utilize video instructions within the shopfloor interface, improving training and operational guidance.
Original PR description
Issue ----- Embedded videos are not displayed in the shopfloor. Steps to reproduce ----- - Create a BOM with at least one operation - Create an instruction in the work order operation - In the instruction text, add a video link - Create a MO and plan it - Open the work order in shopfloor - Open the instruction > Empty window, no video Cause ----- Fix of 61fdab3 got lost in some refactor, so reapplying the logic. ----- Ticket: opw-5926557
This update corrects a calculation error in the Luxembourg HR payroll module. The fix ensures that payroll figures are accurately computed, resolving a potential discrepancy in employee compensation. This improves the reliability of payroll reporting and ensures compliance.
This update clarifies that commission adjustments can only be created using users who are part of approved sales plans. Previously, adjustments could be linked to any active plan, leading to confusion and incorrect user selection. This change improves the accuracy and usability of commission management.
Original PR description
Before this commit, when defining ajustment, the add_user_id and reduce_user_id could belong to any kind of active plan. It would make difficult to select the correct user when multiple plans were available. This commit ensure only approved plan can be used to create ajustments.
This update resolves access restrictions that were preventing basic users (sale, purchase, stock) from completing key workflows like creating invoices and purchase orders. The changes ensure these users can correctly interact with core Odoo modules, improving usability and reducing potential disruptions.
Original PR description
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields…
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access. Here is a list of examples (each performed with every other access rights disabled): - With a `stock user`, open the delivery list or form view #### > Access error - With a `purchase user` create and confirm a PO > Upload Bill #### > the Bill will be created but an access error will prevent the draft bill from opening. - With a `sale user` create and confrim an SO > Create invoice #### > the invoice will be created but an access error will prevent the draft invoice from opening. ## Solutions: ### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user: 1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model. Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view. #### Note for master: IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52 2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53 ### Use case: Open a `stock.picking` views as basic stock user: 3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496 opw-5461135 opw-5417749
This update resolves a memory error that occurred when calculating standard deviation and average values for quality points. By disabling a data fetching step and focusing on only two necessary fields, the system now efficiently processes quality data without exceeding memory limits. Benchmarks show a significant performance improvement.
Original PR description
Before this commit, computing the `standard_deviation` and the `average` of a `quality.point` involved fetching all the quality checks and all their fields. This can cause a memory error because of the field called `notes` that might involve HTML code. To avoid this, I have disabled the prefetcher since we only need two fields for the computation (`x_quality_state` and `measure`). The benchmark done below involved a recordset of quality points of size 1000 and the average size of the `notes` field was 6MB. The recordset was ordered by the size of the note section descending and for the different test cases it was sliced by the $K$ top elements and the compute function was triggered on the sliced version. | Scenario | Before | After | | :--- | :--- | :--- | | 100 | Memory LIMIT | 289.0MB | | 200 | Memory LIMIT | 290.0MB | | 500 | Memory LIMIT | 292.0MB | | 1000 | Memory LIMIT | 331.0MB |
This update resolves an issue where the header in the sign application was overlapping due to a color bar. The team removed a styling tag to correct the layout and ensure a clean, professional appearance for users completing the signing process. This improves the user experience.
Original PR description
Remove `top` tag to prevent header overlap due to neutralize red color bar Before fix: <img width="1953" height="790" alt="image" src="https://github.com/user-attachments/assets/dd9f7a00-eaea-4304-a22d-d8df96203823" /> After fix: <img width="1892" height="639" alt="image" src="https://github.com/user-attachments/assets/247e6067-570a-4fcb-a0e9-6f2640940f21" /> opw-5900244
This update ensures that specific fields related to Belgian payroll and fleet management within the Odoo Enterprise system are hidden for companies outside of Belgium. This change streamlines the system for international users while preserving the unique fiscal logic for Belgian operations. The update aligns with a broader refactoring effort to standardize payroll and fleet data across all countries.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update resolves an issue where FedEx freight service requests were failing due to missing information required by the FedEx API. Specifically, the system was missing a 'bookingConfirmationNumber' field. By disabling freight services, we prevent users from receiving 'SHIPMENT.LOADCOUNT.INVALID' errors and ensure accurate rate retrieval.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
This update ensures that the preparation display in the backend accurately reflects changes when a POS order is cancelled or deleted. When an order is removed, related preparation data is also cleaned up, preventing outdated information from appearing. This improves the accuracy and reliability of the POS system.
Original PR description
**In this commit:** Ensure the preparation display UI is updated when a POS order is cancelled or deleted from the backend. - On order cancellation, the preparation display is refreshed accordingly. - On order deletion, related preparation orders, lines, and states are removed via notify call. Task-5373116 Related: https://github.com/odoo/odoo/pull/240523 Forward-Port-Of: odoo/enterprise#103052
8 changes
Enhancements to existing features
This update adjusts the calculations for the CP200 seizable amount in the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new valuation (2026) to ensure accurate tax deductions and compliance with Belgian regulations. This change improves the payroll accuracy for Belgian employees.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
Resolved issues and error corrections
This update resolves an issue where the selected journal wasn't reflected when viewing journal items within the general ledger report. Now, when you filter by journal, the report accurately displays both the invoice and the associated journal entry, providing a more complete view of financial data. This enhancement improves reporting accuracy and usability.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update simplifies testing within the Odoo Enterprise platform by moving patches from class to instance level. This resolves a detection issue during automated testing and improves the overall stability of the system. The changes primarily affect the testing process for several key modules.
Original PR description
Otherwise they trip the on-test-side-effect-detector (at least in its current incarnation).
This update resolves an issue where grouped tax reports were failing when invoices included both positive and negative tax amounts. The fix ensures that all tax line amounts, including negative ones, are correctly processed, preventing report errors. This improves the accuracy of tax reporting.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790
This update resolves an issue where the public knowledge sidebar overlapped with article content on mobile devices. The fix ensures the sidebar functions as a proper mobile overlay, providing a cleaner and more consistent user experience. This improves readability and usability for mobile users.
Original PR description
Steps to reproduce: 1. Install `website_knowledge` 2. Create a long, scrollable knowledge article with 20 sub-articles. 3. Share the article publicly 4. Open the public link in mobile view (logged…
Steps to reproduce:
1. Install `website_knowledge`
2. Create a long, scrollable knowledge article with 20 sub-articles.
3. Share the article publicly
4. Open the public link in mobile view (logged out)
5. Toggle the sidebar using the top-left menu button
6. Scroll down
Issue:
- On mobile, the public sidebar overlaps with the article's content while scrolling.
Cause:
- the sidebar and its backdrop were positioned absolutely inside a flex container. Because they were not fixed to the viewport, the article content continued to scroll and render underneath the sidebar, causing visible overlap between the sidebar and the article body. Additionally, the sidebar’s internal scroll container was not explicitly positioned, which contributed to inconsistent scrolling behavior when the sidebar was open.
Solution:
- Update the public Knowledge sidebar css to behave as a proper mobile overlay by: Fixing the sidebar and its backdrop to the viewport using position: fixed, ensuring they are removed from the flex layout flow on mobile Explicitly positioning the sidebar’s internal scroll view to ensure correct scrolling behavior
<table>
<tr>
<td><strong>Before</strong></td>
<td><strong>After</strong></td>
</tr>
<tr>
<td><img width="725" height="901" alt="Before image" src="https://github.com/user-attachments/assets/33190684-5b52-4931-b01a-5044734c9cf0" /></td>
<td><img width="686" height="916" alt="After image" src="https://github.com/user-attachments/assets/610a5aef-3467-4215-a0a0-83607375a016" /></td>
</tr>
</table>
opw-5384026This update ensures that CODA file imports processed through the automated cron system correctly split transactions according to the configured journal settings. Previously, the cron process bypassed this splitting logic, leading to incorrect accounting. This fix improves the accuracy of financial data.
Original PR description
When importing CODA files manually, transactions are correctly split according to the journal configuration. However, when processed via the cron, the splitting logic is bypassed because the journal recordset is empty at the time of parsing. This occurs because the journal is identified only after the file has been parsed, which is too late for the cron flow. This commit ensures the journal is available early enough to respect the "Split Transactions" setting regardless of the import method. opw-4954539 Forward-Port-Of: odoo/enterprise#106344
This update corrects a technical problem where payments could be activated but not properly reflected within Odoo, leading to errors. By ensuring payments are consistently marked as activated, this fix prevents disruptions in payment processing and improves overall system stability. This resolves a potential issue impacting payment accuracy.
Original PR description
In some cases, payments are already activated but are not set as activated in Odoo, the consequences of this is that in that case we will always get the error on Odoofin side because the payment will never be set as activated on odoo side. task-5490817
This update fixes an issue where CFDI refund XMLs used a generic description instead of the original line description. It ensures that refund details are accurately reflected in the CFDI document, complying with Mexican tax regulations. This change aligns with a previous update in version 19.0.
Original PR description
Steps to produce: --- - Install `accountant` and `l10n_mx` modules. - Switch to Mexican company. - In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`. -…
Steps to produce: --- - Install `accountant` and `l10n_mx` modules. - Switch to Mexican company. - In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`. - Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice. - Mark the invoice as global. - Register the payment. - Create a credit note and confirm it. - Click Send(make sure CFDI is checked) and check the generated XML. Issue: --- - The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`. Solution: --- - Preserve the original line description for CFDI refunds instead of forcing the generic label. - For POS refunds, continue using the generic label. - This aligns with the fix introduced in 19.0([here]). Before: --- <img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" /> After: --- <img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" /> [here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436 **Backport of https://github.com/odoo/enterprise/pull/97681** opw-5870052 ---
3 changes
Resolved issues and error corrections
This update resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly shown when the localization wasn't installed. The fix adds a new field to the model to control its visibility, ensuring the correct display based on the installed localization.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488
This update fixes an issue where the system incorrectly predicted taxes during XML invoice imports. Previously, it relied on customer history, even if the imported invoice only contained one tax. Now, the system accurately uses the tax data directly from the imported XML file, ensuring correct tax calculations.
Original PR description
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%),even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. This behaviour is fixed by this PR : #246308 And this commit is part of the fix. task-5503126 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update resolves an issue where tasks remained linked to sales orders even without a related sales order line. Previously, this prevented users from properly billing tasks. Now, tasks are only linked to sales orders when there are items associated with them, streamlining billing and task management. This ensures tasks can be easily detached and re-linked when needed.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989