B2G invoices are not sent via Peppol but to Chorus Pro (via the
approved platform).
Chorus Pro is the platform with ID 9999 on the annuaire.
Any invoice to partner associated with that platform on the annuaire
is considered B2G (business to government).

From a user point of view nothing much changes, except that they have
to set some additional fields for which we rely on the existing module
`l10n_fr_facturx_chorus_pro`.

From a technical PoV we store the information whether a partner is
behind Chorus Pro in the `peppol_supported_documents` field.
(By putting the special document identifier for Chorus Pro invoices there.)
We retrieve the information whether a partner is behind Chorus Pro / B2G
from the annuaire lookup.


The following new lifecycle statuses have been added. They are
required for the functional tests for the Chorus Pro connection.
- Sent (sent by the platform)
- Suspended
- Completed (to "resume" the "Suspended" state)

See the related IAP PR: https://github.com/odoo/iap-apps/pull/1804

task-6278159

Forward-Port-Of: odoo/odoo#284677

This commit adds an index on `(journal_id, date)` to speed up `_get_last_sequence_domain`.

The slow part is

`.search(domain, order='date [desc|asc]', limit=1)`

Because of the order by date, postgresql scans the index on `date`, assuming a row will be quickly matched.

If this assumption is wrong though, it'll scan a large part of the index or all of it, which is slow.
This is the case with account move 17102258 on odoo.com at the time of writing this.

- before
   - 1st query https://explain.dalibo.com/plan/6b8ff62b1572ah1a
   - 2nd query https://explain.dalibo.com/plan/41243cgccg5798gb
- after
  - 1st query https://explain.dalibo.com/plan/4fd2c7ed28g7b138
  - 2nd query https://explain.dalibo.com/plan/2heh6c6965c88h71
  - ~~1st query https://explain.dalibo.com/plan/f874a31f4b07hdeb~~
  - ~~2nd query https://explain.dalibo.com/plan/e8h09725gfh4c2e9~~

full `web_read`
- before ~1min 10s
- after ~650ms

task-6481393



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

Forward-Port-Of: odoo/odoo#283159

[IMP] web, html_editor, mail: add backend-only Material Symbols font
---
__Before commit__
Every time a new icon was added, a large part of
`material_symbols_pua_codepoints.py` was overwritten.

This happened because `generate_icons.py` assigned new PUA
codepoints to every icon each time it ran.

Google already assigns predefined codepoints to these icons, which
are included in `material_symbols_outlined_subset.woff2` but were
previously unused.

__After commit__
The font `material_symbols_backend.woff` is introduced for backend-only
usage, such as report generation and backend mail icon rendering. It
replaces the per-style WOFF1 files and the PUA-only font.

The standard codepoints from Google are now used for the icons. We
still need to assign custom codepoints to filled icon variants
because they are separate icons in the optimized version. We do this
by adding an offset of 0x100000 (using a bitwise AND of 0xFFFF for edge
cases to remain within the standard Plane-16 Private Use Area).

__Benefits__
- Adding a new icon produces a significantly smaller diff.
- A single WOFF1 replaces the two per-style ones, and is the only
  format both backend consumers can read: wkhtmltopdf cannot parse
  WOFF2, and Pillow needs the codepoints in the cmap.
- Existing codepoints are removed from WOFF2 files, making fonts
  fetched by browsers a few kB lighter.

[IMP] website: merge countdown snippet layout and template options

Following [commit](https://github.com//odoo/odoo/commit/74a9e5bb734708497456ed2bc91465f95505b2d7), we'd like to improve the countdown snippet.
Key changes:

1. Merge Layout and Template into a single layout option with the following layouts:
   - Circle
   - Text Inline
   - Dominoes (replaces Boxes)
   - Wrapped Numbers
   - Text
   - Big Numbers (replaces Clean)
2. Enable toolbar for both metrics and indicators
3. Remove Edge Spacing
4. Convert Circle layout to Text Inline format: display the countdown
on the left with reduced size.
6. Retain Circle-specific options plus all Text Inline options when
possible.

task-5242156

---

[IMP] website, html_builder: show notification if countdown is outdated

We would like to show the notification to user saying that the
countdown is outdated if it should be updated.
This commit also changes wording in that notification to indicate that
it may cause problems.

task-5242156

---

[IMP] website, html_editor: add countdown toolbar namespace

For metrics in countdown, we don't want to show all toolbar groups, but
rather just font and decoration groups buttons. This commit adds a new
namespace for that, and adds that namespace to buttons we want to
display.

task-5242156

Feedback from the Dimona UX review:

- The Dimona badge on the employee form sat before the review state pill and was a dropdown, so the state could be set by hand. That state reflects what was declared to the ONSS, not a user choice: it becomes a read-only badge, placed after the review pill, and "Send Dimona" stays the only way to act on it. dropdown_selection_badge honors a readonly attribute on the field node for this; props.readonly could not be used, as list and kanban records are never in edition, which would freeze the review state badge as well.

- The manual declaration wizard always showed "Dimona IN" with the text of an entrance declaration, whatever had to be declared. Its title and description now follow the next action (in, out, update, cancel or issue), and the ONSS link points to the Dimona portal instead of the DmfA instructions.

- The ONSS certificate setting only said "Configure ONSS certificate". It now states what the certificate is for, automating Dimona, DMFA and DRS submissions via the API, and links to the ONSS page explaining how to obtain the credentials.

- The Dimona declaration fields on the employee offered to create a declaration from the autocomplete, which would record a declaration that was never sent to the ONSS.

task-6470879

Commit odoo/odoo@1facbc0646bd made the checkout validate every `website.checkout.step` through a single flow, but the localization invoicing steps were left out.

These steps are shown or hidden by publishing or unpublishing a shared step record on each checkout. This is unreliable: the cart and payment pages don't refresh it, so the step can be left in the state set by another visitor. The step is also only validated when the visitor goes through it, so opening `/shop/payment` directly skips it. An override also forces `try_skip_step` off so the checkout page cannot jump past the step.

This commit filters the Chilean and Mexican step out of the breadcrumb steps domain per request when it is not needed, instead of toggling the shared record, and checks it in the validation flow so opening `/shop/payment` redirects back to it while incomplete. Forcing `try_skip_step` off is no longer needed. Chile stores the taxpayer type on the invoicing customer so the check also works when the billing contact is not the ordering one. Mexico uses a best-effort check, since a customer who wants no invoice looks the same as one who skipped it.

task-6045788

See also:
- https://github.com/odoo/odoo/pull/276844
- https://github.com/odoo/upgrade/pull/10806

Problem:
`_compute_electronic_product_code` built `tracking_number_list` by filtering out move lines without a lot_id/lot_name, but kept iterating over the full, unfiltered `move_line_ids`. As soon as a tracked product had an untracked move line mixed in with tracked ones (e.g. a manufacturing byproduct move line with no lot), the two lists fell out of sync: at best tracking numbers got assigned to the wrong move line, at worst `tracking_number_list[i]` went out of range and raised an IndexError.
Solution:
Exclude untracked move lines from `move_line_ids` before building `tracking_number_list`, so both stay the same length and index- aligned. Untracked lines get their own explicit "no tracking number" error instead of breaking the alignment for the rest.

Steps to reproduce:
Open runbot V19 -> go to moves history (Inventory) -> add `electronic_product_code` to list view using studio -> remove filter/select all records -> https://anotepad.com/notes/jwxyskc2

Forward-Port-Of: odoo/enterprise#128521
Forward-Port-Of: odoo/enterprise#123859

When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the team, so a team set up by an English user language produced an English form even when the website served another language.

Steps to reproduce
==================
1. Set a language other than English as the website default language.
2. While your user language is English, create a helpdesk team with the website form enabled.
3. Open the team form on the website.

=> The form is rendered in English instead of the website language.

Root cause
==========
`_ensure_submit_form_view` read the template arch without forcing a language, so it used the current user's language and stored only that value on the generated per-team view.

Fix
===
Read the template arch in the default language of the team's website, so the generated form matches the website language regardless of the user's own language.

opw-6303903

Forward-Port-Of: odoo/enterprise#129265
Forward-Port-Of: odoo/enterprise#121164

### Issue:
A user with Website Editor rights but no Accounting or Expense access gets an `AccessError` when using Optimize SEO to add a cover image, if another user has an expense with an attachment

### Steps to reproduce:
- Install `ai` and `hr_expense`
- With Admin, upload an image as an expense
- Update Demo user rights (Accounting: No, Expenses: No, Website: Editor and Designer)
- Log in as Demo
- Go to Website > Site > This page > Optimize SEO
- In Cover Image, add any image, select it and save
 
Before the fix, an `AccessError` is raised

### Cause:
When Save is triggered, `ai.attachment.vacuum.mark_attachments_used()` is called with the outer domain:
`[('attachment_id', 'in', [3868])]`

The `ai.attachment.vacuum` security rule uses:
`domain_force = [('attachment_id.res_access_write', '=', True)]` https://github.com/odoo/enterprise/blob/474ee25f82a3980530aae4c3450c69d925b6076e/ai/security/security.xml#L1-L24

During optimization, the dotted path is decomposed into an `any` condition:
`('attachment_id', 'any', [('res_access_write', '=', True)])` https://github.com/odoo/odoo/blob/dcb9ad42ba302a5ed0ec334daf4c8a4cb5ec0931/odoo/orm/domains.py#L999-L1004

`_optimize_any_domain_at_level` tries to narrow the comodel scan by reusing the outer constraint on `attachment_id` via `search_domain` in context
It finds `c` where `c.field_expr == 'attachment_id'`, but `c.value` is `{3868}` — a plain set of ids, not a `Domain`
Since the code only recognized `Domain` values, it treated this as unknown and fell back to `comodel_domain = Domain.TRUE`

`_search_res_access` for `ir.attachment` then scanned every attachment using:
`['&', ('res_model', '!=', False),
  '|', ('res_id', '!=', False), ('create_uid', '!=', 5)]`
This matches a lot of attachments because the initial `attachment_id` constraint is missing

This scan included an attachment linked to an expense the current user cannot read
`_inaccessible_comodel_records` in `hr_expense` then checked all expenses linked to the found attachments and raised the `AccessError`

This fallback also triggers a second failure when the database contains more than 10 000 attachments: `_search_res_access` caps its unbounded scan at `MAX_SEARCH_LIMIT` and raises `ValueError("Cannot search, too many attachments")`
Confirmed by seeding ~10 500 attachments and reproducing the error

### Notes:
A new test in `test_any_domain_search_context.py` verifies in isolation that unrelated attachments are never scanned when a plain `in` condition narrows the search

opw-6467087

Forward-Port-Of: odoo/odoo#285384
Forward-Port-Of: odoo/odoo#284678

Currently a traceback is occurring when the user tries to print a sale timesheet 
report in the German language.

**<h3>To reproduce the issue:</h3>**

1) Install the `sale_timesheet` module.
2) Create a `service` product configured to create a `project and task` on the order.
3) Create a confirmed SO with that product
4) Add a timesheet line to the SO from the `Recorded` stat button
5) Switch to the German language
6) Print `Timesheet(Zeiterfassung)` report
7) A traceback occurs

**<h3>Error:</h3>**
```
 ValueError: Element „<xpath expr="//th/span[text()='Description']">“ kann nicht in der übergeordneten Ansicht lokalisiert werden
 ```

**<h3>Cause:</h3>**
The xpath relies on the plain text `Description` to identify the `<th>` element.
https://github.com/odoo/odoo/blob/5f63fb1af418cc75ff2e382b0455002e7a798071/addons/sale_timesheet/report/report_timesheet_templates.xml#L3-L4
The xpath cannot find the Description header when the language is changed 
because the text is translated in the base template. 
As a result, the xpath fails due to the missing target.

**<h3>Fix:</h3>**
Use a language-independent `name` attribute as the `xpath` anchor. 
So the `Description` column can be reliably matched regardless of the active language.

**<h3> Note:</h3>**
This fix requires both modules update, which is generally risky in stable branches. 
However, this template was recently introduced in [saas-19.4](https://github.com/odoo/odoo/pull/191969/changes#diff-9f4f0d28ffb3aa9fcc4a5f1037bdf532e1e71c4e9703e13b6856ddfd79e15e69R4).
So there should be no existing customers using it yet, except saas customers coming from a new database.
Therefore, applying this fix in 19.4 is less risky.

opw- 6475623

Forward-Port-Of: odoo/odoo#284096

**Description of the issue/feature this PR addresses:**

When using the POS in dark mode, certain form control elements display
black text on a dark background, making them illegible.

This occurred because the POS application lacked the `color-scheme` CSS
property. While the backend web client correctly applied this property,
its absence in the POS meant the browser still assumed a light theme, 
forcing default User Agent styles (black text) onto native form controls 
that escaped standard view helpers.

This commit resolves the issue by applying the `$o-webclient-color-scheme`
variable to the POS application. This signals the browser to render form
controls and UI elements based on the current web client color scheme,
ensuring text remains legible within the POS app.

**Steps to reproduce:**

- POS > Open Restaurant Register
  - Hamburger icon (top right) > Switch to Dark Mode
  - Register > vertical ellipses icon (bottom left) > Quotation/Order > type in the search bar > observe black text on dark grey background


**Current behavior before PR:**

<img width="1911" height="588" alt="Before 1" src="https://github.com/user-attachments/assets/99581745-23eb-45e1-96f7-bca78853369c" />
<img width="1919" height="550" alt="Before 2" src="https://github.com/user-attachments/assets/b7eb9726-e2d2-492b-ad2b-6c0cc6613bb8" />

**Desired behavior after PR is merged:**

<img width="1910" height="433" alt="After 1" src="https://github.com/user-attachments/assets/419b7a2a-234e-47c8-854e-22adf6a7c5c1" />
<img width="1915" height="513" alt="After 2" src="https://github.com/user-attachments/assets/8f1cf5c9-5ad1-4aac-9879-840d6d9d537e" />

opw-6508945

Forward-Port-Of: odoo/odoo#284831

Steps to reproduce
------------------
1. Go to the Point of Sale settings and select a shop.
2. Enable UrbanPiper and set a delivery provider.
3. Enable "Log in with Employees".
4. Add two employees to the "Advanced rights" field.
5. Save.

Observation -> Only the employee of the PoS manager is left, the two employees are gone.

Why it's happening
------------------
When saving from the settings, `pos.config` is written with the context key `from_settings_view`, which tells
`_preprocess_x2many_vals_from_settings_view` that the commands received for an `x2many` field are the complete new list, so every record not in these commands is unlinked.

The `write` of `pos_hr` always puts `advanced_employee_ids` in the values, even when the caller does not write this field, to keep the employees of the PoS managers in the list (1766d6d40a45).

Since b48ddcce7bf in enterprise, UrbanPiper writes on the config a second time during the same save, still with `from_settings_view`. That write does not touch the employees, so `pos_hr` fills `advanced_employee_ids` with the managers only (cf 1766d6d40a45), and the ones that were just saved are unlinked.

The fix
-------
When `pos_hr` adds the field by itself, keep the employees already set on the config instead of starting from an empty list.

opw-6500207

Forward-Port-Of: odoo/odoo#284961

In `knowledge_calendar_command_tour`, we were experiencing two issues

1. First, when we change the properties of a new calendar item, we were running into an issues where the tour would fail due to not being able to locate the dropdown option to create a new property. This only occurs if you don't set a step delay on the tour. This happens because in the `editSelectMenuInput` helper, we first check if the dropdown is open bfore we proceed. Since the tour runs so fast, we detect that the dropdown for the first property is open, so we pass the check. However, this then closes since we've moved on to the next dropdown, and since nothing has been input into the next dropdown, the create option doesn't appear. Now, we ensure that the create option will be present before attempting to click it

2. Later in the tour, we attempt to edit the properties on a new calendar item. We previously used `edit` to edit the property name, however this resulted in the "Select a template" modal being opened, which broke the tour, since we needed to click elements behind it. Using `fill` instead to populate the text field doesn't produce this behavior, allowing the tour to proceed without error.

[runbot-939647](https://runbot.odoo.com/odoo/error/939647?debug=assets)

Forward-Port-Of: odoo/enterprise#128830

Onsite events created from the "Onsite" view or the employee resume selector do not appear immediatlely after creation

This occurs because currently the domain for onsite events requires that the event to have multiple slots as well as to have at least one employee registered to it. Therefore, newly created records often fail these criteria and remain hidden.

In further versions, this pr: https://github.com/odoo/odoo/pull/246285/ changes the domain of the event selector in the employee resume by removing the dependency on the multiple slots and filtering by the specific employee for registration.

This change is not stable to backport as it indroduces the `employee_id` field as an invisible field in the xml to be able to compare in the domain.

This commit partly changes both domains to not require the multiple slots anymore, while still showing all events for which an employee is registered. This commit also ensures that when an event is created from the Onsite view or selector, the current user's employee will be registered to it.

Steps to reproduce
- Go to employees->Learning->Onsite
- Select New and create an event
- Go back to Onsite Courses
- You will not see the created event (unless it is multi_slot and an employee was registered)

opw-5915686

Forward-Port-Of: odoo/odoo#284200
Forward-Port-Of: odoo/odoo#258952

**Steps to reproduce:**
- Create a SO and add the Event Registration - Standard product and specify an event
- Confirm the SO then select "Create/Update registrations"
- Cancel the SO, then "Set to Quotation"
- Select "Preview" and confirm the Sale Order again
- There will not be any new registration created when there should be one.

**Behavior:**
Usually when a sale order is confirmed the `action_sale_order_event_registration` form will be opened which when filled correctly creates registrations. However in certain cases: confirming from the customer portal, or simply closing the form when it is opened, will not trigger `action_make_registration` which creates registrations if it is not already the case

`action_confirm()` should be creating the registrations correctly on its own anyway by calling ´init_registrations()´ : https://github.com/odoo/odoo/blob/beed378cde592bc96c1e79a976ac775264b843ed/addons/event_sale/models/sale_order_line.py#L49-L66

This function tries to create each missing registrations by looking at the amount in the so_line and deducting the already created registrations, however since some of them can be cancelled, this computation is wrong. And leads to registration not being created when they should.

opw-6444127

Forward-Port-Of: odoo/odoo#280426

When a user manually sets a price on an optional line (overriding the pricelist), and then changes the quantity in the portal preview, the manual price is lost and gets reset to the pricelist price.

Steps to reproduce:
---
- Install Sales module and enable Pricelists.
- Create a product with qty-based pricelist rules:
   - min qty: 1  → price: 100
   - min qty: 10 → price: 80
- Create a quotation with an optional section containing this product.
- Manually change the product price to 150 (overriding pricelist).
- Mark the section as optional and preview the quotation.
- Change the quantity to 10 in portal preview.

Issue:
---
- The manually set price (150) is incorrectly reset to the pricelist price (80).

Root cause:
---
- After [commit], if there is no config parameter set and if there is an active pricelist, we simply call `_reset_price_unit()` without checking whether the price was manually set or not.
- Additionally, `_reset_price_unit()` calls `update()` which writes `price_unit` and `technical_price_unit` one by one as separate `write()` calls. The `write()` method has a guard([1]) that strips a lone `technical_price_unit` write unless `sale_write_from_compute` is set in context. Without this flag, `technical_price_unit` is silently discarded, causing it to drift from `price_unit`. On the next qty change, this mismatch is detected as a manual price, permanently blocking further pricelist updates.

Solution:
---
- Check whether the price was manually set before calling `_reset_price_unit()`, and pass `sale_write_from_compute=True` in context so both `price_unit` and `technical_price_unit` are written correctly.

[commit]: https://github.com/odoo/odoo/commit/93b6bdd6a4909bc0b45b90ab6a2d0734a218292d
[1]https://github.com/odoo/odoo/blob/fffd987cc98d1ea0cd04e24dda2ed8b64a219cdc/addons/sale/models/sale_order_line.py#L1391-L1399

opw-6426634

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

Forward-Port-Of: odoo/odoo#285212
Forward-Port-Of: odoo/odoo#281107

Issue:
---
Due to this issue, generating PDF Quote using Quote Builder with dynamic fields leads to a traceback.

This was partially fixed by: e16edc7b0d9f56cb7769068ecf7d64ff8b0f6359

Steps:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quote builder tab, select a document. This document should have dynamic fields. e.g. you could use`Office Furnitures Header` document.
4- Print -> PDF Quote.

Cause:
---
In previous fix, we fixed the traceback when no dynamic field is set. However, if you have a dynamic field, then inside
`PdfWriter._update_field_annotation()`, the font is get from `DR` dict inside acroform:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L917-L929
Even if we are not setting a font, we need to have an empty `DR` dict inside acroform, in order to avoid calling `get` on a none object, which is leading to the traceback.

Also in previous fix we were losing `NeedAppearances` inside `AcroForm` by creating new dict which wasn't right.

opw-6392001

Forward-Port-Of: odoo/odoo#278881

Commit 1facbc0646bd made the checkout validate every `website.checkout.step` through a single flow, but the localization invoicing steps were left out.

These steps are shown or hidden by publishing or unpublishing a shared step record on each checkout. This is unreliable: the cart and payment pages don't refresh it, so the step can be left in the state set by another visitor. The step is also only validated when the visitor goes through it, so opening `/shop/payment` directly skips it. An override also forces `try_skip_step` off so the checkout page cannot jump past the step.

This commit filters the invoicing step out of the breadcrumb steps domain per request when it is not needed, instead of toggling the shared record. The cart is passed to the breadcrumb helpers and their cache is removed so the filter runs for each visitor. The Taiwanese step is now checked by the validation flow, so opening `/shop/payment` redirects back to it while incomplete. The checkout page now jumps to the next step, which is the invoicing step when required, so forcing `try_skip_step` off is no longer needed.

task-6045788

See also:
- https://github.com/odoo/enterprise/pull/124616
- https://github.com/odoo/upgrade/pull/10806