Monday, April 13, 2026
9 changes · saas-19.1
Resolved issues and error corrections
This update fixes an issue where sales emails were displaying incorrect invoice amounts (showing $0.00) due to a problem with how the system calculates invoice data in draft mode. The fix ensures that the correct invoice amount is sent to the salesperson, improving the accuracy of sales notifications.
Original PR description
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue:…
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue: --- - In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00. Root cause: --- - Here at [1], the record name is False because the invoice is still in draft state. - In [18], _sync_invoice sets amount_currency = line.balance for new lines, but balance is precomputed as 0 before the INSERT because _compute_balance returns 0 for invoice lines. In [17] it read price_subtotal directly, which is always correct. - In 17.0 the same mail fires at the same moment, but _sync_invoice had already set balance = −295 and amount_currency = −295 from price_subtotal, so the email reads the correct 295.00. Solution: --- - Use record.display_name instead of record.name, as display_name is always present regardless of the record state. - Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices. [1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478 [18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610 [17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585 Before: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" /> After: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" /> opw-6023827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258375 Forward-Port-Of: odoo/odoo#254862
This update resolves a bug where KPI cards (Billable Hours, etc.) displayed incorrect data when filters were applied in the Timesheets dashboard. The issue stemmed from a hardcoded filter that prevented the cards from reflecting the correct timesheet data based on the selected filter criteria. The fix removes this hardcoded filter, ensuring accurate KPI calculations across all filters.
Original PR description
Steps to reproduce: - 1. Go to the dashboard app > Timesheets. 2. Apply any global filter. Issue: - The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user. Cause: - The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data. Fix: - The hardcoded `['user_id', '=', 2]` condition has been removed. task-4782213 Forward-Port-Of: odoo/odoo#258412 Forward-Port-Of: odoo/odoo#224810
This update fixes an issue where product names on invoices weren't always displayed in the correct language when using child contacts. The change ensures that invoice line labels are translated based on the language of the selected invoice contact, regardless of the parent contact's language. This improves the accuracy and consistency of invoices for international customers.
Original PR description
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not…
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language. ### Steps to reproduce the issue: 1. Activate at least 2 languages (X and Y) 2. Create a product and set the translation for that product in the activated languages 3. Create a Contact with the language X 4. Create a child contact (invoice adress type) for that contact with language Y 5. Create a new invoice setting the customer as the child contact 6. Add the product you created 7. See the label is displayed in the language of the parent contact ### Cause of the issue: The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language. ### Reason to introduce the fix: To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner. opw-5955875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258458 Forward-Port-Of: odoo/odoo#254833
This update resolves an issue where Google Ads cookies were not being blocked effectively within Odoo's website configuration. The fix addresses a technical limitation in how the system handles script insertion, ensuring that Google Ads tracking scripts are properly blocked as intended. This improves user privacy and aligns with data protection regulations.
Original PR description
# How to reproduce - Go to Website app > Configuration > Websites > Select your website > Custom Code - In the "Custom <head> code" section add the script given at the last section of this PR (with a…
# How to reproduce
- Go to Website app > Configuration > Websites > Select your website > Custom Code
- In the "Custom <head> code" section add the script given at the last section of this PR (with a proper TAG_ID)
- Go to a new Incognito Tab and go to the Website front page
- Refuse the optionnal cookies
- Open the browser's console and go to Application > Storage > Cookies
# The problem
The Google Ads cookies are present (prefixed by _ga)
# Why
This commit introduced the blocking of 3rd party cookies :
https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1
It works by doing 2 things, but none of them works in our case :
First, it edits the view rendering to replace the `src` value with "about:blank" for watched
tags, but this does not work for `website.custom_code_head` (our case) and `website.custom_code_footer` because it is t-out'ed which bypasses this code :
https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-a27798e1ecfe96676dd48766e0aa9d12fbc0784e328ac1a3ec82b1ce199fc58bR121-R166
Second, it adds a script in the head of the page that patches the setter for the `src`
property of the script tags. If the value that we try to set is a URL to a site that we
block and the cookies are not yet accepted, we replace the `src` value with "about:blank".
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/website/static/src/js/content/cookie_watcher.js#L8
This sadly does not work for parser-inserted scripts that are directly parsed from the HTML.
Indeed, they do not use the setter of `HTMLScriptElement.prototype`.
It is possible to verify this by adding a `MutationObserver` that checks for new script
insertions and adding breakpoints in this observer and in the patched setter. For the
first scripts of the page, the breakpoint in `MutationObserver`is triggerred while the
one in the setter is not.
# Proposed solution
We move this code into new helper functions :
https://github.com/odoo/odoo/blob/95dc247ecd773044ef9c9f1512c7d86d73df836c/addons/website/models/ir_qweb.py#L130-L135
And use these helper functions to create another helper function that allows us to check
an html field for trackers that would need to be removed
We then use this helper function on `website.custom_code_head` and `website.custom_code_footer`
# The script
```html
<!-- Google tag (gtag.js) -->
<script async src="[https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script](https://www.googletagmanager.com/gtag/js?id=TAG_ID%22%3E%3C/script)>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'TAG_ID');
</script>
```
Source : https://developers.google.com/tag-platform/gtagjs
opw-6007810
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256808This update resolves an issue where reopening a Point of Sale (PoS) after an archived combo product caused an error. The change ensures that archived combo products no longer trigger this error, improving PoS stability and preventing potential disruptions to sales operations. This fix maintains data integrity and a smoother user experience.
Original PR description
Before this commit, when a combo product was archived, and the PoS was reopened, an error was raised. opw-5952006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a bug where changing a child company's ZATCA API mode would inadvertently reset and unboard the parent company's related sales journal. The fix ensures that journal resets only apply to the company being modified, improving data stability and preventing unexpected disruptions.
Original PR description
**Steps to reproduce:** * Install `l10n_sa_edi` module. * Create a parent company and a child company, both with the same VAT number. * Onboard the parent company's Sales journal with ZATCA. *…
**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.
**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.
**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.
**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.
opw-6099340
Forward-Port-Of: odoo/odoo#258750
Forward-Port-Of: odoo/odoo#258006This update fixes an issue where kit products were incorrectly calculating their total cost in POS orders. The fix ensures that component quantities are accurately converted between UoMs, resulting in correct pricing and inventory calculations for kits containing components with different unit measurements. This improves the accuracy of sales transactions.
Original PR description
When selling a kit that use component with different UoM than the base component UoM, no conversion was done to compute the correct qty of component used in the kit, which lead to a wrong total cost on the pos order. Steps to reproduce: ------------------- * Create a component A with a cost of 12000€ * Set the UoM for the component A to "dozen" * Create a kit product K with a BoM the use 1 "unit" of A * At this point the cost of the kit K should be 1000€ * Now make a PoS order for 1 K and validate it > Observation: The total cost of the kit is not correctly computed, it should be 1000€ Why the fix: ------------ When computing the qty_per_kit, we were not doing the conversion between the product UoM and the BoM line UoM. opw-6039809 Forward-Port-Of: odoo/odoo#257068
This update optimizes a key process that calculates cumulative balances, which significantly reduces memory consumption and prevents server crashes when handling large volumes of accounting data. By focusing the query on relevant records, the change dramatically improves performance and stability, especially with extensive transaction histories.
Original PR description
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move…
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move lines, the result returned by fetchall() hits the memory limit and the server crashes. We propose to encapsulate the original query to only return the result for the account move lines present in self. Benchmarks --------------- The following benchmarks were generated with a customization of the account.move.line list view to display the cumulated_balance field. Memory usage during the self.env.cr.execute and the dictionary population: | Operation | Before the fix | After the fix | |---------------|----------------|---------------| | populate dict | 1.5 GB | 17.1 MB | | execute query | 430 MB | 8.3 MB | 100 000 lines were displayed at the same time to get a significant size. So the number of records in self is more than 7 000 000 without the fix and 100 000 with the fix. Time spent in the _compute_cumulated_balance method: | No of AML | Before the fix | After the fix | |-----------|----------------|---------------| | 7 000 000 | 10.4 s | 6.8 s | opw-6053720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256658 Forward-Port-Of: odoo/odoo#255780
This update fixes a bug where accrual calculations weren't working correctly for leave allocations using modes other than 'By Employee'. The fix ensures that allocation durations are automatically calculated accurately, regardless of the chosen allocation mode, improving the reliability of leave tracking. This impacts all users who utilize the holiday accrual functionality.
Original PR description
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the…
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the allocation and date from 1st Jan - Notice the Allocation number of days doesn't get automatically calculated ### Cause: This is happening because when trying to process the accrual plan we won't have any records in the field employee_id https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893 And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'. https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270 ### Fix: If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null P.S. In the forward port we will have to introduce another fix for the multi allocation wizard opw-5888023 Forward-Port-Of: odoo/odoo#258520 Forward-Port-Of: odoo/odoo#247091