Description of the issue/feature this PR addresses:

**Description:**
> - When we open the 'Customers' menu on the website, the 'tags' are displayed in a single line

**Steps:**

> - Install the "website_customer" module.
> - Create a "Website Tag" from the Contacts app-> Configurations.
> - Add the tag to any partner's "Website Tags" field (inside the "Sales & Purchase" page).
> - Go to the website and open the "Customers" menu(from url).

Current behavior before PR:

    Before Fix:
![Our-References-My-Website](https://github.com/user-attachments/assets/9d5bc1ac-d407-4225-abd0-5f5edf5d6fa8)

    After Fix:
![Our-References-My-Website(1)](https://github.com/user-attachments/assets/d9876e8a-ef52-44d0-8204-34b3325c1f36)

Desired behavior after PR is merged:

    - All Tags are appropriately shown after my fix
    - The issue comes in version 17.0, 18.0, saas~18.1, and saas~18.2

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

Forward-Port-Of: odoo/odoo#203772

Partial backport of #202835

Nicer strategy for stable to avoid braking all existing clients tests

This should catch most case without introducing a lock and a mandatory allowance of the request.

- If the cookie is present, check if it is valid (request opening cursor in next test)
- Check if the test cursor was opened in the same test as the execute/rollback (request started in previous test executing in next)
- custom expected cookie for browser js to avoid allowing a request after wait_remaining_requests

All message could be silenced to kill the transaction without braking the test if it is a better strategy. 


Some design choices:
 - current_test is passed to Testcursor to avoid to add an import to odoo modules in sql_db, only impacts test logic. Parameter is optional. 
 - test cursor checks current_test before each operation (execute, commit, rollback). 
 - http_request_key is the test itself (between setup and cleanup), only exception is for browser js to avoid request executing during the end of the test (once browser is closed). It is the most common case.

Forward-Port-Of: odoo/odoo#205487
Forward-Port-Of: odoo/odoo#205190

Fixes
```
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end
    self._process_end_unlink_record(record)
  File "/home/odoo/src/odoo/addons/website/models/ir_model_data.py", line 35, in _process_end_unlink_record
    return super()._process_end_unlink_record(record)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2576, in _process_end_unlink_record
    record.unlink()
  File "/home/odoo/src/odoo/addons/mail/models/ir_model_fields.py", line 52, in unlink
    'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
                ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 612, in __getitem__
    return self.registry[model_name](self, (), ())
           ~~~~~~~~~~~~~^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/modules/registry.py", line 240, in __getitem__
    return self.models[model_name]
           ~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'my.custom.model'
```

To reproduce:

* add a model with a tracked field to a module
* create a record and update field value to create a tracking message
* remove the model from the module and update the module


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

Forward-Port-Of: odoo/odoo#204978

**Problem:**
On a repair order, if the user is changed it changes the location (and recycled parts destination location) to the default one.
Additionally, when the order is confirmed, there is no way to change manually the location. The problematic use case is that if you first confirm the RO and then change the user, it will trigger a change of the location that you won't be able to revert manually.

**Steps to reproduce:**
- enable location in DB
- create a new repair order
- change the location and recycled parts destination location
- confirm the repair order
- change the responsible user

**Current Behavior:**
The location and recycled parts destination location fields values are changed to the default value for this operation type.

**Expected Behavior:**
The values of those fields shouldn't change after the repair order is confirmed.

**Cause of the issue:**
The _compute_picking_type_id depends on "user_id" and is therefore triggered when the user is changed
https://github.com/odoo/odoo/blob/1445d5adabf8eabe83e842c214655a74434bad4d/addons/repair/models/repair.py#L196
This triggers the _compute_location_id and _compute_recycle_location_id methods because they depend on
"picking_type_id"
https://github.com/odoo/odoo/blob/fa41c1d50f10ebab08437557ee863348a63de2c0/addons/repair/models/repair.py#L204
This happens regardless of whether the repair order has been confirmed.
Because the list of compute methods to be triggered when user_id is changed is computed all at once before
running them, adding an if statement at the beginning of _compute_picking_type_id (preventing the change
of value of picking_type_id if the state is not "draft") would not prevent _compute_location_id and
_compute_recycle_location_id to run.
Putting an if statement at the beginning of _compute_location_id and _compute_recycle_location_id
to prevent the change when the state is not in "draft" is not a good fix either. That's because
we wouldn't know if the computation is triggered by a change of user or a change of picking_type_id
(in which case we want the computation to run)

**Fix:**
I removed the 'user_id' dependency on _compute_picking_type_id


opw-4555293

Forward-Port-Of: odoo/odoo#202227

Description of the issue/feature this PR addresses:
As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the invocie has been ZATCA verified, are getting errors if they have insufficient access rights; for instance a normal user who has POS User access and Accounting/Billing is unable to generate PoS orders as they are forced to have the invoice checkbox set in the `l10n_sa_pos` and when the invoice is generated it is giving the following Traceback.

Current behavior before PR:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/api.py", line 1013, in get
    cache_value = field_cache[record._ids[0]]
KeyError: 415613

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/fields.py", line 1161, in _get_
    value = env.cache.get(record, self)
  File "/home/odoo/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'account.edi.document(415613,).attachment_id'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/fields.py", line 1187, in _get_
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/odoo/models.py", line 3230, in _fetch_field
    self.check_field_access_rights('read', [field.name])
  File "/home/odoo/src/odoo/odoo/models.py", line 2986, in check_field_access_rights
    raise AccessError(_(
odoo.exceptions.AccessError: The requested operation can not be completed due to security restrictions.

Document type: Electronic Document for an account.move (account.edi.document)
Operation: read
User: 40
Fields:
•⁠  ⁠attachment_id (allowed for groups 'Administration / Settings')
```


Desired behavior after PR is merged:
To Fix the issue and sudo() the access to the edi attachment



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

Forward-Port-Of: odoo/odoo#204912

…rwriting

**Issue:**
The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id.

**Steps to Reproduce:**
1. Install the data_cleaning module
2. Open psql in the terminal
3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';”
4. Observe that data_cleaning.model is missing from the results

Expected Behavior: the form view for data_cleaning.model should be present in the database.

Actual Behavior: the form view for data_cleaning.model is not found in the database.

**Root Cause**

The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views.

**Fix**
To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier.

Opw-4517418

Forward-Port-Of: odoo/enterprise#80594