Daily updates from Odoo
Tuesday, February 17, 2026
62 changes · saas-19.1
Enhancements to existing features
This update improves the performance and stability of our website's image carousel functionality. The Owl library, a key component of our web interface, has been upgraded to the latest version 2.8.2. This ensures continued smooth operation and addresses potential compatibility issues.
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.8.2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248976
This update adjusts Odoo's Indian localization to align with new requirements for GST e-invoices. Specifically, it switches to a new GST Suvidha Provider (GSP) configuration, ensuring accurate and compliant invoice generation. This change is necessary due to recent integration updates with Indian tax authorities.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243296
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
This update adjusts Odoo's payroll system to comply with the new 'One Big Beautiful Bill Act' (OB3) in the US, specifically regarding overtime tax deductions. The changes allow for capped overtime deductions based on income levels, ensuring accurate tax calculations for employees. This update primarily impacts US payroll functionality.
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 Forward-Port-Of: odoo/enterprise#107187
This update switches the GSP provider for Indian GST e-invoices to align with recent integration updates. This change ensures Odoo correctly processes and reports on Indian GST data, maintaining compliance with regulatory requirements. It’s a necessary update to support ongoing operations.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 Forward-Port-Of: odoo/enterprise#103984
Resolved issues and error corrections
This update fixes a usability issue on small devices where users couldn't exit the QR code customer display popup. A back button and close action have been added, allowing users to easily dismiss the popup and continue using the Point of Sale system. This enhances the user experience and prevents frustration.
Original PR description
Before this commit: =================== On small devices, the customer display popup had no way to be closed, which made it impossible to exit the QR code screen. After this commit: ================== Added a header back button and a close action to allow users to dismiss the customer display popup on small devices as well. Task-5926747 Forward-Port-Of: odoo/odoo#248400
This update corrects a previous issue where the 'Employees' smart button in job postings incorrectly counted all companies associated with the job. Now, the button only reflects the employee count for the companies currently selected, ensuring accurate reporting and data. This improves the reliability of job postings.
Original PR description
### Steps to reproduce: - Create a job for multiple companies. - Go to its configuration and click the Employees smart button. - Click the smart button and compare the employee count. ### Before/Root cause: - Currently selected companies were not considered. Instead, all companies were taken into account during the computation. ### After: - When you click on employee smart button only currently selected companies will be considered. ### Fix: - Added a domain filter to consider only the currently selected companies. task-5785245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244718
This update corrects a technical issue where the Delivery Date was incorrectly displayed twice in the Sales Order report preview. The fix removes the redundant data entry, ensuring accurate reporting and a cleaner presentation for sales professionals. This improves the reliability of sales data.
Original PR description
**Steps to reproduce:** 1. Install modules sale_management 2. Go to Settings, Configure Document Layout and set layout to DIN 5008 3. Create a new Sale Order 4. Set a customer, add a product, and fill in the Delivery Date (Other Info) 5. Click on Print and Preview **Issue:** The Delivery Date (commitment_date) is printed twice in the report. **Solution:** Remove duplicated Delivery Date entry from this module to avoid rendering it twice. Issues : https://github.com/odoo/odoo/issues/247522 **opw-5490651** Forward-Port-Of: odoo/odoo#248779
This update fixes potential issues within the website form builder by restricting unsupported options on submit buttons. Removing redundant actions and animation controls enhances stability and prevents unexpected behavior like cloning or deletion. This ensures a more reliable and consistent user experience for website content creation.
Original PR description
*: html_builder, website_mass_mailing Prevent unsupported actions and options on form submit buttons to avoid cloning/deletion issues and UI inconsistencies. - Remove Duplicate and Remove actions from the sidebar for submit buttons (newsletter popup, forms, etc.) instead of disabling them. - Hide the animation option for submit buttons, since it is already handled in the "Button" section. - Remove the Visibility option for submit buttons. Prevent unsupported actions and options on form submit buttons to avoid cloning/deletion issues and UI inconsistencies. task-4702429 Forward-Port-Of: odoo/odoo#241101
This update enhances accounting reports by allowing users to filter based on multiple journals instead of just one. Previously, the system only supported filtering by a single journal. This change provides greater flexibility and control when generating financial reports.
Original PR description
In accounting reports, we want to be able to filter on multiples journals if needed. This filter will allow us to do this. Using `context['search_default_journal_id'] = journal_ids` doesn't work as only the first id is passed to the filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247731
This update corrects a naming issue within the SEPA Direct Debit payment provider setup. Previously, two different payment methods had the same name, causing confusion for users. The change ensures clarity by renaming one method to 'Online SEPA', streamlining the setup process and improving user experience.
Original PR description
When activating SEPA Payment Provider and checking SEPA in your settings, the name of the two (different) method was the same. Rename the method line associated with the method that comes from the provider by 'Online SEPA' to avoid confusion. task-5875979 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246688
A technical issue causing a traceback when generating employee time off reports has been fixed. The fix ensures the report always returns a valid SQL query, even when no employee data is available, preventing errors and improving report reliability. This ensures all users can consistently access and generate their time off reports.
Original PR description
Steps to Reproduce: - Install time off module without demo data - open reporting menu - open 'by Employee' Issue: - Traceback occurs Reason: - the method _table_query returns an empty string when there is no data. - _table_query should return a valid SQL query for report, not an empty string. Solution: - Modify _generate_report_query to return a valid SQL query even when there are no records - Instead of returning an empty string, return a SELECT statement with NULL values for required columns task-5846974
This update restores a previously removed feature that allowed users to designate orders as 'trusted' within the Point of Sale system. This functionality was critical for streamlining order processing and reducing manual intervention. The change ensures that trusted orders are correctly handled, improving operational efficiency.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234941 Forward-Port-Of: odoo/odoo#200567
A recurring timeout issue during automated testing of the l10n_ke_edi_oscu_pos module was identified. This issue occurred when the system refreshed the page after adding products to the cart, triggering a database transaction. This PR increases the test timeout and adds debugging information to address the problem.
Original PR description
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a…
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a listener added on the order component which tries to automatically add the taxes to the products in the order. This triggers a transaction on indexed db. Since the tour test executes the refresh immediately after adding the product to the cart, it causes a timeout. I could not reproduce the issue locally, but it's been happening consistently on almost every nightly run, always on the l10n_ke run. This PR will increase the timeout and add some extra info to the timeout message to help with debugging in the future. Runbot error: [233525](https://runbot.odoo.com/odoo/runbot.build.error/233525) Task: [5897379](https://www.odoo.com/odoo/project/1737/tasks/5897379) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248257
This update prevents an infinite page reload cycle when applying multiple gift cards from the same program. The fix addresses a discrepancy in how discount lines are handled, specifically when multiple gift cards are used. This ensures a smoother checkout experience for customers.
Original PR description
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add…
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add a deliverable product to cart. 3- Open cart and add both gift card codes. 4- Click on checkout to navigate to delivery step. The page is going to keep refreshing. ### Cause: The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.: https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24 After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line. However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card ### Fix: This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines. Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card). opw-5485912 Forward-Port-Of: odoo/odoo#248215
A minor bug causing an error when hovering over the unselect button in BuilderMany2One components has been resolved. This change ensures the component functions correctly and prevents unexpected errors, improving the user experience.
Original PR description
Issue: The `BuilderMany2One` component throws an undefined error when hovering over the unselect button. Steps to reproduce: 1. Create a `BuilderMany2One` component with `allowUnselect=true` 2. Hover over the unselect button 3. Error occurs Cause: `undefined` was passed when `hasPreview` is `false`, but a callback function is expected. Solution: Pass an empty callback function instead of `undefined` when `hasPreview` is false. Forward-Port-Of: odoo/odoo#248824 Forward-Port-Of: odoo/odoo#248387
This update ensures that the language of live chats is consistently displayed in the information side panel. Previously, some live chats were missing this language information. This change consolidates code and improves the user experience by showing the visitor's language for all live chat sessions.
Original PR description
**Purpose of this PR:** some livechats are missing the language in the info side panel. now we moved the code from website_livechat to im_livechat since we are fetching the same in website_livechat task-[`5487074`](https://www.odoo.com/odoo/project/1519/tasks/5487074) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243462
This update fixes an error that occurred when users attempted to create invoices with a quantity of zero. The fix prevents a division-by-zero error during invoice calculation, ensuring invoices can be properly processed. This improves the reliability of the invoicing process.
Original PR description
Currently an error occurs when user tries to post an invoice with zero quantity. Steps to replicate: - Install `stock_account`, 'accountant' and `sale_management`. - Go to Settings and set `Inventory…
Currently an error occurs when user tries to post an invoice with zero quantity.
Steps to replicate:
- Install `stock_account`, 'accountant' and `sale_management`.
- Go to Settings and set `Inventory Valuation` to `Perpetual (at Invoicing)` and `Inventory Cost Method` to `FIFO`.
- Go to Products and create a new one with name `test`, set Track Inventory.
- Open Sale orders, create new one with product `test` and confirm.
- Go to the delivery and Validate it. (set the quantity to meet the demand).
- Go back to the Sale Order and click Create Invoice.
- On the Invoice make the quantity to be `0` and confirm it.
- Error will occur.
Error:
```
File /home/odoo/odoo18/community/addons/stock_account/models/account_move.py, line 37, in _post
self.env['account.move.line'].create(self._stock_account_prepare_realtime_out_lines_vals())
File /home/odoo/odoo18/community/addons/stock_account/models/account_move.py, line 122, in _stock_account_prepare_realtime_out_lines_vals
price_unit = line.with_context(anglo_saxon_price_ctx)._get_cogs_value()
File /home/odoo/odoo18/community/addons/stock_account/models/account_move_line.py, line 85, in _get_cogs_value
return (price_unit * total_qty - posted_cogs_value) / self.quantity
ZeroDivisionError: float division by zero
```
Cause:
- Error occurs after a recent [fix], that added some logic to correctly calculate cogs.
- As the user made quantity as 0, it caused the error at line [1].
Solution:
- Early return from the function if the quantity is zero.
[fix]: https://github.com/odoo/odoo/pull/237119
[1]: https://github.com/odoo/odoo/blob/d088dbad84492234ae792b76545497c6cd62e4f4/addons/stock_account/models/account_move_line.py#L83
sentry-7157442021
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241974This update resolves an issue where validated time entries were incorrectly flagged as conflicts. The new conflict state accurately reflects that these days have already been approved, streamlining the time tracking process and reducing potential confusion for HR and managers. This ensures accurate reporting and prevents unnecessary alerts.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239267
This update corrects a problem in the demo data for the HR Holidays module. Specifically, it ensures that Anita Oliver's leave is properly applied to her next payslip, triggering the 'Time Off to Defer' functionality as intended. This ensures the demo data accurately reflects the expected behavior of the HR Holidays feature.
Original PR description
Add leave for the 1st month against its payslip so that Time Off to Defer happens for the next payslip. task-5912512
This update corrects a technical issue where Odoo's translation system incorrectly identified nodes with directives (like 'groups') as translatable. This fix ensures that only standard content is translated, improving the accuracy and efficiency of the translation process. It resolves a potential inconsistency in how Odoo handles HTML elements.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag. Forward-Port-Of: odoo/odoo#248591 Forward-Port-Of: odoo/odoo#246354
This update fixes an issue where product names, references, and prices in the Arabic version of the Product Catalog were misaligned. The change uses specific styling to ensure text aligns correctly in RTL (right-to-left) layouts, providing a better user experience for Arabic-speaking customers. This improves readability and consistency across all languages.
Original PR description
Steps to reproduce: 1. Switch the user language to Arabic. 2. Open the Product Catalog from a Sales/Purchase order. 3. Observe that the Name, Internal Reference, and Price collapse into a single line with inconsistent ordering due to unmanaged horizontal inline flow. Cause: The use of generic span elements inside a portal encourages horizontal inline flow that fails to mirror correctly in RTL without explicit flex instructions. Solution: Update the Order Line portal template to use 'd-inline-flex' and 'align-items-baseline'. This treats the price and reference as a logical unit that respects the global direction and ensures consistent text alignment in both English and Arabic. opw-5867434 Forward-Port-Of: odoo/odoo#248620
This pull request reverts a recent change to the HR holiday report, addressing a problem that was preventing accurate leave reporting. The change was rolled back to restore the previous, correct functionality, ensuring employees' leave balances are displayed accurately.
Original PR description
…b6c2 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'vertical video' setting for embedded videos was lost when the HTML editor dialog was reopened after replacing the video. The change ensures that users can consistently select and maintain their preferred video format, improving the user experience. This resolves a bug related to video embedding functionality.
Original PR description
#### Description of the issue this PR addresses: - In this [PR](https://github.com/odoo/odoo/pull/242219), `.media_iframe_video` class removed from embedded video. - No common selector for website video and embedded video block #### Steps to reproduce: - Insert a video from media dialog - Enable Vertical option - Reopen dialog via Replace action - Vertical option is not preserved task-5931717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo calculates employee holiday schedules, resulting in faster processing times. The change reduces the number of database queries performed, leading to a smoother and more responsive experience for users managing holiday requests. This improvement focuses on internal performance enhancements.
Original PR description
Given a recordset, we do O(n) queries. Rewrite `_get_first_working_interval` to use batching of the underlying functions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the website's redirection process was losing URL parameters, leading to incorrect page navigation and errors. The fix ensures that all parameters are properly encoded during redirection, maintaining accurate routing and functionality for users. This improves the overall website experience and prevents unexpected errors.
Original PR description
Scenario from 17.0:
- set domain on website
- go to website /website/force/1?path=%2F%3Fa%3Db%26c%3Dd with another
domain
=> you are redirected to {domain}/?a=b instead of {domain}/?a=b&c=d
Scenario from 18.0:
- set domain on website
- go to /appointment/1 on other domain, select person date and time
- click on "Editor"
=> you get error:
> TypeError: AppointmentController.appointment_type_id_form() missing 1
> required positional argument: 'duration'
Cause: the /website/force/ domain redirection doesn't encode the
parameter when redirecting, so we lose parameters after the first one.
Fix: encode parameters when redirecting domain in /website/force/ route.
opw-5441957
Forward-Port-Of: odoo/odoo#248523
Forward-Port-Of: odoo/odoo#242252This update removes an unnecessary step in the HR leave report generation process. Previously, the report created a snapshot of all holiday data, which slowed down performance. Now, the report simply returns an empty table when no data is needed, resulting in faster report generation times. This improves the overall efficiency of the HR reporting system.
Original PR description
Avoid creating the table with a snapshot of current data and just return an empty table when needed Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem with the demo data for the l10n_pl_edi module, ensuring accurate demonstration of the Polish VAT electronic invoicing functionality. The fix resolves an incorrect field being used in the demo data, preventing installation issues and providing a reliable demonstration for users. This ensures the demo data accurately reflects the module's intended use.
Original PR description
To reproduce: - Try to install l10n_pl_edit with demo data --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an access issue preventing users from applying the 'My Department' filter in the Time Off module. The fix avoids a security restriction by directly checking employee department membership instead of relying on a separate model. This ensures the filter functionality works correctly for all users.
Original PR description
**Steps to reproduce:** 1- Install Time off app with demo data 2- Log in as Marc Demo 3- Go to Time Off > Overview 4- Enable `My Department` filter **Issue:** An access error is raised because of not having enough rights to access the field `version_id` on hr.employee. **Fix:** Adding the field `member_of_department` directly on hr.employee to to do the compute and search on that field in sudo to know if the employees in the Overview are part of the department of the current user. Hence, avoiding the need to access the `hr.version` model which the user does not have access to. Task: 5470085
This update resolves an issue where tests were failing due to a helper function raising when a related module (often from the Enterprise version) wasn't installed. The change prevents this error, ensuring Odoo's automated testing process (runbots) continues to run smoothly. This improves the reliability of our software releases.
Original PR description
When the module pointed by ensure_installed is not installed, the caller test is skipped. In 19.1, this helper is raising if the module is not found. It was a great idea to detect if the corresponding module exists or not but is an issue in some runbot builds when the targeted module is in the enterprise version. So let's prevent the raising to make runbot happy again! --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the currency rate used to value purchase invoices wasn't correctly applied when the rate was manually adjusted. This resulted in inaccurate product valuations. The fix ensures that the correct currency rate is always used, regardless of manual rate changes, leading to accurate accounting.
Original PR description
**Problem:** The value of a move does not take the correct currency rate if it was changed manually on the invoice. **Steps to reproduce:** - make sure dollar is your main currency - activate euro…
**Problem:** The value of a move does not take the correct currency rate if it was changed manually on the invoice. **Steps to reproduce:** - make sure dollar is your main currency - activate euro and set a rate of 1 USD -> 2 euros - create an avco perpetual storable product with no tax - confirm a purchase order for 1 product at 100 euros with no tax - validate move - create a bill for this purchase order - set the currency to euro - below 'EUR' change the currency to 4 (the bug also happens if you open the widget calendar and select a date with another rate than the invoice date) - in the journal items tab you should see the value going from 50 to 25 for the account move lines. - confirm the invoice - open stock and search your product **Current behavior:** the unit price is 50 **Expected behavior:** it should be 25 **Cause of the issue:** In _get_value_from_account_move when computing the value, we convert the value of the account move line using the _convert method on the currency at the date of the invoice, but if the rate was changed manually this is no longer correct. https://github.com/odoo/odoo/blob/4ad397e94b4661cd64515e137b3e650dc330269c/addons/purchase_stock/models/stock_move.py#L170 **fix** When manually changing the rate on the widget, the account move lines are updated using currency_rate https://github.com/odoo/odoo/blob/8d7194128b26a09be75bf5bfe4e63c8bbfaac69f/addons/account/models/account_move_line.py#L1634 Using the same compution for the valuation of the move ensures alignment. currency_rate is computed based on invoice_currency_rate which is updated in case the rate was set manually. https://github.com/odoo/odoo/blob/4ad397e94b4661cd64515e137b3e650dc330269c/addons/account/models/account_move_line.py#L726 opw-5416654 Forward-Port-Of: odoo/odoo#245714
This update resolves payment issues with Adyen, Mercado Pago, and Stripe caused by incorrect currency rounding. The fix ensures all payment amounts are rounded down to the currency's minor unit during transaction validation, preventing payment failures and improving payment processing accuracy. This change impacts all payment provider integrations.
Original PR description
*: payment{,_adyen,_mercado_pago,_stripe} ### Issue: The payment in some payment providers are failing to due setting currency decimals. #### Steps to reproduce: 1- In USD currency form in developer…
*: payment{,_adyen,_mercado_pago,_stripe}
### Issue:
The payment in some payment providers are failing to due setting
currency decimals.
#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through Adyen. As you see payments fail.
### Cause and Fix:
This issue is the same as https://github.com/odoo/odoo/pull/245059. That fix only focused on Stripe, however, the same issue is reproducible on other providers e.g. `Adyen`. In order to avoid the same issue, we can have a general fix to round down all payment transaction amounts to currency's minor unit in `_validate_amount_and_currency`.
---
There is another issue in Mercado Pago which the if currency is not one of these currencies then it will not be sent to provider rounded:
https://github.com/odoo/odoo/blob/035b701cbf7bd654f56f07244e606e4038c4115a/addons/payment_mercado_pago/const.py#L39-L43
Mercado Pago rounds **up** in these cases, which will cause mismatch in `_validate_amount_and_currency`.
opw-5871470
Forward-Port-Of: odoo/odoo#248320
Forward-Port-Of: odoo/odoo#245877This update resolves an issue where importing EDI invoices with products restricted to a different company would fail. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors and improving the reliability of multi-company invoice processing. This ensures accurate financial data import across multiple companies.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912
Forward-Port-Of: odoo/odoo#248893
Forward-Port-Of: odoo/odoo#248149This update fixes a bug where future-dated POS orders placed via self-checkout weren't properly canceled. Now, canceling a future order correctly removes it from both the POS interface and the system, ensuring accurate order management. This improves the reliability of our POS system.
Original PR description
Before this fix, when we placed an order from the self-checkout with a preset slot for a future date, we weren't able to cancel it from the POS. The UI showed it as canceled, but after refreshing, the order was still there. Now, when we cancel an order scheduled for the future, it is correctly canceled both in the UI and in the POS. task : 5246089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248246 Forward-Port-Of: odoo/odoo#235775
This update corrects a problem where users could trigger errors when entering non-numeric values in the 'Number of SN' field during serial/lot number generation. By changing the field's input type to 'number' and adding a check for periods, the system now reliably handles numeric input, preventing errors and ensuring smooth operation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed. Forward-Port-Of: odoo/odoo#248729 Forward-Port-Of: odoo/odoo#248221
This update ensures that confirmation emails are reliably sent when an applicant declines a job offer. Previously, it was difficult to track whether these emails were successfully delivered, leading to potential communication issues. This change provides better visibility and ensures applicants receive timely notification of their decision.
Original PR description
Before this commit, applicant refusals were logged in the chatter separately from sending the mail, making impossible to see if the mail was correctly sent or not. Forward-Port-Of: odoo/odoo#235888
This update resolves a technical issue where the composer's content was incorrectly saved to local storage, even when it was empty. This change ensures that composer data is only saved when there's actual content, improving system efficiency and preventing unnecessary storage usage. It's a minor fix that enhances the overall stability of the messaging feature.
Original PR description
Before this commit, composer content was saved in local storage even when the content is empty. This happens because while there's code to clear local storage entry on message post, the content was necessarily saved from debounced or when triggering an action that unmounts the composer of thread, like a change of active thread in discuss. This commit fixes the issue by checking that composer has some content, to determine whether the content must be saved in local storage or explicitly removed. Task-5905834 Forward-Port-Of: odoo/odoo#247030
This update fixes an issue where the number of employees flagged with invalid bank account warnings on the payroll dashboard was inaccurate. The fix ensures a more precise count by optimizing data retrieval and eliminating duplicate employee IDs. This improves the accuracy of payroll reporting and alerts.
Original PR description
> note: to be r+'ed till `master` (`saas~19.2`) because the way we compute warning has been changed in `master` description: - `warning_count` for `hr_payroll_dashboard_warning_employee_invalid_bank_account` is wrong when there are multiple versions for a single employee. steps to reproduce: - install `hr_payroll_account_iso20022` - open Payroll (note: have atleast one employee with multiple versions) - find "Employees With Invalid IBAN Bank Accounts" warning on the dashboard - note the count and click on it, the record count differs fix: - returned unique employee ids from `_get_invalid_iban_employee_ids` - also optimized the query in `_get_account_holder_employees_data` method. reasoning: we do not need bank account data from all the versions, because all the versions share same bank account data. task-5407494 Forward-Port-Of: odoo/enterprise#101678
This update resolves an issue where manual deletion of WhatsApp templates during production upgrades caused database migration blocks. By modifying the configuration to allow missing templates without errors, the upgrade process is now more robust and reliable. This ensures smoother and faster updates for our users.
Original PR description
Issue: ------ The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6)…
Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.
ValueError is raised:
```py
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.
Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.
tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)
Forward-Port-Of: odoo/enterprise#107477This update ensures that DateV identifiers are unique across all partners, including those that have been archived. Previously, the system allowed duplicate identifiers to be assigned, causing issues when partners were reactivated. This change corrects a technical detail to maintain data integrity.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
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
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 calculations to proceed without errors. This ensures users can accurately obtain 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 a bug that prevented users from generating reports by billing time when grouping by employee. The fix corrects an error in the data processing logic, ensuring the report accurately displays hours worked for each employee. This improves the accuracy and usability of the Timesheet analysis feature.
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-5910036
Forward-Port-Of: odoo/enterprise#106969This pull request addresses a critical error in the Belgian payroll calculation (l10n_be_hr_payroll) related to a specific tax code (274XX). The fix ensures accurate payroll processing and compliance with Belgian tax regulations. This update resolves a potential revenue impact for businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#107679
This update corrects a calculation error related to union and professional association fees within the Australian payroll system. The change ensures more accurate deductions are applied, aligning with updated Australian tax regulations and improving the reliability of payroll reporting for our Australian clients. This is a critical fix for accurate financial reporting.
Original PR description
. Update `Union and professional association fees` code in computations of `Fees and Deductions` rule task-5402666 Forward-Port-Of: odoo/enterprise#104911
This update fixes an error in the calculation of end-of-service benefits for employees in Saudi Arabia who resign after less than two years of service. Previously, the system incorrectly generated a negative value; now, it correctly calculates a zero value, aligning with Saudi regulations. The change improves accuracy and compliance for payroll processing.
Original PR description
purpose: In the saudi eos rule, if the employee resigned after working in the company less than 2 years, their end of service is being computed as a negative value when it should be 0 instead. - added the correct check for the case of employee resignation - moved the logic of the salary rules for EOS benefit and provision from python methods to the rule itself to be more clear for the user task-id: 5499646 Forward-Port-Of: odoo/enterprise#104466
This update ensures that all rates displayed on printed payslips are formatted to a maximum of 4 decimal places. This improves the clarity and professionalism of the payslip document, aligning with reporting standards. The change was implemented to address a formatting issue.
Original PR description
This commit improves the payslip display by limiting all rates to 4 decimals max on the printed pdf payslip. Task: 5709739 Forward-Port-Of: odoo/enterprise#104915
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