Daily updates from Odoo
Friday, July 10, 2026
12 changes · 17.0
Security fixes and vulnerability patches
Website forms embedded in Helpdesk pages now protect signed fields from being changed in the browser before submission. This improves the integrity of customized website forms without changing the experience for visitors or editors.
Original PR description
Website forms can be customized using the website editor. These customized values are directly embedded in the form in a hidden input or injected via the data-for js mechanism. For website forms whose action is the route `/website/form/`, this commit ensures that input marked with `data-sign='true'` are not modified by the client. The signature is prepared during the compilation phase, and the signature is calculated at runtime (during rendering) to take into account values rendered dynamically. HTML fields do not pass through the QWeb engine. For this field the form signature is calculated statically. Passing embedded forms within HTML fields through the pre-compilation step allows their signatures to be determined since these forms are static. This mechanism is completely transparent to the end user. Task-6320608
Website forms now include a built-in integrity check so customized hidden values cannot be altered in the browser before submission. This helps ensure helpdesk and other website form data remains trustworthy without changing the user experience.
Original PR description
WIP Task-6320608
New functionality added to Odoo
Adds support for Swedish BBAN, Plusgiro, and Bankgiro payment details, enabling businesses in Sweden to process local bank payments more easily. It also supports Swedish payment bank files in PAIN format, improving compatibility with local banking requirements.
Original PR description
This module adds support for BBAN, Plusgiro and Bankgiro for Sweden. It does also add support for local payment bankfiles in PAIN format for Sweden. This module can included as is. However, It might be better to move part of the module to the account_sepa module and the bank handling to the l10n_se file. My recommendation is to move the bankhandling to l10n_se for the Odoo 18 version. https://www.handelsbanken.com/tron/xgpu/info/contents/v1/document/72-111386
Adds product recycling reporting so businesses can track and report recycling-related product data more easily. The update also includes Swedish localization, helping companies meet local reporting needs in Sweden.
Original PR description
Product Recycling report. with Swedish localization. Original sent as https://github.com/odoo/enterprise/pull/49404
Odoo can now recognize and contact WhatsApp users through business-specific identifiers when a phone number is not provided. This helps businesses keep conversations linked to the right customer and improves contact matching despite phone number formatting differences.
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
Enhancements to existing features
Website forms can be customized using the website editor. These customized values are directly embedded in the form in a hidden input or injected via the data-for js mechanism. For website forms whose action is the route `/website/form/`, this commit ensures that input marked with `data-sign='true'` are not modified by the client. The signature is prepared during the compilation phase, and the signature is calculated at runtime (during rendering) to take into account values rendered dynami
Original PR description
Website forms can be customized using the website editor. These customized values are directly embedded in the form in a hidden input or injected via the data-for js mechanism. For website forms whose action is the route `/website/form/`, this commit ensures that input marked with `data-sign='true'` are not modified by the client. The signature is prepared during the compilation phase, and the signature is calculated at runtime (during rendering) to take into account values rendered dynamically. HTML fields do not pass through the QWeb engine. For this field the form signature is calculated statically. Passing embedded forms within HTML fields through the pre-compilation step allows their signatures to be determined since these forms are static. This mechanism is completely transparent to the end user. Task-6320608
Resolved issues and error corrections
Email buttons for appointments and event registrations now use the website tied to the booking or event, rather than a generic or recently visited website. This prevents customers in multi-website setups from being sent to the wrong site when managing appointments or registrations.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from…
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. Case 1: - Have website A and website B - Create an appointment page website A - Log in via website B - As public user, make an appointment in Website A - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url. This parameter is then used as fallback when we need to retrieve the base url without an active record Case 2: - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf opw-4146760 opw-4336369
The Knowledge card on the customer portal now uses the same layout as the other portal cards. This fixes a visual inconsistency where it appeared slightly wider, improving the page’s polish and consistency for users.
Original PR description
The knowledge portal card was injected directly into "o_portal_docs", causing it to render wider than other cards. This happened because other cards sit inside "o_portal_category" (row g-2 mt-3) divs, while, knowledge was a direct child of o_portal_docs, giving it a different grid context despite both using col-md-6. To fix the issue, we wrapped the portal_docs_entry in an "o_portal_category row g-2 mt-3" div to match the structure of all other portal cards. Steps to reproduce: 1. Go to the website. 2. Click on name drop down menu on the navbar like "Mitchell Admin" 3. Click on "My Accont" from the drop down menu 4. Once the page loads properly, you can see the knowledge card width is a little bit larger than other cards. opw-6251483
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) opw-4146760 opw-4336369
Website forms can be customized using the website editor. These customized values are directly embedded in the form in a hidden input or injected via the data-for js mechanism. This commit ensures that these values are not modified by the client. For website forms whose action is the route `/website/form/`, the form is signed automatically. The signature is prepared during the compilation phase, and the signature is calculated at runtime (during rendering) to take into account values
Original PR description
Website forms can be customized using the website editor. These customized values are directly embedded in the form in a hidden input or injected via the data-for js mechanism. This commit ensures that these values are not modified by the client. For website forms whose action is the route `/website/form/`, the form is signed automatically. The signature is prepared during the compilation phase, and the signature is calculated at runtime (during rendering) to take into account values rendered dynamically. This mechanism is completely transparent to the end user. Task-6320608
Currently each OSS tax group uses the same payable and receivable accounts for the tax closing as the corresponding non-OSS tax group. For the OSS taxes we use dedicated accounts that are different from the accounts for non-OSS taxes. But After the tax closing the taxes will be merged into the same account since the OSS tax groups do not have dedicated accounts. After this commit we create dedicated payable and receivable accounts for each OSS tax group when the OSS tax group is created. (We
Original PR description
Currently each OSS tax group uses the same payable and receivable accounts for the tax closing as the corresponding non-OSS tax group. For the OSS taxes we use dedicated accounts that are different from the accounts for non-OSS taxes. But After the tax closing the taxes will be merged into the same account since the OSS tax groups do not have dedicated accounts. After this commit we create dedicated payable and receivable accounts for each OSS tax group when the OSS tax group is created. (We basically copy the accounts from some existing non-OSS tax group.) task-4134733
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-63
Original PR description
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-6348377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr