Friday, July 10, 2026
6 changes · 17.0
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
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