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

Steps to reproduce:
1) Install `website_sale_slides`.
2) Create a course with enroll policy 'On payment' and publish it. 
3)  Add a content allow preview it and add a quiz
4) Go to website, click Share button and open the generated link in incognito. 
5) Login as a portal user, pass the quiz and click "Buy this course".

Issue:
- A traceback occurred:
`Cannot read properties of undefined (reading 'addToCart')`.

Cause:
- The method call `self.call('websiteSale', 'addToCart', ...)` relied on the deprecated `call` service, which was removed in commit https://github.com/odoo/odoo/commit/b8d0ab4275b24510161de9db793020f3489b0446.
- The service and method `call('websiteSale', 'addToCart'` is not valid and was not updated here : 
https://github.com/odoo/odoo/blob/35161ecf0dd3fde47db9b2166718339c2e30ac92/addons/website_sale_slides/static/src/js/slides_course_join.js#L29
- As a result, `addToCart` was no longer accessible and triggered a JS error.

Solution:
- Update the code to use the new service and method: `call('cart', 'add',`


opw-5045424

Description of the issue this PR addresses:

Issue 1:

Steps to Reproduce:

- Open the website.
- Create a mega menu.
- Enter edit mode.
- Change the mega menu template to “Cards”.
- Click on any option available in the mega menu.
- A link popover will open.
- Click the Edit link button in the popover.
- Click the Apply button to save the link.
- A traceback occurs.

The error occurs because the text-wrap class is applied to the link. When the
hasColor method is triggered, it checks whether a.nav-link has a text color
class. However, TEXT_CLASSES_REGEX incorrectly matches text-wrap as a color
class. As a result, the removeColor method attempts to remove it and triggers
_applyColor to remove the color, but in _applyColor method it does not find any
color to remove on selected text. As a result, the removeColor process enters an
infinite loop, which eventually leads to a traceback.

Solution:

Update TEXT_CLASSES_REGEX so that it only matches valid text color classes and
excludes formatting classes such as text-wrap, text-center, etc.

Issue 2:

This commit ensures that the remove format action is disabled when a button
(.btn element) has custom color or background color applied.

Because buttons include padding, there is no proper way to remove a background
color from a partially selected button, so the action must be ignored in this
case.

task-5062715


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

Forward-Port-Of: odoo/odoo#225477

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