Sunday, July 12, 2026
4 changes · saas-19.3
Resolved issues and error corrections
AI features now skip record fields that a user is not allowed to access instead of failing the whole request. This keeps AI assistance usable for non-admin users while preserving existing access restrictions.
Original PR description
- issue: _ai_serialize_fields_data() builds the JSON context sent to the AI model by iterating over all fields of a record. It is meant to silently skip any field the current user has no access to, but the field value was read outside of the try/except AccessError guard. As a result, any field that raises an AccessError when accessed (e.g. res.partner.rtc_session_ids, restricted to base.group_system) made the whole AI request crash for non-admin users, even though the feature is meant to be usable by everyone. - fix: Move the field value read inside the try block so the existing except AccessError: continue correctly skips inaccessible fields instead of letting the exception propagate. opw-6311015 Forward-Port-Of: odoo/enterprise#124000
This update fixes an issue where the ECPay payment portal displayed in simplified Chinese when Odoo was set to traditional Chinese. The fix ensures the portal correctly displays in traditional Chinese (zh_TW) for users in Taiwan, aligning with the correct locale setting. This improves the user experience for our Taiwanese customers.
Original PR description
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in…
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal should show up in traditional Chinese (zh_TW) also. ## Steps to reproduce: In Odoo 19.0, 1. Install modules: payment_ecpay, website, ecommerce 2. Change the company and website language to Traditional Chinese (zh_TW). Make sure the currency is in TWD (Taiwanese Dollar) 3. Add ECPay as a payment method 4. Add some test products and checkout with ECPay 5. Observe the language on ECPay portal website, and payload in V5 package in network tab ## Cause of the issue: Initially the locale mapping was wrong, mapping CHI to zh. There's no "zh" locale, must either be "zh_TW" or "zh_CN". So when the Odoo locale is set to traditional Chinese (zh_TW), it included Language=CHI in the payload and redirect to ECPAY, making ECPay think that we're trying to request the simplified Chinese site. Caused by commit: 76c81d6f67b54940879b1020068c7140c4f2199b ## Fix: Fixed the language mapping following ECPay developer docs, and what language code to be included in the payload sent to ECPay from current Odoo locale. opw-6270820 --------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269206
This update resolves an issue where cloud attachments downloaded via signed URLs were saved with generic names. The changes ensure that attachment names accurately reflect the original file type and content, improving the user experience when accessing these files. This also addresses a technical requirement for Google Cloud Storage signed URLs.
Original PR description
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 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 Forward-Port-Of: odoo/odoo#275781 Forward-Port-Of: odoo/odoo#274019
This update ensures that customer phone numbers are consistently saved for orders placed through self-order kiosks (like payment terminals). Previously, the phone number was lost during a payment processing step, impacting order details. This fix corrects this issue, ensuring accurate customer contact information is recorded for all kiosk orders.
Original PR description
When ordering from a self-order kiosk (e.g. with a Stripe payment terminal), the customer's phone number was saved on the created partner but no longer on the order itself (pos.order.mobile stayed…
When ordering from a self-order kiosk (e.g. with a Stripe payment terminal), the customer's phone number was saved on the created partner but no longer on the order itself (pos.order.mobile stayed empty), while the email was correctly registered. Self-order (QR code / mobile) was not affected. Steps to reproduce: ------------------- * Set a POS in kiosk mode with a payment terminal * Place an order and fill in the contact information (email & phone) * Pay through the terminal * Open the order in the backend > Observe that the email is registered but the phone (mobile) is not Why the fix: ------------ The kiosk pays through a second server round-trip (/kiosk/payment), which runs _check_pos_order again on the already created order. There, 'email' falls back to the partner's email but 'mobile' was taken only from the payload. By payment time the phone is no longer in the frontend payload (it is stripped from every self-order response), so the second sync overwrote the mobile saved on the draft with an empty value. The email survived only thanks to its partner fallback. Mirror the email behaviour and fall back to the partner's phone so the mobile survives the payment re-sync, consistently with the mobile field being computed from the partner. opw-6331335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273679