Daily updates from Odoo
Sunday, July 12, 2026
7 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
Fixed a display issue in Planning where material resource rows could appear with the wrong height after the resource field changed format. This keeps planning lists visually consistent and easier to read for users managing schedules.
Original PR description
commit - https://github.com/odoo/enterprise/pull/106700/changes/3f27d96bda7c0b20683adb3fc1d38b5c3279c4a4 When the resource field was converted from m2o to m2m, the corresponding SCSS selector in the planning list was not updated. so the row height was not adjusted correctly for material resources using the m2m avatar widget. Forward-Port-Of: odoo/enterprise#123894
Draft planning items in My Planning now display with the expected hatched visual style instead of appearing like confirmed entries. This makes it easier for users to distinguish draft plans at a glance and avoid confusion when reviewing schedules.
Original PR description
Issue: Calendar entries appear plain even when they should appear hatched. (ex. while in draft status) Steps to reproduce: If you create any planning and set it to draft. Then go to Planning > Planning > My Planning, the newly created plan should be in hatched but it becomes plain. Cause: In the view planning.slot.my.calendar there was missing the element that causes the views to become hatched when in draft status. Solution: Added said element. opw-6260055 Forward-Port-Of: odoo/enterprise#119153
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
Documentation and clarification updates
This pull request represents a legal compliance update, specifically a Certificate of License Agreement (CLA) signature by jota2rz. This ensures ongoing adherence to Odoo's licensing terms and allows continued development on this feature branch. It's a standard process for maintaining legal compliance within the Odoo project.
Original PR description
Signing again at 19.0 to be able to continue with this PR: https://github.com/odoo/enterprise/pull/123387 Forward-Port-Of: odoo/odoo#275490