Daily updates from Odoo
Tuesday, July 22, 2025
12 changes · saas-18.3
Resolved issues and error corrections
Users without administration settings access can now use the Reload AI Data action on invoices without hitting an access error. This keeps invoice AI data refresh available to functional users and avoids an unexpected failure during their workflow.
Original PR description
When clicking on the "Reload AI Data" button (`account.move::action_reload_ai_data`), a user not in `base.group_system` group encounters an access rights error when searching on `ir.module.module` model in `account.move::is_indian_taxes()`:
```python
def is_indian_taxes(self):
l10n_in = self.env['ir.module.module'].search([('name', '=', 'l10n_in')])
return self.company_id.country_id.code == "IN" and l10n_in and l10n_in.state == 'installed'
```
This commit adds `sudo()` to the `search` call to ensure that the check for the 'l10n_in' module does not fail for users not belonging to "Administration/Settings" group.
This prevents a traceback and ensures that functional users can reload AI data.
Forward-Port-Of: odoo/enterprise#90021This fix ensures products already scanned from different locations keep their original source locations when an empty destination package is scanned. It helps warehouse teams avoid inaccurate picking records while still assigning all relevant items to the correct package.
Original PR description
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to…
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to reproduce ================ - Enable multi-locations and package; - Create an empty package, two locations and two products; - Create a delivery in the Barcode app; - Scan the first location then the first product; - Scan the second location then the second product; - Scan the empty package -> The package is rightly assigned as the result package for both lines, but the source location of the first product was update for the last scanned source location. Cause of the issue ================== When a source location was previously scanned, when a line is updated (`updateLine`), we update the line's source location. Usually, that's the wanted behavior but in this case, we don't want to the source location of already processed lines when we scan a destination package. Solution ======== When calling `updateLine` from `_assignEmptyPackage`, give a key in the parameters to not update the source location. [opw-4859851](https://www.odoo.com/odoo/project.task/4859851) Forward-Port-Of: odoo/enterprise#90091 Forward-Port-Of: odoo/enterprise#89142
This update adds missing internal labels to automated tests so they are recognized correctly by the test system. It helps keep quality checks reliable without changing customer-facing helpdesk or subscription behavior.
Original PR description
With the new test-tags features that allows to add additional test tags at runtime, the tests that starts a tour or that are using a query_count and that are not detected as such must be tagged respectively `is_tour` or `is_query_count`. Forward-Port-Of: odoo/enterprise#90152 Forward-Port-Of: odoo/enterprise#89934
This fixes a point of sale restaurant booking issue where the date filter stayed active after users switched away from the kanban view. The filter is now properly removed or updated, preventing stale booking results and reducing confusion for staff.
Original PR description
Steps to reproduce: - Open booking in a pos restaurant - Switch from kanban view to any other view - The filter on the date is not removed Issue: The onRemove method in the kanban_controller is never called. Fix: It is not possible to call the code an onWillUmount since onWillUmount is called after the onMount of the desired view. The deletion of the filter needs to be handled in the control_panel. Also each time createStartFilter was called, a new filter was added and never removed. In this commit if a filter already exists it is simply updated. Task-4916512
Fixes an issue where loans could fail when being cancelled, reset to draft, and confirmed again while Accounting Audit Trail is enabled. This helps accounting teams manage loan records reliably without encountering an unexpected error from previously posted entries.
Original PR description
Steps: - Activate Audit Trail in Accounting configuration - Create and confirm a loan, having some moves posted in the past - Cancel it, reset it to draft the re-confirm it again -> ValueError: Expected singleton This is because posted moves can not be unlinked when canceling/closing the loan if audit trail is activated. Therefore we try to access the `state` field from a recordset instead of a singleton. With this commit, we filter the generated move to get the newly created one. opw-4834361 Forward-Port-Of: odoo/enterprise#88286
This fix ensures asset setup only updates accounts that already exist. It prevents the system from accidentally creating incomplete account records during installation or setup, keeping accounting data cleaner and more reliable.
Original PR description
In the post init hook for account_asset we are updating the chart accounts to add the asset models, and then we load those assets. The update should only be performed on accounts that already exist, otherwise the load will create empty account records with all values null except the assets, which is not the intention here. This fix filters the update to existing accounts only, and filters the asset that use those accounts. [ci error](https://runbot.odoo.com/odoo/runbot.build.error/229788)
Project profitability now includes budget lines even when a project's analytic account belongs to a different analytic plan than expected. This prevents valid budget information from being hidden after analytic account migrations or plan mismatches, giving users a more complete profitability view.
Original PR description
In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have…
In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have not adapted the code in project profitability, to take those changes into account. A problematic situation could be the following: 1. We have a project where the account "X" is set to the main project plan (the first one) "Projects" BUT the account "X" actually belongs to the analytic plan "Departments" (yes, it's possible that there is a mismatch between the project plan and the analytic plan, especially after the 18.0 upgrade where "analytic_account_id" just became "account_id", no matter in which plan it was). 2. We have a budget line linked to the account "X" for the plan "Departments". 3. We want to display the budget lines in project profitability, but this line does not appear. That's because we currently only look for the budget lines belonging to the analytic plan "Projects" aka the main/first plan, that match the account "X" of the project. But as account "X" actually belongs to the analytic plan "Departments", no budget lines are found. task-4901400 version-18.0 Forward-Port-Of: odoo/enterprise#88658
Bank statement reconciliation has been optimized to run much faster on very large accounting databases, reducing the risk of slow imports or timeouts. This improves day-to-day accounting workflows, especially when importing statement files with many lines.
Original PR description
[FIX] account_accountant: refactor and optimize _try_auto_reconcile_statement_lines() In big databases, this method called on large recordsets of statement lines would take too much time, or worse:…
[FIX] account_accountant: refactor and optimize _try_auto_reconcile_statement_lines() In big databases, this method called on large recordsets of statement lines would take too much time, or worse: timeout. This is mainly because the 2 SQL queries are doing too complex searches and hence are badly optimized by the query planner. To solve that, * We search for reconciliable accounts outside the queries to avoid a join * We add a trigram index on statement_line.payment_ref and only use ILIKE operations for reference matching so that it can be used * Instead of using complex and costly regexp_split, we search for matches by splitting account_move_line.ref on ' - ' * We move some logic in python, amount matching, rather than in sql * We don't try anymore to match on amounts found in the payment_ref Additionnally, * The algorithm now treats the statement lines with and without partner the same for reference matching, but lines without partner are just ignored for the amount matching, as it's way too dangerous * Bug of with_prefetch, pre-loading the ids of a wrong object, has been fixed * We revert the patch https://github.com/odoo-dev/enterprise/commit/da52bc70cd745f3e9f7a0539528c84aa47b98cc5 because it was only a temporary measure while the time was back to acceptable * The test_matching_rules_with_empty_aml_ref, irrelevant, was removed Benchmark --------- Importing a csv file of 200 statement lines, on a database of 21M account.move.line, and thus triggering the culprit function, takes (hot timings): | Before | After | Speed-up | |--------|-------|----------| | 185 s | 52 s | ~3.5x | see https://github.com/odoo/odoo/pull/218642
Manufacturing orders created from Barcode now generate all required stock transfers when multi-step manufacturing is enabled, including picking components and storing finished products. This prevents missing warehouse movements and ensures by-products are correctly linked to the manufacturing order.
Original PR description
Task: 4558792 If 3-step manufacturing is enabled, the creation of an MO should also create 2 stock transfers: "Pick Components" and "Store Finished Product". Currently, when an MO is created via Barcode, only SFP is created. The problem boils down to the newly created stock move not having a `warehouse_id` field set, which causes Odoo to miss the required stock rules. This PR fixes the issue by fetching the `warehouse_id` field in XML, from where it is later passed to JS and back to Python's `create` method. Additionally, by-product moves for MOs created via Barcode were not correctly associated with the MO. This issue was solved by passing the missing fields from XML to Python. Forward-Port-Of: odoo/enterprise#90370 Forward-Port-Of: odoo/enterprise#83895
The AI assistant now avoids sending the same user question twice when preparing a response. This helps produce cleaner, more accurate replies and reduces unnecessary AI processing.
Original PR description
Prior to this commit, we send messages to the llm like the following:
```
[
{'content': Markup('<p>first question</p>'), 'role': 'user'},
{'content': Markup("<p>Sure, I'm here to help. What's your first question?</p>"), 'role': 'assistant'},
{'content': Markup('<p>second question</p>'), 'role': 'user'},
{'role': 'system', 'content': "You are a RAG assistant.\n\nToday's date to be used: 2025-07-18"},
{'role': 'user', 'content': 'second question'}
]
```
We're actually duplicating the user's prompt and this is because of the retrieval of the chat history. Before calling generate_response, we post the user's message. Therefore, he's message is already recorded in the db. We should then skip the most recent message to assemble the chat history since its just the same to the prompt.Fixed an issue that could prevent a point-of-sale session from closing after an Urban Piper payment method was used. The closing screen now avoids duplicate payment method entries, so staff can complete end-of-day closing normally.
Original PR description
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up…
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up urban piper (no need for credentials) testing with random keys will do * Go into the payment methods and take one of the urban piper one and assign it to a shop * Open that shop * Place an order and use the urban piper payment method * Validate * Try closing the session > Observation: Nothing happen, we're now unable to select the menu. If doing the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach Why the fix: ------------ The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method. Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method. opw-4874699 Forward-Port-Of: odoo/enterprise#90427 Forward-Port-Of: odoo/enterprise#88156
This update simplifies an automated check for signing documents through the customer portal by removing a fragile step tied to another app. It helps reduce false test failures, supporting more reliable releases without changing the signing experience for users.
Original PR description
We remove the last step, which depends on the mail module and is too complex. The reason for this step was to avoid a failed to fetch received after termination. This problem must be solved in another way. runbot-error-id~163605 Forward-Port-Of: odoo/enterprise#84480