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

The system crashes with an error when a user tries to create an invoice.

**Steps to produce:-**
- Install `Accounting` module and switch to `BE Company`.
- Go to `Settings > Users & Companies > Companies` and remove the country from the BE company.
- Create a new customer with:-
    - Country as `Belgium`. 
    - Tax ID as `DE123456788`.
- `Accounting > configuration > settings > enable Verify VAT Numbers`.
- Now try to make `invoice` with customer as previously created customer.

**Error:-**
`TypeError : argument of type 'bool' is not iterable`

**Root cause:-**
- At [1], the code attempts to access `company.country_id`, but since the country was manually removed from the company, it evaluates to null record, leading to the error.

**Solution:-**
- Add a safeguard to ensure `company.country_id` also exist before accessing `country_group_codes`.

[1] -https://github.com/odoo/odoo/blob/4c2330f3cc0d1a0046e28d351f894763aeea57d2/addons/base_vat/models/res_partner.py#L764

**sentry-6851141424**

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

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

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#224755
Forward-Port-Of: odoo/odoo#223689

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

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

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

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

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

**Steps to reproduce:**
1. Install `l10n_de_reports` module.
2. Configure a company with a valid SteuerNummer.
3. Post some vendor bills with `19% I` VAT.
4. Go to *Accounting → Reporting → Tax Report*.
5. Export the report to XML from gear icon.

**Observed behavior:**
- The generated XML contains amounts with a comma `,` as the decimal separator.
- Elster ignores values with commas, so amounts are missing from the submitted VAT return.

**Root cause:**
- The QWeb XML export replaced the decimal point `.` with a comma `,`.
- Elster launched a new tax return application (*einfachELSTERplus*), which enforces `.` as the decimal separator.

**Solution:**
- Stop replacing `.` with `,` when exporting values to XML.
- Keep amounts as floats with period separators, while still rounding or inverting values as required for specific Kz fields.

**ref:**
https://www.elster.de/eportal/helpGlobal?themaGlobal=osseust_import

opw-4935738

Forward-Port-Of: odoo/enterprise#94130
Forward-Port-Of: odoo/enterprise#93623

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

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

Issue:

* When a sign request was copied via a public share link, the process failed 
  with an `AccessError`.
* This happened because the computed field `cc_partner_ids` (partners in CC) was
  read as the *Public user*, who does not have read rights on `res.partner`.
* With recent core changes, many2many writes now enforce read access on linked
  records, making the error unavoidable.

Steps to reproduce:

1. Open the master on Runbot.
2. Upload a PDF to Sign.
3. Press the `Share` button.
4. Log out of the account.
5. Open the copied share link.
6. A traceback appears in the log with an access error on `res.partner`.

Fix:

* Compute the `cc_partner_ids` under `sudo()` in the copy.
* This ensures the system can read the CC partners with elevated rights and only
  passes their IDs (safe to use) to `message_subscribe`.

Impact:

* Public users can now open and copy sign requests from share links without
  triggering access errors.
* Preserves security: only the system uses `sudo()` for computing, while the
  actual subscription still writes the partner IDs as normal.

task- 4067945

---

```yml
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/odoo/community/odoo/http.py", line 2740, in __call__
    response = request._serve_db()
  File "/home/odoo/odoo/community/odoo/http.py", line 2281, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/odoo/community/odoo/http.py", line 2279, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/odoo/community/odoo/service/model.py", line 184, in retrying
    result = func()
  File "/home/odoo/odoo/community/odoo/http.py", line 2326, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo/community/odoo/http.py", line 2541, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo/community/odoo/addons/base/models/ir_http.py", line 357, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo/community/odoo/http.py", line 788, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo/enterprise/sign/controllers/main.py", line 498, in make_public_user
    new_sign_request = sign_request.with_user(sign_request.create_uid).with_context(no_sign_mail=True, sign_request=sign_request).copy({
  File "/home/odoo/odoo/enterprise/sign/models/sign_request.py", line 243, in copy
    new_request.message_subscribe(partner_ids=old_request.with_user(old_request.create_uid).cc_partner_ids.ids)
  File "/home/odoo/odoo/community/odoo/orm/fields_relational.py", line 45, in __get__
    return super().__get__(records, owner)
  File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1738, in __get__
    self.compute_value(record)
  File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1904, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/odoo/community/addons/mail/models/mail_thread.py", line 468, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/odoo/community/odoo/orm/models.py", line 4913, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/odoo/community/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/odoo/enterprise/sign/models/sign_request.py", line 157, in _compute_cc_partners
    sign_request.cc_partner_ids = sign_request.message_follower_ids.partner_id - sign_request.request_item_ids.partner_id
  File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1812, in __set__
    self.write(protected_records, value)
  File "/home/odoo/odoo/community/odoo/orm/fields_relational.py", line 727, in write
    self.write_batch([(records, value)])
  File "/home/odoo/odoo/community/odoo/orm/fields_relational.py", line 748, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/odoo/odoo/community/odoo/orm/fields_relational.py", line 1475, in write_real
    raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field sign.request.cc_partner_ids
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Public user (id=3) doesn't have 'read' access to:
- Contact (res.partner)

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
```

In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated.

To reproduce:
1- Create a product and add quantity on stock.
2- Uncheck `Conitnue Selling` in `Out-of-Stock`
3- Publish the product on the website
4- Create a gift card
5- Add the product to the cart using portal user
7- Using admin user, set the quantity to less than ordered quantity
8- Using portal user, proceed to payment, and use the gift card. Then checkout.
9- As you see, the order is validated

The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`.
However, when checking out with gift card, this method is not called.
To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0)

opw-4941658


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

Forward-Port-Of: odoo/odoo#222306

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
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/mrp/models/mrp_unbuild.py#L187-L188
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, since they already been assigned during consume_move._action_confirm().
This fix reintroduce the condition, for all move with their quantity updated.

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

Additional issue:
The same happen with by-products if they are non storable, the first move line is also created during the first confirmation,
but the manual creation of the second move line and the commit that erased the "if condition" are different since by-product are not in finished_moves:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be#diff-31912cb536cbf184f8f475ccdfb5e42c30796a3f0430eea35751519434a67ba8L202
opw-4830965

X-original-commit: https://github.com/odoo-dev/odoo/commit/b2cadeaa52a6209d2f95e6b9c0043a36477bf31e

Description of the issue/feature this PR addresses:
This pull request adds  `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not unlink) to users in the `account.group_account_invoice` group.

Current behavior before PR:
Only users with administrator access rights on the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners.
<img width="1236" height="673" alt="image" src="https://github.com/user-attachments/assets/92b42973-2b01-4019-8e23-5e3cbf5111a4" />


Desired behavior after PR is merged:
Users with invoicing rights can modify the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. This is needed to properly create the invoices with the perceptions / withholding that apply, for example in cases where by default all partners are set with perceptions, but some depending on their activity are not taxed. In that case, the user that created the partner needs to be able to modify the field by putting a 0% aliquot or deleting the perception line on the contact. 




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

**Steps to reproduce**
- Automatically approved attendances.
- Create an attendance and save it.
- Note the "Extra hours" displayed.
- From the form view, change the check in or check out and save it.
- Issue: "Extra hours" are 0. Expected: they should be the same as "Worked extra hours", as the user has not manually modified the field.

**Cause**
Issue since cc81bb59f87540cf4dd8da65510417d8023ef65b The problem is that a 0 value for `overtime_hours` was computed for the `NewId` record used during edition in the interface. This meant `validated_overtime_hours` was also set to this value https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L171 and sent on save, which meant the value was not further recomputed in `_update_overtime`.
https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L408

**Change**
We avoid a recomputation of `validated_overtime_hours` in the interface (which wasn't useful anyway, it was set to 0) to avoid it being interpreted as a manual change by the user.

opw-5003488

This commit fixes two bugs related to the "Sign in" in button of the registration form.

First bug:
------------
If there is more ordered seats than available seats, an error modal is displayed with a "Sign In" button. This button shouldn't be present. On click, a 500 error is triggered. Now, the button does not appeared on this modal.

Reproduce:
Check "Mandatory" for "Sign in/up at checkout" in the settings. In the event form, add a limit of 1 available seat and add two tickets with each one 1 seat. With a public user, on the website page of the event, click on "Register" to open the registration modal. In the tickets form, select the maximum number of registrations for each tickets. The error modal with the "Sign In" button should appear. Clicking on this button trigger the 500 error.

Second bug:
----------------
The "Sign in" button is displayed even if the tickets have no price. So the label of the button is wrong because public users are not redirected to the checkout. Now, the "Confirm Registration" button is displayed in this case.

Reproduce:
With the same settings as for the first bug, create an event without tickets. Order a registration with an public user. Click on the "Sign In" button of the attendee details form. The confirmation page appears instead of the sign in page.

task-4797022

This commit reverts [1], [2], [3], and [4]. (It actually results in
minimal changes since those commits were already removing parts of
each other.)

Issue before those commits:
1. Setup a auto-fifo category and two storable products (a component
   and a finished product)
2. Receive one compo at 10, then one at 25
3. Produce two MO with one finished product
4. Unbuild the second one

Error:
- For the component, we just use the value of the consumed
  components: IN 1 @ 25
- For the finished product, we process it as a classic out. Reminder,
  we are in FIFO: OUT 1 @ 10

As a result, thanks to the unbuild, we have created
- A over-valuation of the stock (+15)
- An outstanding balance of the "Cost of Production"

This is why [1] has been merged. However, it brought some other
issues, cf [2], [3] and [4]. Unfortunately, it still has some issues
- After the above use case, the difference between the debit and the
  credit of the stock valuation account is no longer the sum of the
  remaining values of the layers
- Adding some landed costs on MOs will lead to a traceback when
  undbuilding
- The over-valuation of the stock (that was already present before [1],
  cf above) is still present

Following some discussions with R&D and the product owners, we have
decided to start over from scratch, which means:
- Revert all commits
- Try another approach (if so, the new PR will be linked to the PR
  related with this commit)

[2], [3], and [4] are partially reverted: the tests can remain, as
they were only failing due to a sequence of changes.

[1] https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3
[2] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c
[3] https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47
[4] https://github.com/odoo/odoo/commit/fb30cde9a320c245cf1321c9dc2ea2e67a53d0a0

OPW-5036574

Forward-Port-Of: odoo/odoo#225728

Currently, an error occurs when user tries to select any measure in cohort view.

Steps to replicate:
- Install `sale_management` and `web_studio`.
- Open the Sales app and turn on studio mode.
- Under the Views tab, turn on cohort view.
- Under the Measures field, select any value and observe the error appearing in the terminal.

Error:
`ValueError: Invalid aggregate method 'None' for 'create_date:None'`

Cause:
- The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`.

- This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view.

Solution:
- Corrected the choices of Measure field to `measureFields`.

- Also added a condition to allow only those fields that have an aggregator
  (for some fields like `sequence` that dont have an aggregator).

- Also removed context field from arguments [2] in the rpc call as function doesnt need it [3]
  (This shows warning on runbot as well).

[1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30

[2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87

[3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805

sentry-6781792463

Forward-Port-Of: odoo/enterprise#91599

## Issue:
Creating multiple suggestions sequences for differents Workorder in Manufacturing Orders that are added aside BoM defined WorkOrder cause an issue with a Traceback error

## Cause:
In the method `add_check_in_chain()`, the `point.sequence` cause issue because the check can have multiple points
https://github.com/odoo/enterprise/blob/e85d11f9b3bf07a55e5365adac7370955a149566/mrp_workorder_plm/models/mrp_workorder.py#L58-L66
That the case because multiple quality checks sequences are created when the operation_id is False
That's unexpected because PLM isn't made to suggest WorkOrder additions and Suggestions to New WO, but only Suggestions to existing operations

So we avoid to create `quality.point` when there is no operation_id

## Information:
To get the Traceback, you need to install Quality_control because this module will copy the QC to the MO including the one with operation_id set to False

## Steps to reproduce:
Quality_control and plm need to be installed
- Enable Work Orders in Settings
- Create a Product with a BoM
- Create a MO for the Product
- Add an extra WO
- In the Shop Floor, Mark as Done the BoM's WO
- On the Extra WO, click Gear Icon > Update Instructions > Improvement Suggestion > Add a Step
- Insert a Title and Propose Change
- Duplicate the MO and redo the Shop Floor steps to get the Traceback

opw-4874108

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

When a payment token is set on a subscription, running the Post-process transactions cron for recurring invoices will trigger a traceback.

Steps to reproduce the error:
- Install ``sale_subscription`` and ``l10n_mx`` modules
- Set up Mexican company and switch to it.
- Set Demo payment provider for Mexican Company
- Create a user A > set the address on the partner of that user A> set payment token in  payment methods via portal >
- Create a new subscription > Add any Subscription product > Set Recurring Plan
  In Other Info Tab, Set Payment Token > Confirm
- Set the Next invoice date to Today > Set delivered quantity of product
- Run the cron ``Sale Subscription: generate recurring invoices and payments``
- Run the cron ``Payment: Post-process transactions``

Traceback:
``AttributeError: 'bool' object has no attribute 'get'``

https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/sale_subscription/models/sale_order.py#L1267-L1269
In the [commit](https://github.com/odoo/enterprise/commit/7c5fd63729c16fb6b9b69ae1e7fa4d9cda2f4733), ``_generate_and_send_invoices`` method is called with
``from_cron=automatic``, where ``automatic`` is set to ``True`` because
the transaction is created during the subscription invoicing cron,
However, ``from_cron`` should only be used when ``sending_data`` is set on the move,
and the ``sending_data`` is only assigned by the ``account.move.send.batch.wizard``.

https://github.com/odoo/odoo/blob/0b34d9dc072c73ed208e287140c97f72dc487b15/addons/account/models/account_move_send.py#L57-L58
Here, ``sending_data`` will be False.
So, it will lead to the above traceback.

sentry-6849994436