### Issue:
When closing an OSS report, the generated tax closing entry was incorrectly identified as a standard Tax Return
After posting, the document type remained `Tax Return` instead of the expected OSS report type

### Cause:
In this PR: https://github.com/odoo/enterprise/pull/95775, a condition was simplified to unify closing moves across report variants However, this caused OSS reports to be treated as standard tax reports

As a result, only one closing move could be created and reused for both Tax Reports and OSS Reports for the same period The document was also incorrect because of this simplification

### Steps to reproduce:
- Install `l10n_nl` and switch to NL Company
- Activate `EU Intra-Community Distance Selling` in Settings (reload taxes if needed)
- Confirm invoices for a Belgian Customer using the tax 21% BE VAT
- Go in Accounting > Reports > Tax Return
- Select the report type OSS Sales and the quarterly period
- Click `Closing Entry`
- Post the entry A Tax Return document is created instead of an OSS report

### Other Fix:
If a standard Tax Report closing entry is created first, the closing move becomes linked to it and is then incorrectly reused for the OSS report

opw-5489822
opw-5882188

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

__

## Short functional explanation of the error
When printing labels of lot or serial products with a custom paper format, the obtained pdf contains several empty pages.

## Reproduction Steps
1. Enable Debug Mode. In Settings, click on the Technical tab. In the reporting section, click on Paper Format.
2. Click on New. Give a name to your paper format. In the Paper Size field, select Custom. For Page Height and Page Width, make sure that they're smaller than A4 measurements. For example, set the Page Height at 57 and Page Width at 35. Set Margins at 0. In the Associated Reports field, select `lot/Serial Number (PDF)`.
3. Go to Inventory. Click on the Products tab > Lots / Serial Numbers. Click on any Serial Number. Click on the Cog on the top left > Print > Lots / Serial Number (PDF).

### Expected behavior
We obtain a PDF of only one page containing the barcode of the serial number.

### Unexpected behavior
We obtain a PDF of 5 pages, including 4 blank pages and only one page holding the barcode.

## Origin of the issue
In the XML of the label reports, we use the css class `o_label_sheet`: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L9 In this class, the height and width of sheets are hardcoded to A4 dimensions:
https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/product/static/src/scss/report_label_sheet.scss#L5-L6 Therefore, if we set the dimensions of the custom paper format to be smaller than an A4 page, we'll obtain several blank pages, until the dimensions of an A4 pages are met.
Moreover, the dimensions of the padding are also hardcoded, which can be an issue in the case of very small custom dimensions. Finally, we nest barcodes in an HTML table:
https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L10 for which we hardcode the dimensions:
https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L6-L7 This will result in always printing the same amount of barcodes per row in the case of batch printing, even if the dimensions are too small to hold them all. This will also result in always nesting 12x4 barcodes, even when only printing one, while hiding the others, which also produces additional unrequired blank pages.

Therefore, we need the dimensions indicated in the paper format of the report to dynamically compute
the dimensions of the padding and the rows/columns of the HTML table.
__
opw-6071885

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.

**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.

**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.

**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.

opw-6099340