Fixed cache pollution of _get_cached_template_info and added tests
regarding the website editor, more specifically on enabling or disabling
options related to views.

Context:
- Base:
  - the xmlid and key of ir.ui.view are unique;
  - the ir.ui.view are inherited if they are active, otherwise inheritance
    is not applied;
  - _get_cached_template_info(key) returns the cached record values.

- Website:
  - the key of ir.ui.view are not unique; they can exist for different
    websites and without a website;
  - the ir.ui.view are inherited if they are active, otherwise inheritance
    is not applied. If a specific inherited view exists (for the current
    website), the default view (with same key) is not applied;
  - for t-call, the specific view are used only if the view is active,
    otherwise the default view is displayed;
  - is_view_active(key) should return False if the view of the website in
    question is inactive. If the default view is False, but the website
    view is True, then the response should be True;

Issue:
`is_view_active` returns True if a view with this key is active, ignoring
the website-specific inactive view.

The issue was seen because the editor changes the display (active) of the
views by copying them with the website reference. So when we want to
change the menu, and hide it, the view is copied and set active=False.
Part of the menu was still visible because it uses a
`t-if="is_view_active(...)"`.

Issue introduced by: 97c2dd2ec569d34b044da6aa6f473277b48ada12

### Description of the issue/feature this PR addresses:
[build_error-227711](https://runbot.odoo.com/odoo/error/227711)

### Current behavior before PR:
When testing for proper move descriptions, we add a second (no variant) attribute to the product only if the module `purchase_product_matrix` is installed.
In its absence (such as in a single-app test), we only have a single attribute_line, and referring to a second line throws an IndexError:
```
Traceback (most recent call last):
  File "/data/build/odoo/addons/purchase_stock/tests/test_create_picking.py", line 886, in test_move_description
    'product_no_variant_attribute_value_ids': [Command.set(product_with_description.attribute_line_ids[1].product_template_value_ids[0].ids)],
                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
  File "/data/build/odoo/odoo/orm/models.py", line 6375, in __getitem__
    return self.browse((self._ids[key],))
                        ~~~~~~~~~^^^^^
IndexError: tuple index out of range
```


### Desired behavior after PR is merged:

Instead, we should only populate the `product_no_variant_attribute_value_ids` of the order line when the no_variant attribute is present in the product, i.e. only when the optional module is installed.



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

**Issue**:
When multiple invoices with different customer languages are sent and printed together, the invoice email button may appear with an incorrect translation for some of them.

**Steps to reproduce**:
- Open the Accounting app
- Go to Customers > invoices
- Create a new invoice with a customer with its language set to German
- Create a new invoice with a customer with its language set to English
- Go back to Customers > invoices
- Select the two invoices just created and click on action > Sent & Print and then click on the Sent & Print button
- Go to Settings > Technical > Email > Emails and check the two last emails. One of them should have the invoice email button wrongly translated

**Cause**:
Before sending an email, it retrieve the `type_name` using the lang of the customer https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/account/wizard/account_move_send.py#L596C1-L605C14

This will trigger that compute method
https://github.com/odoo/odoo/blob/a6368e8a5787f3067d09d79516a2924b3f1207f0/addons/account/models/account_move.py#L841C1-L850C67

which set the `type_name` of all the records. Since the compute method only depends on move_type, it does not recompute type_name per record. As a result, all records may share the same type_name, regardless of language context. Please notice that `type_name` is used to display the invoice email button in the right language. 

**Solution**:
Make the compute method `_compute_type_name` depending to the lang parameter, thus it will use the right `type_name` for each email to send.

opw-4748741

Forward-Port-Of: odoo/odoo#216811

Versions
--------
- 17.0+

Steps
-----
1. Set up 10% price-included tax;
2. copy the tax to a B2B version that's price-excluded;
3. create a B2B fiscal position mapping the first tax to the second;
4. create a $10 product using the first tax;
5. create a branch for the current company;
6. switch to the branch company;
7. set up a sale order with the fiscal position;
8. add the product to the order.

Issue
-----
While the line displays the correct B2B tax, the unit price displays $10, as if it was computed without any taxes, instead of a price-excluded tax.

Cause
-----
In the `_compute_price_unit` method, it filters out all tax records linked to the product that don't have the same company as the order line, so the parent company's tax does not get factored in.

Solution
--------
Rather than requiring strict equality between companies, also allow taxes that belong to a parent company of the line's company.

opw-4853042

Forward-Port-Of: odoo/odoo#217012
Forward-Port-Of: odoo/odoo#216124

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.

on 18.4+, we only rename the variable from isLabelHidden to showLabel

task-4881878

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

Forward-Port-Of: odoo/odoo#217226
Forward-Port-Of: odoo/odoo#215023

Steps to reproduce:
- Install Sales and Stock
- Activate the multi-step routes setting
- Go to a Delivery route in the warehouse
- Change the `location_dest_id` of the operation type set on the rule
- Enable the "Location Dest. Taken from Rule" checkbox
- Ensure `rule.location_dest_id` and `operation_type.location_dest_id`
  are different
- Create a Sales Order (SO) for a product with quantity = 5 and confirm
- Change the SO line quantity to 3 and save

Issue:
A second picking is created with a move taking the product from
`rule.operation_type.location_dest_id -> rule.operation_type.
location_src_id` with quantity = -2.

This happens because the decrease in the SO quantity triggers a
negative move, and this move is not merged with the existing
positive move. Instead, a new move is created in the opposite
direction.

In `_merge_moves`:
https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193

It checks if the negative move has similar characteristics to the
existing positive moves. However, the `neg_key(neg_move)` differs in
`location_dest_id`, so the merge fails. This happens because the
negative move does **not** read the `location_dest_id` from the rule —
unlike the procurement, which **does** use the rule and therefore
creates positive moves with the correct destination.

When the negative move is created with the procurement, it initially
has the correct `location_dest_id`. But then:

https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191
triggers `_compute_location_dest_id`, which doesn't consider the
`rule.location_dest_id` and defaults to `operation_type.
location_dest_id`, causing the merge to fail due to mismatched
destination_locations.

The positive move has read the correct value, because when it
was assigned to a picking, the picking has the correct destination
from the procurement. But for the neg_move it has picking None so
it maps to the operation_type without consdiering the location from
rule checkbox.

opw-4793171

Forward-Port-Of: odoo/odoo#212355

**Steps to reproduce:**
1. Install the website_sale app.
2. Import a user with trailing spaces in the Name field.
3. Make this user Admin in settings
4. Log in with that user and go to Website > Shop.
5. Click on new and create a new product
6. Add this product to the cart and proceed to checkout.
7. The checkout form pre-fills the name (with trailing spaces).
8. fill other fields
9. Submitting the form triggers a warning due to changed name.

**Expected behaviour:**
- Name is not changed by us so it should let us checkout
- There should not be trailing spaces in imported char fields
  if trim attribute is true

**Issue:**
- The name field from the form is trimmed in post request,
  but the value from the database (with trailing spaces) is used during comparison
  This results in a false positive change detection.

- User's name with trailing spaces is because of Imported records does not check for
  trim attribute in backend but this is handled in ui.

**Solution:**
- Trim the database value before comparing it to the form input
- Trim the values of char field before importing if trim attribute is true

opw-4794220

Forward-Port-Of: odoo/odoo#215467
Forward-Port-Of: odoo/odoo#212040

**Steps to reproduce**
- Set "Extra Hours Validation" to "Automatically approved"
- Create an attendance for an employee
- Change the "Extra Hours" to a different value
- Create another attendance for this employee (not necessarily on the same day)
- See that the "Extra hours" of the previous attendance has been recomputed, resetting the value entered by the user.

**Cause**
When creating an attendance for an employee, we recompute the `validated_overtime_hours` for the other attendances of this employee
https://github.com/odoo/odoo/blob/cac96f5d3c391ea0d52da2e3433e7eabe07e8fb0/addons/hr_attendance/models/hr_attendance.py#L426 In case of attendances with no validation, this field is synced with the `overtime_hours`
https://github.com/odoo/odoo/blob/cac96f5d3c391ea0d52da2e3433e7eabe07e8fb0/addons/hr_attendance/models/hr_attendance.py#L156

**Solution**
We may still want to recompute the `validated_overtime_hours` of automatically approved attendances, since it is their default state, unlike manually approved attendances.

If the `validated_overtime_hours` field is different from `overtime_hours`, it means it has been modified. In that case, we avoid recomputing it. This doesn't guarantee a manually set value will never be overriden by a change in its dependencies, but it reduces the likelihood.

opw-4639230

Forward-Port-Of: odoo/odoo#207806

**Steps to reproduce:**
- Install accountant, l10n_ar and l10n_latam_check
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Make sure that USD currency has a rate different than 1

- Create a journal:
  * Journal Name: Checks journal
  * Type: Cash
- Save the journal
=> a Cash Account should be automatically created
- In "Incoming Payments" tab of the journal, set:
  * "New Third Party Checks" with the Cash Account
  * "Existing Third Party Checks" with the Cash Account
- In "Outgoing Payments" tab of the journal, set:
  * "Existing Third Party Checks" with the Cash Account

- Create an invoice:
  * Customer: [an Argentinian customer] (e.g. ADHOC SA)
  * Currency: ARS
  * Invoice Lines:
    - Quantity: 1
    - Price: 150000.00
    - Taxes: VAT 21%
- Confirm the invoice
- Pay the invoice:
  * Journal: [the created Checks journal]
  * Currency: ARS
  * Checks: [add a line with the amount of the invoice]

- Create a bill:
  * Vendor: [an Argentinian customer] (e.g. ADHOC SA)
  * Currency: USD
  * Invoice Lines:
    - Quantity: 1
    - Price: 500.00
    - Taxes: VAT 21%
- Pay the bill:
  * Journal: [the created Checks journal]
  * Payment Method: Existing Third Party Checks
  * Checks: [add a line and select the check used to pay the invoice]

**Issue:**
When the check (from the invoice) is selected to pay the bill, the original amount (in ARS) is used but the currency stays in USD, which is not correct.
If the currency is changed to ARS, the currency rate is applied on the amount that is already the amount in ARS, which generates a higher incorrect amount.

**Solution:**
Use the currency set on the existing check by default.
Also prevent adding several checks with different currencies. 

opw-4741607




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

Forward-Port-Of: odoo/odoo#215435

When multiple `ir.ui.view` records exist with the same key
(e.g., due to duplication), it can lead to a singleton error.

**Steps to reproduce:**
1. Install the website module
2. Go to `Settings > Technical > User Interface > Views`.
3. Find and duplicate the **Home** view for **My Website** (same key).
4. Open the website home page in Editor mode.

**Error:**
`ValueError - Expected singleton: ir.ui.view(2776, 2774)`

**Cause:**
In `viewref()`, it uses `filter_duplicate()` to filter for the 
most suitable view, but it may return multiple views if more 
than one match the criteria. - [1]

**Ref:**
At [2], system uses `limit=1` in `_view_obj()` to 
ensure only one view is returned, even if duplicates 
exist for the same key.

[1]: https://github.com/odoo/odoo/blob/edfa37271a0015a0d4acb17e6985a87e707e5f33/addons/website/models/website.py#L1228-L1230

[2]: https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/web_editor/models/ir_ui_view.py#L326

**Fix:**
This commit ensures that the result is a record set with at 
most one view and preventing singleton-related errors.

sentry-6223988092

Forward-Port-Of: odoo/odoo#213113

**Steps to reproduce:**
- Install accountant, l10n_be and account_winbooks_import
- Switch to a Belgian company (e.g. BE Company CoA)
- Go to "Accounting / Configuration / Settings"
- Click on "Import (for full history)" in "Accounting Import" section
- Click on "Import WBK" in "Winbooks" section
- Upload a Winbooks file containing several journals having their "DBKID" value longer than 5 characters with the 5 first characters being identical (e.g. "SALES001", "SALES002",...)
- Import

**Issue:**
Some journals are not imported.

**Cause:**
The code of a journal is limited to 5 characters and is unique per company.
When a code is longer than 5 characters, only the 5 first characters are kept.
In this case, several journals to create have the same 5 first characters.
Therefore, only one of them is created.

**Solution:**
If the code of a journal to create has the same first 5 characters of a journal that has already been created (and the same last 5 characters), we use a generic code formatted with a starting "*" char followed by a number that is incremented.
This format allows to quickly find it if we want to change its value once imported.
This solution is limited to 9999 journals that have a code that can starts with the same 5 characters than another journal, but it should be more than enough.

opw-4812655

Forward-Port-Of: odoo/enterprise#86068

### Background
In https://github.com/odoo/enterprise/pull/85026 we changed the behaviour of `l10n_mx_edi_post_time` so that it gets set during the CFDI sending process, rather than when the invoice is posted.

This was needed to ensure that the post time both reflects the sending time and is re-used if the invoice needs to be re-sent.

### Bug description
Since then, several Mexican customers have reported that some CFDIs are sent duplicated, with a difference of a few seconds in the CFDI's Fecha.

### Analysis
A disconnection might occur during sending of the CFDI. In that case, the PAC will process the CFDI, but in Odoo the transaction will be rolled back, and the `l10n_mx_edi_post_time` will be lost. When Odoo re-sends the CFDI, it will take a new `l10n_mx_edi_post_time`.

### Solution
Commit before performing the API call so that the `l10n_mx_edi_post_time` gets committed to DB.

opw-4780096

Forward-Port-Of: odoo/enterprise#89263
Forward-Port-Of: odoo/enterprise#89117

Currently a traceback is occurring when the user tries to create a Draft Entry, 
in the batch that contains payslips of multiple companies.

**To reproduce this issue:**

1) Install hr_payroll_account and switch to multi-company environment 
2) Create two employees with two running contracts respectively 
3) Now create a Batch record from payroll/payslips/batches 
4) Create two playslips with different companies with the created batch 
5) Compute both the payslips and open the batch
6) Now, try to click on the  Create Draft Entry

**Error:**
A traceback will occur.
```
ValueError: Expected singleton: res.company(1, 2)
```

**Cause:**
When the user created multiple payslips with multiple companies containing the same batch 
and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, 
and try to change the state to Done using the action_payslip_done method.

https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70

So the self will contain multiple payslip recordsets with different company in each payslip. 
This leads to the above traceback when accessing company_id from self
https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61

**Solution:**

In payslips, the company_id field should be in readonly state, 
since the value of the company_id will  computed from the employee_id which is a required field.

Also raised a validation Error for the previously created record to handle the traceback.

Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763

opw-4797089

Forward-Port-Of: odoo/enterprise#88307
Forward-Port-Of: odoo/enterprise#86628

### Issue:
When searching for "Unknown Partner" in the Partner Ledger to get the lines with no partner, nothing shows on the downloaded XLSX.

### Steps to reproduce:
- Have a partner Ledger with
- Search for "unknown Partner" in the search bar, only the lines grouped under "Unknown Partner" are shown.
- Click on the button "XLSX"
- The downloaded document does not include "Unknown Partner"

### Cause:
When `filter_search_bar` has a value, the domain used to query the partners/lines will check if the names of the partner match the search text. The resulting SQL query excludes the lines where `partner_id` is `NULL`.

### Solution:
Add a new condition in the domain: `('partner_id', '=', False)` This way the lines with no partner are returned by the query

When searching another existing partner these lines are excluded by an [already existing filter](https://github.com/odoo/enterprise/blob/8eff9194618a1d181c57820829e53aa23c7759d5/account_reports/models/account_partner_ledger.py#L55-L58). It excludes the lines if the search test does not match "Unknown Partner".

opw-4772529

Forward-Port-Of: odoo/enterprise#88139