### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/ac2fa3e6d4 [REL] 19.2.0-alpha.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/811ec6d6d2 [FIX] session: always return a Promise [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/900df13338 [FIX] session: recover from errors when sending messages [Task: 5469116](https://www.odoo.com/odoo/2328/tasks/5469116)
https://github.com/odoo/o-spreadsheet/commit/f832009ebf [REF] side_panel: rename CSS classes for clarity [Task: 4982596](https://www.odoo.com/odoo/2328/tasks/4982596)
https://github.com/odoo/o-spreadsheet/commit/ada17cb231 [REF] side_panel: split CF into main and editor panels, use store [Task: 4982596](https://www.odoo.com/odoo/2328/tasks/4982596)
https://github.com/odoo/o-spreadsheet/commit/c3ee9f24ab [REF] side_panel: separate data validation list and editor logic [Task: 4982596](https://www.odoo.com/odoo/2328/tasks/4982596)
https://github.com/odoo/o-spreadsheet/commit/f255b8720d [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580)
https://github.com/odoo/o-spreadsheet/commit/f19bf803a4 [IMP] cf: add top10 conditional formatting operator [Task: 5367065](https://www.odoo.com/odoo/2328/tasks/5367065)
https://github.com/odoo/o-spreadsheet/commit/559cdd8ff1 [FIX] dashboard: properly handle grid resize in dashboard mode [Task: 5223156](https://www.odoo.com/odoo/2328/tasks/5223156)

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>

Purpose
=======
Improve the event slots feature and some other small improvements.

Specification
===========
Event form:
- Add a "Slots" stat button to ease access to slots in addition
to the link already present next to the multiple slots field.
- Make "Sales Start" hidden by default for the event tickets.
- Make sure the left column fields labels are correctly aligned
with the title. A bottom margin was missing underneath the event image
and was messing the form display.

Slot views:
- In calendar view, instead of restricting the creation of slots outside of the event time range,
ask confirmation and adjust the event time range to include the new slots.
- In list view, removing the editable bottom behavior which is messy and tricky to use from mobile.
Instead opening the slot form in a dialog. This also now provides the timezone info to the user.
- In calendar and list view, adding a "New" button to allow single event slot creation.
- Add an hint for the user to make sure they understand that they need
to select days in order to add multiple slots.
- Changing the multi create "Add" button color to primary to make it more noticeable at first sight.
- For the slots out of time range validation error. Format the event time range the same way
as the slot time range so that it's easier to compare the 2.

Task-5114075

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

`datas` is base64-encoded and we directly decode it once set. Most of code should use `raw` directly and avoid handling base64 encoded data, because in the future we will change the cache representation to avoid handling encoded values.

This PR simplifies current usages and will allow to change the representation of binary fields in cache (which are today base64 encoded). base64 takes more space and there is a lot of encoding/decoding involved depending on the abstraction layer, the end goal is to only handle raw data and encode only for the client.

- In `odoo.tools.images` a few base64 functions are deprecated (one remaining for later).
- Allow importing files (see convert) without going though base64.
- Binary fields have now `convert_to_read` (encode as base64) and `convert_to_write` (use the cache format) defined. The *read format* is used by the client and should not be used in the models.
- base tests define common data that can be reused.

task-4251301
https://github.com/odoo/enterprise/pull/100997

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

**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

Forward-Port-Of: odoo/odoo#241153
Forward-Port-Of: odoo/odoo#217125

Bug:

      - Create a new employee (also reproducible with existing employees)

      - Create a Paid Time Off allocation that becomes available in the future

      - Create a Time Off request for this employee at a future date

      - When selecting the Time Off type, it shows “0 remaining out of 0 days” even though leave has been allocated

Reason:
In `_compute_display_name`, the record is accessed using `self.sudo().` Switching to superuser triggers `_compute_leaves`, but the context is lost and therefore the `target_date` is lost as well.
In `get_allocation_data`, because target_date is False, it is replaced with today’s date. This causes `max_leaves` and `virtual_remaining_leaves` to be computed as of today instead of the intended future date.

Fix:
Remove the `sudo() `and use the current user context instead.

-------------------------------------------------------------------------------
Test fix: `test_allocation_dropdown_after_period`

Bug:
After removing `sudo() `from `_compute_display_name`, the test fails and shows “0 remaining out of 0” instead of “9 remaining out of 9”.

Reason:
The test user (Admin) did not have the employee’s company in their allowed companies.
The `name_search` method triggers `_compute_display_name`, which triggers the computation of virtual_remaining_leaves.

Before the fix, `_compute_display_name` used `sudo()`, which propagated superuser privileges down to `_compute_leaves` and `get_allocation_data`. This masked the fact that the test user did not have access to the employee’s company (multi-company rule).

After removing `sudo(),` the user no longer had access to the allocation when running `name_search`, causing the test to fail.

Fix:
Add the employee’s company to the user’s company_ids. This allows allocations and `name_search` to work correctly without using `sudo().`

-----------------------------------------------------------------------
Known limitation:
When booking time off from the employee calendar view, the default value of `holiday_status_id` in the Time Off request widget still calculates remaining days based on today’s date instead of date_from.

To avoid confusion, the display name does not include “(x days remaining out of y days)” in this context.
However, when opening the selection dropdown, the display name is correct and uses the proper date-based calculation.

Forward-Port-Of: odoo/odoo#241448

[FIX] mail: avoid error on service worker push subscription change

Sometimes, the `pushsubscriptionchange` event is called without an
`oldSubscription` defined, which can lead to an error occurring inside
the  service worker.

Steps to reproduce:

1. Enable notification in Odoo.
2. Reset the permission in the Chrome interface
3. Re-enable the permission inside the discuss systray by clicking on
the Odoobot message.
=> The pushsubscriptionchange is called without an oldSubscription


[FIX] mail: ir_cron_web_push_notification are now more robust

With a user having 5 registered devices for push notifications
if a browser registers with an endpoint that has a wrong domain
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX
the cron job cannot resolve the invalid domain of the endpoint and ends
up disabling it.


[FIX] mail: push_to_end_point method to support .invalid TLD

if a browser registers with an endpoint that has a TLD `.invalid`
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX

The TLD `.invalid`[1] is intended for use in online construction of
domain names that are sure to be invalid and which it is obvious at a
glance are invalid. The cron job cannot resolve the invalid domain of
the endpoint and ends up disabling it.

So we need to unregister a device with an endpoint with a `.invalid`
TLD.

[1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2


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

Forward-Port-Of: odoo/odoo#242428
Forward-Port-Of: odoo/odoo#240502

When using a promotion program applied only on specific products with
tax included prices, the discount value was incorrect.

Steps to reproduce:
-------------------
* Create a product with a price of 100$ and tax of 10% included
* Create a promotion program with:
  - Apply on: Specific Products (the product created above)
  - Discount Type: $ Fixed Discount
  - Discount Value: 10$
* Open PoS and add the product to the order
* Apply the promotion code
> Observation: The value of the discount is 9.09$ instead of 10$

The same steps also applies to the discount reward applied on the whole
order.

Why the fix:
------------
When computing the discountable amount for the promotion it would take
the amount excluding tax instead of the base price. The base price
should be the unit price of the product multiplied by the quantity. As
it was before here :
https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/point_of_sale/static/src/app/models/pos_order_line.js#L470-L474
https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/pos_loyalty/static/src/app/models/pos_order.js#L1112
To do so we modified the accounting helpers to provide this value
instead of computing it manually.

opw-[5260067](https://www.odoo.com/web#id=5260067&view_type=form&model=project.task)
opw-[5242194](https://www.odoo.com/web#id=5242194&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#240289

In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order

### Steps to reproduce:

* Create a product with instantly generated variants
* Create a combo choice and add one of his variants
* Create a combo product and add the combo
* Open an store that sells this combo
* Select the combo and choose the product with variant and confirm the selection

Issue : On the left size in the order the variant name will not appear.

### Observation:

When it tries to retrieve the attribute information for the variant https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/services/pos_store.js#L1048 It is empty since during the call of computeComboItems the attribute was not retrieved for this scenario. https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33

------------
When adding a always variant to a combo they are considered like their own product, and attribute.extra_price should not be considered.
The extra price for an always variant is setup in the combo with comboItem.extra_price like stand alone products.

opw-5037355

Forward-Port-Of: odoo/odoo#239314
Forward-Port-Of: odoo/odoo#227176

**AllowanceDate**:
l10n_tw_edi_ecpay has an issue on Credit Notes (Allowances).
When we `_l10n_tw_edi_generate_issue_allowance_json()`, we send the
`l10n_tw_edi_invoice_create_date` which is was set to the associated
invoices creation date, and not the Allowance's creation date.

This creates a potential issue where allowances issued more than 6 days
after the original invoice would bounce back from ECpay with errors.
To be consistent with invoices send to ECPay, we do not send the
`AllowanceDate` parameter at all

Manual Testing/Verification:
1. Create an invoice that has a `l10n_tw_edi_invoice_create_date`,
visible in the Invoice's ECPay tab more than 6 days ago. (Requires
sending to ECPay via the custom wizard via the "Send" button)
2. Create a credit note from the invoice and send to ECPay.
3a. Before this, see that an error would appear.
3b. Now, there would be no error

*InvoiceRemark*:
When Customer Reference `ref` is not set, the code sets the parameter
value as `False`, displaying it's string on the e-invoice and official
printout. We only set the parameter if there exists the `ref` now,
eliminating the issue.

Tests:
1. (both cases) undo the `account_move.py` changes and run the tests.

task-[5455847](https://www.odoo.com/odoo/project/967/tasks/5455847)

---

# New test failed output
<img width="1458" height="353" alt="image" src="https://github.com/user-attachments/assets/77df8e51-5005-4d99-985c-71757c0f62a6" />

```bash
07:47:53,055 ERROR l10n_tw_edi_ecpay-demo-vy2vd3s0 odoo.addons.l10n_tw_edi_ecpay.tests.test_edi: FAIL: L10nTWITestEdi.test_01_can_generate_file
Traceback (most recent call last):
  File "/home/odoo/odev/worktrees/18.0-l10n_tw_edi_ecpay-fix-allowance-date-erle/odoo/addons/l10n_tw_edi_ecpay/tests/test_edi.py", line 61, in test_01_can_generate_file
    self.assertIsInstance(json_data["InvoiceRemark"], str)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: False is not an instance of <class 'str'>
 
07:48:02,516 ERROR l10n_tw_edi_ecpay-demo-vy2vd3s0 odoo.addons.l10n_tw_edi_ecpay.tests.test_edi: FAIL: L10nTWITestEdi.test_13_b2b_refund_upload_deadline_restriction
Traceback (most recent call last):
  File "/home/odoo/odev/virtualenvs/18.0/lib/python3.13/site-packages/freezegun/api.py", line 885, in wrapper
    result = func(*args, **kwargs)
  File "/home/odoo/odev/worktrees/18.0-l10n_tw_edi_ecpay-fix-allowance-date-erle/odoo/addons/l10n_tw_edi_ecpay/tests/test_edi.py", line 430, in test_13_b2b_refund_upload_deadline_restriction
    self.assertNotIn("AllowanceDate", json_data,
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        "B2B Allowances should not include AllowanceDate to avoid >6 day limit errors."
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
AssertionError: 'AllowanceDate' unexpectedly found in {'MerchantID': '1234', 'Details': [{'OriginalInvoiceNumber': 'AB11100099', 'OriginalInvoiceDate': '2025-01-06', 'OriginalSequenceNumber': 0, 'ItemName': 
                                                                                                                                                                                                              'product_a', 'ItemCount': 1.0, 'ItemPrice': 1000.0, 'ItemAmount': 1000.0}], 'TotalAmount': 1000.0, 'TaxAmount': 50.0, 'CustomerEmail': 'partner_b@tsointsoin', 'AllowanceDate': '2025-01-06 15:00:00'} : B2B 
                                                                                                                                                                                                            Allowances should not include AllowanceDate to avoid >6 day limit errors.
```

---

Things to think about:
- FWP
- [ ] 19.0
- [ ] master

Forward-Port-Of: odoo/odoo#241973

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
We add a new field on the `pos.order` model to retain if that order was previously invoiced with a simplified invoice, in that case, we set its type to 'F3' instead of 'F1' when fully invoicing it.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

We have hidden the actions in the activity view for previous versions because they were not working well (see odoo/enterprise#86436). We re-enable them here after having fixed the following problems:
- the actions were not always related to the selected document in the detail panel
- the selection was not working
- only custom actions along with download and share actions were present
- the selection box was absent
- the search box was not hidden when a selection was active

Note that we have decided to reset the selection when switching to the activity view because that view doesn't support multiple selection like other views and often the selected record in other view is not present in the activity view because the record doesn't have activities.

Technical note: In the DOCUMENT_RELOAD event implementation, we remove await env.model.load(); and await env.model.notify(); because await env.searchModel._reloadSearchModel(true); already call them. This solves the problem of reloading in the activity view as the method load was called without the right parameters (which is not the case when called by _reloadSearchModel). To reproduce the problem, share a document in the activity view, an error happens in the console during the reload and if you click on share again, you get a second error and the share panel won't open anymore.

Task-5089173

*mrp_account, sale_mrp{,_margin}, point_of_sale

## Issue 1: Kit sale price
 
### Steps to reproduce:

- Install sale_margin, sale_management, mrp
- Create a kit product with an avco product category:
    - 1 x COMP1, cost 10
    - 1 x COMP2, cost 20
- On the kit product update the cost accroding to the bom
- Create an SO for 1 unit of your kit
- Validate the associated receipt
#### > The cost (purchase_price) of the sol of the kit has been reset from 30 to 0.

### Cause of the issue:

Validating the receipt will trigger the dependence of the `purchase_price` compute method since the moves are now done: https://github.com/odoo/odoo/blob/18dc738c710f87d1f937b0d1fbb619c75f5ad952/addons/sale_margin/models/sale_order_line.py#L15-L18 However, the `_get_price_unit` will `return 0` since `sol` is linked to both component moves:
https://github.com/odoo/odoo/blob/18dc738c710f87d1f937b0d1fbb619c75f5ad952/addons/sale_stock_margin/models/sale_order_line.py#L10-L20

### Issue 2: POS with multiple products
Currently, when a pos order contains more than 1 product, inventory valuation lines are not generated when invoicing the order.

Steps to reproduce:
-------------------
* Using anglo-saxon accounting
* In the settings search for inventory valuation
  * Set inventory valuation to Perpetual
  * Choose standard cost method
  * Set up valuation account and journal
* Create two different products
  * Type -> Goods
  * Track inventory by quantity
  * Set a purchase cost
  * Put some quantity on hand
  * Add category
* In the settings of the category
  * Set up Stock account
  * Set up costing methog, standard
  * Set inventory valuation to perpetual
* Open pos session
* Make 3 orders, invoice them
  * Order 1, only product 1
  * Order 2, only product 2
  * Order 3, both products
> Observation: The invoces for orders 1 & 2 have entries regarding
inventory valuation while the invoice for order 3 does not have any.

### Cause of the issue:

Stock valuation entries are not created for order 3 because the price unit computed is 0.
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/account_move.py#L122-L126

The reason why the price unit is 0 is because in `_get_pos_anglo_saxon_price_unit` we have multiple records in `moves` related to multiple products.
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/point_of_sale/models/pos_order.py#L276-L281

`_get_price_unit` was not designed to treat moves with different products https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228

This leads to think we should filter moves in `_get_pos_anglo_saxon_price_unit` regarding the product.

The end result is now the same as when we make a SO with the two products in the Sales app and invoice it. This results in 2 valorisation lines (1 per product) but this does not change the valorisation when the pos order is not invoice and we close the session (still 1 valorisation line).

### Fix:

The filter on the product_id in the `_get_pos_anglo_saxon_price_unit` has been removed in https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229
Prior to that change the price unit were computed on moves sharing a common product:
https://github.com/odoo/odoo/blob/9cb6476e0f8d319dce4baf65904b8bd5d535c83c/addons/point_of_sale/models/pos_order.py#L271-L275
https://github.com/odoo/odoo/blob/9cb6476e0f8d319dce4baf65904b8bd5d535c83c/addons/stock_account/models/stock_move.py#L28-L29
We reintroduce this filter as it should not have been removed.


#### Issue 1: opw-5420977
#### Issue 2: opw-5328152

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

Forward-Port-Of: odoo/odoo#242052

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185

Forward-Port-Of: odoo/odoo#242319
Forward-Port-Of: odoo/odoo#241269

Issue
-----
After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step.

Steps to reproduce
-----
- Enable multi step routes
- Set WH to 3-step manufacturing
- Create a product
	- empty bom
	- MTO & manufacturing routes
	- 5 in stock
- Create a SO for the product
- Cancel the linked MO
- Open the delivery picking
- Click "Check Availability"

> The product is not getting reserved from stock

> The delivery picking is still "Waiting Another Operation"

Cause
-----
The problem happens in `action_cancel`

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995

In 1-step case, `move.propagate_cancel` is false so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021

where `move_dest_ids` is the move of the delivery picking.

This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931

instead of going into the `else` part

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949

In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014

which lacks the swap to MTS and unlink `move_dest_id` logic.

Solution
-----
We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by

https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012

This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754

and since it was set to MTS, it goes into the `else`part of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216

-----
Ticket:
opw-5124380

Forward-Port-Of: odoo/odoo#242038
Forward-Port-Of: odoo/odoo#237890

This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested snippets.

**Accordion issues**
How to reproduce: drop two nested `s_accordion` snippets. Then:
1. Change the outer "Style" from "boxed" to "highlight active" -> both accordion change,
2. Change the outer "Round Corners" -> both accordion change,
3. Change the outer "Icon Position" ->  both accordion change,
4. Change the outer "Icons" style -> both accordion change.

**Blockquote issues**
How to reproduce: drop two nested `s_blockquote` snippets. Then:
1. Change the outer "Decoration" -> both blockquotes change,
2. Set the inner "Decoration" to "Icon" -> works only if the outer snippet has icon too,
3. Change the outer "Author Alignment" -> only the inner blockquote changes.

**Cause**
The above issues occur because certain `applyTo` and certain CSS selectors match all nested elements rather than restricting the scope only to the snippet being edited.

**Fix**
The relevant `applyTo` and CSS rules now use more specific selectors.

**Note**
See also https://github.com/odoo/odoo/pull/237733

task-5362171

Forward-Port-Of: odoo/odoo#242364
Forward-Port-Of: odoo/odoo#242077

An error occurs when a user tries to assign a Statement to multiple selected lines in the Bank Statement list view.

Steps to reproduce:
1) Install Accounting with demo data.
2) Open the Bank Reconciliation widget.
3) Switch to the List view.
4) Select multiple statement lines.
5) Click on the 'Statement' field to assign a statement to the selected
   lines.

Error:
`TypeError: Cannot read properties of undefined (reading 'root')`

Root Cause:
The `BankRecMany2OneMultiID` component attempts to access `active_ids`
through `this.env.model.root` (see [1]). During re-rendering, the value of
`this.env.model` becomes undefined, which leads to the error.

Fix:
Add a check for the existence of `this.env.model` in the getter to avoid
accessing `root` on an undefined model.

[1]- https://github.com/odoo/enterprise/blob/c194bee0e48db407288e3c402e71840af299568d/account_accountant/static/src/components/bank_reconciliation/list_view/list_view_many2one_multi_edit.js#L14

opw-5403564

Forward-Port-Of: odoo/enterprise#103472
Forward-Port-Of: odoo/enterprise#101792

Before this commit when a combo product was added to the the order, if a note was added and then the product was ordered. And after we change the quantity of this product and the note, the combo children lines were not updated correctly.

After this commit, the combo children lines quantities are correctly updated when the parent line quantity is changed.

Step to reproduce :

1. Add a combo item to the order line in Point of Sale (Restaurant).
2. Add a Note to the main order line and place the order(Send to Kitchen).
3. Now increase the quantity of the main order line and update the note as well.
4. A popup appears to select the combo again make your selection. You'll notice that a new order line is added.
5. However, in the previous order line, the main product quantity is reverted back to the original quantity, but the combo item order line quantity is not reverted, resulting in an inconsistency.

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

Forward-Port-Of: odoo/odoo#232069

Currently, an error occurs when user tries to open the Tax Return view.

**Steps to Reproduce:**
 - Install the `Accounting` module.
 - Go to `Tax Returns` and set the `Fiscal Year End Day to negative value`, then click `Apply`.

**Error:**
`ValueError: day is out of range for month.`

**Cause:**

 - The field is related to the `company's fiscalyear_last_day` [1].
 - When the user enters a `negative value`, that invalid value is written directly to the `company's fiscal year last day`[2] .
 - When the user opens the `Tax Returns`, it going to compute the `fiscal year dates` [4]. Since the day value is negative, it raises error [5] because the day is out of range for the month.

**Fix:**
- This commit ensures that a validation error is raised when a user enters zero or negative fiscal year date.
- In 18.3, setting the value to 0 falls back to the previously defined company value [2].
- In 19.0, however, the value 0 is incorrectly saved on the company [3], causing an error.
- This fix restores the correct behavior and resolves the issue in 19.0 as well.

[1]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L17-L18

[2]: https://github.com/odoo/odoo/blob/45ca03fcb77febf4f373fe35f0242720e88cb85b/addons/account/wizard/setup_wizards.py#L49

[3]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L54-L56

[4]: https://github.com/odoo/enterprise/blob/99642bdf62f8b1c653dfefdbdcd0e9258cc9e307/account_accountant/models/res_company.py#L174-L175

[5]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/odoo/tools/date_utils.py#L242

sentry-7102968735



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

Forward-Port-Of: odoo/odoo#239814

Putting in pack from the SML view leads to package incorrectly located

To reproduce the issue:
1. In Settings, enable "Package"
2. Confirm a delivery with 2 available products
3. Open the SML thanks to the smart button
4. Tick a line > Put in pack
5. On the second line, in "Destination Package", look for the package

Error: it is impossible to find it

When opening the SML thanks to the smart button, we also load a lot 
of default values:
https://github.com/odoo/odoo/blob/1492abd8c6bcfdbc48f730f6767b177aeff54bf7/addons/stock/models/stock_picking.py#L1203-L1221
Those are (obviously) SML specific.

However, this context is used when putting in pack. This is a 
problem since `location_id` is also the field name of a package. As 
a result, the ORM defines the location of the new package with the 
default value, i.e. the source location of the SML. This is incorrect.

One consequence of this bug is the step 5 of the above use case. 
When looking for a package, a domain checks its location:
https://github.com/odoo/odoo/blob/35feed47622b279abf8e593d8190ea36b64d32fd/addons/stock/models/stock_move_line.py#L51-L55
It must be either `False` or equal to the dest loc, which is not the 
case with the created package.

The root cause of the issue is the uncontrollable propagation of the 
default values JS side and/or the poor structure of the default key 
(for instance, the key could contain the model name). Anyway, 
discussed with PY framework: the matter won't be address that soon.

OPW-5215243

Scenario:
* create a delivery with quantity 3 and mark as TODO
* mark the stock move as picked
* open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new package or a new lot
* exit the popup and try to validate the delivery

Behavior before this commit:
* the stock move in the delivery form remains picked
* validation shows a backorder popup, warning of missing quantity

Reason: the newly created stock move line is not picked, but this information is not displayed anywhere, so users are not aware of the cause of this issue

After this commit:
* the stock move is no longer picked after a new move line is added
* users can click the "Picked" checkbox in the delivery form manually, which marks all stock move lines as picked as well
* after this action, delivery validation proceeds without backorders

opw-5345579

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#241790
Forward-Port-Of: odoo/odoo#239089