Daily updates from Odoo
Friday, July 10, 2026
8 changes · saas-18.4
New functionality added to Odoo
Odoo can now recognize and contact WhatsApp users using business-scoped IDs when phone numbers are not shared. This helps businesses keep conversations linked to the right contact and improves matching even when phone number formatting differs.
Original PR description
Add support for whatsapp business-scoped user ids as outline in the [documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-scoped-user-ids) for their introduction this June. This effectively adds a table mapping BSUID to contacts to enable contacting users who contact the business directly, as the business will now not necessarily be provided with their number. Additionally the “whatsapp id”, i.e. the canonical form of the phone number as stored in whatsapp, is stored to help better match contacts regardless of formatting details in odoo and whatsapp. task-5476552 Forward-Port-Of: odoo/enterprise#117782
Enhancements to existing features
Attachment deletion is now much faster for Chilean electronic invoicing and stock documents. This reduces delays when cleaning up records in databases with many invoices or deliveries, improving day-to-day system responsiveness.
Original PR description
## The problem Deleting attachments checks foreign key triggers. Lookups in `account_move` and `stock_picking` tables for `ir_attachment` related fields coming from `l10n_cl_edi` overrides were slow due to missing indexes. ## The solution Added needed indexes to optimize triggers' lookups. ## Benchmark Time benchmark (deleting attachments from a customer database with 224K account moves and 204K stock pickings): |# of rows|Time (Before)|Time (After)| |----------|--------------|-------------| 100 | 29s | 16ms 1000 | 285s | 300ms OPW-6331845 Forward-Port-Of: odoo/enterprise#123350 Forward-Port-Of: odoo/enterprise#123252
Resolved issues and error corrections
This corrects an internal test setup issue for Hong Kong payroll related to leave generation. It helps ensure payroll checks run reliably in newer versions, reducing the risk of unnoticed issues during upgrades.
Original PR description
Which was missed during fwp due to these test not running on Runbot before version 19. Forward-Port-Of: odoo/enterprise#123649
This fix ensures status logs in French reports are rendered consistently when export results are accepted or rejected. Users should now see the intended error and status details instead of broken or incorrectly displayed log content.
Original PR description
A mismatch between error titles and status logs was introduced in 18.0. Markup wasn't added to the status logs, leading to a type mismatch (Markup + str) when displaying errors for 'accepted' or 'rejected' statuses. As a result, the logs were not interpreted as HTML. This commit ensures Markup is applied to each element to guarantee coherence and proper rendering. backport of 5113752 task-6053842 Forward-Port-Of: odoo/enterprise#123250
Fixed an issue where expanding a Knowledge article in the sidebar could show only favorited child articles while hiding the others. Users can now reliably see the full set of child articles without needing to reload the page, improving navigation consistency.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
Changing a project's visibility now ignores linked shortcut documents, preventing unnecessary access-rights warnings. This makes project settings updates smoother for users who organize project files with document shortcuts.
Original PR description
In 18.0 versions, when there is a shortcut document linked to a project, a warning appears as the access rights of a shortcut document is changed. This fix filters out the shortcut documents beforehand. To reproduce on runbot: 1. Go to a project with documents 2. Go to documents 3. Create shortcut of a document 4. Try to change visibility of project, warning occurs opw-6353516 Forward-Port-Of: odoo/enterprise#123184
This fixes an issue where invoice tax recalculations with Avatax could keep using an outdated pre-tax base amount while updating the tax amount. Invoice lines now consistently use the latest Avatax response, helping avoid incorrect invoice totals after tax recomputation.
Original PR description
Previously, when recomputing taxes via Avatax, `manual_tax_amounts` was cleared and repopulated from the fresh API response, but `manual_total_excluded_currency` was only set if it was None. This meant that after the first Avatax call, the pre-tax base amount was never refreshed from subsequent API responses, even though the tax amounts were. This inconsistency could cause stale pre-tax base amounts to persist on invoice lines across recomputations, even when Avatax returned a different base amount. By resetting `manual_total_excluded_currency` to `None` at the start of each recomputation, mirroring what is already done for `manual_tax_amounts`, we ensure that the pre-tax base is always taken from the current Avatax response rather than a previously cached value. opw-6235597
The Argentine VAT Book export no longer fails for partners marked as foreign providers with a foreign ID. This helps accounting teams generate the required VAT ZIP files without manual corrections or blocked reporting workflows.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506