Daily updates from Odoo
Wednesday, July 22, 2026
12 changes · 17.0
New functionality added to Odoo
This change adds support for Meta’s updated WhatsApp onboarding process for newly provisioned business phone numbers. It helps new users complete the required registration and webhook subscription steps, while existing users can continue using the current WhatsApp setup flow.
Original PR description
Purpose Align the module with Meta’s updated WhatsApp onboarding process. Specification Meta has introduced mandatory changes to the onboarding flow for newly provisioned business phone numbers, requiring additional registration and webhook subscription steps. Newly provisioned Meta users can install this module to use the updated onboarding flow, while existing users can continue using the legacy onboarding process available in the standard WhatsApp module. Task-5917364
Resolved issues and error corrections
Apple Pay and Google Pay express checkout can now continue when Starshipit cannot calculate a shipping rate from the limited address shared before payment. Other available delivery options are still shown, while Starshipit remains available later once the customer provides a full address.
Original PR description
#### Description of the issue/feature this PR addresses: Apple Pay (and Google Pay) express checkout via Stripe fails on the cart page with an "update postal address" error when a Starshipit delivery…
#### Description of the issue/feature this PR addresses: Apple Pay (and Google Pay) express checkout via Stripe fails on the cart page with an "update postal address" error when a Starshipit delivery carrier is configured, while normal checkout with a full address works fine. No request even reaches Starshipit's own API logs, because the request is rejected on Odoo's side. #### Current behavior before PR: Express checkout wallets only disclose a partial shipping address before the payment is authorized (city, zip, state, country) — the street is withheld by the wallet for privacy. website_sale rates the delivery carriers against this partial address, setting the express_checkout_partial_delivery_address context key so connectors only require the fields available at that stage. The UPS/USPS/DHL/bpost connectors honor this key and skip the street requirement, but delivery_starshipit ignores it: Starshipit._rate_shipment always sends the (empty) destination street to the /api/rates endpoint, which requires it and returns success:false with "street parameter value is required". _starshipit_send_request raises this as a UserError, which propagates out of starshipit_rate_shipment and aborts the entire express checkout rating RPC (_get_delivery_methods_express_checkout), so no carrier at all is returned to the wallet — hence the endless "update postal address" prompt. #### Desired behavior after PR is merged: During express checkout, Starshipit is skipped when the partial address has no street (it returns an unsuccessful rate without calling the API), so the other published carriers are still rated and the wallet shows the available shipping options. Starshipit is rated normally at the regular checkout step once the full address is known. Normal (non-express) checkout is unchanged. opw-6393393
The Spanish Mod 347 tax report now avoids counting real estate partners twice. This improves the accuracy of reported totals when real estate transactions are included.
Original PR description
The domain used for the Total number of persons and entities is using != None. However, another invoice type is added in l10n_es_real_estates which is already accompted for in another line. This means the partner could have been added twice (once in the real_estate invoice type and once in the all type). To reproduce: - Install l10n_es_real_estates - Create an invoice with l10n_es_reports_mod347_invoice_type set to real estate - Go to the Tax report: mod 347 - The partner would appear under the all operation and real estate.
This fixes where Mexican CFDI invoice fields are placed so they remain visible even when other localization modules are installed. It prevents the CFDI Origen field from disappearing on Mexican invoices, reducing confusion and helping users complete compliant invoicing.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269
There 2 problems fixed here: - First we can always attach at least once document by clicking on the paperclip icon or using the dropzone - It's not possible to add more attachment when we have read permission even if `_mail_post_access` is set to `read` Step to reproduce: - Have a model with `_mail_post_access` set to `read` - Have a user with read only access to the record - The user can upload a document by clicking on the paper-clip but the Attach files button is grayed out so he cant
Original PR description
There 2 problems fixed here: - First we can always attach at least once document by clicking on the paperclip icon or using the dropzone - It's not possible to add more attachment when we have read permission even if `_mail_post_access` is set to `read` Step to reproduce: - Have a model with `_mail_post_access` set to `read` - Have a user with read only access to the record - The user can upload a document by clicking on the paper-clip but the Attach files button is grayed out so he cant afterward - If `_mail_post_access` is set to `write` - The user can still upload a document with the paper-clip even through he only has read access We are also fixing the deletion of attachments, where it wasn't possible for someone with read access on a record where the model `_mail_post_access` is set to "read" to delete his own attachments. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Issue: --- Adding a rating with a message on website is causing TB as the portal user doesn't have the access to send rating message. opw-6316142 Forward-Port-Of: odoo/odoo#271833
Original PR description
Issue: --- Adding a rating with a message on website is causing TB as the portal user doesn't have the access to send rating message. opw-6316142 Forward-Port-Of: odoo/odoo#271833
The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes
Original PR description
The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes this by refactoring the assertions to treat the output HTML structure as a "black box", verifying data integrity and expected content conversions rather than brittle structural layout. runbot-938228
The amount in words split the total with int(decimal * 100), which truncates. 3989.33 is held in binary as 3989.3299..., so the kuruş/cents came out one short (32 instead of 33). The written amount then disagreed with the numeric total on the same invoice and Nilvera rejects it. Round to the currency precision and round the subunit instead. Task-6383690 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
The amount in words split the total with int(decimal * 100), which truncates. 3989.33 is held in binary as 3989.3299..., so the kuruş/cents came out one short (32 instead of 33). The written amount then disagreed with the numeric total on the same invoice and Nilvera rejects it. Round to the currency precision and round the subunit instead. Task-6383690 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
### Issue before the commit: During the import of Italian e-invoices, Pension Fund taxes (Cassa Previdenziale) linked to a 0% VAT rate with a specific exemption reason (Natura, e.g., N2.2) are ignored and not applied to the invoice lines. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Go to vendor -> bills and import the bill in the ticket 3. Check that taxes are not imported as expected ### Cause of the issue: The system incorrectly used the Natura to search
Original PR description
### Issue before the commit: During the import of Italian e-invoices, Pension Fund taxes (Cassa Previdenziale) linked to a 0% VAT rate with a specific exemption reason (Natura, e.g., N2.2) are ignored and not applied to the invoice lines. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Go to vendor -> bills and import the bill in the ticket 3. Check that taxes are not imported as expected ### Cause of the issue: The system incorrectly used the Natura to search for the Pension Fund tax itself. Fiscally, the Natura belongs to the related VAT, not the Pension Fund. This incorrect domain caused the tax search to fail. The Pension Fund tax should not have a Natura setted. ### Reason to introduce the fix: To correctly apply Pension Fund taxes to exempt invoice lines. Ticket [link](https://www.odoo.com/odoo/project.task/6357133) opw-6357133
When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it opens and on every later render. The server raises a ValueError and the call has no error handling, so the whole editor goes down. The bad domain stays saved on the property, so reopening the editor fails the same way and the property can no longer be edited or deleted. Wrap the search_count call in _
Original PR description
When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it…
When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it opens and on every later render. The server raises a ValueError and the call has no error handling, so the whole editor goes down. The bad domain stays saved on the property, so reopening the editor fails the same way and the property can no longer be edited or deleted. Wrap the search_count call in _updateMatchingRecordsCount (property_definition.js) in a try/catch and show no count when it fails. This is the only place the editor counts matching records, so guarding it here handles a bad domain from any source, the field selector or the code editor. The field selector still shows its warning on the invalid path, so the user can fix or delete the property. Steps to reproduce: 1. On a model that has a Properties field, add a Many2one property and set its Model to a model that itself has a Properties field. 2. Open the property Domain and click New Rule. 3. In the field selector pick the Properties entry, then close the selector. => An error dialog appears and the property can no longer be edited or deleted. Ticket [link](https://www.odoo.com/odoo/project.task/6101311) opw-6101311
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. This commit is a backport of [1], which was merged in master(saas-19.2). task-5427275 [1]: https://github.com/odoo/odoo/commit/2506fdfc49f1515aea7e715e9f6d66418a093401
Original PR description
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. This commit is a backport of [1], which was merged in master(saas-19.2). task-5427275 [1]: https://github.com/odoo/odoo/commit/2506fdfc49f1515aea7e715e9f6d66418a093401
Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`. Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund` with `out_invoice` as "inbound",
Original PR description
Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or…
Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`. Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund` with `out_invoice` as "inbound", and `out_refund` with `in_invoice` as "outbound". As a result, a Vendor Credit Note line with no product would be filtered to income accounts instead of expense accounts, and a Customer Credit Note line to expense accounts instead of income accounts. This only surfaced for contacts who are both customer and vendor, since the query needs matching history to return a result; otherwise it silently falls back to the journal's default account, masking the bug for ordinary contacts. This commit uses `get_sale_types` and `get_purchase_types` instead, which classify by document side, sale vs. purchase rather than cash-flow direction, matching the classification already used for product-based lines `is_sale_document` and `is_purchase_document` opw-6373124 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr