Daily updates from Odoo
Navigate
Branch
Sunday, June 28, 2026
36 changes
8 changes
Enhancements to existing features
Austria’s tax settings are updated to reflect a planned VAT reduction from 10% to 4.9% for specific food categories starting July 1, 2026. The chart of accounts and tax return mapping are also adjusted so businesses can continue reporting these transactions correctly.
Original PR description
From first of July 2026, the VAT will change from 10% to 4.9% for some food categories. Adapt the taxes, the CoA and the tax return accordingly. task-6273259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272667 Forward-Port-Of: odoo/odoo#268278
This update makes KSeF invoice retrieval more resilient when one invoice causes an error, so other bills can still be fetched. It also helps users by keeping a draft reference for problematic bills, and fixes cases where invoices from different companies could conflict or where the retrieval window was too large.
Original PR description
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no…
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no clue that there is a bill on KSeF that they have to fetch manually. --- 1. Save the bill on a savepoint, to make sure one problematic bill doesn't affect others 2. Create all bills as draft first so that users have a reference to fallback to in case the have to do manual fetching. --- task-6310321 --- ### Commit 2: Issues: 1. For a db with company_1 and company_2, when company_1 sends an invoice to company_2 via KSeF (out_invoice with a ksef number), company_2 in the same database can't fetch the corresponding bill because there is a move with the same KSeF number. 2. The date difference between `from` and `to` in the `dateRange` must not exceed 3 months as explained in the documentation https://api.ksef.mf.gov.pl/docs/v2/index.html#tag/Pobieranie-faktur/paths/~1invoices~1query~1metadata/post Fixes: 1. Change the unique constraint and the domain to allow same KSeF number per different companies. 2. Minimize the `to` parameter with `from` + 2 months. 3. Increase the TIMEOUT to 30 seconds as 10 seconds is too small. task-6260645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272665 Forward-Port-Of: odoo/odoo#270511
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
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
9 changes
Enhancements to existing features
This update adjusts Austria’s tax rates for certain food categories from 10% to 4.9% starting July 1, 2026. It also updates the related chart of accounts and tax return setup so reporting stays accurate and compliant with the new rules.
Original PR description
From first of July 2026, the VAT will change from 10% to 4.9% for some food categories. Adapt the taxes, the CoA and the tax return accordingly. task-6273259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272642 Forward-Port-Of: odoo/odoo#268278
The Polish KSeF import process now keeps working even if one bill causes an error, so other bills can still be retrieved. It also creates draft records first, giving users a visible fallback when a bill needs to be fetched manually. In addition, KSeF fetching was adjusted to better handle multi-company databases and longer request ranges.
Original PR description
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no…
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no clue that there is a bill on KSeF that they have to fetch manually. --- 1. Save the bill on a savepoint, to make sure one problematic bill doesn't affect others 2. Create all bills as draft first so that users have a reference to fallback to in case the have to do manual fetching. --- task-6310321 --- ### Commit 2: Issues: 1. For a db with company_1 and company_2, when company_1 sends an invoice to company_2 via KSeF (out_invoice with a ksef number), company_2 in the same database can't fetch the corresponding bill because there is a move with the same KSeF number. 2. The date difference between `from` and `to` in the `dateRange` must not exceed 3 months as explained in the documentation https://api.ksef.mf.gov.pl/docs/v2/index.html#tag/Pobieranie-faktur/paths/~1invoices~1query~1metadata/post Fixes: 1. Change the unique constraint and the domain to allow same KSeF number per different companies. 2. Minimize the `to` parameter with `from` + 2 months. 3. Increase the TIMEOUT to 30 seconds as 10 seconds is too small. task-6260645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272665 Forward-Port-Of: odoo/odoo#270511
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
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
8 changes
Enhancements to existing features
Austria’s tax settings are updated for a new VAT rate starting July 1, 2026, lowering tax from 10% to 4.9% for certain food categories. The chart of accounts and tax return rules are adjusted so invoicing and reporting stay accurate under the new rules.
Original PR description
From first of July 2026, the VAT will change from 10% to 4.9% for some food categories. Adapt the taxes, the CoA and the tax return accordingly. task-6273259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272642 Forward-Port-Of: odoo/odoo#268278
This update makes KSeF bill retrieval more resilient when one bill cannot be processed. It also helps users see bills that still need manual attention, and improves fetching rules so bills can be retrieved correctly across companies and within KSeF limits.
Original PR description
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no…
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no clue that there is a bill on KSeF that they have to fetch manually. --- 1. Save the bill on a savepoint, to make sure one problematic bill doesn't affect others 2. Create all bills as draft first so that users have a reference to fallback to in case the have to do manual fetching. --- task-6310321 --- ### Commit 2: Issues: 1. For a db with company_1 and company_2, when company_1 sends an invoice to company_2 via KSeF (out_invoice with a ksef number), company_2 in the same database can't fetch the corresponding bill because there is a move with the same KSeF number. 2. The date difference between `from` and `to` in the `dateRange` must not exceed 3 months as explained in the documentation https://api.ksef.mf.gov.pl/docs/v2/index.html#tag/Pobieranie-faktur/paths/~1invoices~1query~1metadata/post Fixes: 1. Change the unique constraint and the domain to allow same KSeF number per different companies. 2. Minimize the `to` parameter with `from` + 2 months. 3. Increase the TIMEOUT to 30 seconds as 10 seconds is too small. task-6260645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272665 Forward-Port-Of: odoo/odoo#270511
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
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
3 changes
Enhancements to existing features
This change makes Poland’s KSeF bill import more resilient when a single bill has issues, so the whole automated fetch process does not get blocked. It also ensures users still get a draft record as a fallback, and improves fetching rules so bills can be retrieved correctly across companies and within KSeF API limits.
Original PR description
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no…
### Commit 1: We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake 1. The cron gets stuck trying to fetch the problematic bill. 2. Users have no clue that there is a bill on KSeF that they have to fetch manually. --- 1. Save the bill on a savepoint, to make sure one problematic bill doesn't affect others 2. Create all bills as draft first so that users have a reference to fallback to in case the have to do manual fetching. --- task-6310321 --- ### Commit 2: Issues: 1. For a db with company_1 and company_2, when company_1 sends an invoice to company_2 via KSeF (out_invoice with a ksef number), company_2 in the same database can't fetch the corresponding bill because there is a move with the same KSeF number. 2. The date difference between `from` and `to` in the `dateRange` must not exceed 3 months as explained in the documentation https://api.ksef.mf.gov.pl/docs/v2/index.html#tag/Pobieranie-faktur/paths/~1invoices~1query~1metadata/post Fixes: 1. Change the unique constraint and the domain to allow same KSeF number per different companies. 2. Minimize the `to` parameter with `from` + 2 months. 3. Increase the TIMEOUT to 30 seconds as 10 seconds is too small. task-6260645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272518 Forward-Port-Of: odoo/odoo#270511
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
1 change
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
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
1 change
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
2 changes
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
2 changes
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.