This commit introduces a new function `run_tests` to the Odoo shell.
This function allows users to run specific tests directly from the
shell, even after the test code is modified. This significantly speeds
up the debugging process by avoiding the need for a full server restart.

In the odoo shell
```
>>> from odoo.tests.shell import *
>>> run_tests(env, 'test_tags', modules=[module_name], reload_tests=True)
```

Note: `run_tests` automatically reloads test modules but does not reload
Odoo model code. A shell restart is still required after any change to
business logic.



used by
https://github.com/HydrionBurst/odoo-test-vscode
for hot test
vscode extension: 
[odoo-test-0.0.1.vsix.zip](https://github.com/user-attachments/files/22089685/odoo-test-0.0.1.vsix.zip)


tutorial: https://github.com/HydrionBurst/odoo-test-vscode?tab=readme-ov-file#-hot-test



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#225024
Forward-Port-Of: odoo/odoo#224048

Description
-----------
When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening:

1) Once in `convert_to_column`, when converting the `vals` for
   *database* insertion
2) Once post-insert in `convert_to_cache`, when converting the
   `vals` for insertion in the *cache* for the newly created records.

This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries.

To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results.

The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make.

Benchmark
---------
In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were:

| Method                        | Before   | After     | Speed up |
|-------------------------------|----------|-----------|----------|
| `_process_mass_mailing_queue` | 2.84 min | 1.55 min  | 1.8x     |
| `create`                      | 2.11 min | 50.23 sec | 2.5x     |

This represents roughly a *2x* performance improvement in processing an email campaign.

* more detailed benchmarks are available in the task's description

Reference
---------
task-4962646

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

Forward-Port-Of: odoo/odoo#224534
Forward-Port-Of: odoo/odoo#223875

When users refund a real-time/standard cost product purchase, cogs lines are not reversed

**Steps to reproduce**

1. Create a product category [CATEG]:
    - Costing Method: Standard
    - Inventory Valuation: Automated
    - Price Difference Account: 101403 Outstanding Payments (any account will do)
2. Create a product [PROD]
    - Type: Storable
    - Category: [CATEG]
3. Create and confirm a PO with [PROD]
4. Process the receipt
5. Create the bill
6. Issue the return and process it
7. Create the refund

**Issue**

The credit note cogs lines (price difference account and stock interim) have the same balance of the bill
However the credit note should mirror the original BILL with the opposite accounting entries.

This seems to occur because, when generating cogs lines, we take into account that the current move is a refund but then we use the move direction sign to alter the balance sign

opw-4845342

Forward-Port-Of: odoo/odoo#224873
Forward-Port-Of: odoo/odoo#221198

Description of the issue/feature this PR addresses:

Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal.

so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string

Current behavior before PR:
<img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" />
<img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" />
<img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" />


Desired behavior after PR is merged:
<img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" />
<img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" />
<img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" />



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

Forward-Port-Of: odoo/odoo#222588
Forward-Port-Of: odoo/odoo#221858

**Current behavior:**
Since https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3, we valuate an unbuild operation by attempting
to match the ensuing OUT layer with the IN layer from the
original MO.

The point being to eliminate a potential valuation imbalance for
the manufactured product (might affect cost, etc.).

**New behavior**
Don't attempt to match an unbuild valuation layer with the
original MO valuation layer. If there is some cost difference
between build time and unbuild time, make a corrective journal
entry for it.

**Issue with current behavior**
The following sequence:
1. Create Product A with average costing, real-time valuation
2. Create 2 components, avg costing, real-time val
3. Create a BoM for Product A with the components
4. Manufacture 3 units of Product A with different component
quantities (can set flexible consumption on BoM)
5. Unbuild the first manufactured unit

Results in Product A's cost not matching the expected average
cost according to the valuation layers.

**Cause of the issue:**
Unbuilding the first MO created an out move at the original
"build time" cost, but since we've built 2 additional qty, that
original cost is not the current average cost- thus the
"theoretically current" standard price of the product (sum of
layers value divided by remaining qty) is no longer the value we
see on the product form.

**Fix:**
Don't try and match the valuation layers. Aside from issues such
as the one described above, it might not actually make
functional sense to do so (e.g., FIFO isn't actually adhering to
first-in-first-out if we're preferring the original IN layer for
an unbuild valuation).

Instead we make a journal entry with any excess cost of
production (it was actually a solution proposed in the
discussion on https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 in the first place).

Additionally, now that we aren't doing this mapping, we can
revert the non-test difference of https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47, as this commit was
fixing an issue introduced by the change which added the
mapping.

opw-[4877597](https://www.odoo.com/web#id=4877597&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#222014
Forward-Port-Of: odoo/odoo#221718

**Steps to reproduce:**
- Install `mail_mailing`.
- Create a new record and leave the `email_from` field empty.

**Observed behavior:**
- A validation error is raised due to a bad query.

**Expected behavior:**
- Since the field is required, the UI should display a simple “Invalid fields” pop-up instead of a server-side validation error.

**Cause:**
The commit odoo@92c5b0699dffab98f55ed1a54a0236dbc4b5626a removed the `required` attribute from the `email_from` field and replaced it with a constraint. As a result, UI-level validation was lost and only the backend validation error is shown.

**Fix:**
Re-add the `required` attribute for the `email_from` field in the view so that the standard UI validation is triggered.

**Before Fix:**
<img width="1366" height="578" alt="email_from_empty" src="https://github.com/user-attachments/assets/23680aad-e9c8-4554-b990-de0784cb4442" />

**After Fix:**
<img width="1366" height="620" alt="after_fix_email_from" src="https://github.com/user-attachments/assets/ef34c680-8b17-4773-995d-d953a874e6a0" />


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

**Description of the issue/feature this PR addresses**:
It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the jurisdictions they apply to.

**Steps to reproduce**:
1) Go to runbot odoo 18 instance, install l10n_ar module, take position on Argentinean company and activate "Spanish (Latin America)" language.
2) Go to "Accounting / Configuration / Accounting / Taxes", filter by "Sales" Tax Type (type_tax_use) and see that Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe don`t have the complete description. It is needed to show the complete description.

<img width="1825" height="307" alt="image" src="https://github.com/user-attachments/assets/f664e5ec-a4b5-4a8f-bbab-9ba3d824bd2b" />

**Current behavior before PR**:
Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes don`t have the complete description.

**Desired behavior after PR is merged**:
Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes have the complete description.
<img width="1828" height="425" alt="image" src="https://github.com/user-attachments/assets/dc8ee6dd-23c3-40c1-a973-943971e3cb78" />

**Task Adhoc side**: 53028
**Task latam side**: 1356

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

Forward-Port-Of: odoo/odoo#221742

Currently, an error occurs when a user attempts to reload the fiscal localization after uninstalling the `l10n_syscohada` module.

**Steps to Reproduce:**
- Install l10n_cf module(with demo).
- Switch the company to `CF Company`.
- Navigate to Invoicing settings
- Login in different device with admin rights
- In other device, uninstall l10n_syscohada module.
- Now switch back to main device  and do not reload the tab.
- Click on Reload button under Fiscal Localization.

**Error:**
`TypeError: super(type, obj): obj must be an instance or subtype of type`

**Root Cause:**
since https://github.com/odoo/odoo/pull/186635/commits/58fb2db14ce3b7ddd70ffd617d2152c836151455, the line `self = self.env()['account.chart.template']` was removed from [1] when clicking the reload button, system tries create **data** at [2] but fails because the registry has been reset.

[1]- https://github.com/odoo/odoo/blob/1dfa4cc9d259b4918424a07394938e24da8c643d/addons/account/models/chart_template.py#L183-L184

[2]- https://github.com/odoo/odoo/blob/c363014fe77d2ea706dabf8af232745d4e723267/addons/account/models/chart_template.py#L222

**Solution:**
This commit prevents the error by providing new `env` with new `registry` to handle
loading during the reload process.


Sentry-**6272559266, 6750055374**

Forward-Port-Of: odoo/odoo#216315

**Steps to reproduce:**
1. Install Sales.
2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field.
3. Log in as the demo user.
4. Create a quotation and click the 'Send by Email' button.
5. In the wizard, click the three dots between the attachment and AI logo in the footer.
6. Observe the templates list.

**Issue:**
  - The template created for the admin user appears for the demo user as well.

**Cause:**
https://github.com/odoo/odoo/blob/07626050bd0104fecd8799b56d30245d00da3f27/addons/mail/static/src/core/web/mail_composer_template_selector.js#L31-L44
 - The domain used to fetch templates was incorrectly filtering for templates
  assigned to any user (instead of filtering for templates assigned to
  the current user or not assigned at all).

**Solution:**
 - Corrected the domain to include only templates assigned to
  the current user and not assigned to anyone.

opw-4901492

Forward-Port-Of: odoo/odoo#222073
Forward-Port-Of: odoo/odoo#217641

Currently an error occurs when signing an encrypted file with empty password.

**Steps to replicate**
* Install `Sign`
* Sign> Upload a pdf > Add following [pdf](https://drive.google.com/file/d/1M0_VzWLzv-lSZ-IlI9Zmx-M7jFGvtJJj/view?usp=sharing)>  Sign the document using `Sign now`
* Validate and send completed document

`AttributeError: 'NoneType' object has no attribute 'seek'`

**Cause:**
This occurs because [1] returns `None` to the variable `output` at [2] which in turn passes the `None` value to [3] causing the error.

Error occurs in python 3.12+, because it does not throw an exception in `_check_pdf_data_validity`.

**Solution:**
* Add a validation to prevent upload of unsupported files.

[1]: https://github.com/odoo/enterprise/blob/e7861f1ddef2fb9628eebca93942e64c73cc95fc/sign/models/sign_document.py#L242-L243
[2]: https://github.com/odoo/enterprise/blob/e7861f1ddef2fb9628eebca93942e64c73cc95fc/sign/models/sign_completed_document.py#L33-L34
[3]: https://github.com/odoo/odoo/blob/033c7a63bdf3d10d9d2c5084959fd34f52011bea/odoo/tools/pdf/signature.py#L51

**Sentry-6784800544,6802557168**

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

Currently, an error occurs when attempting to find duplicate transactions in the bank.

Steps to Reproduce:
- Install the `Accountant` module.
- In the `Accounting` Dashboard, click on `Bank`.
- In Actions, click `Find Duplicate Transactions`.
- Clear the `Starting Date` and click save.

Traceback:
```py
psycopg2.errors.UndefinedFunction: operator does not exist: date >= boolean
LINE 6:                    AND move.date >= false
                                         ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
```

This error occurs when the system attempts to detect duplicate transactions without a `Starting Date`. During the check, it evaluates the condition `move.date >= date_from`. Since `date_from` is False, the comparison triggers an error.

This commit ensures that if the `Starting Date` is empty when finding duplicate transactions, it uses today’s date as the `Starting Date`.

Reference commit: https://github.com/odoo/enterprise/pull/87000/commits/806ab2d56952e9d0f597cf1ab36ea2f180a84323

Forward-Port-Of: odoo/enterprise#92497