Steps to reproduce:
-------------------------------------
1. Open the chatter of any record
2. Open the full composer for the Log Note
3. Add some text and paste some images > Post the log note
4. Click on the Edit option
5. Save the message without editing anything

Observation:
-------------------------------------
You will notice that the (edited) label appears even though the message wasn't edited at all, only the edit mode was made active.

Issue:
-------------------------------------
When a message is posted via the mail composer, the email conversion pipeline injects MSO conditional comments like
`<!--<![endif]-->` and `<!--[if mso]>...<![endif]-->` into the HTML body. These comments are added by the `_hideForOutlook` and `createMso` https://github.com/odoo/odoo/blob/083e091eaa7d983f6c826c02b0d0652a821227fb/addons/mail/static/src/views/web/fields/html_mail_field/convert_inline.js#L1978-L1988

https://github.com/odoo/odoo/blob/083e091eaa7d983f6c826c02b0d0652a821227fb/addons/mail/static/src/views/web/fields/html_mail_field/convert_inline.js#L1699-L1707

functions to ensure Outlook compatibility, they wrap responsive elements so that Outlook receives simplified table-based fallbacks while modern clients see the original layout. The stored message body on the server retains these comments. When a user clicks "Edit" on such a message, the body is loaded into the OdooEditor. The browser's DOM parser treats `<!--<![endif]-->` as standard HTML comment nodes, which are not preserved in `innerHTML` serialization. So the editor returns the body without these comments, even if the user made no changes. The `edit()` method in then compares `updatedBodyEl.innerHTML` (from editor, no comments) against `messageBodyEl.innerHTML` (from server, has comments), finds a difference, and sends a update to the backend, which stamps the message with the (edited) label.

Solution:
-------------------------------------
Before comparing innerHTML, strip all HTML comment nodes from both the original and updated body elements. This is done on throwaway DOM elements created solely for comparison. The actual body sent to the server (`body` parameter) is never modified.

Note:
-------------------------------------
An alternative approach would be to strip comments at the string level using a regex (`html.replace(/<!--[\s\S]*?-->/g, '')`) before creating the DOM elements. This is valid since HTML comment syntax `(<!--...-->)` is strictly defined and no nesting is allowed, so the regex is reliable.

opw-6328529

Forward-Port-Of: odoo/odoo#287472
Forward-Port-Of: odoo/odoo#274927

In Peru, the printed PoS receipt is the legal electronic invoice/receipt
(Factura/Boleta Electronica): it must carry the QR code and the summary
hash from the signed e-invoice.
Since 19.4, PoS invoice PDF/EDI generation became asynchronous
by default (deferred to a cron) to speed up checkout,
but l10n_pe_edi_pos was never updated to opt out of that for Peru,
so the signed data doesn't exist yet when the receipt is printed
right after validating the order.

Steps to reproduce:
-------------------
* Install l10n_pe_edi and activate SUNAT Signature Provider Setting
* Create and validate a PoS order and set "invoice" to true
* Print the receipt (Full Receipt or Simplified Receipt)

> Observation:
Neither receipt includes the QR code or the summary hash, so the printed receipt is no longer a valid electronic document.

Why the fix:
------------
Forcing the whole invoice (PDF + email + e-invoice) to be generated
synchronously would block checkout on a live SUNAT call, and would leave
failed orders with no way to be retried by the deferred-invoice cron.

PosOrder._generate_pos_order_invoice() now lets the PDF/email stay
deferred to the cron as before, but posts the e-invoice to SUNAT
synchronously on its own (no PDF, no email), so the receipt gets its
QR code/hash right away. This matches the pattern already used by
l10n_sa_edi_pos (generate_pdf=false + a synchronous EDI-only step),
as opposed to l10n_co_edi_pos, the only module forcing generate_pdf=true.

A chatter message is posted on the invoice if SUNAT rejects it, since
calling the EDI step directly bypasses the notification that
account.move.send would otherwise post.

opw-6426510

**Description of the issue/feature this PR addresses:**
If a field is `computed`, `precomputed`, and has `groups` defined, an `AccessError` is raised when a user who does not have the required group creates a record because the field is precomputed.

After this commit https://github.com/odoo/odoo/pull/201565/changes/48521a311a6dc857c3808db70ed359c7866aa125, Odoo checks field access in `__get__`, so an `AccessError` is now raised. If the field is not precomputed, everything works fine. Therefore, this commit prevents the error by using `sudo()` to recompute the value.

I have attached a module to demonstrate the issue.

**Steps to reproduce the issue:**

1. Install the attached module. [sale_margin_security_test.zip](https://github.com/user-attachments/files/31967357/sale_margin_security_test.zip)
2. Create a sales order and add a product.
3. Try to save the sales order. The AccessError is raised.

https://github.com/user-attachments/assets/54c7e4e2-005f-4ced-bb62-22d0e00049d9

For more context, this module is a simple example extracted from the OCA `sale_margin_security` module, which inherits from a mixin and adds groups to the fields: https://github.com/OCA/margin-analysis/pull/285

You can see the error in this PR: https://github.com/OCA/margin-analysis/actions/runs/34254749207/job/102157600233?pr=285#step:8:126

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

Forward-Port-Of: odoo/odoo#287257

Steps to reproduce:
- Create an attribute "Size" with values M and L, variants creation mode "Dynamically", and an extra price of 10 on L
- Create a product at 30 using that attribute, and give the L variant a barcode
- In the PoS, type that barcode in the search bar and click the card

Issue:
The line is added at 50 instead of 40. Scanning the barcode with a barcode reader was fixed by c1ae3261e895, but resolving the variant from the search bar still charges the extra price twice.

Cause:
The lst_price of a variant already contains the extra price of every attribute value that creates a variant ('always' and 'dynamic'); only 'no_variant' extras are missing from it and have to be carried by the order line as price_extra. This is what ProductConfiguratorPopup does, hence the correct price when the configurator opens.

Both openConfigurator(), when the resolved variant leaves a single value per attribute line and no popup is needed, and handleConfigurableProduct(), when configure is false, filter those values with create_variant !== 'always', so a 'dynamic' extra is added on top of a lst_price that already includes it. The same fix was made in 18.0 by d4fabfa08d1c but was lost when pos_store.js was refactored in saas-18.1.

Fix:
Filter on create_variant === 'no_variant' in both places, like the configurator popup. This supersedes the !opts.code condition of c1ae3261e895: product_template_variant_value_ids never holds 'no_variant' values, so the extra is now ignored however the line was added - scan, barcode search, sale order import or optional product.

opw-6531114

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

Forward-Port-Of: odoo/odoo#286460

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/cdb63b4ec9 [REL] 19.4.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3aada7e2af [FIX] search and replace: manage invalid range [Task: 6483222](https://www.odoo.com/odoo/2328/tasks/6483222)
https://github.com/odoo/o-spreadsheet/commit/1512b72179 [FIX] xlsx: fix geo chart xlsx export [Task: 4632983](https://www.odoo.com/odoo/2328/tasks/4632983)
https://github.com/odoo/o-spreadsheet/commit/653c219732 [FIX] calendar chart: wrong groupBy choice filtering [Task: 5358625](https://www.odoo.com/odoo/2328/tasks/5358625)
https://github.com/odoo/o-spreadsheet/commit/e2475d3d89 [FIX] charts: show value do not work for combo chart [Task: 6528059](https://www.odoo.com/odoo/2328/tasks/6528059)
https://github.com/odoo/o-spreadsheet/commit/d05a4c1d8a [FIX] charts: some charts cannot be aggregated [Task: 6501177](https://www.odoo.com/odoo/2328/tasks/6501177)
https://github.com/odoo/o-spreadsheet/commit/9a60018018 [FIX] print: always print in light mode [Task: 6432165](https://www.odoo.com/odoo/2328/tasks/6432165)
https://github.com/odoo/o-spreadsheet/commit/a462726737 [FIX] charts: change chart runtime when changing the theme [Task: 6432165](https://www.odoo.com/odoo/2328/tasks/6432165)
https://github.com/odoo/o-spreadsheet/commit/0563389302 [FIX] print: handle hidden headers [Task: 6332587](https://www.odoo.com/odoo/2328/tasks/6332587)
https://github.com/odoo/o-spreadsheet/commit/09b1f961cc [IMP] package: update owl to alpha 49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/10529bf90d [FIX] composer speech_bubble: move after rendering [Task: 6484405](https://www.odoo.com/odoo/2328/tasks/6484405)
https://github.com/odoo/o-spreadsheet/commit/b5a6ad8264 [FIX] grid: hide AddRowFooter when the mainViewport is too small [Task: 6103620](https://www.odoo.com/odoo/2328/tasks/6103620)
https://github.com/odoo/o-spreadsheet/commit/94b92798e5 [FIX] ComposerHighlight: Highlight the correct sheet with `#` [Task: 6527596](https://www.odoo.com/odoo/2328/tasks/6527596)
https://github.com/odoo/o-spreadsheet/commit/6b1932c4a2 [FIX] clipboard: typo on copy/paste on a merge [Task: 6515850](https://www.odoo.com/odoo/2328/tasks/6515850)
https://github.com/odoo/o-spreadsheet/commit/29c3a79719 [PERF] evaluation: clip range to sheet [Task: 6483083](https://www.odoo.com/odoo/2328/tasks/6483083)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

When a user mentions the wrong partner and corrects it by continuing to type, e.g. picking "John" by mistake, typing further so the text becomes "@ John Doe" and picking "John Doe" in the suggestion popup, the discarded first pick stays in the composer's mentioned partners. On post, mentions are validated by searching the body for "@<name>", and "@ John" is found inside "@ John Doe", so the partner the user tried to replace is kept in the recipients and gets notified even though no mention of them remains visible in the message.

Validate mentions from the longest mention text to the shortest, counting the occurrences of each text and blanking them out before looking for shorter ones. A partner whose mention text only appears inside a longer mention is dropped, while distinct partners sharing the same name each consume one occurrence.

Steps to reproduce:

- Create contacts "John" and "John Doe"
- On any record, open the chatter and type "@John", pick "John" by mistake, then keep typing " Doe" and pick "John Doe" in the suggestion popup to correct it
- Send the message

=> The message is also sent to "John" although only "@John Doe" appears in the body.

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

Forward-Port-Of: odoo/odoo#287122
Forward-Port-Of: odoo/odoo#284239

Currently an exception is generated when the `send_after_commit` tries to
send the email as below step:

- Create a database without demo data and language `fr_FR`
- Install the `appointment` module
- Set up outgoing email server
- Error appears in the log when loading the demo data

Error: `TypeError:'NoneType' object is not subscriptable`

This issue occurs after the recent refactoring changes in [1]. The method
`send_after_commit` (see[2]) sends the email with a new cursor after committing
 to the current cursor, and here when `_send()` tries to send the mail, it uses
the `_()` method for translation, which accesses `self.env` (self refers to the
old closed cursor). However, at this point, the cursor is already closed. As a
result, when the code at [3] is reached from `ormcache`, it raises the above
error because `model.env.transaction.ormcaches__` is `None` (code ref [4]).

This commit fixes the above issue by using `self.env._()` for translation
instead of `_()` while sending the mail to ensure the translation accesses
the current environment cursor instead of the closed one.

[1]: https://github.com/odoo/odoo/commit/13c3adf3a8b5ba6325190d6b9aea45fb8a6a8b2f
[2]: https://github.com/odoo/odoo/blob/86d750e777d1adc09f53016a255c7b1158fd309c/addons/mail/models/mail_mail.py#L708-L713
[3]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/cache.py#L111
[4]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/environments.py#L1012

Sentry-7608119520

Steps to reproduce:
- multi-company database, PoS Manager user with an employee in each company
- current company set to company A
- open the settings of a PoS configuration belonging to company B and save

Issue:
The advanced_employee_ids of company B's PoS now also contains the manager's employee of company A, an employee from another company.

Cause:
res.config.settings.create() appends the PoS managers' employees with `_get_group_pos_manager().user_ids.employee_id`. res.users.employee_id is computed for the current company (self.env.company), not for the company of the pos.config being edited, so the employees of the active company are linked instead of the PoS company's. pos.config.write() already resolves them with `with_company(config.company_id)` since fccccf6cabe5, but the settings path was left unscoped.

Fix:
Resolve employee_id with `with_company(config.company_id)` in the settings create, as done in pos.config.write(). Single-company databases are unaffected.

opw-6544518

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

Forward-Port-Of: odoo/odoo#287182

### Steps to reproduce:
event = env['event.event'].create({
'name': 'Repro Event',
'date_begin': '2026-09-01 08:00:00',
'date_end': '2026-09-01 18:00:00',
})
ticket = env['event.event.ticket'].create({
'event_id': event.id,
'name': 'VIP',
'seats_limited': True,
'seats_max': 1,
})
env['event.registration'].create({
'event_id': event.id,
'event_ticket_id': ticket.id,
'name': 'Attendee 1',
'state': 'open',
})

ticket.seats_available -> 0
ticket.is_sold_out -> True

result = ticket._get_current_limit_per_order(event=event) print(result) # {ticket.id: 30} -- expected {ticket.id: 0}

### Issue and Expected
`_get_current_limit_per_order()` used `if not seats_available:` to detect the "no limit" case returned by `_get_seats_availability()`. That check is truthy for both `None` (genuinely no limit) and the integer `0` (fully booked), so a sold-out ticket/slot combination was incorrectly treated as unlimited and returned `limit_max_per_order or EVENT_MAX_TICKETS` (e.g. 30) instead of `0`.

### Fix
`_get_seats_availability()` explicitly documents `None` as the "no limit" sentinel, with `0` meaning "constrained, zero seats left". Use `seats_available is None` to preserve that distinction instead of a falsy check.

No functional regression was found in the current website_event flow: sold-out slots/tickets are filtered or re-derived independently before reaching this value in every existing UI path. This fixes the underlying contract of the method itself, so future or additional callers don't inherit the wrong value.

https://github.com/odoo/odoo/issues/284098




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

Forward-Port-Of: odoo/odoo#284100

### Issue:
In Germany, the intrastat report requires region code `99` for dispatch moves where the product origin country is not DE

Per the official specification (section 5.8 — Region of origin): "As for goods with foreign origin, code '99' should be entered"
https://erhebungsportal.estatistik.de/Erhebungsportal/api/assets/files?downloadId=0c5422f111104705b021b41616ad1ecc

But `99` was not being used in those cases

### Cause:
`99` was already the default fallback when no `region_code` is set but `_fill_missing_values` had no condition to override the region code for dispatch moves with a non-DE origin country

### Notes:
While fixing this, two additional issues were found when exporting with the German locale (`de_DE`):
- `weight` and `supplementary_units` are formatted with a comma as decimal separator by the German locale, causing `float()` to raise a `ValueError` — fixed by normalizing to dot before conversion, as done in other localizations
- The dispatch/arrival check was comparing against the translated label (e.g. `'Versand'`) instead of a stable identifier A new `intrastat_type_code` field with static values `arrival` and `dispatch` is added based on the existing `id` values from `default_type`, avoiding locale-dependent comparisons This improvement could be extended to other localizations
- Net mass is now rounded to full kilograms per item (see §5.14 of the specification linked above)
 A weight rounding down to 0 kg is reported as `0` instead of being silently dropped (QWeb `t-out` omits the element when the value is `None`)
Totals are computed as the sum of already-rounded per-item values to stay internally consistent

### Steps to reproduce:
- Install `sale_management`, `l10n_de_account` and `accountant`
- Switch to the DE company
- In Settings, configure the Intrastat values:
-- Default invoice transaction code: 11
-- Default refund transaction code: 21
-- Intrastat region: 07
- Create 3 products with a commodity code set and country of origin: one DE, one empty, one other country
- Create and confirm a Sale Order for all products with a European partner, deliver all, create and send the invoice
- Open the Intrastat report (Accounting > Reporting > Taxes & Fiscal > Intrastat)
- Set the month to the current month

Before the fix, all regions show 07
Expected: non-DE origin products should show 99

opw-6455585

Forward-Port-Of: odoo/enterprise#128747

## Steps to Reproduce:
- Install the Time Off module.
- Create an Accrual Plan without any milestones.
- Create an Accrual Allocation using the newly created accrual plan.
- Approve the allocation.
- Add a milestone to the accrual plan.
- Create a new Time Off request after the allocation start date.
- Save the record.

## Error:
`TypeError - '>' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
`lastcall` is initialized by method `_add_lastcalls()`, which is only called at create and write. When an accrual allocation is created with an accrual plan that has no milestones, `_add_lastcalls()` returns early because `level_ids` is empty, leaving `lastcall` set to `False`. - [1]

If a milestone is added later, `lastcall` is compared with `first_level_start_date`, resulting in a comparison between boolean and datetime, which raises an error.

## Fix:
When `lastcall` is not set, default it to `first_level_start_date`.

[1] - https://github.com/odoo/odoo/blob/27036bea232572ba692fbb95387911eb453266bf/addons/hr_holidays/models/hr_leave_allocation.py#L703-L706

sentry-7615375197

Forward-Port-Of: odoo/odoo#282074
Forward-Port-Of: odoo/odoo#280674

Problem:
The bookings calendar of an appointment type opens on the week of the most
distant booking instead of the next one, even when a booking exists later the
same day.

Cause:
`action_calendar_meetings` sets the landing date from `appointments[0].start`,
where `appointments` is `self.meeting_ids.filtered_domain(domain)`.
`calendar.event` is ordered on `start desc` and a one2many is read in the order
of its comodel, so the first record is the furthest booking rather than the
next one. The original `search([...], order='start')` was replaced by the
one2many in 14b5caccc325 (odoo/enterprise#23191).

Solution:
Sort the filtered bookings on `start` in `action_calendar_meetings`. That
method is the only place the initial date is built, and
`action_calendar_event_view_request` reuses it for the gantt start date, so
both entry points are covered. `calendar.event` keeps its `start desc` order,
which the booking list views rely on.

Steps to reproduce:
- Go to Appointments.
- Open the appointment type "Schedule a Demo" and click Appointments.
- Click New, set the date to later today, save and go back.
- Click New, set the date to one year from now, save and go back.
- Go back to Appointments, reopen "Schedule a Demo" and click Appointments.
- Switch to the calendar view.
- Observe that the calendar opens on the week of the booking one year from now.

Ticket [link](https://www.odoo.com/odoo/project.task/6480029)

opw-6480029

Forward-Port-Of: odoo/enterprise#130385
Forward-Port-Of: odoo/enterprise#129000

## Description

Printing any posted electronic invoice whose commercial partner has an identification type **without** ARCA code (typically the generic `VAT` type from `l10n_latam_base`, common on foreign partners of export invoices) crashes:

```
File ".../l10n_ar_edi/models/account_move.py", line 161, in _compute_l10n_ar_afip_qr_code
    data.update({'tipoDocRec': int(rec._get_partner_code_id(commercial_partner_id))})
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
```

## Steps to reproduce

1. Install `l10n_ar_edi`.
2. Create a customer: Country **Spain**, Identification Type **VAT** (no ARCA code), Identification Number `ESA12345674`, ARCA Responsibility Type **Cliente / Proveedor del Exterior**.
3. Create and validate an invoice for this customer on an export electronic journal (document type 19).
4. Print the invoice → traceback above.

## Root cause

Since bb8e6fda72ae6364cf7806acb400b071f4108fc9 ([FIX] l10n_ar_edi: return the correct ARCA code when final consumer, odoo/enterprise#106881), `_get_partner_code_id()` lost its final `return partner_id_code` fallback: when the identification type has no ARCA code and the partner is not a Final Consumer, the method now returns an implicit `None`. The QR code compute casts the result with `int()`, which accepted the previous falsy return (`int(False) == 0`, rendering `tipoDocRec: 0` as in 17.0/18.0) but raises on `None` — making every such posted invoice impossible to print.

## Fix

Restore the fallback return so the method always returns the identification type code (possibly falsy) instead of an implicit `None`. The intent of bb8e6fda72ae is preserved: a Final Consumer with an identification number still gets its real code, and the other callers already handle falsy values (`partner_id_code or 0`).

Forward-Port-Of: odoo/enterprise#126714