Daily updates from Odoo
Friday, October 31, 2025
3 changes · master
New functionality added to Odoo
Adds a new US Direct Deposit module that lets businesses initiate vendor batch payments through Wise instead of relying on Europe-focused payment initiation options. This helps US companies manage supplier payouts with payment choices such as account balance, ACH, Fedwire, or direct deposit via the Wise portal.
Original PR description
Direct Deposit is a common requirement in the US. Payment Initiation via Ponto is not a good solution as that is only usable for Europe, so other solutions have to be developed. Unlike Ponto via account_online_payment, Wise is implemented directly in enterprise instead of odoofin as customers can open an account themselves and handle all of the data without Odoo being responsible for anything. This module works by overriding the validation steps for batch payments to utilize Wise's API to create a batch group on their side, before redirecting to their final step where the customer can pay however they choose. For the United States this can be from their account balance, ACH transfer, fedwire transfer, or via direct deposit if they set that up in their portal. task-5080414 Forward-Port-Of: odoo/enterprise#96588
Enhancements to existing features
Users can now upload files or attach documents directly in conversations with AI agents, so the agent can use that content when answering. This makes AI chats more useful for document-based questions and keeps each file linked to the correct message in the conversation history.
Original PR description
Purpose: -------- When chatting with an agent one can now upload files (or attach documents if documents is installed) that will be processed by the LLM to generate the answers Technical Changes:…
Purpose:
--------
When chatting with an agent one can now upload files (or attach documents
if documents is installed) that will be processed by the LLM to generate
the answers
Technical Changes:
------------------
To support this feature, files needs to be inside their related messages.
Previously they were simply appended to the list of inputs that were sent
to the LLMs, but that does not work inside a chatter because one sends the
history of messages. So if a user uploads a file in its first message, then
another one in the second message, one can't append them both to the list
of inputs otherwise the LLM would consider the first one as a new upload,
instead of an attachment from the previous message.
The `request_llm` method of the llm api service has been refactored to be
able to achieve this, and simplify the addition of attachment in any
message.
Instead of having 3 parameters "user_prompts", "inputs" and "files", there
is now only one parameter "messages".
Messages should always be either a string (considered as user prompt),
either a dict containing the role and the message parts:
```py
{'role': 'user', 'parts': [
{'type': 'text', 'content': 'hello'},,
{'type': 'image/png', 'content': 'aW1hZ2UgY29udGVudA=='},
{'type': 'application/pdf', 'content': 'cGRmIGNvbnRlbnQ='},
]}
```
These messages will be converted to the format expected by the different
providers before the loop calling the llm so that the llm answers can be
appended to this message list.
The tools are now also converted before the loop (there is no real need
to convert them in every loop iteration.
Task-5031785Opening the Phone app call list is now much faster for HR officers on large databases. The access rule was adjusted to avoid slow database filtering, reducing load times from seconds to milliseconds in the benchmark.
Original PR description
Description ----------- The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads…
Description ----------- The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`. To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM. This leads to a few more queries, but each is fast and trivial to process. Benchmark --------- On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took: | Before | After | Speed-up | |--------|-------|----------| | 13.3s | 80ms | 162x | Forward-Port-Of: odoo/enterprise#98098