Since 17.0, `webp` images can be uploaded at any resolution, whereas every other format is refused above IMAGE_MAX_RESOLUTION (50 Mpx) when the attachment is created on the server.

Root cause
===========
`ImageProcess` grouped webp together with empty sources and SVG and set `self.image = False`, returning before the `verify_resolution` check. As a result the resolution limit enforced for `png/jpeg/...` was never applied to `webp`.

Fix
===
Split `webp` out of the skip branch: it is still not processed as before, but its resolution is now read from the RIFF header with `get_webp_size()` and checked against `IMAGE_MAX_RESOLUTION`, so oversized webp images are refused on upload like any other format.

Steps to reproduce
===================
1. Edit any page with the website editor
2. Upload a `webp` image larger than 50 Mpx (e.g. 8000x8000)

=> The image is accepted, while a `png/jpeg` of the same size is refused

task-4134430

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

Forward-Port-Of: odoo/odoo#273140
Forward-Port-Of: odoo/odoo#273010

When uploading a font file "FontName 123 Light.otf" the baseFontName needs to be quoted in the font-face CSS to be valid.

Single font files parsing for the shortestNamedFont now also correctly keeps the weight for the targetFonts.

Description of the issue/feature this PR addresses:
Uploaded fonts with spaces in the name are not working.

Current behavior before PR:
When uploading a font with a space in the filename like  "FontName 123 Light.otf" the css declaration in the attachement is wrong and not working:
```css
@font-face {
	font-family: FontName 123 Light;
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}@font-face {
	font-family: FontName 123 Light;
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}
```

Desired behavior after PR is merged:
The font name is now correctly quoted and the font attributes are no longer overwritten for the shortestNameFont:
```css
@font-face {
	font-family: "FontName 123 Light";
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}@font-face {
	font-family: "FontName 123 Light";
	font-style: normal;
	font-weight: 300;
	src: url("/web/content/1057/FontName 123 Light.otf");
}
```

Info @wt-io-it

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

Forward-Port-Of: odoo/odoo#268842

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

**Steps to reproduce:**
- Install the `l10n_mx_reports` module and switch to a Mexican company.
- Navigate to Accounting > Reporting > Trial Balance.
- From the dropdown menu, click `SAT (XML)`.
- Open the generated XML file and inspect the `<BCE:Ctas>` nodes.

**Observation:**
- The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni`
- However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin`

**Root Cause:**
At [1], the attributes of the `<BCE:Ctas>` node are defined in an order 
that differs from the SAT-recommended structure. While the XML remains 
valid, the generated report does not match the layout recommended by the 
Mexican government specification.

**Fix:**
This commit reorders the `<BCE:Ctas>` attributes to follow the 
SAT-recommended structure, aligning the generated XML with 
the behavior introduced at [2] for `saas-19.3`.

backport-of: https://github.com/odoo/enterprise/pull/115374

[1]:
https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20

[2]:
https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22

opw-6297711

Forward-Port-Of: odoo/enterprise#122469
Forward-Port-Of: odoo/enterprise#121440

When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see
 
https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177

That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc.

Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name.

Steps to reproduce:
1. Enable Reserve with Google on an appointment type.
2. Book a slot from Google Maps with given name John and family name Doe.
3. Open the created booking and its contact in Odoo.

=> the contact name is the email instead of John Doe

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318)
opw-6232318

Forward-Port-Of: odoo/enterprise#120604

The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24)
override builds link.tracker short URLs from
`website.get_current_website()` and the current company's website
domain. It was introduced by
https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a
for a multi-company backend flow (users switching companies to post
social marketing links), but it runs for every compute, including
CRON contexts with no HTTP request such as the mass-mailing queue.

Without a request, `get_current_website()` picks an arbitrary website
(the first in the database) and `self.env.company` resolves to the
user's main company, so the short URL uses that company's website
domain instead of `web.base.url`.

Fall back to `super()._compute_short_url_host()` (which uses
`web.base.url`) when no website is resolvable from the request,
session, or context. Backend flows with a real request still hit the
company-aware branch.

Steps to reproduce:
1. Install Email Marketing and Website.
2. Settings > Companies: create a second company B. Settings >
   Websites: ensure website A points to company A with domain A, and
   create website B for company B with domain B.
3. Settings > Technical > Parameters > System Parameters: set
   `web.base.url` to a third domain C, and add `web.base.url.freeze`
   = `True`.
4. On company A, Email Marketing: create a mailing with body
   `<a href="http://example.com">test</a>` and a recipient list,
   then click Send.
5. Settings > Technical > Automation > Scheduled Actions > "Mass
   Mailing: Process queue" > Run Manually.
6. Email Marketing > Configuration > Link Tracker: open the tracker
   generated for the mailing.

=> The Tracked URL uses domain A.
=> The Tracked URL uses domain C.

Ticket [link](https://www.odoo.com/odoo/project.task/6038590)
opw-6038590

Forward-Port-Of: odoo/odoo#259200