Thursday, August 7, 2025
6 changes · 17.0
Resolved issues and error corrections
The Viva Wallet point-of-sale integration now handles failed responses when setting up webhooks instead of crashing. This helps prevent setup interruptions caused by unexpected or unavailable responses from the payment provider.
Original PR description
When the system tries to get the verification key to configure the webhook at [1], a ```JSONDecodeError``` occurs as the response status gets '404 Not Found'. Line 1: https://github.com/odoo/odoo/blob/a3b88c88d6d137f9b231fd7b2a71c624e905f2d2/addons/pos_viva_wallet/models/pos_payment_method.py#L85 ```JSONDecodeError: Expecting value: line 1 column 1 (char 0)``` To resolve this, the code has been updated to handle bad responses by using a try-except block, which raises a logger warning if an HTTP error is encountered. Sentry-6019053900 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Internal stock transfers in Romania can now be validated without requiring a carrier when no eTransport document is needed. This removes an unnecessary blocking error and helps warehouse teams process internal movements more smoothly.
Original PR description
Internal transfers are a bit of an exception because they almost never require an eTransport document to be sent, and therefore also does not need a carrier to be validated. this commit fixes a bug where when a picking with its picking_type being internal was validated, an error would occur forcing a carrier to be set on the picking. task: 4566929
This fix ensures Odoo assigns a safe fallback value when a module icon status cannot be computed yet. It prevents an unexpected error from interrupting users or administrators while module information is being prepared.
Original PR description
Currently, a traceback will occur when the module id is NewId. The `icon_flag` field is a readonly and nonstorable field. If we get module id as `NewId` the compute method of `icon_flag` fails to assign a value to the `icon_flag` field. https://github.com/odoo/odoo/blob/775b6818f37496f85defc1c76a894c03fe2c8a00/odoo/addons/base/models/ir_module.py#L250-L254 Error:- ``` ValueError: Compute method failed to assign ir.module.module(<NewId 0x72edfa22ba00>,).icon_flag ``` Which leads to the above traceback from the below line https://github.com/odoo/odoo/blob/775b6818f37496f85defc1c76a894c03fe2c8a00/odoo/fields.py#L1215-L1216 sentry-5175358979
This update avoids unnecessary warnings when Odoo runs on newer Python environments. It keeps the base module compatible with both current and older supported documentation-processing libraries, reducing upgrade friction without changing user-facing behavior.
Original PR description
Odoo 17.0 supports Python ≥3.11, which installs docutils==0.20.1. This version deprecates `Node.traverse()` in favor of `Node.findall()`. To avoid deprecation warnings and ensure compatibility with both docutils 0.17 and 0.20.1, this patch uses `findall()` if available and falls back to `traverse()` otherwise. This change is backward-compatible and safe to cherry-pick to >= 18.0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employees without Time Off permissions could see an error when changing a leave request type, such as switching from paid time off to sick leave. This fix prevents that access error so the request form works as expected for regular users.
Original PR description
Steps: ([demo](https://drive.google.com/file/d/1nphgXlAc_w3z0oE7ickuTaGhl5khLhxo/view?usp=drive_link)) - Remove Time Off access to "Demo" user - Login as demo - Request a "Paid Time Off" - Change the Request time off type to "Sick" Actual result: - overtime_id field access error Expected result: - no error Caused by: https://github.com/odoo/odoo/pull/207780 opw-4929659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218095
WhatsApp message processing now skips the failing user check when the related user has been deleted. This prevents scheduled message sending from crashing and keeps queued WhatsApp communications running reliably.
Original PR description
Currently, an error occurs when CRON 'WhatsApp : Send In Queue Messages' tries to send a queue WhatsApp message to deleted users. Steps to produce: - Install WhatsApp and 'ecommerce' - configure a WhatsApp account and sign up for a new portal user, e.g., Portal - Now log in as a 'Portal' user and add a product to the cart > checkout. - Now add a billing address with a phone number > complete the order - Now login as admin and delete the 'Portal' user - Run CRON 'WhatsApp : Send In Queue Messages' >>> error will occur Error: `<class 'ValueError'>: "Expected singleton: res.users()" while evaluating 'model._send_cron()'` This commit fixes the above issue by adding a condition, which is to check if WhatsApp message has a user before checking if it is an internal user or not. sentry-5570895292