Daily updates from Odoo
Sunday, July 12, 2026
12 changes
4 changes
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
2 changes
Resolved issues and error corrections
AI features now skip fields a user is not allowed to access instead of failing the whole request. This keeps AI assistance available 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 the Odoo locale was set to traditional Chinese. The fix ensures the portal correctly displays in traditional Chinese, aligning with the user's locale setting and improving the checkout experience for customers in Taiwan.
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
2 changes
Resolved issues and error corrections
AI features now skip fields a user is not allowed to access instead of failing the whole request. This keeps the AI experience available to regular users while respecting existing access rules.
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 resolves an issue where customers were not appearing in the POS list when using the Taiwan localization. The fix updates the Chart of Accounts to correctly display customer accounts for Taiwan companies, ensuring all customers are visible in POS transactions. This improves the user experience for Taiwan-based businesses.
Original PR description
## Current behavior: Currently, when we go into POS using l10n_tw localization, none of the customers appear on the list. ## Expected behavior: All customers should be shown when using Taiwan localization ## Steps to reproduce: 1. Install l10n_tw and POS modules 2. Use the default US company, observe the customer list in POS. All of them are shown 3. Create and switch to a Taiwan company, go back to POS 4. Observe that no customers are shown ## Cause of the issue: Since 19.0, there is a check where if the default payable or receivable account set on the partner is non-trade, those accounts do not appear ## Fix: - Updated AR accounts in COA template file - Added migration script to version 1.1 opw-6298634 Forward-Port-Of: odoo/odoo#270738
2 changes
Enhancements to existing features
Peruvian electronic invoices can now correctly handle ISC taxes charged as a fixed amount per unit, helping businesses comply with SUNAT requirements. The update also prevents incorrect negative tax bases when ISC-taxed lines are mixed with exempt or unrelated tax lines, reducing invoice rejection risk.
Original PR description
## Summary - Add ISC fixed amount per unit (SUNAT Catalog No. 08, system type 02) support to Peru UBL 2.1 XML generation - Emit `BaseUnitMeasure` and `PerUnitAmount` at line-level `TaxSubtotal` for…
## Summary - Add ISC fixed amount per unit (SUNAT Catalog No. 08, system type 02) support to Peru UBL 2.1 XML generation - Emit `BaseUnitMeasure` and `PerUnitAmount` at line-level `TaxSubtotal` for ISC tipo 02; emit `TierRange` inside `TaxCategory` for all ISC tipos (01/02/03) - Compute effective `cbc:Percent` for ISC tipo 02 as `TaxAmount / TaxableAmount × 100` rounded to 5 decimals (SUNAT rules 3102, 3104, 3108) - Merge ISC variants into a single document-level `TaxSubtotal` (SUNAT rule 3068 — tax code 2000 must not repeat at totals); re-emit `TierRange`/`Percent` at doc level only when all lines share one tipo - Add tests and XML fixture covering pure tipo 02 and mixed tipo 01+02 invoices ## Context Peru's ISC tax supports three application systems defined in SUNAT Catalog No. 08: - **01** — Sistema al Valor (percentage on base) — already supported - **02** — Aplicación de Monto Fijo (fixed amount per unit) — **this PR** - **03** — Sistema de Precios de Venta al Público ISC tipo 02 requires specific UBL nodes per SUNAT specification: `BaseUnitMeasure`, `PerUnitAmount` (at `TaxSubtotal` level) and `TierRange` (inside `TaxCategory`). ### SUNAT validation rules for ISC Percent For ISC (tax code 2000), SUNAT validates `cbc:Percent` with three rules: - **3102** — format must be max 3 integer digits and up to 5 decimal digits - **3104** — value must be different from 0.00 (when `TaxableAmount > 0`) - **3108** — `Percent/100 × TaxableAmount = TaxAmount` (tolerance ±1) For ISC tipo 02 (fixed amount), the per-unit amount cannot be placed directly in `Percent` because the validation formula `Percent × TaxableAmount` would fail. Instead, we compute the **effective percentage**: `TaxAmount / TaxableAmount × 100`, which satisfies all three rules. ### SUNAT rule 3068 — single tax code at document totals When an invoice combines multiple ISC variants (e.g., tipo 01 on one line + tipo 02 on another), they share `TaxScheme/ID = 2000` and SUNAT rejects the document because the same tax code repeats in `cac:TaxTotal` at document totals. To fix this, `l10n_pe_edi_isc_type` is dropped from the doc-level grouping key so all ISC entries collapse into a single `TaxSubtotal` whose `TaxAmount` and `TaxableAmount` are the sum of every ISC variant. `TierRange`/`Percent` are intentionally omitted at doc level when types are mixed (a merged value cannot represent both tipos). Per-line `TaxSubtotal` nodes still carry their own `TierRange`/`Percent` per tipo. When the invoice uses a single tipo, the type is restored at doc-level render time so existing single-tipo invoices keep their previous output unchanged. ### Line and document base totals ISC fixed taxes are already excluded from `LineExtensionAmount` and `TaxExclusiveAmount` because `l10n_pe_edi` sets `fixed_taxes_as_allowance_charges = False` (introduced upstream in commit `d07ca711bf7` to fix ICBPER). This PR relies on that behavior; no additional subtraction is performed in the Peru EDI code. ## Legal references - SUNAT CPE UBL 2.1 specification: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia%2Bxml%2Bnota%20de%20cr%C3%A9dito%2Bversion%202-1%2B1%2B0_0_0%20%282%29.pdf - SUNAT Catalog No. 08 (ISC System Type): https://www.sunat.gob.pe/legislacion/superin/2017/anexoE-245-2017.pdf - Peru Tax Code Art. 50 — ISC application systems: https://www.sunat.gob.pe/legislacion/igv/ley/capitul2.htm - SUNAT Validation Rules (CPE v2026-02-12): AjustesValidacionesCPEv20260212.xlsx — rules 3068, 3102, 3104, 3108 ## Example ISC fixed amount tax configuration (tipo 02 — Aplicación de Monto Fijo): <img width="1206" height="694" alt="ISC fixed amount tax config" src="https://github.com/user-attachments/assets/87bd23a8-5c5a-42bc-9512-6c19ee45b96d" /> ISC percentage tax configuration (tipo 01 — Sistema al Valor, existing behavior): <img width="1206" height="694" alt="ISC percentage tax config" src="https://github.com/user-attachments/assets/95e5e914-08d4-4b01-abf3-e5b6159079aa" /> Invoice with ISC fixed amount (tipo 02) — successfully sent to SUNAT: <img width="1789" height="857" alt="Invoice with ISC fixed amount sent to SUNAT" src="https://github.com/user-attachments/assets/66f89c51-7aac-4a17-a3d3-cc02629fd3f9" /> Invoice with ISC percentage (tipo 01) — backward compatibility confirmed: <img width="1789" height="857" alt="Invoice with ISC percentage backward compatible" src="https://github.com/user-attachments/assets/9e99387c-b6ed-43aa-8e56-a25e24685172" /> Invoice with ISC — SUNAT validation passed: <img width="1789" height="857" alt="Credit note with ISC validated by SUNAT" src="https://github.com/user-attachments/assets/ada2016a-aece-404e-b2f1-50193d9eac72" /> ## Functional testing (edge cases validated) | Case | qty | price | ISC/unit | Effective Percent | SUNAT | |------|-----|-------|----------|-------------------|-------| | Base case | 50 | 100 | 10.00 | 10.0 | ✅ | | Different price | 5 | 123 | 2.70 | 2.19512 | ✅ | | High price | 1 | 530 | 2.70 | 0.50943 | ✅ | | Very high price | 1 | 99999 | 2.70 | 0.0027 | ✅ | | Price < ISC | 5 | 2.00 | 10.00 | 500.0 | ✅ | | Mixed tipo 01+02 (rule 3068) | — | — | — | per line: 17.0 / 2.19512; doc-level: merged into one ISC `TaxSubtotal` (`TierRange`/`Percent` omitted) | ✅ | | Tipo 02 + solo IGV | — | — | — | 0.50943 | ✅ |
The messaging-related menus for WhatsApp and connected apps are being consolidated into one clearer entry point. This makes navigation more consistent for users and reduces duplicated menu behavior across AI, Documents, Knowledge, and WhatsApp areas.
Original PR description
community https://github.com/odoo/odoo/pull/269104
1 change
Resolved issues and error corrections
AI requests now continue working for non-admin users when some record fields are not accessible to them. Instead of crashing, the system skips restricted fields and still provides the available context to the AI feature.
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
1 change
Enhancements to existing features
Peru's e-invoicing setup now includes the product classification codes required by SUNAT's upcoming 2026 validation rules. This helps businesses selling affected goods avoid invoice rejections by ensuring the necessary codes are available when the Peruvian localization is used.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907