Daily updates from Odoo
Wednesday, September 17, 2025
28 changes · 19.0
Enhancements to existing features
Users can now permanently delete discussion threads they created, with a confirmation step to prevent accidental removal. This makes it easier to manage outdated or unwanted conversations directly from the Discuss sidebar or chat window.
Original PR description
purpose of Commit: Added delete button to threads, visible only to the user who created the thread. Clicking the button opens a confirmation dialog, and upon confirmation, permanently deletes the thread. This commit is available in discuss sidebar and chat window, similarly to "leave" / "unpin" action. task-4629867 <img width="476" height="238" alt="Screenshot 2025-09-12 at 17 57 40" src="https://github.com/user-attachments/assets/4cafc7f5-bc20-4fde-b19e-1616ede6706d" />
Payroll contract templates now better preserve country-specific contract details when creating new employee contracts. This helps payroll teams avoid missing localization-specific information and adds checks to ensure templates load correctly across supported localizations.
Original PR description
This commit implements _get_whitelist_fields_from_template() method across all HR payroll localizations to ensure that localization-specific fields are properly copied when creating contracts from templates. Additionally, tests has been added for all localizations to validate the whitelist functionality and ensure proper template loading behavior. task-4954283 Forward-Port-Of: odoo/enterprise#92093
Resolved issues and error corrections
Refreshing the page now preserves the correct menu context when different apps share the same underlying customer or partner action. This prevents users from being unexpectedly moved to another app menu, such as Sales changing to Invoicing, improving navigation consistency.
Original PR description
* STEP TO REPRODUCE: install sale management module, go to sale app -> customer menu -> Then reloading the page using F5 -> the menu is change to invoice which is not correct * Also Multiple modules (Sale, Account, Purchase) share same actions (e.g. partner action) * SOLUTION: - Modified webclient.js action-to-menu mapping to handle multiple menus sharing same action Forward-Port-Of: odoo/enterprise#94512 Forward-Port-Of: odoo/enterprise#94485
Reloading a page now keeps users in the correct app menu instead of switching to another menu that uses the same underlying action. This avoids confusion for teams working across Sales, Accounting, Purchase, and shared customer records.
Original PR description
* STEP TO REPRODUCE: install sale management module, go to sale app -> customer menu -> Then reloading the page using F5 -> the menu is change to invoice which is not correct * Also Multiple modules (Sale, Account, Purchase) share same actions (e.g. partner action) * SOLUTION: Modified webclient.js action-to-menu mapping to handle multiple menus sharing same action 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#226713 Forward-Port-Of: odoo/odoo#225984
Customers can now choose between a recurring subscription plan and a one-time purchase when a product has only one subscription plan. This fixes a checkout choice that was previously hidden, helping avoid missed sales and customer confusion.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a product with only one recurring plan 2. Enable option 'one-time purchase' 3. On e-commerce it is not possible to select between the recurring plan and the one-time option Issue: - When a product has only one recurring plan and the 'one-time purchase' option is enabled, the recurring plan selection is hidden. Solution: - Updated the `subscription_pricing_select` logic to allow selection when 'one-time purchase' is enabled, even if there is only one recurring plan.
Refreshing the Point of Sale while the screensaver is active now returns users directly to the first POS screen instead of reopening the screensaver. This prevents cashiers from being locked out of the session and avoids needing to close and reopen the browser tab.
Original PR description
Fix issue appearing when you reload the page while the ScreenSaver is active, which caused the ScreenSaver to be displayed again after the reload (and the user is stuck on that screen). Steps to reproduce: - Open POS - Trigger screen ScreenSaver - Reload the page (F5) (without triggering any user activity so we stay on the screen saver) - The ScreenSaver is displayed again after the reload - => The user is stuck on the saver, moving clicking or typing does not do anything, you have to close the tab and open it again => Now when refreshing the page while on the screen saver, we just directly navigate to the first page of the POS. Description of the issue/feature this PR addresses: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226535
This fixes an issue where using Shift+Tab to move nested list items outward could corrupt the list layout in Odoo's HTML editor. Users editing notes, to-dos, or other rich text content can now reorganize lists without breaking their structure.
Original PR description
### Steps to reproduce: - Open the To-Do. - Use the following HTML: ```html <ol> <li> <div class='o-paragraph'>abc</div> <ol> <li>def</li> <li class='oe-nested'> <div class='o-paragraph'>ghi</div>…
### Steps to reproduce:
- Open the To-Do.
- Use the following HTML:
```html
<ol>
<li>
<div class='o-paragraph'>abc</div>
<ol>
<li>def</li>
<li class='oe-nested'>
<div class='o-paragraph'>ghi</div>
<ol>
<li>jkl</li>
</ol>
</li>
<li>mno</li>
</ol>
</li>
<li>pqr</li>
</ol>
```
- Place the cursor inside []ghi.
- Press Shift + Tab twice.
- Observe that after two outdents, the list structure breaks.
### Description of the issue/feature this PR addresses:
- While merging similar list items, we checked the last child of the previous sibling or the first child of the current list item.
**This caused merging like:**
```html
<li><div>abc</div><ol><li>def</li></ol></li>
<li><div>ghi</div></li>
```
**Producing invalid structure:**
```html
<li><div>abc</div><ol><li>def</li></ol><div>ghi</div></li>
```
### Desired behavior after PR is merged:
- Checks if the first child of the current element is a list item.
task-5048387
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe spreadsheet sharing controls have been adjusted so users no longer see a share button while editing dashboards, preventing related errors. On mobile, duplicate share options have been removed because sharing remains available through the File menu, making the interface clearer.
Original PR description
Current behavior before PR: - Share button caused errors when editing dashboards. - Duplicate 'Share' and 'Freeze and share' buttons shown in mobile view. Desired behavior after PR is merged: - Hide share button in dashboard edit. - Remove duplicate share buttons in mobile (already under File -> Share). Task: [5043228](https://www.odoo.com/odoo/2328/tasks/5043228)
Fixes an issue in Attendance where changing checkout time could prevent manually validated overtime hours from being recalculated correctly when saving. This helps ensure overtime values remain accurate and avoids confusing discrepancies for HR users.
Original PR description
This fixes a weird behaviour where field that is not triggering the compute on the save because it was already triggered on the onchange If a user ser the validated_overtime_hours to a value that is…
This fixes a weird behaviour where field that is not triggering the compute on the save because it was already triggered on the onchange If a user ser the validated_overtime_hours to a value that is not the one in overtime_hours, upon changing the check_out time we will trigger the compute for both those fields. Overtime_hours calculates it's value based on attendance.overtime model, which is not being updated here, hence it will have the same value. Validate_overtime_hours in the other hand will be updated since there is a write in overtime_hours (even though with the same value) and this will mark the field to be updated when a web_save happens. Now when the save happens the overtime_hours is updated but even though validate_overtime_hours depends on it, it won't be updated since it's being writen to, as a field to be updated This fix aims to prevent writing to overtime_hours when there is no real need to, preventing the described issue opw-4806193 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222832
External values linked to tax reports can no longer be edited or created after the relevant tax return lock date. This helps protect submitted tax filings from accidental changes and adjusts the tax closing process so required default values are created before the period is locked.
Original PR description
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the…
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the user is not supposed to modify any external values anymore. To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow. Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error. task-5012442 Forward-Port-Of: odoo/enterprise#94641 Forward-Port-Of: odoo/enterprise#92949
Sales and purchase order sections are no longer treated as regular product lines when documents are exported and re-imported. This prevents incorrect quantities and prices from appearing on imported orders and avoids a misleading import warning message.
Original PR description
Steps to reproduce: - Create Sales/Purchase order with sections - Print Sales/Purchase order as PDF - Drop the PDF into purchase app Problem: - Sections are added as a normal order line with…
Steps to reproduce:
- Create Sales/Purchase order with sections
- Print Sales/Purchase order as PDF
- Drop the PDF into purchase app
Problem:
- Sections are added as a normal order line with quantity, price, etc..
- `return True` was removed from `_import_order_ubl` because it
shows an incorrect warning in the chat log.
"Attachment {{name}}.xml not imported: True" whenever the attachment
is imported correctly and its supposed to show the reason if something
goes wrong not "True".
**Notes:**
- Orders were filtered to not include sections, because
UBL does NOT support sections.
- `return True` was removed from `_import_order_ubl` because it
shows an incorrect warning in the chat log.
"Attachment {{name}}.xml not imported: True" whenever the attachment
is imported correctly and its supposed to show the reason if something
goes wrong not "True".
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227200This fix improves the website and email editing experience for right-to-left languages such as Arabic. Columns and grid elements now stay aligned with the cursor when users drag or resize them, reducing layout mistakes while editing pages or mailings.
Original PR description
**[FIX] web_editor, mass_mailing: fix resizing columns in rtl mode** This commit fixes issues in edit mode when resizing columns or using grid mode on websites displayed in a right-to-left (RTL) language like Arabic. task-4815296 Forward-Port-Of: odoo/odoo#224650 Forward-Port-Of: odoo/odoo#217338
This update fixes several issues in manufacturing work orders, quality checks, and barcode scanning. It helps shop floor and warehouse users complete scans and quality steps more reliably, reducing interruptions during daily operations.
Original PR description
Various fixes, mostly related to barcode scanning and some JS. task 5089956
This fix improves stock valuation reports by showing understandable account names, correcting date-based valuation calculations, and using clearer cost labels. It helps users review inventory value history more reliably and with less confusion.
Original PR description
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
EU OSS taxes now receive the correct Spanish tax classification when tax mappings are refreshed. This helps ensure Spanish reporting treats these cross-border sales correctly and avoids incorrect compliance data.
Original PR description
The EU OSS taxes were generated with the wrong l10n_es_type. - Install l10n_es and l10n_eu_oss. Then go to Settings and refresh the tax mapping in “EU Intra-community Distance Selling.” - In Taxes, filter by tax group containing “OSS.” All OSS taxes appear with l10n_es_type = sujeto. This is incorrect. The correct type should be “No Sujeto por reglas de localización” (see section 2): https://a3responde.wolterskluwer.com/es/s/article/version-3-05-del-moduloticketbai-batuz-de-a3erp-mejoras#OSS This commit adds the possibility of adding country specific field during the account_tax creation using chart_template -> fields mapping. opw-5009180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227238 Forward-Port-Of: odoo/odoo#224192
Blackbox devices connected through IoT now keep their existing setup when unplugged and reconnected, even if the Raspberry Pi assigns them a different serial port. This prevents duplicate device records and avoids configuration loss for affected users.
Original PR description
Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing…
Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing configuration wouldn't work. After this commit, we handle the blackbox as a special case, and if the name of the device matches exactly with our existing blackbox, we update its identifier instead of creating a new device. This does require a new device specific check in the controller which is quite ugly. Another approach would have been to make the identifier of the blackbox equal its FDM ID instead of the serial port, but this was not done for the following reasons: - Changing the identifier format in stable would cause all existing clients' blackboxes to become unconfigured once their IoT box restarts. - Making the identifier different to the serial port would require a hack in the blackbox driver to change its own identifier and update the devices dictionary, since the serial interface assumes all devices use the port as their identifier. task-5055027 Forward-Port-Of: odoo/enterprise#93665 Forward-Port-Of: odoo/enterprise#93593
The Sign app now lets users drag and drop fields correctly when working with multiple uploaded documents. This removes a blocker in preparing signature requests and helps users complete multi-document signing workflows without interruption.
Original PR description
Version: - saas-18.3 Steps to reproduce: - install sign - upload multiple documents - try to drag the field Issue: - Fields cannot be dragged when multiple documents are uploaded. Solution: - update the condition to check if !acive then return no need to preventdefault. Impact: - Users can now upload multiple documents and drag/drop fields without issues. Forward-Port-Of: odoo/enterprise#94882
Fixes an issue where previously used serial numbers could appear again when adding delivery lines after deleting assigned lines. This helps warehouse users pick only valid available stock and avoids mistakes in deliveries.
Original PR description
Steps to reproduce the bug: Create a storable product “P” tracked by serial number Create a receipt for 100 units with serial numbers sn.001 to sn.100 Create a delivery for 10 units, Odoo assigns serial numbers from sn.001 to sn.010, Validate Create a delivery for 3 units, Odoo assigns serial numbers from sn.011 to sn.013, Delete the 3 move lines, Add a line: you will see again the serial numbers sn.001 to sn.010 in the list Origin: This pr : https://github.com/odoo/odoo/pull/216035 removed the 'on_hand' & 'in_stock' without removing their uses (search_default_*). Fix: Ensure a correct domain when adding a line. opw-5075144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now shows only the correct available serial numbers when users add or replace delivery lines. This prevents already-used serial numbers from being offered again, reducing picking errors and inventory inconsistencies.
Original PR description
Steps to reproduce the bug: Create a storable product “P” tracked by serial number Create a receipt for 100 units with serial numbers sn.001 to sn.100 Create a delivery for 10 units, Odoo assigns serial numbers from sn.001 to sn.010, Validate Create a delivery for 3 units, Odoo assigns serial numbers from sn.011 to sn.013, Delete the 3 move lines, Add a line: you will see again the serial numbers sn.001 to sn.010 in the list Origin: This pr : https://github.com/odoo/odoo/pull/216035 removed the 'on_hand' & 'in_stock' without removing their uses (search_default_*) Fix: Ensure a correct domain when adding a line. opw-5075144
The appointment booking page now shows the correct maximum number of people based on the available resources. This prevents customers from seeing an artificially low capacity when the first listed resource has fewer spots than others, and ensures skipped resource selections do not limit availability incorrectly.
Original PR description
**How to reproduce:** - Create an appointment with availability assigned to a resource. - Enable 'Manage Capacity' - Set the capacity of the first resource lower than the second one. - Open the appointment's booking page. **Technical Reason:** If appointment is scheduled based on 'resource_time' then resource_default is updated as the first value of resource_possible. Related PR: https://github.com/odoo/enterprise/pull/47059 **After this PR:** 'Number of people' dropdown will display the maximum capacity from all available resources. Task-4664393 Forward-Port-Of: odoo/enterprise#94917 Forward-Port-Of: odoo/enterprise#84243
Sales order sections are no longer imported as regular purchase order lines when a PDF is processed through the purchase app. This prevents non-product section headers from incorrectly adding quantities, prices, or extra order lines, improving accuracy when converting sales documents into purchase documents.
Original PR description
Steps to reproduce: - Create Sales order with sections - Print Sales order as PDF - Drop the PDF into purchase app Problem: - Sections are added as a normal order line with quantity, price, etc.. Note: Orders were filtered to not included sections, because UBL does NOT support sections. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents certain important business attachments from being moved to cloud storage when they are needed directly by Odoo processes. It helps ensure documents used for accounting, expenses, and similar workflows remain available for reports and business logic.
Original PR description
some models use attachments for data for business logics for example, ``account_move.message_main_attachment_id.datas`` ``hr_expense_sheet`` will use all bounded attachments to generate report This commit prevents uploading attachments to cloud storage for some models if they ``_inherit`` or ``_inherits`` model ``mail.thread.main.attachment`` This PR is also a supplement for https://github.com/odoo/odoo/pull/226094 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#227165
This fixes an upgrade issue that could block some customers moving from older 18.3 databases to 18.4 or later when the salary package module is installed. The failing step was removed from the wrong place because the related HR data structure had already been renamed earlier in the upgrade process.
Original PR description
The `hr_contract` table is renamed to `hr_version` as part of the https://github.com/odoo/upgrade/blob/3bea30d1fd0cd202006da4ad11e00e283cbc78d0/migrations/hr/saas~18.4.1.1/pre-migrate.py#L29, script,…
The `hr_contract` table is renamed to `hr_version` as part of the https://github.com/odoo/upgrade/blob/3bea30d1fd0cd202006da4ad11e00e283cbc78d0/migrations/hr/saas~18.4.1.1/pre-migrate.py#L29, script, which is executed before any `hr_contract_salary` script, including module ones. As a result, any database from 18.3 to 18.4+ with `hr_contract_salary` < 2.1 will run into:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
File "<decorator-gen-6>", line 2, in new
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
load_modules(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 181, in load_module_graph
migrations.migrate_module(package, 'pre')
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/enterprise/saas-18.4/hr_contract_salary/upgrades/saas~18.3.2.1/pre-unarchive-partially-signed-offers.py", line 4, in migrate
cr.execute(
File "/home/odoo/src/odoo/saas-18.4/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.errors.UndefinedTable: relation "hr_contract" does not exist
LINE 4: FROM hr_contract c
^
```
As a fix, the query is moved into the `hr` script mentioned above.
see: https://github.com/odoo/upgrade/pull/8466
opw-5071923
upg-3121357
tbg-2136
Forward-Port-Of: odoo/enterprise#94931Tax return reports for UK and New Zealand companies now follow the company’s configured fiscal year instead of assuming a calendar year. This ensures transactions are included in the correct quarterly return when the fiscal year ends on a non-December date.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_uk_reports - Switch to a British company (e.g. UK Company) - In Accounting settings, set the last day of the fiscal year to another date than "December 31" (e.g. "January 31") - Create some invoices with tax between the 1st of January and the 30th of April - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the "Tax Report (GB)" for the first quarter (i.e. Tax Q1) **Issue: (same issue for NZ localization)** The Tax Report is ignoring the configured date of the fiscal year. All the invoices from January are included and those from April are excluded. It should be the opposite. **Solution:** Override the "_get_start_date_elements" method for the British tax report that allows to define the start date. opw-4939971 opw-5067877 Forward-Port-Of: odoo/enterprise#94793
The checkout payment setup flow now correctly starts Stripe activation instead of showing a missing action warning. This lets e-commerce users enable and configure Stripe from the payment step without being blocked.
Original PR description
Steps to Reproduce: 1. Go to the website e-commerce shop and add a product to the cart. 2. Proceed to checkout and reach the Payment step. 3. Click the Activate Stripe button. 4. Warning message…
Steps to Reproduce:
1. Go to the website e-commerce shop and add a product to the cart.
2. Proceed to checkout and reach the Payment step.
3. Click the Activate Stripe button.
4. Warning message pop-up: Missing Action – The action 'payment.action_activate_stripe' does not exist.
Description:
This commit fixes the broken Stripe activation flow by adding the missing server action. With this in place, users can activate and set up the available payment provider without warning on the checkout page in e-commerce.
Before this commit:
- Clicking Activate Stripe on the checkout page raised a warning: The action 'payment.action_activate_stripe' does not exist.
- The Stripe payment provider could not be activated from the checkout e-commerce.
After this commit:
- Added a server action in `ir_actions_server_data.xml`.
- Clicking Activate Stripe now triggers the payment onboarding process via `res.config.settings._start_payment_onboarding()`.
- Users can correctly activate and configure available payment provider .
opw:5022767
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change fixes an issue that could cause Odoo to fail in Safari on iOS when handling browser storage. It improves reliability for mobile users accessing Odoo from Apple devices.
Original PR description
Error on safari browser on iOS, Indexedb table difference is not handle yet Fix: use js command more common on browsers --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users working across multiple companies can now log timesheets on projects that are not assigned to a specific company. This prevents an incorrect validation error and makes timesheet entry work as expected in multi-company setups.
Original PR description
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without…
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without setting a company (making it a global project). 5. Enable both companies in the systray 6. Try to log a timesheet on the global project. issue: ------ A ValidationError is raised: "Timesheets must be created with an active employee in the selected companies." cause: ------ During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381 If the project has no company set, `company_id `becomes **False**. This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215 solution: --------- Use `self.env.company` if company_id is missing(or False) in the vals. opw-4892449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227268 Forward-Port-Of: odoo/odoo#223846
Sales orders for products using subcontracting or kit bills of materials will no longer create empty manufacturing orders when Make To Order is enabled. This avoids confusing production records and keeps manufacturing processes aligned with the correct fulfillment method.
Original PR description
Issue before this commit: ========================= When a product has a non-normal BoM type (e.g. subcontracting or kit) and the MTO route is enabled, and creating a Sale Order generates a blank MO.…
Issue before this commit: ========================= When a product has a non-normal BoM type (e.g. subcontracting or kit) and the MTO route is enabled, and creating a Sale Order generates a blank MO. Steps to Reproduce: ========================= - Install the mrp module. - Create a product with a BoM of type Subcontracting (or Kit). - Enable the MTO route on that product. - Create a Sale Order for the product. → A blank MO is created, which should not happen. Cause of the issue: ========================= In this [PR](https://github.com/odoo/odoo/pull/223685), MRP route are now defined at the warehouse level, so by default, the MRP route becomes applicable to every product, and is excluded only under specific conditions. For the MRP route, we only checked whether the product had a BoM [here](https://github.com/odoo/odoo/pull/223685/files#diff-6d86bc8c3e9aa22586656b702849c5bbbb00c9b97ffd08bc0842e0e68f8948f9R75) without considering the BoM type when filtering the mrp route. This led to the creation of an MO for a subcontracting BoM. With This Commit: ========================= - We ensure that the MRP route is filtering based on the BoM type, not only on the existence of a BoM. - This prevents the creation of an MO when the BoM type is non-normal (e.g. subcontracting or kit).