Before this commit, discuss call HOOT tests retained the window object after test ended.

Retained memory was about 2.5Mb-4Mb per test.

An earlier PR [1] fixed a similar issue from a `const` object being used in field default value. This was a problem because JS models internal code is keeping a reference to this object, and since HOOT suite test reuses the same window object, the window of each test were retained. The PR [1] fixed the issue by not setting object as default value of the field.

Note that the default value and its presence in internal code of JS models happened for all tests that use `@mail` static files. That means this PR `[1]` fixed a retained memory for all `@mail` and related tests.

While this fixed many tests, we still observed this retained memory on all discuss call tests. This happens because while the default value no longer uses this shared object, the computed value still does. Therefore call tests were sharing the const and thus retaining the window object. Note that the computed method is implicitly lazy, so this is only invoked in code that actually uses this `iceServers` field, hence why only discuss call tests were still affected by the issue.

This commit fixes the issue by replacing the DEFAULT_ICE_SERVERS object by GET_DEFAULT_ICE_SERVERS function. This ensures each test use a different object, thus preventing retaining the window object after test has ended.

[1]: https://github.com/odoo/odoo/pull/204521

Correct multi-company lead visibility in portal.

[task-4482622](https://www.odoo.com/web#view_type=form&model=project.task&id=4482622)

Description of the issue/feature this PR addresses:
In a multi-company environment, portal users (partners) were unable to access Opportunities and Leads belonged to them, when these records belonged to company(branch) that is not main company. Their visibility was restricted to records from the main company, even if their access rights were configured to allow access to multiple companies.

Steps to reproduce:
1. Create a new company
2. Create a partner and grant them portal access
3. Grant the partner access right to the new company.
4. Switch to the new company and create an opportunity and assign it to
this partner (Under assigned Partner tab).
5. Log in as the partner, go to "my/opportunities."
6. The opportunity is not there.

Desired behavior after PR is merged:
Partners can see lead/opportunities from multiple companies.

---
Current behavior exists for other portal endpoints such as my/subscriptions, my/sales, my/invoices but I believe that the current behavior is expected and normal for these endpoints.

---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Steps to reproduce
- open a record from Contacts app
- from chatter, click `send mail` , open full mail composer
- add a attachment
- schedule a message, by clicking '▼' on send message
- Again from chatter, click on edit the same message
- try to add another attachment

Observation:
A traceback is received

Issue:
Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static/src/core/web/mail_composer_attachment_selector.js#L25-L30

but in case message is scheduled, which is stored in `mail.scheduled.message` ,when editing it we do not have `res_ids` 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/wizard/mail_compose_message.py#L120

instead we have `res_id` field, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/models/mail_scheduled_message.py#L46
hence a traceback is received when trying to json parse a `undefined` value.

Fix:
Adapt the `onFileUploaded` function to consider both, `res_ids` and `res_id`

opw-4839926


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

**Steps to reproduce:**

- Install the `documents_project` module.
- Create a project, set visibility to '**Invited internal users (private)**', and add Marc Demo as a follower.
- In the project settings tab, hover over the folder name and open it.
- Click the gear icon and select 'Share', ensuring Marc Demo is listed under '**People with access**'.
- Set both '**Internal Users**' and '**Anyone with the link**' to None, then click 'Done'.
- Create a task for the project and add Marc Demo as the assignee
- Upload a document via the document smart button
- Now go to the task with Marc Demo

Marc Demo cannot see the document but can see the attachment. The document smart button shows 0 count.

**Issue:**

Marc Demo, a project follower and task assignee, cannot see the document because it’s not shared with his user’s partner. 

**Solution:**

- Grant 'view' access to task assignees if project visibility is set to
  'Invited internal users (private)', allowing assignees to access the documents.
- Revoke document access for partners who are unsubscribed and no longer
  followers of the associated project and task.
- Also, implemented a test case to cover these use-cases.

opw-4702911

**Steps to reproduce:**
- Install account_budget
- Activate "Budget Management" in Accounting settings

- Go to "Accounting / Accounting / Analytic Budget"
- Create a new budget:
  * Budget Type: Expense
  * Period: [this month]
  * Budget Lines: [a line with an analytic account (AA) in 2 plans]
- Open the budget

**Issue 1:**
Create a PO at the current date with a line having only one of the AA as analytic distribution and an amount higher than the budgeted amount.
The PO line and the Budget button appear in red, but it shouldn't because the analytic distribution of the line doesn't match all the accounts defined on the budget line.
The line will not impact the budget, but it appears in red, which is confusing.

**Cause 1:**
When computing the budget lines linked to the PO line, the domain that is used is only taking into account the plans that are set on the PO line, ignoring the plans that are not set.
For the Budget button, all the PO lines are used instead of just those having the correct analytic distribution.

**Issue 2:**
- Create a PO at the current date with 2 lines:
1) a line with the same AA than the budget line and an amount higher than the budget amount
2) a line with the same AA than the budget line and an amount lower than the budget amount
- Save the PO
The first line should be red, but it is not.

**Cause 2:**
When computing the budget lines linked to the PO lines, only the last PO line has its value set.

opw-4757067

### Steps to reproduce:
- On a contact, add the "Factur-X" E-Invoicing method under the "Accounting" tab
- Create an invoice with this contact as the customer
- Send the invoice, download the PDF
- Verify the PDF. For example with https://demo.verapdf.org/
- `The aforementioned EOL marker shall be immediately followed by a % (25h) character followed by at least four bytes, each of whose encoded byte values shall have a decimal value greater than 127`
- `The MIME type of an embedded file, or a subset of a file, shall be specified using the Subtype key of the file specification dictionary. If the MIME type is not known, the "application/octet-stream" shall be used`

### Cause:
- 1
Pypdf 2.2 is [adding the necessary binary](https://github.com/py-pdf/pypdf/commit/036789a4664e3f572292bc7dceec10f08b7dbf62) like Odoo [does](https://github.com/odoo/odoo/blob/c1679123c9c6f7184293befb399de1e79a6205a9/odoo/tools/pdf/__init__.py#L471) for Pypdf2.1 because it is mandatory for PDF/A.

The issue comes from two line break following each others:
Pypdf2.2 adds one at the beginning of the [file](https://github.com/py-pdf/pypdf/blob/036789a4664e3f572292bc7dceec10f08b7dbf62/PyPDF2/pdf.py#L487): 
`\n % E2 E3 CF D3`
Then Odoo [adds the header `%PDF-1.7\n` before](https://github.com/odoo/odoo/blob/c1679123c9c6f7184293befb399de1e79a6205a9/odoo/tools/pdf/__init__.py#L469) resulting in :
`b"%PDF-1.7" \n \n % E2 E3 CF D3`
PDF/A expects to have `% E2 E3 CF D3` on the second line right after the header but there is nothing on this line.

- 2
The Subtype is badly formatted: from `text/xml` to `/text#232Fxml` instead of `/text#2Fxml`

This occurs as Odoo [replace `/` by `#2F`](https://github.com/odoo/odoo/blob/2e43bee546d5c14729d654386209b539d8aa71d7/odoo/tools/pdf/__init__.py#L369-L377).
But then when [adding the subtype](https://github.com/odoo/odoo/blob/2e43bee546d5c14729d654386209b539d8aa71d7/odoo/tools/pdf/__init__.py#L595C17-L595C74) to the attachment, we call `NameObject` from PyPdf. This object will [format](https://github.com/py-pdf/pypdf/blob/1c4173a12cd21b91dff6d6596ed0bbf1999f2d10/PyPDF2/generic/_base.py#L548) the text again replacing the `#` by `#23`. 

### Solution:
- Don't add a `\n` after `%PDF-1.7` when using `_pypdf2_2`.

- As PyPdf2.2 is doing the formatting itself, we don't format on our side if `submod == ._pypdf2_2`. 
We still need to add the `/`.

opw-4748600

Forward-Port-Of: odoo/odoo#211006

Whenever there is a fault in the ZATCA onboarding steps (like missing
Certificate Signing Request (CSR) information etc.), a traceback is
returned to the user instead of a clear error message.
This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671
which changed the return format of the `_l10n_sa_call_api` function in
case of failures.

Steps to reproduce:
- Configure a Saudi Arabia company
- Switch ZATCA environment to Simulation (or Production)
- Attempt to onboard a journal using an incorrect OTP code
- A traceback is triggered instead of a clear user-facing error

Traceback example:
```
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 200, in _l10n_sa_compute_production_csid_validity
journal.l10n_sa_production_csid_validity = self._l10n_sa_get_pcsid_validity(
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 516, in _l10n_sa_get_pcsid_validity
b64_decoded_pcsid = b64decode(PCSID_data['binarySecurityToken'])
File "/usr/lib/python3.10/base64.py", line 80, in b64decode
s = _bytes_from_decode_data(s)
File "/usr/lib/python3.10/base64.py", line 45, in _bytes_from_decode_data
raise TypeError("argument should be a bytes-like object or ASCII "
TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'
```

This is due to the check in `_l10n_sa_get_compliance_CSID` for an 'error'
key, not present in the response when an OTP is invalid because in these
case, the `_l10n_sa_call_api` return the response_data directly.

This fix improves the behavior by displaying a user-friendly alert
message with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

opw-4838542

Forward-Port-Of: odoo/odoo#215067
Forward-Port-Of: odoo/odoo#214391

Previously, when multiple form snippets were added to the same page,
corresponding fields (e.g., the "Name" field) in each form were assigned
the same ID.

This happened because we retrieved the form fields from the
`FormEditorRegistry`.
For the first form snippet, field IDs are generated and assigned
correctly. However, assigning IDs to the fields also updated the fields
stored in the `FormEditorRegistry`.
So when a second form snippet is added, the fields it receives from the
registry already have an ID.
The ID generation logic skips fields that already have an ID, so the
fields in subsequent forms never got new IDs.

With this fix, we now create a shallow copy of each field before using
it. This prevents the original field definitions in the
`FormEditorRegistry` from being modified.

As a result, fields in different forms now receive unique IDs without
needing to explicitly delete the field ID to force a new one to be
generated.

[task-4251881](https://www.odoo.com/web#id=4251881&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#210537
Forward-Port-Of: odoo/odoo#183883