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

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

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

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

Previously, marketing campaign testing (through debug) could cause
an issue where tracked links could cause a traceback if a marketing
activity was edited after a test was attempted.

To work around this, #13665 deactivated link tracking in marketing
campaign tests. However, this meant that flows including click actions
could no longer be tested.

As this issue has been resolved in odoo/odoo#48845, this commit
reverts https://github.com/odoo/enterprise/pull/13665 to once again
permit marketing automation testing.


--

Additional changes are needed to fix other issues:
Tests using one's own coordinates are prone to breaking due to newer
mailing traces attaching themselves to the oldest marketing trace.

This commit makes it so that marketing campaign tests for the same
marketing campaign and coordinates cannot run concurrently, by
cancelling older test campaigns upon starting a new one.

Different tests can still run concurrently on distinct partners/leads/
etc.

Additionally:
- Running tests are now visible on campaigns in the "New" state;
- Activities don't mark themselves as needing sync unless their campaign
is in the "Running" state.

task-4557855

Forward-Port-Of: odoo/enterprise#89364
Forward-Port-Of: odoo/enterprise#78793

**Steps to reproduce:**
- Set up CRM / Appointment / Website apps
- Create new company (2)
- Create partner contact with specific email and the new company
- Create appointment type linked to a staff user of another company (1) who has no access to the new one
- Enable `Create Opportunities` on the new appointment type
- Go to the website as an anonymous user
- Submit an appointment request using the partner's email
- `Incompatible companies on records:` error

**Issue:**
Previous solution (17.0) was trying to use existing partner if the email was provided and existed in the database
 `customer = request.env['res.partner'].sudo().search([('email_normalized', '=', email_normalized)], limit=1` 
This means that, in a multi-company environment, the lead created by the new appointment for the appointment user of company 1 can be linked to the partner contact of company 2 and throw an error on validation.

**Fix:**
Restricted partner search domain using current allowed companies using the `staff_user` or the user which created the `appointement_type`.

opw-4713060

Forward-Port-Of: odoo/enterprise#87620
Forward-Port-Of: odoo/enterprise#84006

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