Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend.

Steps to reproduce:
-------------------
* Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup
* Create an online payment method (use demo for example)
* Change the kiosk settings to use those two payment methods
* Change the settings of the preparation display to use the kiosk
* Open preparation display
* Open kiosk, make on order, and select the online payment method
* Scan QR code and pay
> You are redirected to the confirmation page saying that the order
is being prepared while not sent to the preparation display

Why the fix:
------------
The fix to send the order to the backend is in the other part of this fix.

Here we decide to only allow to use the online payment methods that have been set on the config. Previously if two were existing but only one setup you were able to select any of them.

We also make a change to the `filterPaymentMethods` method. This method is called when pressing the pay button and is indirectly responsible for the fact that if there's only one payment method then we directly start the payment process.

Prior to this fix if we only had a terminal method setup and clicked to pay an order we directly had the screen telling us to follow the instructions on the terminal. However if we only had a online payment method, when clicking on pay, we would directly have the screen prompting us to pay at the register, we could never select the payment method.

With the fix, when there's only one payment method and it's online, clicking on pay will show the qr code.

opw-5001998

Enterprise: https://github.com/odoo/enterprise/pull/92825

Forward-Port-Of: odoo/odoo#225851
Forward-Port-Of: odoo/odoo#223689

When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback.

Steps to reproduce:
-------------------
* Marc demo and Abigail Peterson using the same calendar
* Create a "Paid time off" leave for marc demo: June 19 - June 20
* Create a "Extra time off" for abigail: same date
* Update Time off type "Extra Time Off" to "Ignore Public Holidays"
* Approve both leave request previously created
* Create public holidays on June 19 --> traceback

Observation:

When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561

Why the fix:
------------
Added a new key on work_days_data to avoid the collision of two similar timeoffs.

opw-4933820

Forward-Port-Of: odoo/odoo#225443
Forward-Port-Of: odoo/odoo#221942

__Current behavior before commit:__
The color palette for SVG Dynamic Colors doesn't work properly.
The color preview doesn't show the current color and some colors make
the SVG disappear.

__Description of the fix:__
- The [`_update_svg_colors`] backend method only works with rgb, hex and
the palette colors matching `/^o-color-[1-5]$/`. So all other custom CSS
variables (e.g. `var(--white)`) are converted to hex notation in the SVG
URL search params.
- Furthermore, to show the correct color in the little color preview
circle, [`getValue`] now always returns a normalized CSS color value.
- The regex matching rgba color in [`convertCSSColorToRgba`] has been
fixed to include alpha values that don't have the 0 before the decimals
(e.g. `rgba(255, 255, 255, .5)`).

__Steps to reproduce:__
1. Open the website builder
2. Switch to "Artists" theme
2. Drop a Horizontal Attributes snippet
3. Click on one of the SVG icon => the color previews in
Image > Dynamic Colors don't correspond to the SVG colors
4. Click on one of the color to open the palette
5. Choose one in the top row => the SVG disappears
6. Go in the "Custom" tab of the color palette => the current color is
not the correct one
7. Choose one of the grey shade at the top => the SVG disappears

[`_update_svg_colors`]: https://github.com/odoo/odoo/blob/64efa6b7dc7/addons/html_editor/controllers/main.py#L92
[`getValue`]: https://github.com/odoo/odoo/blob/64efa6b7dc7/addons/website/static/src/builder/plugins/dynamic_svg_option_plugin.js#L29
[`convertCSSColorToRgba`]: https://github.com/odoo/odoo/blob/64efa6b7dc7/addons/web/static/src/core/utils/colors.js#L218

When creating a unbuild order for non storable product, it will generate two stock.move.line going form Stock>Production.

** Steps to reproduce **

	- Create an untracked product (is_storable = False).
	- Create a BOM (the components don't matter).
	- Create a manufacturing order & produce it for the untracked product.
	- Unbuild the manufacturing order.
	- Manufacturing Order> Unbuilds>(Select the Unbuild (UB/...))>Product Moves
	- Two move lines are created from stock to production for the untracked product when only one should have been created.
	
** Cause of the issue **

Clicking on unbuild, will launch a call of the action_unbuild method. During this call, 
the moves of the unbuild for the final product of the MO  are created and confirmed here:
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/mrp/models/mrp_unbuild.py#L181-L182
During this confirmation process and since the product is not storable, (hence move should by pass reservation) therse moves will be assigned and the related move line created:
https://github.com/odoo/odoo/blob/e4d9ef3f39bd62a8db6854270b4cf6a35936b8d4/addons/stock/models/stock_move.py#L1759-L1762
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/stock/models/stock_move.py#L1581-L1583
However, in the rest of the action_unbuild call, since we don't expect the move to be assigned by the action_confirm we create and associate manually a second move line to our unbuild move:
https://github.com/odoo/odoo/blob/de2216ae52cee40d0851b4b8c0b71cb7e1d5ec89/addons/mrp/models/mrp_unbuild.py#L196-L198

** Observation **

During this commit
https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-31912cb536cbf184f8f475ccdfb5e42c30796a3f0430eea35751519434a67ba8L156
An "if condition" was removed that allowed untracked product to skip the manual assignation ("consu" product are untracked), since they already been assigned during consume_move._action_confirm().
This fix reintroduce the condition, for all move with their quantity (1) updated.

Which resolve the issue for non stored product since their quantity is updated during _action_confirmation>_action_assign

(1) https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR325
opw-4830965

Forward-Port-Of: odoo/odoo#213305

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Enterprise: https://github.com/odoo/enterprise/pull/92951

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

Forward-Port-Of: odoo/odoo#224947
Forward-Port-Of: odoo/odoo#223852

### Steps to reproduce:

- Install stock_delivery
- Create and confirm a receipt for 2 products:
    - 1 x P1
    - 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking

#### Expected behavior:

The scheduled date of the picking is updated but not the one of the other move.

#### Current behavior:

The the move scheduled date is also updated.

### Cause of the issue:

Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901

### Note:

This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38

opw-5017423

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

Forward-Port-Of: odoo/odoo#225197
Forward-Port-Of: odoo/odoo#224986

#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp}

### Steps to reporduced:

- In the settings enable: Automatic Accounting
- Create 3 storable product:
	- COMP1, cost 1 $
	- COMP2, cost 2 $
	- KIT with a kit bom using COMP1 and COMP2, cost 3 $
- Modify the product category of all three products to:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
- Create and confirm a sale order with 2 lines:
    - 1 x KIT
    - 1 x COMP2
- Create and confirm the associated invoive
- Try to validate the delivery
#### > UserError: You are trying to reconcile some entries that are already reconciled.

### Cause of the issue:

Validating the delivery will create stock valuation layers related to the associated stock moves — one for COMP1 and two for COMP2 — and then attempt to validate the corresponding accounting entries: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_move.py#L283-L291

However, during this call, the SVLs are grouped by product_id: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L88-L93

As a result, the first time we enter the loop, the accounting entries related to COMP01 will not be reconciled by the
`_stock_account_anglo_saxon_reconcile_valuation` call. This is because we restrict this call using the product COMP01. Therefore, we will not find the invoice needed to reconcile the outgoing moves here: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/account_move.py#L217-L219 (This happens because the related line of the invoice actually refers to the kit product, as the AMLs were not exploded like the stock moves.)

Now, the issue is that, since the AMLs were not reconciled, they will be added to the pool of lines to be reconciled later: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L92-L100

However, the second time we enter the loop — for COMP02 — since COMP02 was sold by itself, there will be an account move line referring to this product on the invoice. The `_stock_account_anglo_saxon_reconcile_valuation` call, now restricted to COMP02, will therefore reconcile the AMLs for both COMP02 and COMP01 related to the kits (as it successfully finds the invoice to reconcile all outgoing moves). This is problematic because the AML related to COMP01 has now been reconciled, despite already having been added to the set of moves to be reconciled. This will raise an error during the second reconciliation attempt: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/account/models/account_move_line.py#L2379-L2380

### Fix:

In the case of kit products, the account move lines of the invoice refer to a different product than the stock valuation layers (because the stock move was exploded but not the AMLs). Therefore, it is important to refer to the kit product during the reconciliation process.

We achieve this by grouping the SVLs using the product of their associated SOL or POL. Unfortunately, we cannot rely on the product from the BoM related to the stock move of the SVL, as kits can be nested within one another. In such cases, the invoice related to the SO or the bill related to the PO would not refer to the intermediate kit we would found that way.

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

Forward-Port-Of: odoo/odoo#224956
Forward-Port-Of: odoo/odoo#221337

# Steps to reproduce:

- Configure an early discount payment term (e.g., 2/7 Net 30).
- Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the BE fiscal position).
- Create an invoice using the early discount payment term.
- On bank reconciliation, register the transaction taking into account the early payment discount (e.g., 98% of the invoice amount_total).

On the third line with account 657000, corresponding to the early discount payment, the analytic distribution model does not apply.

In contrast, when manually registering a payment for the invoice, the analytic is correctly applied.

When the bank reconciliation lines are created, _lines_check_apply_early_payment_discount gets its values for the early payment lines from _get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line, which does not check if there is an analytic distribution model.

enterprise pr: https://github.com/odoo/enterprise/pull/90641

opw-4868986



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

Forward-Port-Of: odoo/odoo#221785
Forward-Port-Of: odoo/odoo#217933

**Issue:**
- After https://github.com/odoo/odoo/commit/777cb220259e1c1529b960761a6f59ec6115038e we are not able to search for event/track/sponser when we have other language
selected except `en_US`.
- This is because of how `search_type` attribute is set in related templates.
- currently it gets translated as according to  website's language,
for e.g when website's language is `Spanish (AR) / Español (AR)`

'events' get translated to 'eventos' and
'track' get translated to 'sesión'
- hence the parameter for search get altered, failing the search.
https://github.com/odoo/odoo/blob/ac5ea3cbd075db650c8e538d59e24657a0f04bb9/addons/website/static/src/snippets/s_searchbar/000.js#L118-L121

**Step to reproduce:**
- Add another language except en_US, say ,spanish
- install website_event
- open events from website and switch language to spanish
- search for event

**Observation:**
- No search result

**Fix:**
- set the search_type attribute correctly, i.e using `t-valuef`

opw-4972519

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

Forward-Port-Of: odoo/odoo#226084
Forward-Port-Of: odoo/odoo#221877

Before this commit:
-------------------------
- The 'Print' button in the Purchase Order form always triggered the RFQ report,
  regardless of the order state.
- This caused confusion for users expecting the Purchase Order report when the
  order was already confirmed.

Steps to reproduce:
-------------------------
1. Install 'purhcase' module.
2. Confirm a purchase order (move it to the 'Purchase Order' state).
3. Click on 'Print' button .
4. Notice that the RFQ report is printed instead of the PO report.

Cause of the issue
-------------------------
- The print button was hardcoded to always prints the RFQ report—even for
  confirmed purchase orders.

After this commit:
-----------------------
- The system now prints the Purchase Order report when the order is confirmed.
- The Print button behavior dynamically changes based on the order state
- This improves user experience by ensuring the correct document is printed
  according to the current state of the order.

Task Id: 4905350

Forward-Port-Of: odoo/odoo#221148

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Community: https://github.com/odoo/odoo/pull/223852

opw-5009635

Forward-Port-Of: odoo/enterprise#93605
Forward-Port-Of: odoo/enterprise#92951

### [PERF] l10n_pe_edi: Avoid OOM during installation

### Description:

Installing `l10n_pe_edi` on large databases with many moves and move lines could cause out-of-memory (OOM) errors. This happens because several stored fields need to be computed at installation.

### Fix:

This fix adds the columns via SQL, preventing Odoo from computing and populating the field for all existing records. This reduces memory usage and avoids installation failures.
____
### [FIX] l10n_pe_edi: Fix error during post-init hook

### Description:

During installation, the `l10n_pe_edi` module's post-init hook attempts to update tax groups, setting the new `l10n_pe_edi_code` field. This can cause an error if a tax group doesn't exist and needs to be created, because the name field is missing in the list of values given to the `_load_records` function.

### Fix:

This fix filters the tax groups to only update existing ones. This prevents `_load_records` from trying to create new groups, which avoids the installation error.

___
### Reference:

opw-4982181

Forward-Port-Of: odoo/enterprise#91997

Steps to reproduce
===================
1. Insert any list view in the knowledge article.
2. Click on open view from the article.
3. Come back and click edit.
-> Traceback occurs

Technical
=============
When we open a view from an embedded view in the article, we add `orderBy` from the
action context to the action props if it exists. As the action prop is initialized
and assigned directly from `embeddedState.additionalViewProps` without copying, it
mutates the original object, changing the `data-embedded-props` attribute in the DOM
and marking the body of the article as unsaved from `StateManager.changeState`. The
action continues, and the action service commits those unsaved changes to the article.

Once it is saved and the action is executed, when we get back to the article and
click on edit, we check for `additionalViewProps` to be undefined/empty for all
other views except calendar. As the DOM already has saved data in attributes, we
get `orderBy` in `additionalViewProps`, and thus a manual error is thrown in the
`editView` function.

After this commit
===============
Clone `additionalViewProps` when preparing the view action props.

Task-4921282

Forward-Port-Of: odoo/enterprise#91113