Daily updates from Odoo
Friday, June 26, 2026
18 changes · 18.0
Enhancements to existing features
This update prepares the Austrian localization for a VAT change effective July 1, 2026, reducing the rate from 10% to 4.9% for certain food categories. It also adjusts the related chart of accounts and tax return mapping so accounting and reporting stay correct.
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#268278
This change makes KSeF bill retrieval more resilient when one bill causes an error, so the whole import process does not get blocked. It also helps users keep track of bills that need manual follow-up and improves handling of edge cases between companies and date 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
Resolved issues and error corrections
This change fixes a visibility issue in Field Service where customers created under a parent company could not be selected when working from one of its branches. It now correctly recognizes the parent company relationship, so users can choose the expected customer record and continue their work without interruption.
Original PR description
**Steps to Reproduce:** 1. Create a branch under an existing company. 2. Create a contact in company (so the contact is visible only to the company). 3. Switch to the branch of the company. 4. Open Field Service and create a new record. 5. In the *Customer* field, try to select the contact created earlier. **Issue:** The contact created under the company is not selectable in the *Customer* field in Field Service. **Current behaviour:** The same contact is visible in the Contacts app, and also selectable in Sales Order — but not in the Field Service. **Expected behaviour:** The contact created under the company should be selectable as a customer in Field Service when the current user is operating from that branch. **Fix:** Modified the condition of python constrains to check parent company also. **Task-5114444**
This fix makes sure recurring products cannot be added to a sales order without a subscription plan, whether they are added manually or through the product catalog. It prevents inconsistent behavior and avoids orders being saved in an invalid state.
Original PR description
Steps to reproduce: --------------------------------------- 1. Install Subscription Module 2. Create and Confirm SO with no recurring plan and a non-recurring product 3. Add a recurring product >…
Steps to reproduce: --------------------------------------- 1. Install Subscription Module 2. Create and Confirm SO with no recurring plan and a non-recurring product 3. Add a recurring product > Save SO > Observe the User Error 4. Now add the same recurring product through Catalog View Observation: --------------------------------------- No User Error raised stating 'You cannot save a sale order with recurring product and no subscription plan.' Issue: --------------------------------------- When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177 When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint. https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933 Solution: --------------------------------------- Two private helpers are introduced: * `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders). * `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync. `_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points. opw-6194865 Forward-Port-Of: odoo/enterprise#117879
This change prevents an error that could happen when upgrading databases using the Italian accounting reports. It cleans up outdated report entries before the upgrade runs, so the update completes successfully without duplicate-label conflicts.
Original PR description
Steps to reproduce: - Create a database with `l10n_it_reports` on a version before PR #264294 - Switch to current `17.0` - Upgrade module `l10n_it` - An error is raised Upgrading a database with `l10n_it_reports` installed raises an error if the database was created before that PR In that PR, we modified the formulas of several report expressions to use subformulas instead of simple aggregations. During upgrade, the ORM attempts to insert the updated expressions while the old ones still exist, violating the UNIQUE constraint on `(report_line_id, label)` in `account.report.expression` Only happens on upgrade, not on a fresh install. A migration script is added to delete the outdated expressions before the upgrade runs Ticket [link](https://www.odoo.com/odoo/project.task/6299385) opw-6299385 Forward-Port-Of: odoo/odoo#271320
This update corrects how the Intrastat report handles companies without a country set. It prevents the report query from failing, so users can generate the report reliably in that configuration.
Original PR description
When there is no `country_id` on the company we get `False`. The generated query then fail at: ``` ... CASE WHEN (code.country_id IS NULL OR code.country_id = false) THEN code.code ELSE NULL END AS commodity_code, ... ``` with: ``` ERROR: operator does not exist: integer = boolean LINE 12: ... WHEN (code.country_id IS NULL OR code.country_id = false) T... ``` Forward-Port-Of: odoo/enterprise#121608
This change prevents a contact list from failing to open when users work across multiple companies. It ensures meeting information is calculated only from records the user is allowed to see, so browsing contacts remains smooth and access-safe.
Original PR description
### Steps to reproduce: - Download Calendar and Contacts app - Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies - Go to the Setting -> Users -> Manage…
### Steps to reproduce: - Download Calendar and Contacts app - Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies - Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies - Create a another user who also have access to both companies - Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field - Switch the company of the logged in user to the other company - Open the test contact form, use the meeting smart button and create a new meeting - Open the kanban contact view **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.** ### Cause of Issue: When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user. ### Fix: Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope. Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance. opw-5874204
This update corrects the email verification banner on public forum profiles so it uses the logged-in account instead of the profile being viewed. As a result, users no longer see another person's private email address in the confirmation message.
Original PR description
**Steps to reproduce:**
- Install website_forum module
- Create a new portal user and log in with it
- Go to the website forum to see that the account requires email verification
- Send the verification email to see the green banner ('an email was sent to XX')
- Add XP (karma) points to this user as admin (User > Smart actions > Karma)
- Switch back to the portal account
- Check any public user profile on the forum (`/profile/user/2?forum_id=2`)
- Green banner now displays the private email of the user you're checking
**Issue:**
On the `email_validation_banner` the user field is used for the validation
data, but it is overridden by `_prepare_user_profile_values` which is
setting the current page user.
**Fix:**
Properly set `user` to `env.user` in the template.
opw-6276809Neutralized databases will now use the test VIES endpoint instead of the live production service when no demo data is present. This reduces the risk of sending checks to the real external service during testing or database neutralization, while leaving any custom endpoint settings unchanged.
Original PR description
Neutralized databases don't always have demo data, so they talk to production VIES endpoint. With this change, the production endpoint is replaced with the test one. If some database has a custom endpoint, nothing is done. @moduon MT-15142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that invoices only keep the delivery notes that match the quantity actually invoiced. It prevents extra delivery references from appearing on partial invoices, which avoids inconsistencies in the exported accounting documents.
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
Swiss invoices will now generate a payment reference even when the customer is outside Switzerland or Liechtenstein. This ensures the invoice PDF still displays the payment communication and bank details, making payment easier and avoiding missing information on the document.
Original PR description
Issue: When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the…
Issue: When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details. Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country. Steps to reproduce: - Configure a Swiss company with a QR IBAN bank account - Set the sales journal Communication Standard to Switzerland - Create and confirm an invoice for a non swiss customer (US, BE) - Observe in the pdf and in the other info tab -> no payment reference or payment details Cause: `get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated. Solution: Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency. opw-6222417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a customer adds an online payment option to an order that was already synchronized, the system now sends the updated order information again. This ensures the customer is charged the correct, latest amount after changes like increasing the order total.
Original PR description
When an online payment line is added, the order is synced to the server so the customer can pay it online. This sync was only performed when the order did not yet exist on the server (string id). As a result, once an order had already been synced, modifying it (e.g. increasing the amount) and adding the online payment line again did not push the new amount to the server. opw-6314690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error that could appear when a user clears the currency field while registering a payment for Argentine withholding. It makes the payment process more reliable and avoids an unexpected traceback in this workflow.
Original PR description
When the user removes the currency from the payment register, a traceback is raised. Steps to reproduce the error: - Install ``l10n_ar_withholding`` module - Switch to ``(AR) Exento`` company - Create a new invoice > Confirm > Pay > Unset the currency Traceback: ```py ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/l10n_ar_withholding/wizards/account_payment_register.py#L27 This line causes a traceback with an empty currency when the user removes the currency from the payment register. sentry-7362499567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mailing campaigns now correctly count email bounces for contacts, even when the bounce notice comes from a different sender address. This improves the accuracy of campaign reports and helps teams better identify invalid or unreachable email addresses.
Original PR description
Previously, when a mailing campaign sent out an email to a mailing.contact, and that email bounced, the bounce would not increment the contact's bounce count. This commit makes it so that the bounce count is correctly updated when a mailing campaign sends an email that bounces. task-4893615
When a user signs in from a new device, the alert email will now be sent in that user’s chosen language. This fixes cases where the subject and email content could appear in the wrong language, improving clarity and consistency for users with 2FA enabled.
Original PR description
**Steps to reproduce:** - Enable 2FA - Change user language - Log in in another private window / device - Check the notification email of a login with another device - Email body/subject are not properly adapted to user language **Issue:** View manual rendering doesn't pass the user language. **Fix:** Add it to the context before `_render_template` and subject translation (reapply similar fix [1]). [1] https://github.com/odoo/odoo/commit/4d8d1736ca03a3d6b4e86cbc7463a79a284d1f3c opw-6042550
This change prevents the Repair app from failing during installation in certain database setups. It matters because it restores successful automated builds and avoids a blocking error when the app is installed without optional add-ons being loaded first.
Original PR description
Runbot builds on version 17.0 and 18.0 fail due to the lines below. These lines reference `move.sale_line_id` as the previous dependencies did not add `sale_line_id` to the `stock.move` model when using --skip-auto-install. https://github.com/odoo/odoo/blob/51824f462402d3d141bda2717402d1fdcf2e118b/addons/repair/models/stock_move.py#L97-L100 To reproduced the issue: 1. New blank database 2. ./odoo-bin -d [database-name] -i repair --skip-auto-install 3. See error in console Looking ahead to verison 18.1+ we see the dependencies change here: https://github.com/odoo/odoo/commit/f7dbdec11b74f8c7d969763d8c5cf09542a47f86 **Affects 17.0 and 18.0** Ticket [link](https://www.odoo.com/odoo/project/27948/tasks/6306099) This can also close this very, very old PR https://github.com/odoo/odoo/pull/189584 Forward-Port-Of: odoo/odoo#271901
The Italian Ri.Ba. payment flow now checks that the company SIA code is exactly 5 digits long. This prevents batch payment validation from failing with an error during XML generation when the code is too long.
Original PR description
Currently, the sia_code field on res.company lacks length validation. For Italian Ri.Ba (CBI) exports, this field MUST be exactly 5 characters. If a user enters more (e.g., during initial setup), the Batch Payment validation (specifically the XML file generation) crashes with a traceback. Steps to Reproduce: - Set Company SIA Code to 6+ characters - Create multiple payments with Ri.Ba. method - Create a Ri.Ba Batch Payment - Click 'Validate' Ticket [link](https://www.odoo.com/odoo/project.task/6031062) opw-6031062 Forward-Port-Of: odoo/enterprise#121610
Documentation and clarification updates
This update adds Djody Kort to the list of approved contributors under Codeforward B.V.'s existing corporate contributor agreement. It does not change product behavior, but it allows future Codeforward-authorized contributions to be accepted smoothly.
Original PR description
Adds me (Djody Kort) to the contributor list of the existing Codeforward B.V. Corporate CLA (`doc/cla/corporate/codeforward.md`). This precedes an upcoming `[FIX] service/server` bug-fix contribution. Codeforward's Corporate CLA v1.0 is already on file (signed by Sander Lienaerts), and I am authorized to contribute on Codeforward's behalf. Forward-Port-Of: odoo/odoo#269240