Thursday, November 20, 2025
26 changes · saas-18.3
Resolved issues and error corrections
When a purchase quotation is emailed from a company with its own website, the View Quotation button now opens the right website instead of the default one. This prevents customers from being sent to the wrong domain and improves the experience for multi-company setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Host a server with demo data on localhost; 2. create & switch to a second company; 3. have a website linked to the second company; 4. set the website's domain to http://2.localhost:8069; 5. create a purchase order; 6. send order via email; 8. open mail via Settings / Technical / Email / Emails. Issue ----- The "View Quotation" button links to the default URL instead of the second company's website. Cause ----- The button added via `_notify_get_recipients_groups` only adds a relative URL, which then defaults to the database's base url when sent. Solution -------- Use an absolute URL, using the order's `get_base_url` method. opw-5035391 Forward-Port-Of: odoo/odoo#236438 Forward-Port-Of: odoo/odoo#233255
The point of sale now loads only draft delivery orders when a session starts, instead of pulling in every delivery order. This reduces startup delays and improves overall performance for users. A console warning was also removed from the delivery button component.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99904This fix stops the system from crashing when a manufacturing order line is left without a product name and the schedule date is changed. It helps users continue editing draft or incomplete orders without running into an error.
Original PR description
The error arises when the user removes the product name from add a line and change the `Schedule Date`. Steps to reproduce: --- - Install `MRP` - Create a New MO - Add a product and confirm it - Add a product from add a line and remove the product name, and change the `Schedule Date` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0(v18.0)` When a move line has no `product_id`, its Unit of Measure (UoM) is also empty. Changing the date triggers computation, which causes an error due to these missing values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234884
Hover animations on website card images could leave visible white gaps around the image. This update keeps the image filling its container properly, so pages look cleaner when editors enable hover effects.
Original PR description
Step to reproduce: 1. Open website 2. Click edit button and drop s_three_columns snippet 3. Click image and change animation option into hover 4. Some extra white space shown. Before this commit: Applying a hover animation on card images caused the `object-fit` property to unintentionally switch from `cover` to `contain`, resulting in visible white borders around the image.This happened because of the `geo_square` shape, which is automatically injected when a hover effect is applied and no user shape is chosen. This behavior was intentionally introduced in PR [1]. After this commit: Now cropped images use object-fit: contain to preserve the visible properly. and after stretch option apply it can take cover of this container. so his ensures the image fully covers its container without leaving any white gaps. [1]:https://github.com/odoo/odoo/pull/119197 task:4875770 Forward-Port-Of: odoo/odoo#215766
This update makes the rating cards in Website Slides use the same background color as the rest of the page area. It improves visual consistency so the interface looks more polished and matches the website theme better.
Original PR description
PR #229272 sets the background color of the portal chatter to `body-bg`, aligning it correctly with the other parts of the chatter and website themes. However, `website_slides` module has a customized scss variable to change its main body background color which makes the background color for the rating cards (chatter top) being different in this module. This change sets the `--body-bg` in this customized scss to the same variable used for the background color, aligning the background colors with each other. Before: <img width="1182" height="552" alt="image" src="https://github.com/user-attachments/assets/6aba4609-e99c-48de-8af7-a97029859fab" /> After: <img width="1097" height="555" alt="image" src="https://github.com/user-attachments/assets/0d4ed53b-6d83-4eba-8499-0d38b10b4234" /> Forward-Port-Of: odoo/odoo#236527
This update corrects how invoice totals are recalculated when a currency rate is changed directly on the invoice. It ensures tax rounding stays consistent with the global rounding setting, so duplicated invoices keep the same balance and avoid small but important discrepancies.
Original PR description
- Set the tax rounding method to `'global'` in the settings. - Create an invoice in a foreign currency with: - Quantity: `0.80` - Unit Price: `894.34` - Currency rate set on the invoice: `1 / 1189.5` - This results in a journal entry balance of **851,051.57**. - Now set the currency rate directly on the currency instead. - Duplicate the invoice: the journal entry balance becomes **851,053.94**. The issue arises because _sync_tax_lines, triggered when setting the currency rate directly on the invoice, was computing the journal entry balance on a per-line basis, even though the tax rounding method was configured as global. opw-5012817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225407
This fix prevents Odoo Studio from crashing when a user adds a Selection field option without typing a value first. Instead of showing an error, the interface now handles the empty input safely, making field configuration more reliable and forgiving.
Original PR description
**Before this commit:** When a user added a new Selection field and clicked the “Add Selection” :white_check_mark: button without entering any value, a `Client Error: (Cannot read properties of undefined (reading 'trim'))` was raised, resulting in a crash of the Studio interface. **After this commit:** Clicking the “Add Selection” :white_check_mark: button with an empty input no longer triggers an error. task-5159376 Forward-Port-Of: odoo/enterprise#99783 Forward-Port-Of: odoo/enterprise#98767
This change moves a messaging override to the module that actually depends on portal features. It keeps the code structure correct and reduces the risk of future maintenance issues without changing how users interact with the feature.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module. Forward-Port-Of: odoo/odoo#236436 Forward-Port-Of: odoo/odoo#236249
This change prevents an error when validating a Sendcloud delivery after a down payment invoice has been created. It ensures non-product sale lines are ignored during customs price calculation, so delivery processing continues normally.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
This fix prevents the system from resetting the chosen warehouse when inter-company order options are changed. It ensures the warehouse previously selected by the user stays in place, which avoids confusion and keeps company settings consistent.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
This update prevents the message composer from failing when no message is attached to it during suggestion loading. It ensures the related thread is treated as unavailable in that case, which avoids an error and keeps suggestions working reliably.
Original PR description
This commit solves a runbot issue created by the debounced nature of the suggestion fetch. A composer could not have a message associated with it and was therefore failing to find the related thread. Now, the thread is set to undefined in that case since we do not need the result anyway. fixes-runbot-230311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236262
This update makes the point-of-sale black box integration more resilient when the device responds incorrectly or not at all. It now follows the documented retry behavior, which helps reduce failed transactions caused by temporary communication issues.
Original PR description
Following documentation, max timeout should be 1.5s and we should retry 3 times on every bb NACK/invalid data. Forward-Port-Of: odoo/enterprise#99705
The calendar day view no longer cuts off event titles on mobile devices. This makes it easier for users to quickly understand what each event is without opening it, improving readability and daily planning.
Original PR description
Before this commit, when the user goes to a calendar view in day to check what he have to do. He cannot see the event title properly in his mobile phone since the title is truncated. This commit makes sure the event title is not truncated to clearly see the whole event title. Before the fix: <img width="1172" height="802" alt="image" src="https://github.com/user-attachments/assets/f85a4a03-89a3-48c8-bda7-38e72854ce1f" /> After the fix: <img width="1179" height="808" alt="image" src="https://github.com/user-attachments/assets/7b0b31ba-10f5-412b-837b-8399c78c5bac" /> Forward-Port-Of: odoo/odoo#235823
Fixed an issue where the Timesheets stat button could show dramatically inflated values when timesheets were displayed in days or half-days. This ensures the totals now match the actual time entered, so managers see accurate information in Helpdesk team settings.
Original PR description
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4.…
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4. Open the team’s settings and observe the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the team’s settings and observe the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------ After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed. Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36 For ex: Consider unit_amount = 20 minutes: **Before** Case 1: Encoding method = Hours/Minutes (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 1 = 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 8 = 160 Days --> INCORRECT **After** Encoding method = Days/Half-days (unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor (20 * 1) / 8 = 2.5 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. **NOTE:** Before this change, when the user opened the timesheet sublist view in debug mode and clicked the View button, it opened the default form view of the `account.analytic.line` model instead of the intended timesheet form view. This allowed editing of the Unit of Measure (product_uom_id) field also. To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41). Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related community PR: https://github.com/odoo/odoo/pull/233803 Forward-Port-Of: odoo/enterprise#98545
The Profit and Loss report now correctly includes the new “Other Expenses” account type. This ensures these costs are shown in financial reports instead of being left out, giving a more accurate view of company expenses.
Original PR description
In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Profit & Loss Report. Since l10n_be is the only CoA which uses this account type, the issue was not uncovered until OXP testing days.
This change prevents an error from appearing in Documents when a related CRM record has already been deleted. Orphaned upload documents are now handled safely, so users can open the Documents app without seeing a traceback.
Original PR description
Steps to reproduce: - Install crm and documents - Go to CRM → Activity Types - Set a folder in the Upload Document activity - Create a CRM lead and schedule an upload document activity - Delete the created lead - Open the Documents module Issue: - A traceback occurs because web_read tries to access values_by_id[record.id], as the upload request document remains in the database after its related activity is deleted. Solution: - fix the recompute of res_name and set it to False, avoiding MissingError opw-5080182 Forward-Port-Of: odoo/enterprise#97461
Project dashboard timesheet totals now display the correct amount when the timesheet setup uses days or half-days. This fixes a conversion error that could show much larger values than expected, helping users trust the figures they see at a glance.
Original PR description
Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 20 hours) 4. Open the project dashboard…
Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 20 hours) 4. Open the project dashboard and check the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the project dashboard and check the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------- After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143 The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234 **Before** Case 1: Encoding method = Hours/Minutes Consider allocated_hours = 80 Hours, total_timesheet_time = 20 Hours Then: uom_ratio = 1/1 => 1 allocated = 80/1 => 80 Hours effective = 20/1 => 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days Consider allocated_hours = 80 Hours, total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it) Then: uom_ratio = 1/8 => 0.125 allocated = 80/.125 => 640 Days effective = 2/0.125 => 16 Days --> INCORRECT **After** Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method) and total_timesheet_time = 2 Days (already in days, no conversion). Then: uom_ratio = 1/8 => 0.125 allocated = 80*.125 => 10 Days effective = 2 => 2 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related enterprise PR: https://github.com/odoo/enterprise/pull/98545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233803
This fix prevents an error that could appear when reopening a page after adding or replacing a Vimeo video in the website editor. It ensures the editor can correctly handle the video item being passed between components, so users can edit and save pages without interruption.
Original PR description
Steps to reproduce: =================== 1- Website app > Open any page in Edit mode. 2- Drag a Video block into the page. 3- Paste a Vimeo video URL in the dialog and save. 4- Save the page, then…
Steps to reproduce:
===================
1- Website app > Open any page in Edit mode.
2- Drag a Video block into the page.
3- Paste a Vimeo video URL in the dialog and save.
4- Save the page, then re-open it in Edit mode.
-> traceback
Cause:
======
The Wysiwyg "openMediaDialog" passes the selected media DOM node as "media" to the MediaDialog.
The MediaDialog forwards that value as "media" prop to VideoSelector. VideoSelector declared "media" as "{ type: Object, optional: true }". Owl validates "type: Object" as a plain object, not as any "typeof object".
DOM elements such as HTMLImageElement do not pass this plain object check, so Owl raises an error.
Solution:
=========
Relax the "media" prop type in VideoSelector so DOM nodes are accepted. In web_editor VideoSelector, change the "media" prop to "{ optional: true }".
In html_editor VideoSelector, also keep "media" declared as "{ optional: true }".
opw-5239889
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236296This change updates the LinkedIn API version used by the social sharing integration. It was needed because the previous version was retired, helping ensure continued posting and account connection functionality for users.
Original PR description
This commit updates the linkedin version header so that we can use the version of the API. Our actual version was recently sunset, needing the change of version to be done. task-5271712 Forward-Port-Of: odoo/enterprise#99759
This fix ensures the POS uses the right component lines when calculating costs for products with variants in a Bill of Materials. As a result, orders for different variants now show the correct line costs, improving accuracy in reporting and inventory valuation.
Original PR description
When you create a product with atleast one variant that has 2 value, and create a BoM for this product that has 2 lines with each line having one of the two values, then create a POS order with one…
When you create a product with atleast one variant that has 2 value, and create a BoM for this product that has 2 lines with each line having one of the two values, then create a POS order with one unit of each variant, the cost of the first line not correctly computed. Steps to reproduce: ------------------- * Create a prodcut P with one attribute A that has two values A1 and A2 * Create a product C with no attribute and a cost of 10$ * Create a BoM for P with two lines: - Line 1: product C, quantity 1, only for attribute value A1 - Line 2: product C, quantity 2, only for attribute value A2 * Open a PoS session * Add Product P with attribute value A1 to the order * Add Product P with attribute value A2 to the order * Validate the order and close the session * Go to the order and check the cost of each line > Observation: The cost are not correct, they should be 10$ and 20$ Why the fix: ------------ Before this fix we were not taking the `bom_product_template_attribute_value_ids` into account when filtering the stock moves to consider for the cost computation. This value represent the attribute values that the product must have for this BoM line to be considered. opw-4765234 Forward-Port-Of: odoo/odoo#235502 Forward-Port-Of: odoo/odoo#225014
When a manufacturing order’s component quantity was changed, the system could incorrectly mark the component as already picked, which prevented reserving the needed stock again. This fix keeps the component available for reservation when no quantity has actually been consumed, avoiding blocked production orders.
Original PR description
Steps to reproduce the issue:
- Create a storable product “P1” with the following BoM:
- Component: - 1 unit of C1
- Update the quantity on hand of C1 to 10 units
- Create a manufacturing order to produce one unit of P1
- Confirm the order → The quantity of C1 is reserved, and the produced quantity of P1 is 0 (expected behavior)
- Update the component's quantity to consume (C1) to 2
- The consumed quantity is set to 0 and the move marked as picked
- Try to reserve the quantities again
Problem:
Since the move is picked, the
new quantity cannot be reserved.
Solution:
Prevent the move from being marked as picked when the consumed quantity is zero.
opw-5152592This update ensures that when a Point of Sale order linked to a sales order is refunded from the back office, the invoiced quantity is updated correctly on the sales order line. It helps keep sales and invoicing records accurate after refunds.
Original PR description
When doing a refund of a POS order linked to a SO in the backend, the qty_invoiced on the SO line is not updated correctly. Steps to reproduce: ------------------- * Create a SO with 1 quantity of any product * Settle the SO in the PoS * Refund the PoS order from the backend not from the PoS interface * Check the qty_invoiced on the SO line > Observation: The qty_invoiced is still 1 Why the fix: ------------ The method _compute_qty_invoiced was not triggered when the refunding order was paid. So we need to add a new dependency on the function. Note: ----------- In the test we need to flush all before doing the payment of the refund, because if we do not do it, the _compute_qty_invoiced method would be called during the payment. But that is not the case outside of the test. This is just to ensure that the test fails correctly without the fix. opw-4991405 Forward-Port-Of: odoo/odoo#235512 Forward-Port-Of: odoo/odoo#231840
This change prevents an error that could appear when a helpdesk team has no working hours set and a ticket is moved to Done or Canceled. It makes ticket closing more reliable by only applying the working-hours logic when a schedule is actually configured.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
When editing a website, discussion bubbles will now shift aside instead of covering the editor. This makes it easier to select and edit content, especially for users with many active conversations.
Original PR description
Before this commit, discuss bubbles would appear on top of the editor when editing a website. I was therefore be difficult to select some snippets, especially when the user had a lot of conversations at the same time and he wanted to keep the discuss bubbles visible. This commit shift the discuss bubbles on edit to solve the issue. task-4266898 Forward-Port-Of: odoo/odoo#184671
Opening the shop floor from a manufacturing order now takes users to the right work center and keeps the manufacturing order in view. This prevents users from landing on the wrong screen and makes it easier to continue production work without confusion.
Original PR description
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE:…
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE: Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC) NOW: Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour. Note: I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4 as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different) task#4629641 Forward-Port-Of: odoo/enterprise#99855 Forward-Port-Of: odoo/enterprise#93841
This update prevents a crash when opening older point-of-sale refund orders created before a data model change. It ensures existing refund records are handled safely after upgrades, avoiding errors during normal use and upgrade checks.
Original PR description
In saas~17.1, the field `refunded_order_id` was changed from a Many2Many to a Many2One, as refunding lines from different orders with the same order was no longer possible. The problem is that there were no changes applied to the existing data to account for this, so databases with those kind of refunds will trigger an error when the field is computed: ``` ValueError: Wrong value for pos.order.refunded_order_id ``` This behaviour can also break upgrades if the error happens during the mock crawl test after the upgrade. To reproduce: - In 17, create an order refunding products from different orders. - Upgrade to 18. - Try to view the refunding order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224515 Forward-Port-Of: odoo/odoo#221355