Daily updates from Odoo
Friday, January 23, 2026
17 changes · 18.0
Enhancements to existing features
This update enhances the Invoicing & Banks role's access to critical accounting reports like General Ledger and Profit & Loss. Previously restricted, the role now has read-only access, improving reporting capabilities and providing better insights for financial analysis.
Original PR description
Before: The Invoicing & Banks role did not have access to important accounting reports such as General Ledger, Trial Balance, and Profit & Loss. After: The role now inherits read-only privileges, allowing access to all essential accounting reports. Task-5418541
This update switches the directory lookup for Nemhandel from a discontinued CNAME method to a more reliable IAP lookup. This ensures continued functionality with Nemhandel, which is a key partner for Danish businesses. The update also standardizes a component for improved consistency.
Original PR description
We need to switch the lookup on the directory to NAPTR, as the CNAME one is discontinued on January. We now go through IAP to do the lookup. It's also ensuring _check_document_type_support has always the same format as the super() coming from Peppol. task-4486039 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
Resolved issues and error corrections
This update fixes a calculation error in the VAT sales reports for Vietnam (l10n_vn). Previously, 8% VAT transactions were being excluded from the total sales base, leading to inaccurate reporting. This change adds a missing tag to the report formula, ensuring accurate calculation of the taxable sales base.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154
This update fixes a bug that prevented the dashboard from accurately counting high-priority maintenance requests. The fix ensures that critical requests are correctly identified and displayed, improving visibility and enabling users to prioritize maintenance effectively. This improves the reliability of the maintenance module.
Original PR description
Issue before this commit: ========================= The high-priority maintenance request count (todo_request_count_high_priority) was not calculated correctly. Steps to Reproduce:…
Issue before this commit: ========================= The high-priority maintenance request count (todo_request_count_high_priority) was not calculated correctly. Steps to Reproduce: ========================= - Install the maintenance module. - Create a maintenance request and set the Priority to High (3-starred) in the form view. - Open the dashboard. - Observe that the high-priority request count is not displayed. - The count always remains 0, even when high-priority requests exist. Cause of the issue: ========================= In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. The priority field is defined as a Selection field, but while computing the count, the comparison was done against an integer(3, not '3') instead of the actual string value. Since the stored value is '3' (string), the condition is always evaluated to False, resulting in a count of 0. With This Commit: ========================= Ensure that high-priority maintenance requests are correctly counted and displayed on the dashboard when they exist. This provides better visibility of critical requests and helps users prioritise maintenance work effectively. Forward-Port-Of: odoo/odoo#244987
This update fixes an issue where DHL labels were always delivered in PDF format, regardless of the user's selection. It also ensures that DHL error messages are now displayed to the user, providing clearer information about delivery issues. This improves the overall DHL integration experience.
Original PR description
This PR contains fixes for 2 issues: 1. Changing the label format in the Delivery Method has no effect, labels are always received in PDF format. 2. Some DHL errors (eg "Invalid Credentials") do not get propagated to the user, they get a "Validation Error" prompt with an empty message body. opw-5423897
This update resolves an issue preventing point of sale functionality within the l10n_ar_edi module for Arabic VAT. The fix ensures proper integration with Arabic tax regulations, allowing businesses to accurately process sales transactions. This improves compliance and usability for users in the Arabic-speaking market.
Original PR description
Tarea: 62909 Forward-Port-Of: odoo/enterprise#105104
This update resolves an issue where leaves taken after the carryover date were incorrectly included in accrual calculations. The fix ensures that only leaves up to the carryover date are considered, accurately reflecting available leave balances. This improves the reliability of leave tracking for employees.
Original PR description
### Issue: During carryover of accrual days, the leaves taken after the carryover date are taken into account in the computation when they shouldn't be. ### Steps to reproduce: - From a date in…
### Issue:
During carryover of accrual days, the leaves taken after the carryover date are taken into account in the computation when they shouldn't be.
### Steps to reproduce:
- From a date in January
- Create an Accrual Plan
- Accrued Gain Time: At the start of the accrual period
- Carry-Over Time: Other
- Carry-Over Date: 1st of February
- New Milestone:
- 15 days monthly on the 1st of the month
- Carry over with a maximum of 5 days
- Create new allocation for a new employee
- Accrual allocation with the new accrual plan
- Start on 01/01/2026
- Validate
- Create a new leave for this employee from 16/02/2026 to 20/02/2026
- On the employee dashboard change the "Balance at the" to 17/02/2026
- The amount of days on this day is 20
- It should be 15 (5 days from the carry-over + 15 days from the allocation - 5 days for the leave)
### Cause:
During the carryover, the code subtracts the leaves taken from the number of available days before checking if it's greater than the carryover value. The purpose of this subtraction is to not consider available days that will be deducted before the carryover because leaves were taken before the carryover.
https://github.com/odoo/odoo/blob/f4e4f74074e1fa4aad5cbff45c62054dc4371b07/addons/hr_holidays/models/hr_leave_allocation.py#L516-L525
The issue is that the variable `leaves_taken` includes all leaves between today and the balance date selected, including leaves after the carryover.
So what happens exactly in the steps is:
- `allocation.number_of_days - leaves_taken` = 10 (15 - 5)
- `min(postpone_max_days, allocated_days_left)` = 5 (min(5, 10))
- `min(allocation.number_of_days, allocation_max_days) + leaves_taken` = 10 (min(15, 5) + 5)
### Solution:
We need to get the number of leave days before the carryover date. For this, we call `_get_consumed_leaves()` with `carryover_date - relativedelta(days=1)` as a target date.
opw-5386252This update resolves an issue where the system incorrectly attempted to calculate self-billing eligibility when using the oioubl_21 eInvoice format. The fix ensures the system uses the correct method for determining export eligibility, preventing UI access failures and ensuring accurate billing processes. This impacts users configuring partners with the oioubl_21 format.
Original PR description
While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the EDI builder. However, this method is only implemented for the…
While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the EDI builder. However, this method is only implemented for the ```account.edi.xml.ubl_bis3``` builder and is not available on other EDI formats such as ```oioubl_21```,
```oioubl_201```.
When a partner is configured to use the ```oioubl_21``` eInvoice format,
this resulted in an ```AttributeError``` during record reads, causing menu crawl and
UI access failures (e.g., Accounting → Vendors → Bills/Refunds).
```sql
Traceback (most recent call last):
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 13, in _compute_can_send_as_self_invoice
if move._is_exportable_as_self_invoice():
File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 31, in _is_exportable_as_self_invoice
and edi_builder._can_export_selfbilling()
AttributeError: 'account.edi.xml.oioubl_21' object has no attribute '_can_export_selfbilling'
```
**Steps to reproduce**
1) Install l10n_dk_nemhandel module
2) Set the eInvoice format to oioubl_21 for the partner
3) Create Bill for that partner
3) Confirm the bill
OPW - 5863081
UPG - 3846482
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a memory error that occurred when loading website pages, specifically within the page manager. The fix involved optimizing how the system retrieves page information, reducing the amount of data loaded and improving overall performance. This change enhances the speed and stability of the website experience.
Original PR description
Before this commit, loading the list view of the website pages invoked a method called `_get_most_specific_pages`. This method caused a memory error due to loading the field called `key` for the pages being fetched. This field was related to a field called `key` in the model `ir.ui.view`, so a cache miss in the recordset causes a `SELECT *` query for the ir.ui.view potentially causing a memory error if the size of these views are big. A solution for this is to force the ORM to load only the `key` field by invoking **search_fetch** on the `ir.ui.view` model instead. In order to improve the retrieval of a given page key count, we now use a Counter map (=> constant time instead of linear search). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where 0% NT/EXEMPT taxes were incorrectly filtered during downpayment creation in the Arabic localization (l10n_ar). Previously, these taxes weren't properly included, leading to incorrect calculations. This change ensures accurate tax reporting for downpayments, aligning with Arabic tax regulations.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245252
This update resolves an issue where pricelist rules weren't being applied to product variants when editing in 'expanded' mode. Previously, rules only applied to the product's template. Now, when a pricelist rule is edited for a variant, it correctly applies the selected price, ensuring accurate pricing in sales quotations.
Original PR description
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is…
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is missing on the `product.pricelist.item` form view. Current behavior before PR: - Install `sale_management` - Enable "Pricelist" setting - Go to Sales - Products - Pricelists and create a new "Sample" Pricelist. - Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" /> - Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" /> - Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" /> - Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" /> - Same thing for second rule <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" /> - Create a new sale quotation with pricelist set to our "Sample" - Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" /> - Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" /> - Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" /> Desired behavior after PR is merged: - Each variant must have its own price. - The added test simply edit the pricelist item using its own form. - The `applied_on` field is added to the pricelist item form to ensure that its value is saved. - If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column. _Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?). But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`. _Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` .... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where errors during tax processing in HR payroll could silently fail. It now provides clearer warnings for unsuccessful tax calculations, ensuring accurate reporting and preventing data discrepancies. The changes also improve compatibility with UBL tax extension features.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where payment references on Italian invoices were incorrectly populated with a unique invoice number. Now, the payment reference field will only be filled with the actual payment reference provided by the partner, simplifying automated payments and aligning with Italian tax regulations. This ensures accurate reconciliation of payments.
Original PR description
Description of the issue/feature this PR addresses: The payment_reference field in invoices was being filled with a wrong field from the imported XML, progressivoinvio is the progressive number of invoices sent by the partner's system, not a partner's requested payment reference. Current behavior before PR: On import, payment_reference was being filled with ProgressivoInvio, making automated payments out to partners harder. Desired behavior after PR is merged: payment_reference is only being filled if partner specifies a payment reference in the EDI, avoiding confusion. --- 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 Fedex rate selection process was failing when the requested currency didn't match the Fedex account settings. The fix ensures the rate request uses 'PREFERRED' as a prefix, aligning with available Fedex rate types and preventing errors calculating shipping costs.
Original PR description
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the…
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means `d['rateType'] == rating_result['actualRateType']` is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`. Solution ----- In the request we send, we hardcode `'rateRequestType': ['PREFERRED']` so we can look for a match using 'PREFERRED' as a prefix of `rateType`. The Fedex API lists all possible values of the enum `rateType` https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html <details> <summary>Enum values as per the API</summary> "enum": [ "INCENTIVE", "NEGOTIATED", "PAYOR_ACCOUNT_PACKAGE", "PAYOR_ACCOUNT_SHIPMENT", "PAYOR_CUSTOM_PACKAGE", "PAYOR_CUSTOM_SHIPMENT", "PAYOR_LIST_PACKAGE", "PAYOR_LIST_SHIPMENT", "PAYOR_RETAIL_PACKAGE", "PAYOR_RETAIL_SHIPMENT", "PREFERRED_ACCOUNT_PACKAGE", "PREFERRED_ACCOUNT_SHIPMENT", "PREFERRED_CUSTOM_PACKAGE", "PREFERRED_CUSTOM_SHIPMENT", "PREFERRED_INCENTIVE", "PREFERRED_LIST_PACKAGE", "PREFERRED_LIST_SHIPMENT", "PREFERRED_NEGOTIATED", "PREFERRED_RETAIL_PACKAGE", "PREFERRED_RETAIL_SHIPMENT", "RATED_ACCOUNT_PACKAGE", "RATED_ACCOUNT_SHIPMENT", "RATED_CUSTOM_PACKAGE", "RATED_CUSTOM_SHIPMENT", "RATED_LIST_PACKAGE", "RATED_LIST_SHIPMENT", "RATED_RETAIL_PACKAGE", "RATED_RETAIL_SHIPMENT", "UNKNOWN" ], </details> There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe. ----- Ticket: opw-5482949
This update resolves an issue that previously caused errors when users created inherited views in Odoo. The fix ensures that a validation error is triggered if the XPath syntax is incomplete, preventing the application from crashing and improving user experience. This change enhances the stability of the user interface customization features.
Original PR description
Currently, an error occurs when a user creates an inherited view. **Steps to Reproduce:** - Go to `Settings > Technical > User Interface > Views`. - Create a new view by entering `name` and selecting…
Currently, an error occurs when a user creates an inherited view.
**Steps to Reproduce:**
- Go to `Settings > Technical > User Interface > Views`.
- Create a new view by entering `name` and selecting any `inherited view`.
- In the `Architecture`, enter the below code:
```
<xpath position="replace">
<field name="name"/>
</xpath>
```
- Now save the view.
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
Cause:
As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.
This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.
[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145
[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76
[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78
[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384
sentry-7161414430
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the UBL export incorrectly interpreted a '/' as a VAT indicator. The change ensures that when a partner doesn't have VAT, the mandatory CompanyID is correctly included, aligning with PEPPOL standards. This improves the accuracy of electronic invoice generation for simplified documents.
Original PR description
To signify that you know a partner does not have vat, we advise using '/'. But we should take care of that in the UBL export, to not consider it a real vat Also, in the cases where we don't have the vat, the CompanyID is supposed to be mandatory. https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-TaxRepresentativeParty/cac-PartyTaxScheme/ So, remove the whole PartyTaxScheme if vat is not present. Zatca does not override that rule (except enforcing that seller must have vat, which raises a constraint), so we modify the tests for the simplified documents. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238499
This update corrects a bug where a delivery order's picking state would incorrectly update the serial number of a product. The fix ensures that the original serial number is maintained when adding new moves to a 'ready' picking, preventing data discrepancies and improving inventory accuracy. This resolves an issue impacting product traceability.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state.