Daily updates from Odoo
Monday, January 26, 2026
225 changes
7 changes
Resolved issues and error corrections
This update fixes an issue where payment references on Italian invoices were incorrectly populated with a unique invoice number. Now, the payment reference field only uses the actual payment reference provided by the partner, simplifying automated payments and aligning with Italian tax regulations. This ensures accurate reconciliation of payments and improves the efficiency of financial processes.
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 Forward-Port-Of: odoo/odoo#245058
This update fixes a visual issue where product attributes with single values were displaying incorrectly with empty borders. The change refines the CSS selector to accurately hide attribute sections, ensuring a cleaner and more consistent user experience for product browsing. This improves the overall presentation of product information.
Original PR description
Before this commit, when a product attribute with display_type 'pills' has only one non-custom value, the parent li.variant_attribute is correctly hidden. However, the CSS :has() selector still matched the inner li.o_variant_pills, causing the attributes section to display with empty borders. This commit refines the selector to only match pills outside of variant_attribute elements (UOM pills). task-5852515 | Current (19.0) | After | |--------|--------| | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/64519161-e552-492f-b010-d1353b07f80a" /> | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/6022e371-18eb-4d2a-99d0-da3c94b291d0" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245175
This update ensures that LNA (a security feature) is consistently enabled for IoT devices across all Odoo POS systems, including kiosks. Previously, LNA was only active in the POS, creating a potential security gap. This change strengthens security and improves the overall performance of self-order IoT devices.
Original PR description
Before this commit, LNA was being used for IoT devices in the POS but not in the Kiosk when `point_of_sale.use_lna` was enabled. After this commit, LNA will also be enabled for IoT devices in the Kiosk. task-5874663 Forward-Port-Of: odoo/enterprise#105460
This update optimizes how category data is loaded on the website, resolving a previous issue that caused excessive memory usage. The change reduces the amount of data processed, leading to faster website loading times and a smoother user experience. This improves overall website performance.
Original PR description
Previously the function was fetching all the product template ids and looping over them for each product template. This triggered the prefetch_ids and prefetch fields for these products which would cause memory issues due to the bloat of the cache from the prefetcher. The current way is a read_group over the categories and check if category id exists or not. 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#239499
This update resolves a visual issue where Marketing blocks sometimes displayed incorrectly due to a problem in how the system converted table layouts. The fix ensures that tables render consistently, regardless of column sizes, preventing layout overflows and maintaining a professional appearance. This improves the overall user experience for users creating and viewing Marketing content.
Original PR description
This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1. The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout. Original issue:…
This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1. The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout. Original issue: Problem: The grid conversion logic only finalized a row when iterating through the last column in the input list. If a row reached exactly 12 grid spans while more columns remained (e.g., a `col-12` in the middle), the logic did not start a new row. As a result, remaining columns overflowed the current row visually. Cause: In a single row, if a column had a size 12 and was followed by another column of any size, it would crash because the algorithm did not reset the index to the start of the next row. Steps to reproduce: - Add a Marketing block. - Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" /> - Save. - Traceback. Solution: This more thorough fix properly handles all problematic aspects: - filter conflicting `col-x` instructions on a single element to keep only one size - ensure that a gridIndex of 12 does not cause a crash in the algo - properly add all effective `td` in a row in all circumstances (there where cases where the final row could be omitted) opw-5439481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245674
This update resolves an issue where Stripe-created expense records were being duplicated, causing confusion and errors in the system. By preventing the duplication, we ensure accurate expense tracking and streamline the process for employees. This improves data integrity and reduces potential reconciliation problems.
Original PR description
Prevent expenses automatically created by Stripe Issuing to be duplicated. Currently, it adds a lot of noise on customer dbs. The payment method is duplicated and it can lead to errors (eg: employee submit duplicatas instead of the original expenses. The automatic reconciliation doesn't happen afterwards) task-5246475 Forward-Port-Of: odoo/enterprise#102034
This update resolves issues where smart buttons on VoIP call forms were missing access groups, causing errors and incorrect numbers to display. The fix ensures these buttons function correctly, improving the user experience when initiating VoIP calls across various modules like CRM, Helpdesk, and Sales.
Original PR description
1. Tickek/Application smart buttons on voip.call form miss access groups. 2. In voip.call form, when clicking the application smart button, a singleton error will raise. 3. Incorrect numbers on smart button. Task-[5461729](https://www.odoo.com/odoo/5778/tasks/5461729) Forward-Port-Of: odoo/enterprise#103233
2 changes
Resolved issues and error corrections
This update corrects an error that prevented the creation of new contract templates in the US payroll module. The system was incorrectly enforcing a requirement for a filing status, which doesn't apply to templates. This change ensures that contract templates can now be created without causing errors, aligning with the correct process of determining filing status per employee.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566
This update corrects a technical issue preventing the proper validation of vendor bills in the ARCA system. The change ensures the required 'CodAutorizacion' field is correctly included in the data sent for verification, resolving errors related to missing information. This ensures accurate bill processing and compliance with Argentine regulations.
Original PR description
In this commit https://github.com/odoo/enterprise/pull/103370/changes#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318R289 where a refactor has been made, the field 'CodAutorizacion' was left as 'invCodAutorizacion' on _l10n_ar_edi_get_request_data_verify. This leads to errors when validating vendor bills on ARCA, since the organism could not find the required field. <img width="640" height="163" alt="image" src="https://github.com/user-attachments/assets/74a0cdc6-c007-474c-a67b-fd12d484838f" /> Forward-Port-Of: odoo/enterprise#105362
4 changes
Resolved issues and error corrections
This update fixes an issue where invoices were incorrectly using a progress number instead of the actual payment reference provided by the partner. Now, the payment reference field in Italian invoices will only be populated with the payment reference specified by the partner, ensuring accurate automated payments and reconciliation. This improves the process of receiving and managing payments from our Italian business partners.
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 Forward-Port-Of: odoo/odoo#245058
This update resolves a technical issue where the demo data for the Mexican payroll modules incorrectly set the company and partner names during installation. This prevented proper CFDI stamping of invoices and payment complements in the demo databases, ensuring a stable and functional demo environment.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases. Forward-Port-Of: odoo/enterprise#103870 Forward-Port-Of: odoo/enterprise#102558
This update resolves an issue where users would encounter an error when creating inherited views. The fix ensures that a validation error is triggered if the XPath configuration is incomplete, preventing the 'TypeError' and improving the user experience when customizing views.
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-pr
Forward-Port-Of: odoo/odoo#242203This update corrects a technical issue preventing the proper validation of vendor bills in Argentina (ARCA). The change ensures the required 'CodAutorizacion' field is correctly included in the data sent for verification, resolving a validation error that was impacting bill processing. This ensures accurate and timely processing of invoices.
Original PR description
In this commit https://github.com/odoo/enterprise/pull/103370/changes#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318R289 where a refactor has been made, the field 'CodAutorizacion' was left as 'invCodAutorizacion' on _l10n_ar_edi_get_request_data_verify. This leads to errors when validating vendor bills on ARCA, since the organism could not find the required field. <img width="640" height="163" alt="image" src="https://github.com/user-attachments/assets/74a0cdc6-c007-474c-a67b-fd12d484838f" /> Forward-Port-Of: odoo/enterprise#105362
2 changes
Resolved issues and error corrections
This update fixes a build error that occurred when displaying call status badges, preventing a crash in certain scenarios. The issue stemmed from an undefined 'id' value within the call status calculation logic. The fix ensures the correct record ID is used, regardless of whether the call is a real or virtual record, improving stability.
Original PR description
We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_. That error is raised in the class UserAgent ```js isInProgress(callId) { return (…
We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_.
That error is raised in the class UserAgent
```js
isInProgress(callId) {
return (
(this.mainSession?.call?.id === callId && this.mainSession.isInProgress) ||
(this.transferSession?.call?.id === callId && this.transferSession.isInProgress)
);
}
```
because both this.mainSession and callId are undefined in the test context.
### Root cause
In the class CallStatusBadgeField
```js
get statusLabel() {
const isInProgress = this.isInProgress(this.props.record.data.id);
const { direction, state } = this.props.record.data;
return Call.getStatus({ direction, isInProgress, state });
}
```
isInProgress is called with this.props.record.data.id but id can not be found in this.props.record.data so that when there
is no main voip session, the crash occurs.
Actually, for a real record, the id is given by this.props.record.resId and for a virtual record (a record not already created in db) the id is given by this.props.record.virtualId. Note that resId and virtualId are never both defined.
### Fix
Since a session is always linked to a read record, we pass to isInProgress the id given by this.props.record.resId but we have to protect us from the case were the record is virtual. Hence the use of the optional chaining operator in case the sessions would not be defined.
runbot-error-238415This update prevents the OCR from automatically updating a user's address information when processing QR-bills. Previously, the system would incorrectly overwrite existing partner details, causing confusion for users who receive QR-bills via email and forward them. This change ensures accurate address data is maintained, streamlining the billing process.
Original PR description
When the OCR detects that the document is a QR-bill, it will always overwrite the address information from the partner currently set on the record. We shouldn't do that if the partner wasn't created by the OCR. In the following scenario, it's pretty obvious why it is a bad idea: - User receives his QR-bills on his personnal email address. - He forwards it to the email alias set up for vendor bills. - A vendor bill is created with himself set as the supplier (already a bit annoying for him) - The OCR automatically analyses the document and updates the user's record with the address found in the QR-bill (really annoying). The same issue can arise if the user manually sets a supplier before sending the QR-bill for digitization. task-none Forward-Port-Of: odoo/enterprise#105343 Forward-Port-Of: odoo/enterprise#104902
6 changes
Resolved issues and error corrections
This update corrects a bug in how reordering rules utilize warehouse routes. Previously, leaving the 'warehouse_ids' field blank resulted in incorrect route assignments. This fix ensures that reordering rules correctly apply the 'Buy' route when using the default 'All Warehouses' placeholder, streamlining inventory management.
Original PR description
Update warehouse_ids placeholder ("All Warehouses") to a new placeholder that reflect its behavior.
### Steps to reproduce:
* Enable multi-Step Routes
* Inventory > Routes > Buy > Warehouses
* Select the checkbox but leave the field empty (placeholder says "All Warehouses")
### Steps to verify behavior:
* Leaving the warehouse_ids fields empty ("All Warehouses")
* Create a product tracked by quantity and add a vendor
* Create a Reordering Rule
-> It doesn't put the "Buy" route by default as it should
opw-5264571This update resolves a visual issue where the camera button displayed a warning message for channels that didn't require camera access. Now, the warning is only shown for channels configured for video-full-screen mode, streamlining the user experience and avoiding unnecessary alerts for typical voice calls.
Original PR description
Only channels that have cameraPermission of `prompt` should show the red and warning. If the permission is `denied` or `granted`, no badge should be shown. task-5263066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing manufacturing administrators from completing work orders. The fix adds necessary permissions to ensure the workflow functions correctly, allowing users with manufacturing access to successfully produce materials. This improves efficiency and eliminates a roadblock in the production process.
Original PR description
Steps to reproduce:
Create a user with admin access rights for Manufacturing and Quality only. Then, create a work center that has a cost per hour.
Create a product that has a BoM and create a MO then confirm it.
Add a work order that takes place in the created work center and has duration of 60 mins.
Using the created user, try to "Produce All".
Issue:
The user gets an access error when trying to "Produce All", eventhough they have manufacturing access rights.
Fix:
Add sudo access where the process fails to ensure that the workflow is as expected.
Note: a test will be added in anoher PR
opw-5480608This update fixes an issue where the inventory reason provided during barcode inventory counts wasn't being recorded. Now, when completing an inventory count via the Barcode app, the specified reason will be properly logged in the Moves History, ensuring accurate tracking of inventory adjustments. This improves the reliability of inventory reporting.
Original PR description
## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.
## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
- **The _Inventory Reason_ given in step 5 does not appear anywhere**
If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.
## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.
opw-5423934This pull request corrects a technical error where the Greek language code was incorrectly identified as 'gr'. It also adds missing translation modules for Cyprus and Greece, ensuring that Odoo supports these languages correctly. This improves the user experience for customers and partners who speak Greek.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245524 Forward-Port-Of: odoo/odoo#244684
This pull request corrects a critical issue where newly added modules to the Odoo Enterprise stable version were not included in the translation files (.weblate.json). This meant that the Greek language (el) was not supported for translation, preventing users from accessing the software in Greek. The update adds the necessary module definitions to the .weblate.json file, ensuring proper translation support.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#105355 Forward-Port-Of: odoo/enterprise#104890
4 changes
Resolved issues and error corrections
This update resolves a bug in the website editor that occurred when users manipulated selections in Chrome, leading to invalid offsets. The fix ensures that the selection plugin validates offsets before using data, preventing errors and maintaining editor stability. This improves the user experience and prevents unexpected behavior.
Original PR description
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing…
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing `anchorElement`, but has an invalid `offset`. **How to reproduce** This seems to be reproducible only on Chrome. 1. Enter in the website edit mode 2. Drop the `s_newsletter` snippet 3. Drop the `s_popup` snippet 4. Click on the popup, and delete it 5. Click on the blank space inside the `s_newsletter` snippet 6. Delete the `s_newsletter` snippet 7. The error occurs Notes: 1. Snippet different than `s_newsletter` can be used to reproduce the problem, as long as they contain a blank space. 2. It is important to make sure that the movement of the mouse pointer does not trigger any preview when going from step 5 to step 6. **Why the problem happens** On Chrome, clicking on a blank area can cause `document.getSelection()` to return a selection with a null `anchorNode.` When this happens, `SelectionPlugin.getSelectionData()` will use the already existing `activeSelection` if `activeSelection.anchorNode` is still connected. Before this commit, this method only checked that `anchorNode` was connected, without validating offsets. This leads to the following edge case: 1. The user removes the `s_popup` 2. At this point, `document.getSelection()` would point to the `s_newsletter` snippet, so if the user just deletes the snippet nothing bad would happen. But instead, if: 3. The user clicks on a blank area in `s_newsletter`, `document.getSelection()` will now return a null `anchorNode` 4. The user delete the `s_newsletter` snippet, and `SelectionPlugin.getSelectionData()` is called by an handler after the deletion 5. At this point: `document.getSelection()` has a null `anchorNode`, so the method will check if `activeSelection.anchorNode` is still connected, WITHOUT validating the offsets. 6. Since `anchorNode` is still connected, this selection will be used, and an error will be triggered shortly after, because the offset is too high (pointing to `s_popup` which does not exist anymore). **Fix** After this commit, when `SelectionPlugin.getSelectionData()` checks that `activeSelection.anchorNode` is still connected it also checks that the offsets are valid (meaning that they are smaller than the number of nodes). task-5430500
This update resolves a bug that caused the follow-up report to crash when users unfolded partner lines while prefix groups were enabled. The fix corrects an error in how the report processed data, ensuring stability and preventing unexpected errors for users.
Original PR description
When prefix groups were enabled, and a prefix group line had been unfolded, the report crashed when trying to unfold the partner. This happened because res_ids_map is computed for each of the unfolded lines, including the prefix groups one, which then had no 'res.partner' key, causing a key error.
This update resolves a technical issue that prevented users from adding attachments when sending emails to large groups of contacts (501+). The fix addresses a limitation in how the system handles data volume, ensuring the email composer function works reliably with larger contact lists. This improves the user experience for sending bulk emails.
Original PR description
Steps to reproduce: 1. Install 'contact' 2. Create 501+ contacts (e.g. by duplicating existing one) 3. Select all contacts in list view and click Send Email (from Action menu) 4. Try to add an attachment Issue: - A traceback is raised in the mail composer: `SyntaxError: Unexpected end of JSON input` Cause: `res_ids` is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of active_ids exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails. see: https://github.com/odoo/odoo/blob/abc8417413faf598fb83106de4328571d71888aa/addons/mail/wizard/mail_compose_message.py#L400 Solution: - Fallback to context.active_ids when res_ids is not available opw-5351374
This update resolves an issue where users without superuser privileges could encounter access errors when generating global invoices in the Mexican CFDI module. The fix ensures proper access control and cache management for the ir.sequence used in global invoice creation, preventing errors and intermittent failures.
Original PR description
**PROBLEM** 1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model. 2. There is an issue with the cache of the field…
**PROBLEM** 1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model. 2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance). **STEP TO REPRODUCE** 1. Create 1 invoice with CFDI to public checked. 2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it. 4. A access error may appear (depending on cache value). **CAUSE** 1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege. 2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered. opw-5472552