This PR fine-tunes the design of the datetime picker within the front-end after the merge of Commit[^1].

- Requires https://github.com/odoo/odoo/pull/215763
----------------

Prior Commit[^1], the previous, next, and month selection buttons were all placed in a flex at the top of the datetime picker. After Commit[^1], buttons are re-ordered in a different layout, with the right button class on each of them.

After this change, each button is separated and thus has its radius and background. In the backend, this `btn-light` is okay since it matches the background of our views, while in the front-end, this color is dynamic and does not match the page background. As each button is separated, it results in a weird visual result.

To fix this issue, we remove these `btn-light` classes and add a `btn-sm` one to handle the size of these buttons.

This change is meant to affect the datetime picker occurrences within the front-end but does not affect the `web_editor` one, as it inherits the backend design.

task-4893742

[^1]: [e2b78fca435f268515f9593c2af821616aff7ebb](https://github.com/odoo/odoo/commit/e2b78fca435f268515f9593c2af821616aff7ebb)

The `account_codes` engine generates a giant `UNION ALL` to map prefixes to accounts. This fully loads postgres for up to minutes at a time, which in the default configuration loads 3 full cores. This also leads to significant *variance* on runbot: runbots are configured with as many builds as they have cores[^1], so the test can take 3 cores when the machine is idle but during the day when machines tend to be fully loaded it contends a ton and slows down dramatically.

`l10n_ro_reports.account_financial_report_ro_bs_large` for instance has nearly 400 different clausesm, something postgres does not cope with well https://explain.dalibo.com/plan/ea5d23aefd3b861f#grid

This is not helped by those searches being filtered by account codes, which have not been indexed since 18.0 (because it's now `company_dependent`).

Since the accounts table is pretty small (800 records on runbot, 8000 on odoo.com) we can just load the entire thing in memory and index it.

before: 164.80s user 1.71s system 12% cpu 23:03.28 total
after: 124.43s user 1.80s system 23% cpu 8:46.15 total

NOTE: Currently the code (prefix) search uses a binary search so complexity is O(m log(n)). This could be improved by sorting the non-tag formulas, as we could then use synchronised linear search, working in O(m + n).

[^1]: while they are hyperthreaded that's only an extra 10-ish% performance opportunity at best for CPU-bound workloads, sometimes less

**Problem:**
When having products that were sold with Intrastat (which permits
the selling of products accross borders in the EU), the weight was
not correctly displayed. The weight always had the '.' decimal
separator, regardless of the language. In French, the decimal
separator is ',' but a product weighting 3 and a half kilos would
be displayed 3.5 instead of 3,5. The same can be said about the
supplementary unit column.

**Steps to reproduce:**
- Change your company to belong to the EU.
- Change the langugage to one that takes a comma as a decimal separator, like French or Spanish.
- Create a product that has a weight in the inventory tab, as well as intrastat values in the accounting tab.
- Make a sale for this product with a client in another country belonging to Intrastat and confirm the invoice.
- Go to Instrastat report in accounting in the audit reports.
- The weight is not correctly displayed.

**Cause of the issue:**
The language of the user was not taken into account when
fetching the data.

**Fix:**
The fields are now changed depending on the current language,
to match the needed decimal separator.

opw-4575332

Description
-----------
During bank statement reconciliation, finding matching journal entries generates a complex and resource-intensive query due to elaborate domain.

This commit optimizes query performance by introducing a new `search_account_id` field that pre-filters the condition on `account_id` criteria. This allows the domain leaf to be resolved early and the resulting IDs to be re-injected into the main query.

The optimization enables Postgres to leverage `pg_stats` directly for more accurate cost estimates. It also eliminates the need to join `account.account` with large tables like `account.move.line` and `account.move`.

Overall performance improves significantly, given that `account.account` is a relatively small table, making it efficient to reuse the filtered IDs in the main query without impacting performance negatively.

Benchmark
---------
Clicking on "Reconcile" to open the wizard with the list view of matching Journal Entries (150k matches) from the new reconciliation view, on odoo.com takes (hot timings):

| Before | After | Speed-up |
|--------|-------|----------|
| 14.7s  | 5.75s | ~2.5x    |

Reference
---------
task-4863071

Forward-Port-Of: odoo/enterprise#87427

The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined in `l10n_co_dian` module, and the workflow
in the module also depends[[1]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_invoice.py#L9)[[2]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/product_template.py#L8) on DIAN being installed. Both modules have the same dependency `l10n_co_edi`
and are autoinstalled. This can easily break if the user chooses to uninstall the dian module.

The module will fail to install if dian is not installed.
The uninstall of the dian module will also cause an error if this module is installed.
The upgrade will fail if the user has dian uninstalled (edi_mandate is a new module and will try to autoinstall)

This fix makes the dependency explicit.

Forward-Port-Of: odoo/enterprise#88607

Steps to reproduce:
- Install payroll, l10n_mx_hr_payroll (mexican localisation)
- Install l10n_mx_hr_payroll_account
- Switch to a Mexican Company
- Create a payslip for a mexican employee with amount < 4000
- Compute the sheet for the payslip

Error message appears, this error message is not a descriptive to the
user or not telling what could have gone wrong. This happens because
the mexican pay structure has some salary rules that has to be
computed, one of these rules is `Retirement, assault in elderly and
old age (CEAV) IMSS (Employer)` that has mode of code. This mode means
calling safe_eval on the code raw text of it written in the xml file
on the data folder. This rule aims to find the suitable taxation level
to be applied on the salary. It reads the limits of each level and
check if the `integrated_daily_wage` of the employee falls in this
level and applies that taxation level. There is no upper limit on the
salary, But there is a min level, hence if the integrated_daily_wage
< mdw (minimum daily wage) the function returns None that used as
index in the taxation table leading to an unreadable Exception from
the safe_eval call.

https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L1111-L1120

opw-4576482

Forward-Port-Of: odoo/enterprise#88560
Forward-Port-Of: odoo/enterprise#83364

## Issue
When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`.

### Analysis
The `write` override could unnecessarily fetch the `datas` field (binary file content).
This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch the binary content even when it was not needed.

## Solution
We leverage Python's boolean short-circuiting to ensure that this behavior is avoided.

### Benchmarks
Profiling peak memory consumption when moving 8 documents (66 Mb each) to the trash:
| Before  | After  | % |
|------------|------------| --- |
|  1.3 GiB | 96 Mb  |  - ~93% |



Query count when unlinking account.move (using Runbot data):
| Before  | After  |
|------------|------------|
|  66 | 72  |

(we may avoid these additional queries by prefetching the fields beforehand, let me know your thoughts)

```
[0.564 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3398) 

[0.713 ms] query:  UPDATE "ir_attachment"
SET "res_id" = "__tmp"."res_id"::int4, "res_model" = "__tmp"."res_model"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (3398, 117, 'documents.document', '2025-06-17T15:24:12.867699'::timestamp, 22)) AS "__tmp"("id", "res_id", "res_model", "write_date", "write_uid")
WHERE "ir_attachment"."id" = "__tmp"."id"
                 
[0.305 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."res_model", "ir_attachment"."res_id", "ir_attachment"."res_field", "ir_attachment"."public", "ir_attachment"."create_uid" FROM "ir_attachment" WHERE ("ir_attachment"."id" IN (3397)) 

[0.666 ms] query: SELECT "account_move"."id" FROM "account_move" WHERE ("account_move"."id" IN (255)) AND ("account_move"."company_id" IN (10)) ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC  

[0.436 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3397) 

[0.436 ms] query: SELECT "documents_document"."id", "documents_document"."attachment_id", "documents_document"."active" FROM "documents_document" WHERE ("documents_document"."attachment_id" IN (3397)) ORDER BY "documents_document"."id" DESC  
```

### References
opw-4552436
Memory flamegraphs available on the ticket

Forward-Port-Of: odoo/enterprise#88180
Forward-Port-Of: odoo/enterprise#85020

It's not rare to have databases with a huge number of svls for some products. For instance, the database of opw-4326597, which is currently on 17.0 and hosted on Odoo.sh, has 166 000 svls for the same product. Because of that, the current code in `svl_empty_stock` is likely to raise a MemoryError in those databases. The reason for that
is the `__get__` call on `stock_valuation_layer_ids` along with a call to `filtered`. After expanding the singleton
with the `prefetch_ids` and fetching all the fields of the related svls, the cache will probably raise a MemoryError.

We are preempting this issue by changing this part of the code with a call to `_read_group` to get the correct lots directly.

Thanks to @mwath for pointing this out.

#### speedup

Benchmark of the `_svl_empty_stock` method, with a product
with 200 000 svls with a lot.

| Before PR  | After PR  |
|:----------:|:---------:|
| 15.03s     |  198.64ms |

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

This commit is a partial backport of this commit [[1]].

This commit has 2 different purposes:

1. Connect the bank synchronization and the payment module to a new API route to get the connection status instead of only getting the consent expiring date.
This new route still provides the consent expiring date but will also provide more information about the payment initiation. Three new information are provider, whether the payment feature is enabled, whether the payment activation is requested to the provider and whether the feature is activated with the provider.

2. This second purpose is directly linked to the first one, it modifies the Initiate payment visibility. Before it was visible once the bank journal was connected to a bank synchronization, now it's visible once the bank journal has a bank synchronization where the payment initiation feature is enabled by the customer.

task-4413740

[1]: https://github.com/odoo/enterprise/commit/a89d1aed466167249cd52b30bce157f015355458

**Problem:**
the split of the landed cost between lots doesn't
take into account if a lot has no quantity left
or if it has less than it's initial quantity

**Steps to reproduce:**
- enable the "lot & Serial Numbers" and "landed costs" settings
- create a storable product, tracked by lot
- in general information activate "valuation by Lot/Serial Number"
- select FIFO as the category
- create a request for quotation for this product for a quantity of 5 and a unit price of 10.000
- confirm and click on the receipt smart button
- on the move line click on the Lots/serial number widget on the right
- create 4 lots (L1 with 1 units, L2 with 2 units, L3 and L4 with 1)
- save and validate the picking
- create a sale order for a quantity of 2 of this product, confirm it and validate the picking
- create a new service product, in "purchase" check "is a landed cost"
- open accounting/vendors/bills, create a new one for the same vendor as the purhase order
- add a line with the landed cost and a price of 5000 (quantity of 1)
- set a bill date and save
- clik on "create landed costs"
- in the "transfers" field write the refernce of the receipt of the PO
- open inventory/reporting/valuation and type your product in the search bar

**Current behavior:**
4 lines were created :
a line of 600 for L1
a line of 1200 for L2
a line of 600 for L3
a line of 600 for L4

an additional issue, is that if we now sell the 3 remaining quantity and search our product in inventory/reporting/valuation the quantity will be zero but total value will be 600

**Expected behavior:**
the spliting should adapt to the remaining quantities like it does when lots are not involved
(for instance when there is a landed cost linked to a PO with a quantity of 5 but only 4 of those products are still in stock the value of the landed cost valuation line linked to this product is 4/5 of the landed cost)

So here it should be :
no line for L1 (no remaining quantity in L1)
a line of 1000 for L2 (only 1 remaining, so a third of the 3000 (3/5 * 5000)) a line of 1000 for L3
a line of 1000 for l4

**Cause of the issue:**
the quantity used is the one of the initial stock move line so it doesn't take into account the current number of product in the lot

opw-4828963

reproduction:
18.0+18.1:
1. In Todo, insert an inline image, and create a link including the image and some text
2. click on the text part, click edit button, modify the label area and click apply
3. the image is removed

Test case 2:
1. go to Recruitment, and open an application and click "Send interview"
2. click on the link inside the template, change the url
3. apply, format of the button breaks

18.2:
same flow with test case 2, click apply causing a traceback

18.3:
same flow with test case 2, click on the link, do nothing and click away, the popover not close

Fix: a partial back port of https://github.com/odoo-dev/odoo/pull/4633 The idea is that when the link doesn't only contain text, we don't show the label input field nor apply the label to the link. Because the label field extracts/display the text content of the link element, the field doesn't support html fragment, applying the label on a link including another element inside will break it.

task-4881878

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

**Steps to reproduce the issue:**
- Install Stock, Sales applications
- Set the allowed companies to Marc Demo to be only one company
- Change the user to Marc Demo
- Create a SO with partner another company than Marc's company
- Confirm the SO

**Issue:**
A traceback is raised:
`No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.`

**Root Cause:**
- When the procurement group searches for a pull rule with a destination location set to the inter-company transit location (due to the partner's company being different), the rules for the inter-company transit location are not automatically applied.
- The `_get_rule_domain` method https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_rule.py#L641-L653 modifies the destination location to the customer's location if:
  - The user belongs to the `base.group_multi_company` group.
  - The destination location is the inter-company transit location.
- In this use case, the user does not belong to the `base.group_multi_company` group because they are restricted to a single allowed company.

Additionally, the logic in `_compute_location_dest_id` https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_move.py#L227-L231 for inter-company transfers does not account for users with a single allowed company.

**opw-4749870**

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

Fixed an issue in ```_default_picking_type_id``` where a missing picking type triggered a ```RedirectWarning``` due to an incorrect domain in the ```search``` Hence disabled `active_test` context to ensure proper fallback behavior.

```sql
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1328, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 480, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
    registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 604, in init_models
    model._auto_init()
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3468, in _auto_init
    new = field.update_db(self, columns)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3215, in update_db
    return super(Many2one, self).update_db(model, columns)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1090, in update_db
    self.update_db_notnull(model, column)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1142, in update_db_notnull
    model._init_column(self.name)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3384, in _init_column
    value = field.default(self)
  File "/home/odoo/src/odoo/18.0/addons/purchase_requisition_stock/models/purchase_requisition.py", line 13, in _default_picking_type_id
    self.env['stock.warehouse']._warehouse_redirect_warning()
  File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_warehouse.py", line 172, in _warehouse_redirect_warning
    raise RedirectWarning(msg, warehouse_action.id, _('Go to Warehouses'))
odoo.exceptions.RedirectWarning: ('Cree un almacén para la empresa Navieras Internacionales, S.A. (Navinter).', 464, 'Ir a los almacenes', None)
```
```sql
depr_2982092=> select id,name,active,company_id,warehouse_id from stock_picking_type where code = 'incoming' and active = 'f' order by company_id;
 id |                                                name                                                | active | company_id | warehouse_id
----+----------------------------------------------------------------------------------------------------+--------+------------+--------------
  6 | {"en_US": "Devoluciones"}                                                                          | f      |          1 |            1
 67 | {"en_US": "Recepciones", "es_GT": "Recepciones"}                                                   | f      |          1 |           12
 72 | {"en_US": "Devoluciones", "es_GT": "Devoluciones"}                                                 | f      |          1 |           12
  1 | {"de_DE": "Anlieferungen", "en_US": "Recepciones", "es_GT": "Recepciones", "nl_NL": "Ontvangsten"} | f      |          1 |            1
(4 rows)

```
OPW - [4869238](https://www.odoo.com/odoo/project/70/tasks/4869238?debug=1)

UPG - [2982092](https://upgrade.odoo.com/odoo/upgrade.request/2982092)

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

Current behavior before commit:

The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL).

Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14

Method Call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L18

During recursion in `_compute_average_price`, the company context incorrectly reverts to the global company instead of preserving the original company context from the initial call.

Recursive call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L77

Since the product is a kit, its cost is derived from its components. However, due to the incorrect company context switch, the purchase price is incorrectly set to 0 (because the product does not exist in the global company). This distorts sales margins in ongoing sales orders.

Root Cause:

The stock_moves passed into the method have env.company set to Company 1. At
https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L66

bom_lines are extracted, inheriting the environment from stock_moves. As a result, _compute_average_price is executed within the context of Company 1, which may lead to incorrect computations when the intended company context is different.

Fix:

Ensure that stock_moves is explicitly passed into the method with the correct company context. This guarantees that the company context remains consistent throughout the execution, preventing unintended company switching.

opw-4222976

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#215785
Forward-Port-Of: odoo/odoo#192890

When doing the following steps:
Purchase > Receipt > Landed Cost > Return > Return > Bill

The landed cost would prevent the method _generate_price_difference_vals from correctly computing the correct Out Quantity.

Hence, even if no stock is actually out, the bill would generate a COGS line for the currency rate difference for the quantity already out.

---

### Test result without fix:
```
2025-06-25 11:17:39,821 33449 ERROR oes_test_17 odoo.addons.stock_landed_costs.tests.test_stockvaluationlayer: FAIL: TestAccountInvoicingWithCOA.test_fifo_return_twice_and_bill_with_landed_cost_and_multi_currency
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/stock_landed_costs/tests/test_stockvaluationlayer.py", line 759, in test_fifo_return_twice_and_bill_with_landed_cost_and_multi_currency
    self.assertRecordValues(bill2.line_ids, [
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/tests/common.py", line 667, in assertRecordValues
    self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
Wrong number of records to compare: 5 records versus 3 expected values.

==== Additional record ====
{'account_id': 388, 'amount_currency': 0.0, 'balance': 25.0}

==== Additional record ====
{'account_id': 406, 'amount_currency': 0.0, 'balance': -25.0}
```

---

OPW-4512411
Origin PR: #199440

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

Forward-Port-Of: odoo/odoo#215827

**Issue 1**
- Have a pricelist with the "Discount policy" == "without_discount"
- Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line
- Set a discount on both lines
- Save the SO
- Issue: the discount on the non-subscription line has been reset to 0.0

**Issue 2**
- Using the previous SO, add back a discount value for the non-subscription line
- Confirm the SO and invoice it
- Close the subscription
- Issue: the discount on the non-subscription line has been reset to 0.0

**Cause**
Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount.

**Solution**
It is not possible to know which dependency triggered the compute, therefore the solutions are to:
- avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary
-  avoid calling super for lines if the subscription is closed

opw-4645579

Forward-Port-Of: odoo/enterprise#84754