Daily updates from Odoo
Tuesday, September 2, 2025
19 changes · 18.0
Resolved issues and error corrections
The organization chart now picks the right employee and manager information when shown from user, employee, or public employee forms. This prevents incorrect chart details from appearing and improves reliability for HR users viewing employee relationships.
Original PR description
This update ensures that the correct employee and parent IDs are fetched depending on whether the widget is displayed in a `res.users`, `hr.employee` or `hr.employee.public` form. The `onWillStart` was removed since `useRecordObserver` is triggered in `onWillStart`, and both used to have the same logic. task-5039701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224456
This fixes an issue where the Settings page could fail when a section header did not have a label configured. Headers can now be displayed without a label, preventing avoidable errors for users and administrators.
Original PR description
Before this commit, an error would occur if a header setting did not contain an attribute string or field. This was because the code tried to infer the label. However, the label should be optional. 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#225080
Refunds for standard-cost purchased products now correctly reverse the original cost accounting entries. This prevents credit notes from overstating balances and keeps inventory and purchase accounting aligned after returns.
Original PR description
When users refund a real-time/standard cost product purchase, cogs lines are not reversed
**Steps to reproduce**
1. Create a product category [CATEG]:
- Costing Method: Standard
- Inventory Valuation: Automated
- Price Difference Account: 101403 Outstanding Payments (any account will do)
2. Create a product [PROD]
- Type: Storable
- Category: [CATEG]
3. Create and confirm a PO with [PROD]
4. Process the receipt
5. Create the bill
6. Issue the return and process it
7. Create the refund
**Issue**
The credit note cogs lines (price difference account and stock interim) have the same balance of the bill
However the credit note should mirror the original BILL with the opposite accounting entries.
This seems to occur because, when generating cogs lines, we take into account that the current move is a refund but then we use the move direction sign to alter the balance sign
opw-4845342
Forward-Port-Of: odoo/odoo#221198Fixed a mobile issue where opening the Employee form and tapping the gear icon could cause the page to crash. This makes the employee screen more reliable for users working from phones or tablets.
Original PR description
Opening the Employee form on mobile and tapping the gear icon could crash because `PresenceActionItems` was undefined. Initialize it and guard the template. task-5055564
The Secure Entries wizard now uses far less memory and loads much faster when many accounting entries are waiting to be secured. This prevents the wizard from crashing on large databases and helps accounting teams complete compliance-related entry security work without delays.
Original PR description
Description ----------- On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be…
Description
-----------
On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be hashed.
This can lead to the processing of a large number of moves when opening the Secure Entries wizard, more specifically:
```
-> `_compute_warnings`
-> `_compute_hash_date`
-> `_compute_max_hash_date`
-> `_get_chains_to_hash`
```
While manipulating this large recordset, the ORM prefetcher will read *all* fields on the model upon the first cache miss, which usually are a lot, and some of them are quite large (label type fields).
This commit refactors the code to avoid any cache miss by fetching only what is necessary. This is achieved by:
- Use of a `_read_group` instead of 2 subsequent `groupby`
- Delegate `max` and `min` lookup to the database
- Explicitly fetch the fields that are going to be read
- Avoid the linear search into the associated statement lines for unreconciled moves
- Introduce a context key `chain_info_warnings` to skip the warnings computation of `_get_chain_info`, as it's unused for the context of `_compute_max_hash_date`.
Benchmark
---------
On a database with over 1.3M `account.move` that are pending hashing, opening the wizard for the Secure Entries took:
| | Before* | After | Improvement |
|--------------|---------|---------|-------------|
| Memory | 6.8 GiB | 700 MiB | 9.9x |
| Query Count | 26.7k | 18.5k | 1.4x |
| Timing SQL | 41.2s | 18s | 2.3x |
| Timing PY | 7.29min | 14s | 31.2x |
| Timing Total | 7.98min | 32s | 15x |
\* - benchmark was taken with unlimited memory, the request takes more than 2 GiB -> OOM killed and never completes
Reference
---------
opw-5014345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix makes Indonesian e-Faktur Coretax product codes easier to find when editing product templates. Users can now search by product code or description, reducing confusion and speeding up tax-related product setup.
Original PR description
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or…
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal. so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string Current behavior before PR: <img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" /> <img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" /> <img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" /> Desired behavior after PR is merged: <img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" /> <img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" /> <img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222588 Forward-Port-Of: odoo/odoo#221858
Italian electronic invoice exports now omit payment information where it should not appear and place supplier invoice references in the correct section. This helps companies using Italy localization produce XML files that better match official tax authority requirements and reduces rejection or compliance risk.
Original PR description
1- `<DatiPagamento>` shouldn't be included in autofatture. 2- The supplier's original invoice number and date must be placed in the `<DatiFattureCollegate>`, using `<IdDocumento>` and `<DataDocumento>` fields respectively. Currently `<IdDocumento>` is added to the `<DatiOrdineAcquisto>`. A fix is made to add `<IdDocumento>` and `<DataDocumento>` to `<DatiFattureCollegate>`. references: https://www.agenziaentrate.gov.it/portale/documents/d/guest/guida_compilazione-fe-esterometro-v1-10_aprile_2025 opw-4810326
Incoming invoice emails sent to a company journal alias are no longer rejected just because the sender's user account cannot access that company. This helps ensure supplier invoices and similar documents are created reliably from email, matching the behavior for unknown senders.
Original PR description
To reproduce the bug: 1- Create a DB with two companies and accounting app 2- Create a user and allow it to access company 2 3- Send a email using the user email to alias from purchase journal alias of company 2 4- The email will be rejected 5- Send a email using a random email address to alias. 6- The email will be accepted and an account.move is created. In a normal flow, when a user associated to the email not exists, the user_id is set to odoobot, otherwise, the user accosiated to the email. In the buggy flow the bug happens because `_compute_company_id` in account_move model, will set `company_id` to empty when user has no access to the company, as a result the `account_move` will fail. opw-4853027 Forward-Port-Of: odoo/odoo#217322
Point of Sale orders that skip the receipt screen are now still sent to the preparation display. This prevents kitchen or preparation teams from missing invoiced orders when automatic receipt printing is enabled.
Original PR description
Steps to reproduce: ------------------- - Enable "Automatic Receipt Printing" - Make a PoS order, with "Invoiced" checked, and validate it -> Observe that the command is not sent to the preparation display. Reason: ------- When skipping the receipt screen, we don't call `checkPreparationStateAndSentOrderInPreparation`, which then doesn't send the new command to the preparation display. The fix: -------- Backporting 26425ab712a3269beec98722 but without any refactoring. opw-5000406
Refreshing the Thank You page of a live survey session no longer causes an error if a survey question was deleted in another tab. This keeps completed live sessions stable for participants and avoids a disruptive crash in the survey flow.
Original PR description
Currently, an error occurs when refreshing a live session's `Thank You` page after deleting a survey question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, `add a question` and click on `Create Live Session`. - Complete the survey and leave it on the `Thank You` page. - Switch back to the `first tab`, delete the question and `save` the survey. - Return to the `Thank You` tab and `refresh` the page. **Error:** `IndexError: list index out of range` **Root Cause:** At [1], the controller assumes the question exists and tries to access `index [0]`, but when the question has been deleted, the recordset is empty, causing an `error`. [1] https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/survey/controllers/survey_session_manage.py#L236 This commit prevents a crash when refreshing a live session if the question was deleted. sentry-6736648824 Forward-Port-Of: odoo/odoo#218312
Saving a view with an unsupported XML tag now shows a proper validation message instead of an unexpected system error. This helps administrators understand the issue and correct the view setup without disruption.
Original PR description
When a user tries to save a view with an invalid tag, an error occurs. **Steps to produce:-** 1. Go to Settings > Technical > User Interface > Views. 2. Click on New. 3. Add the view name. In architecture -> add `<template></template>`. 4. Try to save the changes. **Error:-** `ValueError:Wrong value for ir.ui.view.type: 'template'`. **Root cause:-** - The view type in `ir.ui.view` is automatically inferred from the `root tag` of the XML defined in the `arch` field. - In this case, `<template>` becomes the inferred view type, which is not part of the valid selections for the type field in the model `ir.ui.view`. **Solution:-** - Before calling `super().create(vals_list)`, add a validation check to ensure `values['type']` is in the allowed types. If not, raise a ValidationError. sentry-6561028171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now retry deleting items in related lists after cancelling a confirmation prompt. The delete button is briefly disabled to prevent accidental double-clicks, then automatically becomes available again.
Original PR description
PR [1] aimed at fixing a double-click issue with the delete button in x2many lists. In standard views, it works fine. However, there are customizations (e.g. project sub tasks, product attributes...) that add a confirmation step before actually removing the row. If the user cancelled the deletion, clicking on the delete icon of that row afterwards had no effect at all. This commit fixes the issue by re-enabling the button after 500ms, thus only preventing double clicks. [1] https://github.com/odoo/odoo/pull/173481 opw~5019621 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
Saving the document layout no longer tries to update a company bank account when the displayed account number has not changed. This prevents unnecessary errors for trusted bank accounts while keeping the same visible settings for users.
Original PR description
Description of the issue/feature this PR addresses: The document layout wizard (base.document.layout) attempts to write the partner’s bank account number even if it has not been changed. If the first bank account is marked as trusted, Odoo blocks the write and raises an error. This PR prevents that error by only writing the account number when it has actually changed. Current behavior before PR: - The wizard shows the account_number field. - On saving, _inverse_account_number always writes to the first partner bank account. - Trusted bank accounts trigger an error: “You cannot change the account number or partner of a trusted bank account.” Desired behavior after PR is merged: - The wizard still shows the account_number field. - On saving, _inverse_account_number only writes if the value changed. - Trusted bank accounts that are not modified do not cause an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Analytic plans are now processed from parent to child during project app installation. This prevents setup failures when a plan depends on a parent plan that has not yet been prepared, improving reliability for companies using hierarchical analytic plans.
Original PR description
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can…
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"` This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields. The fix is ordering the recordset by `parent_path`. Steps to reproduce: 1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records. 2. Create a first plan. 3. Create a second plan and set the first plan as its parent. 4. Install the `project` app (triggers `_sync_plan_column`). 5. Observe the crash due to an unknown related field. OPW-5006494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where barcode transfers could incorrectly merge lot-tracked kit component lines with the same component added separately. This prevents unnecessary backorders when warehouse staff scan and validate the correct quantities.
Original PR description
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating **Steps to reproduce:** - create two products tracked by lot (comp A and comp B) - set an on hand quantity for both - create a storable product (final product) and create a BOM - in the BOM add comp A and comp B - create an internal transfer for 1 final product and 1 comp B - click on "mark as todo" - open this transfer in barcode, we see that the two lines from the comp B are grouped - scan the source location, click on +1 and +2 button to fulfill the quantities and validate **Current behavior:** a backorder is created **Expected behavior:** no backorder should be created as we entered the right quantities of the picking **Cause of the issue:** the lines from comp B should not have been grouped in the barcode picking. When doing the same scenario but with product not tracked those lines are not grouped opw-4998766
This fixes an error that blocked users from posting several invoices at once when using Avalara Brazil automatic tax mapping. Businesses can now process batches of these invoices without needing to post each one individually or encountering a system traceback.
Original PR description
Issue:
When posting multiple invoices with Avalara Brazil tax mapping, a traceback is raised:
ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move
Only occurs when fiscal position is set to:
Automatic Tax Mapping (Avalara Brazil)
Affected versions:
- 17.0 and later
Steps to reproduce:
1. Set Avalara connection
2. Create an invoice with fiscal position: Automatic Tax Mapping (Avalara Brazil)
3. Duplicate that invoice
4. Select two or more invoices in draft
5. Try to post those entries
https://drive.google.com/file/d/1_CjX9vGhr-ZyUegP9QhOdQ--bfA8ylsH/view?usp=sharing
Current behavior:
- Error is raised: ValueError: Expected singleton
Expected behavior:
- Invoices should post correctly without errors
Forward-Port-Of: odoo/enterprise#93272The Malaysia Statement of Account report now applies the correct currency conversion when invoices are issued in a foreign currency. This prevents balances from being shown with the company currency symbol but the unconverted foreign amount, improving accuracy for customer reporting and receivables review.
Original PR description
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for…
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done. For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€ ## Reproduction Steps 1. In a db without demo data, Download the app l10n_my. 2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1. 3. In accounting > settings, click on -> Currencies. Activate this second currency. 4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings). 5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm. 6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download. ### Expected behavior The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying. ### Unexpected behavior The lines under Balance are displayed as the main currency of the company but the currency rates are not applying. ## Origin of the issue In the code, the currency rate isn't used to generate this line of the report: https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52 __ opw-4975540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website generation flow now reliably stops its background status checks when users leave or the screen is closed early. This prevents unnecessary server calls and avoids crashes that could interrupt the website creation experience.
Original PR description
In a component lifecycle, it may happen that onWillStart is called but not onWillUnmount. Indeed, if the component is destroyed before being mounted (because the current rendering has been cancelled), onWillUnmount isn't called. As a consequence, in the WebsiteGenerator component, the setInverval might never been called, thus producing an orm call every 10 seconds, when the component is destroyed. These calls lead to crashes ("Component is destroyed").
The solution is to use the onWillDestroy hook instead, which is always called.This fixes an issue where users could not save Documents settings for secondary companies after installing the Sign integration. The hidden Sign folder setting is no longer required, preventing an unnecessary validation error and allowing normal configuration changes.
Original PR description
**Steps to reproduce** - On a fresh DB, have multiple companies - Install documents_sign - With a company other than the main one, go to Settings > Documents > try to change a setting (e.g. Spreadsheets Workspace) - Error: "Invalid fields: Sign Base Folder" **Cause** The `documents_sign_folder_id` is only set on the main company and since it is invisible and required on the view, saving it is impossible. **Change** Since the folder serves no purpose, make it non required in the view. opw-5048447