When unsetting the Available in Self Order field on a product, a traceback occurs.

Steps to reproduce the error:
- Install ``pos_self_order`` module with demo data
- Open any Product that is available in pos >
  In Point of sale Tab, Unset Available in Self Order field > Save

Traceback:
```py
ValueError: Expected singleton: pos.config()
```

When the ``self_order_available`` field is updated, ``write()`` calls ``_send_availability_status()`` at [1].
Previously, this method only processed POS configurations with a ``current_session_id``,
but that condition was removed in commit https://github.com/odoo/odoo/commit/22e075987cf05c5891120b86694b5312936d4def at [2].
As a result, ``_send_availability_status()`` may now call ``load_product_from_pos()``
with a POS configuration that has no current session. This eventually calls ``_get_available_pricelists()``
on an empty ``pos.config`` recordset, triggering the singleton error.

[1]-https://github.com/odoo/odoo/blob/8e7732045bd465cd1a763329e4e8448de45960ad/addons/pos_self_order/models/product_product.py#L118-L120
[2]-https://github.com/odoo/odoo/blob/8e7732045bd465cd1a763329e4e8448de45960ad/addons/pos_self_order/models/product_product.py#L126

sentry-7614402869

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

Steps:
- Install l10n_co module.
- Set `CO company` on user.
- Go to address page on portal address.
- Set `Company Name`, `ID Type` and `ID Number` on the address page.

Issue:
- Not able to save address without any error message on the address page and in logger it raise validation error.

Cause:
- In address we actually do vat validation before creation/updation and if there is any issue with vat number then add it into invalid_fields instead raising any validation error, so here when user set `Company name` on address it try to create parent company and again do vat validation and it raise validation error because `ID Type` on customer is not propagated to parent when creating parent company from portal.

Fix:
- Skip vat validation on parent company creation from address.

To-do: We also need to pass `ID type` and other accounting related values when creating parent company from customer or make them dependent like `Vat`.

Issued PR: https://github.com/odoo/odoo/pull/264356

opw-6434127

Forward-Port-Of: odoo/odoo#281441
Forward-Port-Of: odoo/odoo#280859

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/5c667fedc1 [REL] 19.4.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/48df9225db [IMP] composer: writing an number value should override date formats [Task: 6353692](https://www.odoo.com/odoo/2328/tasks/6353692)
https://github.com/odoo/o-spreadsheet/commit/48e2180e31 [FIX] index: export `CarouselFigure` [Task: 6449019](https://www.odoo.com/odoo/2328/tasks/6449019)
https://github.com/odoo/o-spreadsheet/commit/1a6144752d [FIX] chart: geoChart uses same d3 projection for main and full screen chart [Task: 6395379](https://www.odoo.com/odoo/2328/tasks/6395379)
https://github.com/odoo/o-spreadsheet/commit/60d40c1514 [FIX] carousel: crash on multiuser when deleting chart [Task: 6445004](https://www.odoo.com/odoo/2328/tasks/6445004)
https://github.com/odoo/o-spreadsheet/commit/4e9affe04f [FIX] figures: fix movement issue with arrow keys [Task: 6374091](https://www.odoo.com/odoo/2328/tasks/6374091)
https://github.com/odoo/o-spreadsheet/commit/01acbcaa9d [IMP] package: update owl to 45 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

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>

### Problem:
Background videos on `website` were not looping correctly for 3 reasons
- Not all `video_providers` implemented the loop `optionsConfig`.
- The `loop` optionsConfig was not enabled automatically when adding
  background videos
- YouTube requires a `playlist` url param with the same value as the
  `videoID` in order to loop correctly

### Steps to reproduce:
- Go to website.
- Add a Snippet.
- In the snippet builder options, add a background video like [1].
- Save the website.
- The background video does not loop.

### Solution:
This PR,
- Implements the `loop` optionsConfig for more supported video
  providers.
- Enables the `loop` optionsConfig for background videos by default
- Adds the `playlist` param for YouTube video provider when `loop`
  optionsConfig is enabled.

### Unsupported video providers:
- Loom [2]
- Twitch [3]
- Facebook [4]
- Instagram
- GoogleDrive
- Dailymotion [7]

### Supported Players:
- YouTube [5]
- Vimeo [6]

##### Note on Dailymotion:
Dailymotion supports the loop parameter on iFrame embedded videos but
the behavior of playback goes against expectations set by other
providers. Instead of looping through the requested video, Dailymotion
will loop through an automatic "playlist" that it then goes through.
This behavior is also not consistent with all videos, some videos don't
seem to adhere to this norm. Since playing random videos is worse than
not looping, the loop param addition is not handled by this PR.

[1]: https://www.youtube.com/watch?v=sEH3pOhj0xs
[2]: https://support.atlassian.com/loom/docs/embed-your-video-into-a-webpage/
[3]: https://dev.twitch.tv/docs/embed/video-and-clips/
[4]: https://developers.facebook.com/docs/plugins/embedded-video-player
[5]: https://developers.google.com/youtube/player_parameters
[6]: https://help.vimeo.com/hc/en-us/articles/12426486963857-How-to-add-autoplay-and-loop-parameters-to-my-video-s-embed-code
[7]: https://developers.dailymotion.com/docs/add-runtime-player-parameters-web

task-6431769

**Steps to reproduce:**
1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company
2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium
3. Create a website for the belgian company and enable stripe payment provider
4. Add SEPA payment method in stripe configuration
5. Open the website, add any product to cart, go to checkout and make a payment using SEPA

**Issue:**
- Check the transaction in Stripe dashboard: the order reference is currently sent only
in the `Description` field which is for internal information and is not shown to
customers on their bank statements. Customers only see "MACKNET", so they cannot
identify which order the payment relates to.

**Expected behavior:**
- Should also send the order reference to Stripe's `statement_descriptor` field, which
is the field used for the customer-facing bank statement reference.
- The `statement_descriptor` value must comply with Stripe's requirements:
Must not contain <, >, \, ', ", or *
Must contain at least one letter
Maximum 22 characters

**Fix:**
- Pass the order reference, which should already satisfy the first two requirements based
on Odoo order/invoice naming conventions

opw-6424994

Forward-Port-Of: odoo/odoo#281417
Forward-Port-Of: odoo/odoo#280985

Currently, when the user receives a product with an expiry date whose removal date is before the current date, creating a backorder for the corresponding subcontracting operation causes the system to crash.

## Steps to produce:
- Install Manufacturing
- Go to settings and enable:
   - Subcontracting
   - Lots & Serial Numbers
   - Expiration dates
- Create a product named Vegetable Salad and set Tracking to By Unique Serial Number.
- In the inventory section, enable Expiration date and configure:
   - Expiration Date: 10 days after receipt
   - Removal Date: 8 days before expiration date
- Create a BoM for Vegetable salad
   - BoM Type: Subcontracting
   - Subcontractor: Chef
   - Component: Vegetable
- Create a receipt for 2 units of Vegetable Salad from Chef
- Mark it as Todo > Details > Assign serial to both lines
- Set the Removal Date of the second serial number to a date earlier than today, then Save and Validate the receipt.
- In the expiry warning wizard, click Proceed Except Expired and create backorder

## Observed Behavior:
Creating a backorder after proceeding with the expiry warning wizard fails with the following error:
`ValueError: Expected singleton: stock.move(12, 13)`

## Root cause:
This issue occurs because, when the user confirms the backorder, the current picking is validated at [1]. This calls `_action_done` at [2], which in turn calls
 `_action_done` on the todo moves at [3]. As part of this process, `todo_moves`
creates backorders at [4] and then confirms those backorder moves at [5].

During confirmation, the subcontracting manufacturing order (MO) with a serial number that has expired is split at [6], creating a new MO. This new MO then creates two backorder moves at [7]: one for the finished product and one for the component.

The problem arises because `default_lot_ids` are added to the context at [8] for the expiry wizard. That same context is unintentionally propagated to the backorder wizard during backorder confirmation. As a result, the ORM assigns those lot IDs to both the component and finished product moves. This triggers the `_set_lot_ids` inverse method, which calls `_prepare_move_line_vals` at [9].

However, `_prepare_move_line_vals` is an `ensure_one` method, while `self` now contains two moves (the component move and the finished product move). Because the method expects a single record but receives two, it raises a singleton error.
[1]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/stock/wizard/stock_backorder_confirmation.py#L64 
[2]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/stock/models/stock_picking.py#L1428-L1429 
[3]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/stock/models/stock_picking.py#L1273 
[4]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/stock/models/stock_move.py#L2267-L2268 
[5]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/stock/models/stock_move.py#L2332 
[6]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/mrp_subcontracting/models/stock_picking.py#L158 
[7]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/mrp/models/mrp_production.py#L2055-L2075 
[8]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/product_expiry/models/stock_picking.py#L33-L38 
[9]:
https://github.com/odoo/odoo/blob/c744f123ae4c7a4969e9885ee1efa99be7775340/addons/stock/models/stock_move.py#L679

## Solution:
Sanitize the context before opening the backorder wizard so that `default_lot_ids` from the expiry wizard are not propagated. This prevents the ORM from incorrectly assigning lot IDs to the component and finished product backorder moves, avoiding the singleton error in `_prepare_move_line_vals`.

With this change, users can successfully create backorder pickings and subcontracting manufacturing orders for products that are being removed without encountering any errors


opw-6390571

Forward-Port-Of: odoo/odoo#278262

Steps to reproduce:
- Set a Saudi company with a long legal name (e.g. "Golden Oasis Trading and Contracting Company Limited")
- Make a POS order and look at the receipt QR code

Issue:
The QR code is drawn visibly smaller and denser than for a company with a short name, even though the image it sits in is the same 150px box: 90px of code at a 2px module pitch, against 111px at 3px.

Cause:
The ZATCA payload embeds the seller name, so a longer name needs a higher QR version, i.e. more modules. ZXing's BrowserQRCodeSvgWriter draws each module at a whole number of pixels of the canvas it is given (multiple = floor(canvas / (modules + 8))), so asking it for a fixed 150x150 or 200x200 canvas leaves a leftover margin that varies with the module count. The code shrinks as soon as the module count crosses a multiple of the canvas size.

opw-6399878

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

Forward-Port-Of: odoo/odoo#281036
Forward-Port-Of: odoo/odoo#280000

Steps to reproduce:
1. Install Calendar
2. Create a meeting in Calendar in form view
3. Set the video link on it
4. Turn on the debug mode
5. Now, clear the video link

Issue:
- Traceback
```
Uncaught Promise > Invalid props for component 'CopyButton': 'content' is not a string or object or function
```

Cause:
- The 'CopyButton' component expect content to be a string, object or function but receives false.
  It does not happen in previous versions because in the refector https://github.com/odoo/odoo/commit/c2f34517b2f9832a498981d0fa17ec39b9739cb6 set the `videocall_location` to false instead of empty string like before https://github.com/odoo/odoo/blob/499420f7062ab467ff6f50b30c547e54c35ae1e9/addons/web/static/src/core/copy_button/copy_button.js#L14
- but any field using the `CopyClipboardChar/CopyClipboardURL` widget passes its raw field value straight through as content. An empty char/text field is represented as false, so whenever such a field becomes empty, CopyClipboardField hands `false` to CopyButton, which fails prop validation (debug mode).


Solution:
- Fix it at the source: CopyClipboardField's template now falls back to an empty string when the field value is falsy,
  so CopyButton never receives false but a valid string.

opw-6360936

Forward-Port-Of: odoo/odoo#280363
Forward-Port-Of: odoo/odoo#275236

Steps to reproduce:
- a Basque company with TicketBAI enabled
- one PoS config opened on two different devices (browsers)
- make a sale from the first device
- make a sale from the second device

Issue:
The second order is rejected by TicketBAI with the error 5040, the invoice number is already registered for that issuer, series and year.

Cause:
The invoice number sent to TicketBAI is the pos.order name. That name is built by _get_order_name_from_pos_reference out of the last part of pos_reference only, which is the receipt counter each device keeps in its own browser local storage and which restarts at 1. Both devices therefore name their first order "<config> - 000001", and _get_tbai_seq_from_name derives the same SerieFactura and NumFactura for the two of them.

Fix:
Send pos_reference instead. It is the number printed on the customer receipt and it also holds the device identifier, allocated by the device sequence of the config, which is what makes it unique. The device part ends up as the series and the counter as the number, so the numbering stays sequential inside the series of each device, and the series still starts with the year the duplicate check is made on. Both stay well below the 20 characters SerieFactura and NumFactura are limited to.

The name of the refunded document is taken from the same helper, so a credit note cannot reference a number that was never registered.

The pos.order name itself is not unique on any version from 19.0 on, but it cannot be changed in stable.

opw-6442837

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

Forward-Port-Of: odoo/odoo#280621

**Issue:**
Flexible employees in French companies cannot request the reference paid time off type, even when they have a sufficient allocation.

**Steps to reproduce:**
- Install the l10n_fr_hr_holidays module.
- Create a French company and set it as the active company.
- Log in as a user whose working schedule is Flexible (i.e., the employee's Working Hours field is left blank).
- Ensure the company's Time Off Type matches the leave type that the employee is requesting.
- Set a Resource Calendar on the company (this is required and must differ from the employee's flexible working schedule).
- Attempt to create a Time Off request for the employee.

**Cause:**
https://github.com/odoo/odoo/blob/5e865aeec854ca012dc5537f36b2e626ee39cf0b/addons/l10n_fr_hr_holidays/models/hr_leave.py#L17-L27

`_l10n_fr_leave_applies()` considers an empty employee calendar different from the company calendar. This sends flexible leaves to `_get_fr_date_from_to()`, which requires attendance rows and rejects the request.

**Solution:**
We need to require a concrete employee calendar before applying the French part-time calendar adjustment, leaving flexible employees to the core flexible-duration computation.

opw-6417220

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

Forward-Port-Of: odoo/odoo#280288

Version:
--------
- saas-19.4+

Steps to reproduce:
-------------------
- Install `stock` module
- Create a storable product and set 10 units on hand
- Create a delivery for 10 units, confirm it
- Under Operation tab click into view button which is optional hide
- Delete the move line and save

Issue:
------
After deleting the stock move line, the move is no longer reserved, but
the **Reserve** button does not reappear on the delivery.

Cause:
------
Saving the Detailed Operations form writes both `move_line_ids` and
`quantity` in the same `stock.move.write()` call.

`BaseModel.write()` applies field values according to each field's
`write_sequence`.

`move_line_ids` is written first (`write_sequence = 20`):
https://github.com/odoo/odoo/blob/9eca8f23bfa24e5dc4bf70a6dd7be2e6aff7a91d/odoo/orm/fields_relational.py#L603

After this [commit](https://github.com/odoo-dev/odoo/commit/7c2880c2ab43d70dc51bdba499eacc17c95af46c
)  in saas-19.4, `quantity` is written afterwards
(`write_sequence = 25`) so that lot updates happen before the quantity
inverse:

As a result:

1. Deleting the move line triggers `stock.move.line.unlink()`, which
   immediately calls `_recompute_state()`.

https://github.com/odoo/odoo/blob/9eca8f23bfa24e5dc4bf70a6dd7be2e6aff7a91d/addons/stock/models/stock_move_line.py#L584

2. At that moment, `quantity` has not yet been updated, so
   `_recompute_state()` still sees the previous reserved quantity and
   leaves the move in the `assigned` state.

https://github.com/odoo/odoo/blob/9eca8f23bfa24e5dc4bf70a6dd7be2e6aff7a91d/addons/stock/models/stock_move.py#L2488-L2489

3. Afterwards, the `quantity` inverse updates the reservation, but no
   second state recomputation is triggered, leaving the move and the
   picking state inconsistent. (and thus `show_check_availability` on the picking,
   which depends on move state) stays out of sync.

3. `quantity` is written afterwards and its inverse (`_set_quantity`)
   updates the reservation, but nothing recomputes the state again,
   so the move (and thus `show_check_availability` on the picking,
   which depends on move state) stays out of sync.

Before [commit](https://github.com/odoo-dev/odoo/commit/7c2880c2ab43d70dc51bdba499eacc17c95af46c
) `quantity` was written before `move_line_ids`, so when
`unlink()` triggered `_recompute_state()`, the quantity had already been
updated and the move state was computed correctly.

Fix:
----
When `move_line_ids` is modified through `stock.move.write()`, mark the
move for state recomputation, similarly to `move_orig_ids`.

The actual `_recompute_state()` call is deferred until after
`super().write()` completes, ensuring it runs with all written fields
(including `quantity` and its inverse) already updated, regardless of
the internal field write order.

---

opw-6359640

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

### Steps to reproduce

1. Install *Sales* and *Timesheets*
2. Create a service product: Invoicing Policy = *Based on Timesheets*, Create on Order = *Task*
3. Create a sale order for it (quantity 1) and confirm it
4. On the generated task, log **4.5 h on 15/06** and **3.5 h on 23/07**
5. *Create Invoice* with no timesheet period → 8 h, and post it
6. On that invoice: *Reverse* → *Partial Refund*, set the quantity to **3.5 h** and post it → 4.5 h invoiced
7. Log **1 h on 31/07** → 9 h delivered
8. *Create Invoice* again, with a **Timesheets Period of 01/06 → 31/07**

### Current behavior

The invoice bills **9 h**: the 4.5 h that were invoiced and not credited are billed a second time.

### Expected behavior

The invoice bills **4.5 h** — the quantity delivered minus the quantity invoiced.

### Cause of the issue

Posting a partial credit note clears `timesheet_invoice_id` on every timesheet the reversed invoice
had linked (`sale_timesheet/models/account_move.py`, `action_post`), because a credit note carries a
quantity and never a set of timesheets, so there is no way to tell which hours it credited.

All of those hours therefore become candidates again in `_recompute_qty_to_invoice`, which assigns
their sum to `qty_to_invoice` without comparing it to what is still due on the line.

### Fix

Timesheet links cannot express a partially invoiced timesheet, so they are used only to select the
hours a period concerns, while the quantity that may still be billed is
`qty_delivered - qty_invoiced`. The period lookup is capped by that remainder, and kept at zero or
above so that an over-invoiced line is corrected by a deliberate credit note rather than as a side
effect of invoicing a period.

### Tests

Five tests are added to `addons/sale_timesheet/tests/test_sale_timesheet.py`.

Three of them fail without the fix:

| test | without the fix |
| --- | --- |
| `test_period_invoice_does_not_rebill_refunded_invoice_hours` | `9.0 != 4.5` |
| `test_period_invoice_after_refund_is_computed_per_line` | `4.0 != 1.5` |
| `test_period_invoice_after_refund_of_an_over_invoiced_line` | `8.0 != 1.0` |

The other two cover behaviour that is not exercised today and that the fix must not break: an
over-invoiced line (which must be left out rather than credited, and must not prevent the other
lines of the order from being invoiced) and the reversed invoice's own `invoice_date`, which must not
influence the quantity billed for a period.

The full `sale_timesheet` suite passes (86 tests).

Forward-Port-Of: odoo/odoo#281065
Forward-Port-Of: odoo/odoo#280536