Friday, October 31, 2025
3 changes · 19.0
New functionality added to Odoo
Adds a new US Direct Deposit capability that lets businesses pay vendors through Wise from Odoo batch payments. This gives US customers a practical alternative to Europe-focused payment initiation options, supporting payout methods such as account balance, ACH, Fedwire, or direct deposit depending on their Wise setup.
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
Enhancements to existing features
The Phone app now opens much faster for HR officers by improving how access checks are handled behind the scenes. This reduces waiting time dramatically on large databases while keeping the same access behavior for users.
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 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 |
HR users can open the Phone app much faster on large databases. The access check was optimized to avoid slow database scanning, 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 | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr