Friday, September 4, 2026
4 changes · master
Security fixes and vulnerability patches
Restaurants can now choose a Dynamic QR mode for table self-ordering, where staff generate a unique QR code for each meal instead of leaving a reusable table QR available. This helps prevent former guests or anyone with an old link from viewing, changing, or paying for an active table order, while existing table QR setups continue to work as before.
Original PR description
..., point_of_sale, pos_restaurant, pos_loyalty, pos_sale, l10n_id_pos, l10n_in_pos, pos_safaricom, pos_bancontact_pay, pos_online_payment, pos_online_payment_self_order, obox_pos_self_order --- When…
..., point_of_sale, pos_restaurant, pos_loyalty, pos_sale, l10n_id_pos, l10n_in_pos, pos_safaricom, pos_bancontact_pay, pos_online_payment, pos_online_payment_self_order, obox_pos_self_order --- When a self-order config is set to service mode "Table" with "Pay after" set to "Meal", the QR code printed on the table stays valid for as long as the meal lasts. Anyone who knows that URL - not just the customers currently seated there - can open it and view or edit the order tied to that table, even after those customers have left. There is no way to tell, from the URL alone, whether the person opening it is still at the table. To fix this, this introduces a new self-ordering service mode, "Dynamic QR", as an alternative to "Table" for restaurants that want this guarantee. Selecting it automatically sets "Pay after" to "Meal", since the whole point of this mode is a tab that stays open for the length of the meal. With "Dynamic QR" active, the self-order app is inactive for that table by default - there's nothing to scan on the table itself. Instead, once staff open an order for the table at the register, they can generate a QR code for that specific order from the POS screen. Scanning it is the only way to load that order in the self-order app. The QR can be shown on the customer-facing display or printed on a paper receipt, so it can be handed to the table. Anyone without that QR simply sees a message asking them to get one from staff - browsing the menu, seeing the order, or paying isn't possible without it. Existing "Table" configs are unaffected by this - they keep working the same way as before, QR-code-on-the-table included. This is an additional, opt-in mode for restaurants that specifically want this tighter guarantee. Along the way, this also simplifies how a payment integration pushes a QR code to the customer-facing display - previously each integration had to fetch that method from the POS and manually check whether it existed before calling it; the base point_of_sale API now standard. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6381129
Restaurants can now choose a Dynamic QR mode for pay-after-meal table orders, where staff generate a QR code for each specific meal instead of leaving a permanent table QR available. This helps ensure only current diners with the issued QR can view, edit, or pay for their order, while existing table QR setups continue to work unchanged.
Signing certificates now clearly show when a document was signed through a shared public link without email verification, helping businesses understand the level of assurance behind a signature. The update also improves privacy and security by discarding sent signature request emails and strengthening protection for signing links against timing-based attacks.
Original PR description
### [IMP] Sign: Tell on the Certificate When a Document Was Signed via Shared Link A document shared through a public link can be signed by anyone who has access to that link, without email…
### [IMP] Sign: Tell on the Certificate When a Document Was Signed via Shared Link A document shared through a public link can be signed by anyone who has access to that link, without email verification. Previously, the certificate of completion did not clearly indicate this and could even display an email verification column that was not applicable to shared-link signers. The certificate now explicitly states when: - The document was signed via a shared link. - The signature was not verified by email. - Anyone with access to the link could sign the document. ### [IMP] Sign: Delete Signature Request Emails Once Sent Signature request emails contain private signing links for recipients. Keeping copies of these emails could expose those links through the mail application. Signature request emails are now automatically discarded after they have been sent successfully. ### [FIX] Sign: Compare Sign Access Tokens in Constant Time Public signing routes are protected solely by the access tokens embedded in their URLs. Previously, token validation used a standard equality comparison, which could leak information through response timing differences. An attacker could potentially exploit this behavior to recover a valid token and gain unauthorized access to another user's document. Access tokens are now compared using a constant-time comparison method to mitigate timing attacks. **Task:** `task-6196852`
This update reduces exposure of sensitive technical error details in web responses while keeping full information available in server logs for troubleshooting. It also makes internal server signaling utilities reusable for new infrastructure services, supporting future platform work.
Original PR description
* [IMP] core: suppress_debug_traceback() * [MOV] core: make pipe_ping and co public Forward-Port-Of: odoo/odoo#285728
Original PR description
..., point_of_sale, pos_restaurant, pos_loyalty, pos_sale, l10n_id_pos, l10n_in_pos, pos_safaricom, pos_bancontact_pay, pos_online_payment, pos_online_payment_self_order, obox_pos_self_order --- When…
..., point_of_sale, pos_restaurant, pos_loyalty, pos_sale, l10n_id_pos, l10n_in_pos, pos_safaricom, pos_bancontact_pay, pos_online_payment, pos_online_payment_self_order, obox_pos_self_order --- When a self-order config is set to service mode "Table" with "Pay after" set to "Meal", the QR code printed on the table stays valid for as long as the meal lasts. Anyone who knows that URL - not just the customers currently seated there - can open it and view or edit the order tied to that table, even after those customers have left. There is no way to tell, from the URL alone, whether the person opening it is still at the table. To fix this, this introduces a new self-ordering service mode, "Dynamic QR", as an alternative to "Table" for restaurants that want this guarantee. Selecting it automatically sets "Pay after" to "Meal", since the whole point of this mode is a tab that stays open for the length of the meal. With "Dynamic QR" active, the self-order app is inactive for that table by default - there's nothing to scan on the table itself. Instead, once staff open an order for the table at the register, they can generate a QR code for that specific order from the POS screen. Scanning it is the only way to load that order in the self-order app. The QR can be shown on the customer-facing display or printed on a paper receipt, so it can be handed to the table. Anyone without that QR simply sees a message asking them to get one from staff - browsing the menu, seeing the order, or paying isn't possible without it. Existing "Table" configs are unaffected by this - they keep working the same way as before, QR-code-on-the-table included. This is an additional, opt-in mode for restaurants that specifically want this tighter guarantee. Along the way, this also simplifies how a payment integration pushes a QR code to the customer-facing display - previously each integration had to fetch that method from the POS and manually check whether it existed before calling it; the base point_of_sale API now standard. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6381129