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