### 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

LATAM task 1299 / Adhoc Task 47453

---

### Description of the issue/feature this PR addresses:

Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes.

For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448

### Current behavior before PR:

Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals

![before-print-detail-other-taxes](https://github.com/user-attachments/assets/2bc416c9-4231-42c4-8c71-fd1f5531d3d2)

### Desired behavior after PR is merged:

We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes

![new-taxes](https://github.com/user-attachments/assets/d75ae2ad-b787-4399-a9d7-c6b3082c67ec)

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

Forward-Port-Of: odoo/odoo#203374
Forward-Port-Of: odoo/odoo#201257

…ring orders

**Issue:**
When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique.

**Steps to Reproduce:**
1. Install the Manufacturing app.
2. Install the Studio app.
3. Change the language to one other than English.
4. Navigate to Manufacturing > Operations > Manufacturing Orders.
5. Create a new Manufacturing Order.
6. Open Studio and set the name field to read-only.
7. Save the first Manufacturing Order with the default name ("New").
8. Attempt to create another Manufacturing Order.
9. Error: The system prevents saving due to a duplicate name.

Expected Behavior: The Manufacturing Order name should be automatically updated to a unique value upon saving, regardless of the selected language.

Actual Behavior: The name remains "New", but it is not translated when using a different language. Since the name field is set to read-only, the system does not trigger the automatic conversion to a unique name. As a result, when attempting to create another order, the system detects a duplicate and prevents saving due to a name conflict.

**Root Cause**
The system always sets the default name to "New" in English. However, the automatic name conversion process expects a translated name before updating it to a unique value. Because "New" remains untranslated, the system does not recognize it as a placeholder and fails to convert it.

**Fix**
Modify the default value of the name field to use a localized translation like it’s done for the sale order https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/sale/models/sale_order.py#L55. This ensures that the default name is translated according to the user's language, allowing the system to properly detect and replace it with a unique value when saving.

Opw-4553109

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

Forward-Port-Of: odoo/odoo#200138

The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options).

This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters  being too tall.

It also changes the style of the `Select period...` option to be more placeholder-like.

Note: the same fix cannot easily be done in 16.0, because there the date picker isn't a popover there, this adding `overflow` to the CSS breaks it.

Task: [4624108](https://www.odoo.com/web#id=4624108&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

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#201391

Issue
=====
Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation.

How to reproduce
================
1. Create two products with a barcode;
2. Open the Barcode app and create an operation;
3. Scan a product then click on the edit button to open the form view;
4. Update the product quantity field;
5. While still in the form view, scan another barcode -> You can see the quantity was reset;
6. Update again the quantity and save;
7. Try to exit the operation -> Bim badaboum, traceback 💥!

Cause of the issue
==================
When a barcode is scanned, the app doesn't check where is the current state and process the barcode anyway which lead to strange behavior and inconsistencies between the current lines and the lines to save.

Solution
========
Disable the scan while somewhere else that in the barcode line view.

Miscellaneous
=============
Remove an old forgotten `console.warn` 😬

[OPW-4567723](https://www.odoo.com/odoo/project/49/tasks/4567723)

Forward-Port-Of: odoo/enterprise#82029
Forward-Port-Of: odoo/enterprise#81512