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

Steps to reproduce the bug:
- Install point of sales app, employees app
- Make a shop and enable multiple employees per session option
- Add another user as a basic right user for any shop
- Open a shop session (the one rights are set up for)
- Log out of the current user and log in with the other user account
- Open the session
- The current logged-in user can close the session despite having basic rights

Problem:
The close session in the XML was having a condition of pos.employeeIsAdmin, and the employeeIsAdmin flag was checking if the user is having advanced rights on the shop or it is the logged-in Odoo user. So if you are the logged-in user, you will always have the close register option regardless of the access rights you have for a specific shop.

opw-4575692

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

Enhance query efficiency for large accrued data by implementing batch processing
Previously, fetchall() loaded all IDs at once, causing memory errors.


```sql
select count(*) from pos_order;
  count
----------
 16736714
(1 row)

select count(*) from pos_order_line;
  count
----------
 24988345
(1 row)

select count(*) from pos_payment;
  count
----------
 16430502
(1 row)
```

- Traceback

```python
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1321, 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 127, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 484, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 372, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 240, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 254, in migrate_module
    mod.migrate(self.cr, installed_version)
  File "/home/odoo/src/odoo/18.0/addons/point_of_sale/upgrades/1.0.2/post-deduplicate-uuids.py", line 38, in migrate
    deduplicate_uuids("pos_order_line")
  File "/home/odoo/src/odoo/18.0/addons/point_of_sale/upgrades/1.0.2/post-deduplicate-uuids.py", line 30, in deduplicate_uuids
    all_ids = [r[0] for r in cr.fetchall()]
MemoryError
```

opw - 4544050
upg - 2459515

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

**Steps to reproduce:**
- Install Accounting and l10n_es_edi_facturae
- Switch to a Spanish company (e.g. ES Company)
- Create an invoice:
  * Customer: [a Spanish customer] (e.g. Ayuntamiento De Bilbao)
  * Product: [any]
  * Customer Reference: [anything]
- Confirm the invoice
- Generate Facturae edi file via "Send & Print" button
- Check the generated XML

**Issue:**
When submitting the XML to FACe service, the XML is rejected because "ReceiverTransactionReference" and "ReceiverContractReference" are not defined for each "InvoiceLine" element.
There are just defined for the invoice in general in "FileReference" element.
According to the official documentation
https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx they can be defined in "InvoiceIssueData" and "InvoiceLine". FACe seems to require it in "InvoiceLine".

**Solution:**
Also add "ReceiverContractReference" in "InvoiceLine" and fall back on customer reference of the invoice for "ReceiverTransactionReference" of the line.

opw-4579987




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

Forward-Port-Of: odoo/odoo#205264
Forward-Port-Of: odoo/odoo#204294

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