Commit [1] introduced the possibility to select the output device used for all softphone call voices and ringtones.

For the ringtone, it only worked for the outgoing calls though. Indeed, the ringtone object specific to each session* was only known by the AudioManager instance once an incoming call was actually >answered<. While the softphone was ringing, the output device used was left to default browser selection which often means default OS selection.

Steps to reproduce:
- Have a working Odoo voip provider
- Have two audio outputs on your computer and the OS allowing output to both at the same time (if connecting a headset, it often means having to select the computer speaker as the main source os side).
- Call your softphone with your smartphone => The softphone rings, through the main OS selection
- Change output device in the softphone setting => Bug 1: Nothing changes
- Hangup
- Change output device to something other that the default OS output in the softphone setting
- Call your softphone with your smartphone => Bug 2: The softphone rings, still through the main OS selection

*: this bug is another symptom of the fact that we really should have
   only one ringtone service instead of one object per session. This
   will be probably be done in master later, as it requires more checks.

[1]: https://github.com/odoo/enterprise/commit/e964e4b28604f32550566ad1b9f17aed89653597

Related to task-6533808

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#286603
Forward-Port-Of: odoo/odoo#286236

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:
1. Drop a "Products" dynamic snippet (or open /shop) in edit mode.
2. Click the snippet, open the Design sliding panel.
3. Drag the "Gap" slider or change its number input.

Before this commit:
The dynamic snippet content re-renders on every slider/input change, causing the products grid to blink.

Issue:
The dataset write in `SetGapAction.apply` mutates the element's dataset, which changes `getConfigurationSnapshot()` of the DynamicSnippet interaction, causing the interactions to stop and restart on every change.

That write is guarded by the `needsDbPersistence` flag of the panel, which is set from the `recordName` prop. This
https://github.com/odoo/odoo/commit/f427f795c24e instantiated `ProductsDesignPanel` with `recordName` on the dynamic snippet option, so from this version on the write lands on `.s_dynamic_snippet_products`, the root element of the interaction.

The dataset write was originally read by `onSave()` to persist the gap. This https://github.com/odoo/odoo/commit/728049b4597b refactored persistence to read the value directly from style property value of `--o-wsale-products-grid-gap` in `product_design_list_to_save.getData()`, leaving the dataset write without any reader.

Solution:
Remove the unused `dataset.gapToSave` write from `SetGapAction.apply`. Inline style alone covers rendering, persistence, and dirty tracking. Also remove the now unused `needsDbPersistence` property from the panel, as it was only consumed by the removed code.

task-[6535301](https://www.odoo.com/odoo/project/974/tasks/6535301)

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c8c526d863 [REL] 19.3.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/269e2c6342 [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/dea2498fd1 [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/32c6cc5f3f [FIX] svg: remove unused commented SVGs [Task: 6317134](https://www.odoo.com/odoo/2328/tasks/6317134)
https://github.com/odoo/o-spreadsheet/commit/3593d9f264 [FIX] chart: fix funnel chart show value [Task: 6475094](https://www.odoo.com/odoo/2328/tasks/6475094)
https://github.com/odoo/o-spreadsheet/commit/98da68e226 [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/cd38becce3 [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/d5fff28fab [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/bd7d230bfe [FIX] print: figure border wrong render [Task: 6458624](https://www.odoo.com/odoo/2328/tasks/6458624)

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:**
* 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

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#130264
Forward-Port-Of: odoo/enterprise#129000

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

### 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#129181

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

## 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