Friday, May 30, 2025
9 changes · 18.0
Enhancements to existing features
When a contact is moved under a different parent company, related accounting entries are updated to match the new commercial partner. This keeps receivables and payables reporting consistent, while limiting the action to users with Accountant permissions.
Original PR description
- Update accounting entries to reflect the new commercial_partner_id: * Ensures consistency across account.move.line and partner_id fields. * Changes are restricted to users in the Accountant group. 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
Restaurant staff can now switch individual UrbanPiper delivery platforms online or offline directly from the point of sale. This helps businesses quickly pause or resume specific aggregators without going into backend settings, with notifications confirming each change.
Original PR description
Following this commit : ==== - An online/offline toggle option is provided for the food delivery dropdown. - If the user has configured more than one provider and wishes to close/off one of the aggregator, then without going on the backend from the UI itself, the user can offline that particular provider and vice versa. task-4582032
The EC Sales List now warns users when multiple partners share the same VAT number, helping prevent inaccurate Intrastat submissions. Users can identify highlighted duplicates and choose a main partner to consolidate related records and keep reporting consistent.
Original PR description
When submitting the EC Sales List via Intrastat, redundant partner entries with the same VAT number (but different commercial entities) may lead to inaccurate reporting and validation issues. - Detecting partners with duplicate VAT numbers. - Displaying a warning banner at the top of the report when duplicates are present. - Highlighting duplicated partners in the report with a yellow background. - Adding a "Set as main" button to duplicated rows, allowing users to set a partner as the commercial partner for all others sharing the same VAT. task-4707491
Resolved issues and error corrections
Odoo now avoids showing push notifications when a user is already focused on the relevant mail conversation. This reduces duplicate alerts and makes the Discuss/chat experience less distracting.
Original PR description
**Current behavior before PR:** Push notifications are shown even when the user is already viewing the same conversation in the Discuss app or in the ChatWindow. The Service Worker does not currently…
**Current behavior before PR:** Push notifications are shown even when the user is already viewing the same conversation in the Discuss app or in the ChatWindow. The Service Worker does not currently check whether the conversation is focused, leading to redundant and unnecessary notifications. **Desired behavior after PR is merged:** The Service Worker now intelligently checks the state of the Discuss and ChatWindow before displaying push notifications. Notifications are only shown when the user is not actively focused on the same conversation. The updated logic ensures: - Chat bubble minimized and tab focused → Show - Chat window open, tab focused, but a conversation not focus → Suppress - Chat window open, tab focused, the conversation is focused → Suppress This behavior is achieved by the Service Worker sending a message to the client window to get the active thread and its focus status before deciding whether to show a notification. This results in a cleaner user experience by avoiding redundant alerts when they’re not needed. task-[4582533](https://www.odoo.com/odoo/my-tasks/4582533) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This updates Odoo’s spreadsheet engine to the latest version, bringing targeted fixes for spreadsheet users. It improves autocomplete dropdown readability and addresses an issue with pivot charts when fields contain a mix of text and numbers, helping reports remain clearer and more reliable.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d201086ee [REL] 18.0.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d201086ee [REL] 18.0.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ab92eab3c [REV] pivot: chart field with mix of text and numbers [Task: 4800411](https://www.odoo.com/odoo/2328/tasks/4800411) https://github.com/odoo/o-spreadsheet/commit/5831ad228 [FIX] autocomplete_dropdown: Improve dropdown readability [Task: 4813433](https://www.odoo.com/odoo/2328/tasks/4813433) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents portal token access from changing the global chat user identity. It keeps live chat and portal conversations separate, avoiding stalled chatbots or messages appearing under the wrong user after redirects.
Original PR description
*: portal, portal_rating, test_mail_full. Before this commit, the chat bot could stop when redirecting to a page where the portal is enabled. Both the portal and live chat modules rely on the discuss store’s `self` field which identifies the authenticated user. However, the portal also supports authentication via a token in the URL, which temporarily identifies the user on a specific thread. Previously, the portal would overwrite the global `self` value, causing inconsistencies for other users of the store such as messages appearing as if sent by another user. Since token authentication is specific to portal threads, it should only affect actions on the granted thread without altering the global user identity. This fix prevents the portal from overwriting the global `self` value and instead returns the thread-specific `portal_partner` field. opw-4722466
This fix prevents Point of Sale sessions from getting stuck when a loyalty reward has an invalid product rule. Instead, the shop opens normally and staff see a clear warning so they can continue serving customers while the reward configuration is corrected.
Original PR description
Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is…
Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is unable to open and keeps loading with an error visible on the console. This is because when the session tries to open, the compute_discount_product_ids method is called which runs into an error because it cannot use the domain. Ideally, the pos screen should still load and give an alert message saying “The reward "xxx” contains an error in its domain, your domain must be compatible with the PoS client” and after closing the popup, the pos shop can be used however this does not happen as the code line for deleting the erroneous loyalty reward runs into an error because the delete method expects a record but receives an id. The alert message written before never appears because this delete statement runs into an error.
Purpose: Passing the correct argument to the delete function so that the loyalty program with issues in domain can be properly deleted from loaded models. After this correction, the pos session will load and there will be an alert warning the user of the reward error.
Steps to Reproduce on Runbot:
1. Choose any discount program for the pos shop. Open the reward pop up and choose to put the discount on specific products.
2. Edit domain in the “Discount Product Domain” and put <Products> <contains> <screen> in the rule `[("product_variant_ids", "ilike", "screen")]`. We can see 3 records here on the reward.
3. Save and close the program screen. Open the pos shop and check the console. The screen keeps loading and there is a traceback error in the console.
opw-4350676
opw-4352567
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSubcontracted manufacturing orders now automatically record the receipt that triggered their creation. This restores traceability between related manufacturing orders, making it easier for teams to follow subcontracting flows and investigate issues.
Original PR description
This commit ensures that the 'Source' field of a subcontracted MO is automatically filled with the name of the receipt that led to its creation. Steps to reproduce the bug: - Create a storable…
This commit ensures that the 'Source' field of a subcontracted MO is automatically filled with the name of the receipt that led to its creation.
Steps to reproduce the bug:
- Create a storable product “P3”:
- route: Drop-ship
- Vendor: vendor P3
- BoM:
- type: subcontracting
- Subcontractors: Vendor P3 - Components:
- P2:
- Vendor: Vendor P2
- Route: drop-ship subcontractor on order
- BoM:
- Type: Subcontracting
- subcontractor: Vendor P2
- Components:
- P1:
- Vendor: Vendor of product P1
- Route: Drop-ship subcontractor on order
- Create a quotation:
- Customer: Azure Interior
- Product: P3
- Confirm the quotation -> A purchase order is created for P3
- Open the PO
- Confirm it
- A purchase order is created for P2, and an MO is generated for P3
- Confirm the PO for P2 → an MO is created for P2
Problem:
The Origin field is not set for either MO, preventing the linkage between parent and child MOs.
Backport of:
https://github.com/odoo/odoo/commit/cca6c7abc1adcf688123a1e41033a3e25daf8d6a
opw-4788501Receipts for Indian point-of-sale transactions now display the tax percentage alongside the tax type. This makes receipts clearer for customers and improves accuracy for tax transparency and compliance needs.
Original PR description
Before this commit: ==== - Previously, only the tax type was displayed on receipts and the tax percentage was missing for Indian localisation. Following this commit: ==== - The tax percentage is now displayed alongside the tax type on receipts, improving transparency and accuracy. task-4464136