Thursday, July 3, 2025
19 changes · saas-18.1
Resolved issues and error corrections
Fixes an error that could stop CRM users from converting multiple duplicated leads into opportunities when deduplication is enabled. The conversion now skips leads that were already merged, allowing the process to complete reliably.
Original PR description
Currently, when mass converting leads that contain duplicates, you are met with an error. ### Steps to reproduce * Install `crm` * Activate leads in CRM settings * Pick a lead in the list of leads…
Currently, when mass converting leads that contain duplicates, you are met with an error. ### Steps to reproduce * Install `crm` * Activate leads in CRM settings * Pick a lead in the list of leads and duplicate it * Select both the original and the duplicate leads → Action → Convert to Opportunity * In the wizard, ensure that "Apply deduplication" is enabled You will be met with the following error message: ``` Missing Record Record does not exist or has been deleted. (Record: crm.lead(...), User: ...) ``` ### Cause When mass converting leads with "Apply deduplication" enabled, the system processes each selected lead and attempts to deduplicate it by merging it with matching leads and deleting the duplicates. However, if one of the selected leads is also identified as a duplicate and gets deleted earlier in the loop, the process fails when it later tries to access the already-deleted lead. Although logic to skip already processed leads exists, there's a small mistake: it compares the lead record (`lead`) to a set of IDs (`merged_lead_ids`), which always fails. opw-4893775 Forward-Port-Of: odoo/odoo#216527
This fix restores a missing validation when converting quantities between units of measure. It helps prevent incorrect stock quantity calculations when units do not share a valid reference, reducing the risk of inventory inconsistencies.
Original PR description
With the removal of uom categories, the uom factor can only be valid if the uoms have a common reference somewhere but the [validation](https://github.com/odoo/odoo/blob/794c0cfd6fee2e674d244951bc0576f639eed392/addons/uom/models/uom_uom.py#L225-L227) was not replaced. This fix adds back the validation when a quantity needs to be computed in a different uom. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant point of sale preparation printers now produce a separate receipt when ordered items are cancelled or reduced. This helps kitchen staff see both newly ordered items and cancelled items, reducing missed updates and preparation errors.
Original PR description
Steps to reproduce: -------------------------- - Install POS restaurant & configure a preparation printer. - Open a session, order item A with some quantity from table X. - Again open table X & remove some qty of item A and add some qty of item B. - Order the changes. - On the preparation printer the cancelled KOT for item A won't appear. Issue: -------- - No receipt printed for the items which are cancelled. Cause: --------- - We have conditioned the printing in a way that if we found something new or if mode is updated rest prints won't be printed. Fix: ----- - Now we will have 2 receipts one for the new ordered items and the another with cancelled items. Task: 4805293 Forward-Port-Of: odoo/odoo#210776
This fix prevents refunds in Point of Sale from being paid with an online payment method, which is not supported. It helps avoid a situation where a cashier or manager can complete such a refund but then cannot close the POS session afterward.
Original PR description
**Problem:** When refunding an order that has been done in the frontend from the backend, then when trying to pay for it again using an online payment method, it will currently work. The problem is…
**Problem:** When refunding an order that has been done in the frontend from the backend, then when trying to pay for it again using an online payment method, it will currently work. The problem is that doing this will prevent the user from closing their session afterwards. The issue is that refunding through online payment method is not supported but is going though either way. **Steps to reproduce:** - Have an online payment method. - Go to your POS session and make a purchase, pay for it in cash. - Go back to the backend, to orders and chose your order. - Return the products and click payment to pay for it again. - Chose your online payment method and make the payment. - Try to close your POS session, an error prevents you from doing so. **Why the fix:** The problem is that an error should be thrown when trying to pay the refund with an online payment method. But this error is never reached. It was reached before this commit https://github.com/odoo-dev/odoo/commit/2dce0f22e92299b17162343e3629dcdab8a697b5 This commit is fixing an error that has since been avoided by this commit https://github.com/odoo-dev/odoo/commit/0c8f0d730465028657ff8da28e7ab14e2df08f69 The use case does not even go through the fixed *create* function anymore, so there should be no problem reverting the fix. Before said commit, we set the *online_account_payment_id* whether it exists or not. This then allows us to check if one of them is None later on. If it is, it means we can't create the online payment, as we can't create one without an accounting payment. After said commit, we didn't add it if the accounting payment didn't exist, so the error was never thrown as the code couldn't be reached. opw-4815049 Forward-Port-Of: odoo/odoo#213117
Vendor credit notes used to be added as positive landed costs, which could overstate inventory value. This fix keeps refund amounts negative so stock valuation is reduced correctly and duplicate cost effects are avoided.
Original PR description
Before this PR, creating a landed cost in the following scenario incorrectly increased the stock valuation instead of reducing it: - Create a Purchase Order with a valuated product and a landed cost…
Before this PR, creating a landed cost in the following scenario incorrectly increased the stock valuation instead of reducing it: - Create a Purchase Order with a valuated product and a landed cost product in the order lines. - Validate the receipt of the PO. - Create the vendor bill from the PO and confirm it. - Create a landed cost from the vendor bill by clicking "CREATE LANDED COSTS" and selecting the receipt in the landed cost. - Validate the landed cost. - Create a credit note from the vendor bill. - Create a landed cost from the credit note by clicking "CREATE LANDED COSTS" and selecting the same receipt. - Validate the landed cost. In this scenario, the refund amount is treated as a positive landed cost, causing the stock valuation to increase again. This can lead to the landed cost being applied twice by mistake, overstating inventory value. After this PR, the landed cost line amounts for credit notes are correctly set as negative, which reduces the stock valuation instead of increasing it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr OPW #4844792 @qrtl QT5401 Forward-Port-Of: odoo/odoo#216602 Forward-Port-Of: odoo/odoo#212669
This change prevents errors when creating records that use mail aliases, such as projects, in multi-company setups where one company has no email domain configured. It ensures the missing domain is treated as empty instead of incorrectly reusing another company's domain, making app installation and setup more reliable.
Original PR description
Before this commit, creating a mail alias mixin (typically a project) with an unspecified domain in a multi-company setup could lead to access errors "We could not create alias Inactive Alias because domain <client domain> belongs to company <company 1> while the owner document belongs to company <company 2>" Steps to reproduce: 1. Start with a clean DB 2. install an app that uses mail (e.g. CRM or Project) 3. Create a second company 4. Set a domain for the 1st company (the one created by default) 5. Erase the domain of the second company (the one created at step 3) 6. Try to install the Field Service app After this commit, not specifying the domain gets correctly interpreted and a default None value is used. opw-4051655 Forward-Port-Of: odoo/odoo#173999
This fix prevents checkout errors when a website has delivery methods tied to different companies or with no company set. Customers can now select valid delivery options consistently, reducing failed orders caused by company assignment mismatches.
Original PR description
Description of the issue/feature this PR addresses: Error during checkout when using delivery methods with mixed company assignments. Current behavior before PR: If you create a delivery method assigned to company X, and then create another without a company (i.e., assigned to the website company or left empty), the checkout process fails when trying to select a delivery method. Steps to reproduce: 1. Create a delivery method and assign it to company X. 2. Create another delivery method with no company or assign it to the website's company. 3. Go to the website and try to place an order. 4. The checkout will fail when selecting the delivery method. Desired behavior after PR is merged: Checkout handles delivery methods consistently, even when companies are mixed or missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216917 Forward-Port-Of: odoo/odoo#216515
Work entries created for employees in another selected company now use the employee's company instead of the user's default company. This prevents payroll and HR records from being linked to the wrong company in multi-company setups.
Original PR description
BUG - when you select 2 companies in the multi company widget (A & B, default : A) and I create a work entry for an employee of company B. The work entry will be related to company A. Expected behavior: - The default company should be the employee one if has a one FIX - check if the employee has a company add it to the create vals_list Task: 4781100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209011
This fixes an issue in Point of Sale where manually entering payment amounts with shortcut buttons could produce the wrong total. Cashiers can now combine quick amount buttons and number keys reliably, reducing payment entry mistakes at checkout.
Original PR description
Steps to reproduce: =================== - Add a product to the orderline from the product screen - Click payment - Select any payment method - Enter the amount manually - Press `+20`, then press `2`, OR press `+20`, then press `6` Issue: ====== - In the case of `+20` and `2`, the expected result is `202`, but we get `20` - In the case of `+20` and `6`, the expected result is `206`, but we get `20.01` Cause: ====== - `formatCurrency` is used for the buffer, but the buffer should not depend on the currency Fix: ==== - Remove the usage of `formatCurrency` and treat the buffer as a string Task: 4850543 Forward-Port-Of: odoo/odoo#216942 Forward-Port-Of: odoo/odoo#213294
Portal users are no longer shown as if they are the same person as the logged-in user when accessing messages through a portal token. This reduces confusion in chatter, messages, mentions, and related actions while still allowing authorized portal actions such as editing or deleting messages.
Original PR description
Since [1], discuss considers both the logged in and the portal partner as "self". However, even if the token grants access to act as the portal partner, it doesn't mean that both users are the same. Visually, it's confusing that every hint in the UI assimilate the current user to the portal partner (messages, mentions, ...). This commit fixes that by separating the concept of portal partner and "self". The user providing the portal token can access portal partner actions (editing/deleting message) but is considered a different user. [1]: https://github.com/odoo/odoo/pull/211204 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#217062
Fixes a website navigation issue where mega menus could close before visitors reached them when using the rounded box menu style with hover-based submenus. This makes website menus easier to use and prevents visitors from losing access to menu content unexpectedly.
Original PR description
Scenario: - edit navigation bar to "Rounded box menu" (header_boxed_opt) - select option "Sub Menus" to "On Hover" - add a mega menu - outside of editor, hover the mega menu item and move mouse over…
Scenario: - edit navigation bar to "Rounded box menu" (header_boxed_opt) - select option "Sub Menus" to "On Hover" - add a mega menu - outside of editor, hover the mega menu item and move mouse over it Result: the mega menu content closes before we get to it. History: In saas-18.1 and saas-18.2, these menus with the show on hover have been broken and fixed through different changes: (A) normal popup menu (B) all mega menu (C) mega menu with header_boxed_opt menu bar Here is the list of commit and what was broken after them: - 671515811436a01ea8931d4aa92b62608f8aec90 (nov 2024): C - b9b3a605e0f4c5da3a258c980107d6162da7f44f (jan 2025): A+C - ddf071267bd8aca341cb9b7481f3153a254212e7 (apr 2025): B+C - e65d4cf16a2e973482497c3d9d405b566007e705 (apr 2025): C And hopefully this commit will fix C that happen since in 671515811436a01ea8931d4aa92b62608f8aec90 where we added a !important margin-top to the mega menu in case of header_boxed_opt header that is causing issue C. We do not the the change for a menu inside .o_mega_menu_is_offcanvas because in this case "header_sidebar_opt" doesn't need the fix and needs to have a margin-top because: - it is in the margin-top space that the go back button is - the height is computed taking into account the margin-top, so if we removed it the height of the megamenu+margin-top would not be 100% and there would be a gap at the bottom opw-4876149
Barcode receipts now correctly update an existing product line when a matching package barcode is scanned, instead of creating a duplicate line. This helps warehouse teams keep receipt quantities accurate and avoids extra cleanup during barcode processing.
Original PR description
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable…
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable "Units of Measure & Packagings" - Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional) - Inventory > Configuration > Product > Units & Pacakagings - Click on pack of 6 > Packaging Barcodes > New - Create a new one for your product - Create and confirma receipt for 6 units of your product - Go to the barcode app and scan a pack of 6 #### > A new line 1 pack of 6 was created rather than updating the already existing one. ### Cause of the issue: When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753 ### Note: This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466 ### opw-4866981
The UAE payroll calculation now matches the government end-of-service calculator by applying the full 30-day compensation only after completing the sixth year of service. This helps ensure employee final settlement amounts are calculated correctly and consistently with local guidance.
Original PR description
- to algin with UAE goverment eos calculator, salary rule is update to concider full 30 compensation after completing the 6th year not the 5th. Task: 4756963 Forward-Port-Of: odoo/enterprise#84752
This fixes an issue where GSTR-2B JSON files attached during bill creation were not properly linked to the new bills, causing users to see a 404 error when opening them. Bookkeepers can now access these attachments directly from the related bills after matching.
Original PR description
**Before this PR:** - The GSTR-2B JSON was attached to the message but not linked to the newly created bills (`res_id` was not set). - As a result, when a Bookkeeper user created a new GSTR-2B bill and tried to open the attachment, it raised a 404 error: `"The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again."` **After this PR:** - The issue is resolved. - During GSTR-2B matching, unattached message attachments are now properly linked to the newly created bills by updating their res_model and res_id fields. Task ID : 4831758 Forward-Port-Of: odoo/enterprise#89250 Forward-Port-Of: odoo/enterprise#86785
Open shifts created when copying planning schedules now calculate hours correctly when an employee is on leave. This prevents lunch breaks from being counted as extra working time, keeping allocated hours accurate for planners and managers.
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#88411
Forward-Port-Of: odoo/enterprise#73478Bookkeeper users can now process automatic follow-ups and send manual reminders even when a customer is missing an email or address. This prevents access errors during overdue invoice follow-up workflows and helps teams continue collection actions without administrative intervention.
Original PR description
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic…
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic Follow-ups For the Automatic Follow-ups action, the user wasn't able to access the 'missing information view' For the Followup Button (manual_reminder), that's in the follow-up report view, the user wasn't able to access either the 'manual_reminder view' or the 'missing information view' ## Steps in runbot 17.0: - Create an invoice with a past due date and a new customer (leave email empty) - Go in Accounting > Customers > Follow-up Reports - Select the In need of action report for your new customer - In Actions, click on Process Automatic Follow-ups - An AccessError should be displayed ## To test the manual reminder: - Create the invoice as before and go to Follow-up Reports - Open the report linked to your new customer - Click on the Follow up Button - An AccessError should be displayed opw-4848745 Forward-Port-Of: odoo/enterprise#88168
The Work Entries Analysis report now respects the selected companies in multi-company environments. This prevents users from seeing payroll report data for companies outside their current selection, improving reporting accuracy and data separation.
Original PR description
BUG - In multi-companies env the report shows all the companies no matter what is selected in the company selection menu Expected behavior: - Only selected company data is presented in the view FIX - add a domain to the report action to show only allowed companies data Task: 4781100 Forward-Port-Of: odoo/enterprise#85690
This fix prevents the selected rental period from shifting when shoppers add another rental product to their cart, especially for users in time zones ahead of UTC. It helps ensure customers see and keep the dates they chose, reducing cart confusion and potential booking errors.
Original PR description
## Version
18.0
saas-18.1
Fixed from saas-18.2 thanks to commit 951433846e18e77a3d468af1f005b5c8e224ef89
## Issue
If user's timezone is in UTC+X, rental period changes after adding 2nd rental product to cart.
## Steps to reproduce
- Go to Rental App:
- Via `Products` create 2 rental products (`Product A` and `Product B`):
- Under the `Rental prices` tab, add a new pricing with a `Daily` period;
- Publish the products.
- Go to website's shop:
- Look for `Product A`:
- Select a one-day period (same date for start and end dates);
- Add the item to cart.
- Look for `Product B`:
- Click `Add to cart` button and see the end date change for the next day.
opw-4744250
Forward-Port-Of: odoo/enterprise#87401EasyPost shipping labels now include the related Odoo delivery reference where carriers support custom label text. This helps users match physical labels and carrier dashboard entries with the correct Odoo delivery, reducing confusion during fulfillment.
Original PR description
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the…
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the corresponding Odoo move. Steps to reproduce ----- - Set an Easypost delivery method up - Create a sale - Add delivery product & get a rate - Confirm the sale - Go to the linked delivery & confirm it --> The printed label has no reference field Discussion ----- As per EasyPost: > The reference field within the shipment body is used for transmissions of electronic data between the shipper and EasyPost, and typically does not get expressed anywhere on the physical label. To get data to the label, you need to leverage the "print_custom" fields outlined in the options section of the shipment. See also https://docs.easypost.com/docs/shipments/options Visual comparison ----- DPD UK labels, before and after the change:  USPS labels, before and after the change:  ----- Ticket: opw-4681615 Forward-Port-Of: odoo/enterprise#88941