Daily updates from Odoo
Sunday, June 28, 2026
16 changes
4 changes
Resolved issues and error corrections
This fix ensures the stock quantity history uses both the existing filter and the product template filter together, instead of replacing one with the other. As a result, users get more accurate results when reviewing stock history and related quantities.
Original PR description
Description of the issue/feature this PR addresses: During a previous refactoring, the additional domain was assigned instead of being combined with the existing domain, causing the original domain to be overwritten. Current behavior before PR: The existing domain is replaced, so only the product template domain is applied. Desired behavior after PR is merged: The product template domain is combined with the existing domain using an AND operation, ensuring that both domain conditions are applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272393
This update enables Odoo to work with Android devices for passkey-based sign-in and registration. It adds the required web link between Odoo and the Android app, so users can authenticate more smoothly from mobile.
Original PR description
This commit adds a route for Digital Asset Links (`assetlinks.json`) that link the domain with the Android Mobile App. Also we adapt some functions authentication/registration so Odoo accept request…
This commit adds a route for Digital Asset Links (`assetlinks.json`) that link the domain with the Android Mobile App. Also we adapt some functions authentication/registration so Odoo accept request origin from the mobile App. The origin should be `android:apk-key-hash:BASE64(SHA256(APP_SIGNATURE))` Note: the `/.well-known/assetlinks.json` file should be serve on port HTTPS (443) without that the Android Digital Asset Links will fail. Url for debugging Digital Asset Links https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https://MY-DOMAIN.local&relation=delegate_permission/common.get_login_creds&target.android_app.package_name=com.odoo.mobile&target.android_app.certificate.sha256_fingerprint=D6:73:20:02:CA:2D:01:C9:FD:FC:94:73:5A:D0:73:CF:2C:36:10:29:1F:4B:F7:5D:91:C2:1D:37:B2:18:E8:91 https://developers.google.com/digital-asset-links https://developer.android.com/identity/passkeys/create-passkeys https://developer.android.com/identity/credential-manager/prerequisites opw-6279212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270551
The invoicing process now links only the delivery documents that match the quantity actually invoiced. This prevents extra delivery references from appearing on invoices and keeps the generated export files consistent and accurate.
Original PR description
### Issue: When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist…
### Issue: When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist until the remaining quantities are invoiced, at which point the extra DDTs are moved to the new invoice This creates inconsistencies in the generated XML, which references DDTs not actually covered by the invoice ### Cause: The quantity allocation loop only checked whether there was remaining `move_qty` to consume, but never checked whether the invoiced quantity (`inv[0]`) had already been fully consumed As a result, once all invoiced quantity was allocated, the loop kept iterating and linking additional DDTs from the sale order ### Steps to reproduce: - Install `l10n_it_stock_ddt` with demo data - Switch to the IT company - Create a Warehouse - Create a Product (Invoicing Policy: Delivered Quantities) - Create and confirm a Sale Order (qty: 5) for that product - Validate 3 partial deliveries of qty 1, creating a backorder each time - Create the invoice, set the quantity to 2 and confirm Before the fix, 3 DDTs were linked instead of 2 opw-6294035 Forward-Port-Of: odoo/odoo#272582 Forward-Port-Of: odoo/odoo#270235
Self-orders placed through the QR menu or kiosk will now correctly display the selected table in the order details view. This makes it easier for staff to review paid orders and confirm where service should be delivered.
Original PR description
### **Issue** Self-orders created through the mobile QR menu or kiosk were not displaying table information in the Order Info section of the payment screen. ### **Root Cause** The Order Details…
### **Issue** Self-orders created through the mobile QR menu or kiosk were not displaying table information in the Order Info section of the payment screen. ### **Root Cause** The Order Details dialog relied on `order.getTable()` to retrieve table information. However, self-orders only store the table reference through `table_id`, which was not properly handled when rendering the dialog, resulting in missing table information. ### **Solution** This PR introduces the following changes: * Add a dedicated `getTableInfo()` helper in `pos_restaurant` to retrieve table information from the order. * Use `getTableInfo()` when building the Order Details dialog fields. * Allow self-order flows to provide table information through `table_id`, ensuring table details are displayed correctly. ### **Steps to Reproduce** 1. Enable the following options in POS Configuration: * QR Menu & Ordering * Service at Table * Online Payment 2. Open a self-order from the mobile QR menu 3. Select a table and complete the payment 4. Open the POS session 5. Open the paid self-order 6. Click the **Details** button on the right side ### **Video Reproduction** https://drive.google.com/file/d/138AoJCTF1HNlCGFgk9BRTb0UTai-uXX7/view?usp=sharing ### **Before** Table information was not displayed in the **Order Info** section for self-orders. ### **After** Table information is now correctly displayed for self-orders. opw-6179516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264046
5 changes
Resolved issues and error corrections
A recent refactoring caused one of the stock search filters to overwrite an existing filter instead of adding to it. This fix makes both conditions apply together, so product results are filtered more accurately.
Original PR description
Description of the issue/feature this PR addresses: During a previous refactoring, the additional domain was assigned instead of being combined with the existing domain, causing the original domain to be overwritten. Current behavior before PR: The existing domain is replaced, so only the product template domain is applied. Desired behavior after PR is merged: The product template domain is combined with the existing domain using an AND operation, ensuring that both domain conditions are applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272393
When customers invoice only part of a sale order, the invoice now links only the delivery documents that match the invoiced quantity. This prevents extra documents from appearing on the invoice and keeps the generated legal XML consistent and accurate.
Original PR description
### Issue: When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist…
### Issue: When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist until the remaining quantities are invoiced, at which point the extra DDTs are moved to the new invoice This creates inconsistencies in the generated XML, which references DDTs not actually covered by the invoice ### Cause: The quantity allocation loop only checked whether there was remaining `move_qty` to consume, but never checked whether the invoiced quantity (`inv[0]`) had already been fully consumed As a result, once all invoiced quantity was allocated, the loop kept iterating and linking additional DDTs from the sale order ### Steps to reproduce: - Install `l10n_it_stock_ddt` with demo data - Switch to the IT company - Create a Warehouse - Create a Product (Invoicing Policy: Delivered Quantities) - Create and confirm a Sale Order (qty: 5) for that product - Validate 3 partial deliveries of qty 1, creating a backorder each time - Create the invoice, set the quantity to 2 and confirm Before the fix, 3 DDTs were linked instead of 2 opw-6294035 Forward-Port-Of: odoo/odoo#270235
Odoo now supports Android devices when using passkeys, making it easier for users to sign in and register from the mobile app. The update also adds the required web connection step so Android can verify the site and trust it for passwordless login.
Original PR description
This commit adds a route for Digital Asset Links (`assetlinks.json`) that link the domain with the Android Mobile App. Also we adapt some functions authentication/registration so Odoo accept request…
This commit adds a route for Digital Asset Links (`assetlinks.json`) that link the domain with the Android Mobile App. Also we adapt some functions authentication/registration so Odoo accept request origin from the mobile App. The origin should be `android:apk-key-hash:BASE64(SHA256(APP_SIGNATURE))` Note: the `/.well-known/assetlinks.json` file should be serve on port HTTPS (443) without that the Android Digital Asset Links will fail. Url for debugging Digital Asset Links https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https://MY-DOMAIN.local&relation=delegate_permission/common.get_login_creds&target.android_app.package_name=com.odoo.mobile&target.android_app.certificate.sha256_fingerprint=D6:73:20:02:CA:2D:01:C9:FD:FC:94:73:5A:D0:73:CF:2C:36:10:29:1F:4B:F7:5D:91:C2:1D:37:B2:18:E8:91 https://developers.google.com/digital-asset-links https://developer.android.com/identity/passkeys/create-passkeys https://developer.android.com/identity/credential-manager/prerequisites opw-6279212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270551
This update makes the Viettel e-Invoicing integration correctly find invoice XML files whether they are inside a single ZIP or nested ZIP archives. It prevents invoice sending from failing with an error when the returned file structure is different than expected.
Original PR description
Description of the issue/feature this PR addresses: The actual XML extraction hardcoded the double-zipped case by reading only the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it…
Description of the issue/feature this PR addresses: The actual XML extraction hardcoded the double-zipped case by reading only the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it was always a nested zip containing the XML. This made it fail when: - The XML was directly in the outer zip (single-zipped). - The zip contained multiple files and the first nested zip didn't hold the XML. Current behavior before PR: After sending an Invoice to Viettel S-Invoice, the e-Invoicing platform would return a ZIP containing one XML file. The XML File being double-unzipped, a traceback is raised. Desired behavior after PR is merged: The fix rewrites _recursive_zip_xml_file_data to actually be recursive. Invoices can be sent to Viettel S-Invoice without raising a traceback. opw-[6249929](https://www.odoo.com/odoo/project.task/6249929?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272121 Forward-Port-Of: odoo/odoo#268482
This change fixes an error that could occur when using AI-assisted fields in Studio, especially on employee appraisal forms. It ensures the system handles the field list in the expected format, so AI-generated values can be inserted without failing.
Original PR description
**STEPS TO REPRODUCE** 1. Add an AI Studio field in the employee appraisal form view (can be a regular text field or other) 2. Add `employee_feedback` to the prompt using '/' 3. Click the AI button to populate the field 4. Error occurs: `TypeError: unsupported operand type(s) for +: 'OrderedSet' and 'list'` **CAUSE** In any model, the read function expects the argument `fields` to be a list. When using AI fields in Studio, the fields argument is stored as an OrderedSet instead of a list, causing errors when performing operations. opw-5954203 Forward-Port-Of: odoo/enterprise#120799
6 changes
Resolved issues and error corrections
This fix ensures that only the delivery documents actually covered by the invoiced quantity are linked to an invoice. It prevents extra delivery references from appearing in the invoice and exported XML when customers are billed for only part of a sale order.
Original PR description
### Issue: When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist…
### Issue: When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist until the remaining quantities are invoiced, at which point the extra DDTs are moved to the new invoice This creates inconsistencies in the generated XML, which references DDTs not actually covered by the invoice ### Cause: The quantity allocation loop only checked whether there was remaining `move_qty` to consume, but never checked whether the invoiced quantity (`inv[0]`) had already been fully consumed As a result, once all invoiced quantity was allocated, the loop kept iterating and linking additional DDTs from the sale order ### Steps to reproduce: - Install `l10n_it_stock_ddt` with demo data - Switch to the IT company - Create a Warehouse - Create a Product (Invoicing Policy: Delivered Quantities) - Create and confirm a Sale Order (qty: 5) for that product - Validate 3 partial deliveries of qty 1, creating a backorder each time - Create the invoice, set the quantity to 2 and confirm Before the fix, 3 DDTs were linked instead of 2 opw-6294035 Forward-Port-Of: odoo/odoo#270235
This update lets Odoo work with passkeys on Android devices by linking the website to the mobile app. It also adjusts the login and registration flow so Android users can authenticate more reliably from the app, improving mobile sign-in compatibility.
Original PR description
This commit adds a route for Digital Asset Links (`assetlinks.json`) that link the domain with the Android Mobile App. Also we adapt some functions authentication/registration so Odoo accept request…
This commit adds a route for Digital Asset Links (`assetlinks.json`) that link the domain with the Android Mobile App. Also we adapt some functions authentication/registration so Odoo accept request origin from the mobile App. The origin should be `android:apk-key-hash:BASE64(SHA256(APP_SIGNATURE))` Note: the `/.well-known/assetlinks.json` file should be serve on port HTTPS (443) without that the Android Digital Asset Links will fail. Url for debugging Digital Asset Links https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https://MY-DOMAIN.local&relation=delegate_permission/common.get_login_creds&target.android_app.package_name=com.odoo.mobile&target.android_app.certificate.sha256_fingerprint=D6:73:20:02:CA:2D:01:C9:FD:FC:94:73:5A:D0:73:CF:2C:36:10:29:1F:4B:F7:5D:91:C2:1D:37:B2:18:E8:91 https://developers.google.com/digital-asset-links https://developer.android.com/identity/passkeys/create-passkeys https://developer.android.com/identity/credential-manager/prerequisites opw-6279212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270551
This update ensures DIAN email templates are translated when a new language is installed. It prevents untranslated invoice and credit note emails for users who add languages after the Colombian DIAN module is already in place.
Original PR description
### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly…
### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment Only languages installed afterwards are affected ### Cause: The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files The `TranslationImporter` finds nothing to import for them The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed `TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced This is the standard way to push translations while preserving any manually modified values ### Notes: Languages installed before this fix are not updated Only newly installed languages will get the synced translations ### Steps to reproduce: - Install `l10n_co_dian` - Enable Developer Mode in Settings - Install any language (e.g. `fr_FR`) - Go in Settings > Technical > Email > Email Templates - Search for DIAN and open Invoice or Credit Note Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html opw-6269979 Forward-Port-Of: odoo/enterprise#120855
This fix ensures the product template filter is combined with the existing search conditions instead of replacing them. As a result, stock quantity history screens now apply all relevant criteria correctly and show more accurate results.
Original PR description
Description of the issue/feature this PR addresses: During a previous refactoring, the additional domain was assigned instead of being combined with the existing domain, causing the original domain to be overwritten. Current behavior before PR: The existing domain is replaced, so only the product template domain is applied. Desired behavior after PR is merged: The product template domain is combined with the existing domain using an AND operation, ensuring that both domain conditions are applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272393
This update makes Viettel e-invoice processing more reliable by correctly finding the invoice XML whether it is in the outer ZIP file or inside a nested ZIP. It prevents errors during invoice submission, reducing failed sends and manual follow-up.
Original PR description
Description of the issue/feature this PR addresses: The actual XML extraction hardcoded the double-zipped case by reading only the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it…
Description of the issue/feature this PR addresses: The actual XML extraction hardcoded the double-zipped case by reading only the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it was always a nested zip containing the XML. This made it fail when: - The XML was directly in the outer zip (single-zipped). - The zip contained multiple files and the first nested zip didn't hold the XML. Current behavior before PR: After sending an Invoice to Viettel S-Invoice, the e-Invoicing platform would return a ZIP containing one XML file. The XML File being double-unzipped, a traceback is raised. Desired behavior after PR is merged: The fix rewrites _recursive_zip_xml_file_data to actually be recursive. Invoices can be sent to Viettel S-Invoice without raising a traceback. opw-[6249929](https://www.odoo.com/odoo/project.task/6249929?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272121 Forward-Port-Of: odoo/odoo#268482
Fixed an issue that could prevent AI-generated values from being inserted into Studio fields in forms such as employee appraisals. This ensures the feature works reliably when users ask AI to fill in a field, avoiding unexpected errors during use.
Original PR description
**STEPS TO REPRODUCE** 1. Add an AI Studio field in the employee appraisal form view (can be a regular text field or other) 2. Add `employee_feedback` to the prompt using '/' 3. Click the AI button to populate the field 4. Error occurs: `TypeError: unsupported operand type(s) for +: 'OrderedSet' and 'list'` **CAUSE** In any model, the read function expects the argument `fields` to be a list. When using AI fields in Studio, the fields argument is stored as an OrderedSet instead of a list, causing errors when performing operations. opw-5954203 Forward-Port-Of: odoo/enterprise#120799
1 change
Resolved issues and error corrections
This update ensures employees on partial incapacity or long-term sickness are not incorrectly marked as eligible for loss on commissions. It helps avoid payroll miscalculations and keeps commission handling aligned with the intended Belgian payroll rules.
Original PR description
Partial incapacity and long term sickness are not elligible to loss on commissions. Forward-Port-Of: odoo/enterprise#121514