Before this commit, TestPartner.test_res_partner_to_store fails on the all-modules and per-country builds:

AssertionError: '2024-06-06' != '2024-06-07'
 : Return date is the return date of the main user of the partner

This happens because the test reads the first entry of the hr.employee list, which holds one employee per user of the partner: back on the 7th for the main user, on the 6th for the other.

This comes from "[FIX] hr*: load out-of-office dates from all user employees", which added the employees of the partner to the payload, where it held those of the main user only.

The problem is that the list keeps the order of employee_ids, which is 'name' with no tiebreaker, and both employees are named test1, as an employee takes the name of its user and creating the second user renames the partner. Postgres is then free to return either one first, and the failing builds get the second one.

This commit fixes the issue by ordering the employees on 'name, id', so that employees sharing a name keep a stable order instead of the one the database picks. The test asserts the whole hr.employee list, one entry per user of the partner, rather than its first entry alone, and that assertion pins the order.

https://runbot.odoo.com/odoo/error/945994

Forward-Port-Of: odoo/odoo#286750
Forward-Port-Of: odoo/odoo#286236

Steps to reproduce:
- Create a sale order with a down payment term.
- Invoice the down payment (down payment invoice A).
- Credit that down payment invoice directly (credit note A), without reconciling it with anything else.
- Generate the FatturaPA XML for credit note A.
- Observe that DatiFattureCollegate lists both down payment invoice A and credit note A itself, instead of only down payment invoice A. On an order with several down payment invoices/credit notes over time, every one of them is listed instead of just the document the current credit note actually reverses.

Cause of the issue:
_l10n_it_edi_export_data built downpayment_moves from self.invoice_line_ids._get_downpayment_lines().move_id with no filtering. _get_downpayment_lines() (sale override) returns every invoice line ever created against the same down payment sale order line, across the whole life of the order, not just the invoice the current document actually relates to. The template renders DatiFattureCollegate for every one of those moves unconditionally, on top of the already-correct reversed_entry_id/reconciled_moves fallback, including the current document itself.

Solution:
Restrict downpayment_moves to lines with a negative price_subtotal, mirroring the existing down payment deduction-line detection a few lines above, and explicitly exclude the current document. This limits DatiFattureCollegate's down payment entries to the case they are meant for: a final invoice actually deducting a previously invoiced down payment.

opw-6429716

Forward-Port-Of: odoo/odoo#285555
Forward-Port-Of: odoo/odoo#279938

Since https://github.com/odoo/enterprise/pull/97488, the images are shared across spreadsheets and the attachments are no longer related to a specific record. Due to the management of the IrAttachment access rights, it means that those attachments are not accessible by anyone by default and we rely on the access_token to display them in the webclient.

However, the method that builds the final xlsx file fetches the images from the server and did not use the access token, meaning that it could never access the attachment. Such situation raised a UserError that was caught by the webclient.

How to reproduce:
- As admin, create a spreadsheet and insert an image inside of it
- try to download the spreadsheet as an xlsx file

counterpart of https://github.com/odoo/enterprise/pull/126384

Task-6432724

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#285981
Forward-Port-Of: odoo/odoo#279788

Before this commit, the "Get A Booth" page of an event could keep listing the booths of the category checked on load after the visitor picks another one. Only a page reload brought the right ones back. The tour webooth_exhibitor_register timed out on that list:

FAILED: [5/13] Tour webooth_exhibitor_register -> Step Choose Booth (trigger: .o_wbooth_booths div:contains(OpenWood Demonstrator 2) input:not(:visible)).
TIMEOUT step failed to complete within 10000 ms.

This happens because the page fetches the booths of the category checked on load, and clicking another category fetches its booths while that first answer is still on its way. The answer coming back last fills the list, and the widget caches it under the category active on arrival, so the booths of the first category land in the cache of the clicked one.

This commit fixes the issue by caching an answer under the category it was asked for, and by filling the list only while that category is still the chosen one.

https://runbot.odoo.com/odoo/error/110527
https://runbot.odoo.com/odoo/error/161834

Forward-Port-Of: odoo/odoo#286552
Forward-Port-Of: odoo/odoo#286266

### Issue before this commit:
When generating a tax closing entry for France, the VAT credit carryover from the previous period is missing from the journal entry lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_fr
2. Go to Vendor > Bills
3. Create a vendor bill with date in June and price > 0 (ex. 1000$) and the 20% G tax that produce a 200$ VAT tax
4. Go to Customers > Invoices
5. Create an invoice with price > 0 (ex. 9000$), the date in July and the 20% G tax that will produce a 1800$ VAT tax
6. Go to Tax Return and validate all opened months up to July and see that for June the balance is -200$
9. Then go to View Entries of July using the 3 dots next to the "submit" button and see that there is no mentioning of the 200$ carry over of credit from the month before

### Cause of the issue:
The issue stems from a structural change in the core code where the logic to evaluate and balance the tax receivable account was removed from the _add_tax_group_closing_items method. Consequently, the VAT closing entry now only processes the current period's taxes and there is no reporting of any carried-forward VAT credits.

### Reason to introduce the fix:
French accounting rules strictly require the carried-forward VAT credit to be explicitly integrated into the current period's tax closing entry.

opw-6438648

Forward-Port-Of: odoo/enterprise#130377
Forward-Port-Of: odoo/enterprise#129181

**Problem:**
Creating a view from Settings > Technical > User Interface > Views fails with a validation error, even though both the model and the architecture are valid.

**Steps to reproduce:**
1. Go to Settings > Technical > User Interface > Views
2. Click New
3. Set the View Name and pick a model in "Model of the view"
4. Set the View Architecture to `<list><field name="name"/></list>`
5. Save

**Current behavior:**
The record cannot be saved:

    Error while validating view near:
    <list __validate__="1"><field name="name"/></list>
    Model not found: False

Duplicating an existing view and editing the copy works, so the issue only shows up on brand new records.

**Expected behavior:**
The view is saved, and validated against the model that was picked.

**Cause of the issue:**
The form edits `model_id`, a non-stored `Many2one` whose inverse `_inverse_compute_model_id` is what actually fills the stored `model` field. The architecture is edited through `arch_base`, whose inverse chain ends in `_inverse_arch` writing `arch_db`; `write` then runs `_check_xml`, which validates the architecture against `view.model`.

Both values therefore reach the record through inverse methods, so the order those run in decides whether `model` is set by the time the architecture is validated. That order became deterministic in this version: the ORM sorts inverse groups by `(field.write_sequence, field index)`. Both fields keep the default `write_sequence` of 0, which leaves the declaration order to break the tie, and `arch` is declared well before `model_id` — so the architecture is validated while `model` is still empty.

The same ordering also breaks a plain edit: changing the model and the architecture of an existing view in a single save validates the new architecture against the previous model.

**Fix:**
`write_sequence` is the ORM's hook for exactly this kind of ordering dependency, so a negative one on `model_id` states the real constraint — the model has to be known before anything is validated against it — rather than leaving it to where the fields happen to sit in the class. It also covers the write path, which a create-only workaround would miss.

opw-6467991

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/7660254439 [REL] 19.4.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a510812a88 [FIX] carousel: cannot add non-existing chart to carousel [Task: 6455790](https://www.odoo.com/odoo/2328/tasks/6455790)
https://github.com/odoo/o-spreadsheet/commit/c875c44655 [FIX] Fonts: fix linux font on css variable [Task: 6452045](https://www.odoo.com/odoo/2328/tasks/6452045)
https://github.com/odoo/o-spreadsheet/commit/ae830f0ff5 [FIX] svg: remove unused commented SVGs [Task: 6317134](https://www.odoo.com/odoo/2328/tasks/6317134)
https://github.com/odoo/o-spreadsheet/commit/6970933bb4 [FIX] chart: fix funnel chart show value [Task: 6475094](https://www.odoo.com/odoo/2328/tasks/6475094)
https://github.com/odoo/o-spreadsheet/commit/06d1c65ec7 [FIX] pivot: unbounded ranges in the pivot side panel [Task: 6478220](https://www.odoo.com/odoo/2328/tasks/6478220)
https://github.com/odoo/o-spreadsheet/commit/c95922a0d1 [FIX] figure: color of snap lines in dark mode [Task: 6515587](https://www.odoo.com/odoo/2328/tasks/6515587)
https://github.com/odoo/o-spreadsheet/commit/95b0854895 [FIX] chart: consistency in the background color for xlsx export [Task: 6507087](https://www.odoo.com/odoo/2328/tasks/6507087)
https://github.com/odoo/o-spreadsheet/commit/583393936f [FIX] chart_menu: align chart menu items tag and style [Task: 6469005](https://www.odoo.com/odoo/2328/tasks/6469005)
https://github.com/odoo/o-spreadsheet/commit/41874ca9de [FIX] composer: crash when hovering a composer token [Task: 5153319](https://www.odoo.com/odoo/2328/tasks/5153319)
https://github.com/odoo/o-spreadsheet/commit/1bedab5196 [FIX] evaluation: wrong dependencies invalidation with spread formulas [Task: 5103328](https://www.odoo.com/odoo/2328/tasks/5103328)
https://github.com/odoo/o-spreadsheet/commit/037f4f8aa5 [FIX] print: figure border wrong render [Task: 6458624](https://www.odoo.com/odoo/2328/tasks/6458624)
https://github.com/odoo/o-spreadsheet/commit/44c8d0b2a8 [FIX] chart: fix bubble chart show value [Task: 6475014](https://www.odoo.com/odoo/2328/tasks/6475014)

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>

Steps to reproduce:
1. Install Sign.
2. Open the form view of a document.
3. Select a model in the "Link to" (Reference) field, but leave the record empty.
4. Save and refresh the page.

Issue:
- After refreshing, the selected model is cleared because the reference value is invalid.

Cause:
- A reference field is only valid when it contains both a model and a record ID. However, the record selector has no placeholder, making it easy to overlook and save an incomplete value.

Solution:
- Add a default placeholder to the record selector of reference fields to make it more visible.

<table>
  <tr>
    <th>Before</th>
  </tr>
  <tr>
    <td>
      <img src="https://github.com/user-attachments/assets/3ba34b77-f901-4d3e-9768-5acaf2e673b8" alt="Before" width="100%">
    </td>
  </tr>
  <tr>
    <th>After</th>
  </tr>
  <tr>
    <td>
      <img src="https://github.com/user-attachments/assets/1fe54b89-221f-4d28-bd2b-0a3c706d5746" alt="After" width="100%">
    </td>
  </tr>
</table>


opw-6426339

Forward-Port-Of: odoo/odoo#280266

**Steps to reproduce:**
* Install the **l10n_mx** localization.
* Enable **USD** and fetch the latest currency exchange rate from the settings.
* Configure **Quadrum** as the **PAC** in the settings.
* Create and sign a USD invoice with **16% IVA** (e.g. 4,500 USD + 720 USD tax = 5,220 USD total).
* Send the invoice to **CFDI**.
* Register a **partial MXN payment** that does not convert to a round USD amount (e.g. 30,000 MXN = 1,762.45 USD).
* Send the payment complement to the PAC by clicking **Update Payments** on the invoice.

**Observed behavior:**
The PAC rejects the CFDI with error **CRP20268**:
> El campo BaseP que corresponde a Traslado, no es igual a la suma de
> los importes de las bases registrados en los documentos relacionados
> donde el impuesto del documento relacionado sea igual al campo
> ImpuestoP de este elemento y la TasaOCuotaDR del documento
> relacionado sea igual al campo TasaOCuotaP de este elemento.

**Cause:**
* The SAT validator enforces a strict arithmetic relationship between three fields that are printed in the payment complement XML:
```
  BaseP == round(BaseDR / EquivalenciaDR, 6)
```
* When `percentage_paid` is a non-terminating decimal (which happens for any partial MXN payment against a USD invoice), the internal `raw_base` float carries more precision than the 6-decimal-place `BaseDR` that is actually written to the XML:
```
  percentage_paid = 1762.45 / 5220 = 0.33763409961685825...
  raw_base        = 4500 × 0.33763... = 1519.353448275862...
  BaseDR (XML)    = float_round(raw_base, 6) = 1519.353448
```
* The old code then used `raw_base` (the unrounded internal value) as the dividend when computing BaseP:
```
  BaseP (old) = float_round(1519.353448275862... / 0.0587483333, 6)
              = 25862.068980   ← written to <TrasladoP BaseP="...">
```
* The PAC performs the same division using only what it can read from the XML. The already-rounded BaseDR:
```
  BaseP (PAC) = round(1519.353448 / 0.0587483333, 6)
              = 25862.068975
```
* The 6th-decimal mismatch (25862.068980 ≠ 25862.068975) triggers CRP20268 and the document is rejected.

* The same issue occurs with a full MXN payment on a different date than the invoice when multiple invoice lines cause the rounded aggregate to diverge from the sum of per-line raw values.

**Fix:**
In `_l10n_mx_edi_add_payment_cfdi_values` (`account_move.py`), the block that builds the BaseP aggregation list was changed from iterating over raw per-`base_line` amounts to building a single synthetic entry per invoice using the already-rounded document-level `BaseDR` values (`tax_details['base']`) as the dividend:

  - Before : wrong: raw_base ≠ BaseDR printed in the XML
  'raw_base': tax_details['raw_base'] / inv_rate

  - After : correct: 'base' == BaseDR, the exact value in the XML
  'raw_base': tax_details['base'] / inv_rate

This guarantees that Odoo and the PAC divide the identical value, producing the identical 6-decimal result.

The `base_line_cfdi_values_mx_curr_list` path (used only for the `Totales` summary fields rounded to 2 dp) is left unchanged because the CRP20268 rule does not apply to that block.

opw-6468077

Forward-Port-Of: odoo/enterprise#128357

Steps to reproduce:
- Go to the website editor.
- Add a snippet with editable text to the page.
- Select the text and set its font size to 144.
- Save the edited block as a custom snippet.
- Open the snippets dialog.
- Go to the Custom category. => The custom snippet preview shows the text too large.

Before this commit, responsive font sizes using `clamp()` with a `vw` term were rendered too large in the block dialog. The `vw` value was based on the full preview iframe width, while snippets were displayed inside columns.

After this commit, the block dialog adjusts `vw` values on cloned `.o_rfs` preview content only, so the preview matches its column width without changing the snippet dropped on the page.

task-6303725

| BEFORE  (font size -> 144)  | AFTER  (font size -> 144) |
| ------------- | ------------- |
| <img width="416" height="409" alt="image" src="https://github.com/user-attachments/assets/e0eb0a4e-eb7b-4ee6-b080-536ea2a75c68" />  | <img width="421" height="272" alt="image" src="https://github.com/user-attachments/assets/6468a234-0966-45c9-9435-e97d9752b794" />  |

Forward-Port-Of: odoo/odoo#273257

**Steps to reproduce:**
1. Create a product.
2. Add two attributes: multi-checkbox and any single-select type (e.g. Radio).
3. Publish the product and open its page on eCommerce.
4. Verify that no multi-checkbox option is selected by default.
5. Refresh the page twice.

**Issue:**
On the second page refresh, the first option of the multi-checkbox attribute is automatically selected, and the URL is updated with its parameter.

**Cause:**
- `_prepare_product_values` construct attribute combinations by mapping requested `attribute_values` query parameters line by line.
- When URL query parameters were present (e.g., set after the first refresh), the fallback logic `or ptal.product_template_value_ids.filtered('ptav_active')[:1]` treated unselected `multi_checkbox` attribute lines as missing required selections rather than empty selections, forcing them to default to their first active option.

**Fix:**
If no selection is provided for `multi_checkbox` line, return an empty recordset instead of falling back to the first active option.

opw-6494697

Forward-Port-Of: odoo/odoo#286492
Forward-Port-Of: odoo/odoo#284798

## HOW TO REPRODUCE:
- Create a product AVCO Perpetual
- Receive 10 units with a unit price of $10 => Product average price is now $10
- Create a Sale Order for 10 units, confirm, deliver and invoice => COGS are at $100
- Receive 1 unit with a price of $5 => Product average price is now $5
- Update SO and add 1 unit, deliver and invoice this new unit => New invoice COGS is $-45

This is because Odoo computes the COGS for the whole SO, and decided that the value of the deliveries is the `quantity * standard_price`, which would means `11 units * $5 = $55`. Because the 1st invoice has a COGS balance of $ 100, the 2nd invoice is set to $ -45.

This behavior is inconsistent with how it was done in previous versions. Furthermore, if we added the +1 unit in a new invoice, the COGS would have been $ 5, for a total products COGS of $ 105.

- - -

With this fix, the COGS are computed using the average of the move value. So if the first move value is $100, and the second is $5, then the global COGS for the sale order should be $105. Because the first invoice COGS are already at $100, the second invoice COGS must be $5.

OPW-6442049

---

## TEST RESULT WITHOUT FIX:
```
2026-08-21 08:00:11,722 28203 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: Starting TestAngloSaxonValuation.test_cogs_average_multiple_invoices_and_deliveries ... 
2026-08-21 08:00:13,055 28203 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: ====================================================================== 
2026-08-21 08:00:13,055 28203 ERROR oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: FAIL: TestAngloSaxonValuation.test_cogs_average_multiple_invoices_and_deliveries
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/sale_stock/tests/test_anglo_saxon_valuation.py", line 1935, in test_cogs_average_multiple_invoices_and_deliveries
    self.assertRecordValues((cogs_line_1 | cogs_line_2), [
  File "/home/odoo/Odoo/src/19.0/odoo/odoo/tests/common.py", line 727, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'ac[142 chars]it': 5.0}, {'account_id': 3566, 'debit': 5.0, 'credit': 0.0}] != [{'ac[142 chars]it': 45.0}, {'account_id': 3566, 'debit': 45.0, 'credit': 0.0}]

First differing element 2:
{'account_id': 3536, 'debit': 0.0, 'credit': 5.0}
{'account_id': 3536, 'debit': 0.0, 'credit': 45.0}

  [{'account_id': 3536, 'credit': 100.0, 'debit': 0.0},
   {'account_id': 3566, 'credit': 0.0, 'debit': 100.0},
-  {'account_id': 3536, 'credit': 5.0, 'debit': 0.0},
+  {'account_id': 3536, 'credit': 45.0, 'debit': 0.0},
?                                 +

-  {'account_id': 3566, 'credit': 0.0, 'debit': 5.0}]
+  {'account_id': 3566, 'credit': 0.0, 'debit': 45.0}]
?                                               +

 
```

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

Forward-Port-Of: odoo/odoo#283778

Steps to reproduce:
===================
1. Add several images to a product, one of them much wider than tall.
2. On the product page, set the image ratio to "Disabled".
3. Move the thumbnails below the image.

=> The wide thumbnail sits at the top of its slot, with blank space
   under it.

Root cause:
===========
Thumbnails are given a fixed width of 64px and take their height from `aspect-ratio: var(--o-wsale-product-image-ratio)` [1]. With cropping disabled that variable is `auto`, so each thumbnail keeps the shape of its own image and they no longer share a height.

They sit in a flex row, which stretches every slot to the height of the tallest one. The image inside keeps its own height and stays at the top of the slot, so a wide image leaves the rest of its slot empty.

The slots are only stretched when the images differ in height, which is why the problem needs cropping to be disabled, and why it does not appear when every image is a landscape one.

- [1] sized the thumbnails from the image ratio.

Fix:
====
Center the thumbnails in the row so each one keeps the height of its own image instead of being stretched to the tallest.

Their width stays at 64px, so a row of wide images still takes the same space as before and none of them is pushed out of the container.

[1]: 670b1daa2254
opw-6472484

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

Forward-Port-Of: odoo/odoo#283246

## Issue
By default in Odoo, `datetime.now()` returns the UTC time, which is two hours behind the local time in Belgium. This leads to two tests failing when executed between 00:00 and 02:00 Belgian time: `test_ir_sequence_interpolation_dict` and `test_ir_sequence_iso_directives`.

The `_interpolate_dict` method (responsible for interpolating the prefix/suffix from the sequences) specifies the tzinfo when calling `datetime.now()`:

https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/odoo/addons/base/models/ir_sequence.py#L211-L212

Since this is not the case in the tests, the tests evaluate the date using UTC. This creates a two hours difference between the time expected and the time actually used by `next_by_code`. The tests thus fail between 00:00 and 02:00 because the evaluate dates from both `datetime.now` calls differ, leading to a mismatch in the expected prefixes.

## Fix
We force the `env.tz` on the `datetime.now()` call, to mimic the behavior from the `_interpolate_dict`.

runbot-242662

Forward-Port-Of: odoo/odoo#284955