### Issue:

Tldr: If a field A depends on an other computed field B and if the value of A is used in the computation of the field B, the ORM will consider that the value of A is false  (or empty record set) in the computation of B.

On the `mrp.production` model, the `product_tmpl_id` is a related non stored field:
https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L82 depending on the `product_id` field. This means that if we need to access the value of that field, we will first need to access the value of the `product_id` field. However, the `product_id` field is a computed field: https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L62-L66 So that if its value is marked as dirty in the cache at the moment we try to access the value of the `product_tmpl_id` of the we will launch a call of its compute method. This is problematic because the 'related' that launched the compute is used inside the compute method: https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L397 This is probelmatic because it would technically lead to an infinite recursion loop. So, to avoid any of these situation, when the computation of the `mrp.production.product_tmpl_id` has been started the filed has been marked as protected and is used as "False" in each of the subsequent computations:
https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/odoo/fields.py#L1295-L1299 In particular, we will compute the `product_id` of the mrp.production considering that the `product_tmpl_id` is false and we will therefore set a wrong value on the bom.

### Steps to reproduce:

Using studio, you can create a set of fields linked to the 'product.template' and `mrp.production` models and an automated rule that will force a situation where the above situation will be triggered with the following flow:
- Create a product with 2 variants.
- Create a bom for the template of these products and one bom line:
    - 1 x COMP
- Create and confirm an MO for 1 unit of variant 2.
- Change the bom line to 2 x COMP.
#### > Return to the MO and click on update bom, the `product_id` of the MO has been altered to variant 1.

The details of the set up are the following:
1. Create a new field with the following configuration: Name: x_studio_1 Model: Product Field Type: many2one Stored: True Related Model: res.partner
2. Create a new field with the following configuration: Name: x_studio_2 Model: Manufacturing Order Field Type: char Stored: True Readonly: True Related Field Definition: product_tmpl_id.x_studio_1.name
3. Create an automation rule on the manufacturing order model that trigger on save and that trigger's the action of updating the record responsible to Joel willis.

### Fix:

We should not rely on the related field `mrp.production.product_tmpl_id` inside the compute method of the `mrp.production.product_id`. Particularly since we can access this value using the direct path to this value. This avoids any recursion issue.

opw-4658754
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
 - Install manfacturing app
 - Activate the Unit of measure setting in the mrp settings
 - Go to create new manafcturing order and start zooming in with different screen resolutions

Problem:
The product_qty field starts disappearing on zooming in and this makes the user can't enter a value in it. This happens because the width:auto applied to the field of the uom beside it that takes as much space as possible so the product_qty field disappears.

opw-4560205

Description of the issue/feature this PR addresses:

Current behavior before PR: the product_qty field in the creating manufacturing order disappears while zooming in with different screen resolutions.

Desired behavior after PR is merged: The product_qty field is appearing on all zoom levels from 100 to 400 and tested on all screen resolutions in the settings of display in Ubuntu

**Before**: ![before](https://github.com/user-attachments/assets/88997248-6c36-401c-9a79-3e4bf82f38e9)


**After**: ![after](https://github.com/user-attachments/assets/6e1fb253-4553-4b45-9c0e-b37dd2613e8a)




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, a user could start a module installation, abandon the loading page due to impatience, and attempt to start another installation. This could lead to various errors, such as `SERIALIZATION_FAILURE`, "Failed to load registry," or even a broken database.

Module operations (install/upgrade/uninstall) are executed in multiple transactions:
1. Dependency Check & State Update:
   - A transaction checks module dependencies, determines which modules need updating, and marks them as 'to install', 'to upgrade', or 'to remove'.
2. Registry Reload & Module Update:
   - The registry is reloaded, and modules are updated one by one in their own transactions, changing their states to 'installed' or 'uninstalled'.

This commit introduces two additional checks in step (1):
a. If any module is already in an updating state, raise a `UserError` to prevent concurrent module operations in step (2).
b. If the transaction fails to acquire a `SELECT ... FOR UPDATE` lock on all `ir_module_module` records, raise a `UserError`, as this indicates another concurrent operation of step (1) has either acquired the lock or already modified some module states and committed.


related PR for backport
https://github.com/odoo/odoo/pull/203667

abandoned PR
https://github.com/odoo/odoo/pull/125586

These checks ensure proper concurrency control, preventing concurrent module operations

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

Currently, a return for exchange made on an incoming transfer (receipt) creates a procurement, which usually ends up with a purchase of the exchanged products.
After the "Return" popup is closed, the exchange transfer is not created; instead, Odoo creates a PO that needs to be approved first in order to create the exchange transfer.

That is a bit confusing for the users, who might expect the exchange to be created immediately.
Also, the procurement process requires the product to have a "Buy" route enabled (in "Inventory" tab) and at least one vendor configured in the "Purchase" tab. Without this configuration, the return for exchange process shows an error message.

After this commit, a return for exchange made on a receipt will ignore the procurement process, and instead it will create the exchange picking immediately.
That way users will see the exchange transfer immediately after closing the "Return" popup. Also, all 3 transfers (original, return, exchange) will be linked to the initial PO (if a PO was created).
Additionally, the exchange picking will be shown as a return of the return picking.

Task: 4453571

Issue:
========

There is an issue during the generation of invoices from subscription that causes the is_invoice_cron field on the sale order to remain `True`. This prevents the processing of transactions and, as a result, does not mark the invoices as paid. Furthermore, this issue blocks the generation of subsequent invoices.

To reproduce:
=============

1. Create a subscription that does not require initial client payment, (can generate an invoice on the next invoice date).
2. Create 30 other subscriptions (equal to the batch size value) that cannot generate invoice until the client has made a payment.
3. Run the scheduled action “Sale Subscription: generate recurring invoices and payments.”
4. You will notice that the first Sale Order remains to “is_invoice_cron” as True

Problem:
========
the condition to trigger the cron to invoice subscriptions is based on the number of subscriptions that can be invoiced in a batch. But we are taking all the subscriptions while it should be only the subscriptions that can be invoiced.

Solution:
=========
filter the subscriptions that can be invoiced before checking the condition to trigger the cron to invoice subscriptions.

opw-4559250

Versions
--------
- 18.0+

Steps
-----
1. Have purchase & sale_stock_renting installed;
2. create a 2nd company;
3. enable inter-company transactions for Sale/Purchase Orders for both;
4. enable Warehouse storage locations;
5. enable multi-step routes;
5. enable dropshipping;
6. enable rental transfers;
7. create a dropshipping route assigned to the 1st company;
8. create a purchasable, rental product, tracked by quantity;
9. add dropship route to its operations;
10. add 2nd company as vendor;
11. create a rental order with the product;
12. confirm the rental order;
13. go to the generated purchase order via the smart button;
14. confirm the purchase order;
15. switch to the 2nd company;
16. try to open the generated sale order.

Issue
-----
> TypeError: '>' not supported between instances of 'datetime.datetime' and 'bool'

Cause
-----
On confirming the purchase order, the sale order it generates gets created as a rental order, due to the `in_rental_app` context value being set.

When trying to open the rental order, it attempts to compute the quantity available for the tracked rental products during the rental period.

The rental order was generated based on purchase order data, which lacks any kind of rental information, hence the rental order doesn't have a rental period set.

The lack of rental dates is what causes the error when trying to partition the lines based on rental period.

Solution
--------
When creating a sale order via a purchase order, pass the `in_rental_app=False` context value to ensure it won't be created as a rental order.

opw-4583210

### Issue :
   The return button was visible even when the customer had  only a sale order. Clicking it caused a traceback.

###  Steps to Reproduce:
   1. Install `helpdesk_stock`.
   2. Create a Sale Order (SOL) with a storable product.
   3. Create a helpdesk ticket.
   4. Save the ticket.
   5. Click on the return button.

###   Fix:
   The return button now appears only when a related delivery (picking) exists.

###  Technical Details:
   We used `commercial_partner_id` to search for pickings, ensuring that pickings from child partners are also considered, so checking `partners_in_sale`  is unnecessary.

  The `partners_in_sale` condition is removed because it incorrectly returned when no picking existed.

   ### Test Scenarios:
   1. Create a product.
   2. Create a sale order:
                  - Customer: `Azure Interior`
	          - Delivery address: `Azure Interior, Brandon Freeman`
   3. Confirm the sale order.
   4. Create a helpdesk ticket with customer `Azure Interior`
	      and check the return button.
   5. Validate the picking.
   6. Create a ticket for `Azure Interior` and check the return button.
   7. Create a ticket for `Azure Interior, Brandon Freeman`  and check the return button.

In this commit: [commit](https://github.com/odoo/odoo/commit/57b8b2487def43a1b9c461c0fa4eb02200b5c1ef),
	the condition `if wizard.picking_id` was removed, which led to the traceback.

task: 4522134