[FIX] website: avoid page template to crash at preview removed

Steps to reproduce:
- On the website, click on "New" then "Page" to create a new page.
- On the blank page, click on "Use this template".
- Insert a file name (e.g. `rte_translator.xml`) and click on 'Create'.

-> If the last operation was fast enough a traceback of type `TypeError:
Cannot read properties of null (reading 'fonts')` can occur.
Note that to be able to reproduce the problem, a delay may have to be
added in the `onceAllImagesLoaded` method and the operations of file
name insertion and page creation have to be quite quick (you can for
example use the `rte_translator` test tour).

Since [this commit], it is possible to create new pages from templates.
The problem here is that the template preview is removed before the
`onMounted()` operation of the `AddPageTemplatePreview` component
finished. Due to it, the content document of the preview iframe is not
set and trying to search for its `fonts` leads to an error. This commit
fixes this issue by ensuring that the component has not been destroyed
before continuing its `onMounted()`  process.

[this commit]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7

Forward-Port-Of: odoo/odoo#179894

### Steps to reproduce:

- Enable multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Change your warehouse to manufacturing in 3 steps
- Create a storable product COMP with 10 units in stock
- Create a manufacturing order for a product Final product using COMP as components

#### > The forcast of the components indicates that they are not available

### Cause of the issue:

The location query of the `_get_forecast_availability_outgoing` was recently changed to:
https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/addons/stock/models/stock_move.py#L2253 This change was made for optimisation purposes because the forecast lines now take care of the precise locations here: https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/addons/stock/models/stock_move.py#L2255 However, this optimisation is not correct as the forecast the result of this query is used in order to determine if a move is incoming or outgoing here:
https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/addons/stock/report/stock_forecasted.py#L31-L44 and these domains only makes sense if the `wh_location_ids` are indeed all the locations of the warehouse and not these that are children of the "pre-prod" location.

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

Forward-Port-Of: odoo/odoo#179897
Forward-Port-Of: odoo/odoo#179850

**Steps to reproduce:**
	1- Install POS and POS restaurant
	2- Activate self ordering
	3- Create a self order from the mobile menu
	4- Create another order from the Shop POS

**Current behavior before PR:**
There is a conflict happening in order numbers between Self order and other orders where at some point we might have two orders with the same number. This is happening because when adding the order from Shop we get the sequence number from the JS side in Order class
https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/point_of_sale/static/src/app/store/models.js#L1383 but in case of self order. We get it from ir_sequence https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/pos_self_order/controllers/orders.py#L19 So we don't have a shared sequence between them.

**Desired behavior after PR is merged:**
We are now creating another sequence for self-order and as agreed with the PO we will have
'S' before the order number if the order is self-order

opw-3809595

Forward-Port-Of: odoo/odoo#179744
Forward-Port-Of: odoo/odoo#162119

Issue
----

When work orders are computed, the compute function may delete some of the previous work orders. However,
it doesn't take into account these deleted work orders when choosing whether to update or create a work order.
So it ends up issuing an update command after a delete command for the same order. This happens during splitting
and causes work orders to disappear.

Steps
-----

 - Open Manufacturing -> Create a storable product and a BoM for this product.
 - Create a product as part of the BoM.
 - For the latter product, create another BoM that is a kit.
 - Create an operation in the BoM of the kit.
 - Create a manufacturing order for the storable product (first created product).
 - Set a quantity larger than 1, say 10, and manually save the MO (without confirming it).
 - Split the MO into same quantity (e.g. 10), and after confirming the split the following traceback is triggered:

 `remaining_qty = initial_workorder_remaining_qty[index % workorders_len]
ZeroDivisionError: integer division or modulo by zero`

opw-3994583

Forward-Port-Of: odoo/odoo#179821
Forward-Port-Of: odoo/odoo#171493

Steps
---
* install `stock`, `sale_management`
* configure reception in 2 steps
  (*Setting > Multi-step routes* + *Configure Warehouse Routes*)
* make *Stock/Input* a return location
  (*Inventory* > *Configuration* > *Stock/Input* form)
* create an SO for 5 units of a storable product (say P)
* (put at least 5 of P available in stock)
* confirm it > go to the delivery > validate
* *Return* > from the wizard set *Stock/Input* as the return location
* validate the `Customers -> Input` receipt
* validate the `Input -> Stock` internal transfer
* => on the orignal SO the delivered quantity is now -5 instead of 0

Cause
---
When generating moves in a push rules, we copy the fields of the
generating move, including `to_refund`, so both moves affect the
delivered quantity.
But when we check if a return move should affect the delivered/received
qty on SO/POs, we only check the `usage` of the destination location;
so in the case of multi-step routes, moves further down the chain
will affect the qty twice or more, and we will have a negative
delivered quantity

Fix
---
Use a stricter check to determined which moves should affect SO
quantities

opw-4129497

Forward-Port-Of: odoo/odoo#178392

Steps to reproduce:
-----------------------------------------------------------------------------------------------------------
1. Install the Project.
2. Go to settings and select customer ratings.
3. Then go to any project edit the stage and select the template for the rating
 email template.
4. Then change the stage of any task. check the email and give a rating to your
 task.
5. Check the Discus app then you will see a notification and no space between the
 name of the task and the calendar icon. 

Issue:
-----------------------------------------------------------------------------------------------------------
- A missing space between the name of the task and the calendar icon. 

Cause:
-----------------------------------------------------------------------------------------------------------
- The task's name and the calendar icon are not separated.

Fix:
-----------------------------------------------------------------------------------------------------------
- After this commit there is a space between the name of the task and the
 calendar icon 

task-3681318

Forward-Port-Of: odoo/odoo#179669
Forward-Port-Of: odoo/odoo#151700

Steps to reproduce the issue:
=============================
- Switch to dark mode
- Go to any record with a chatter
- Open mail composer in log note
- Add a table
- Save
- Switch to light mode
- The table is still dark

Origin of the issue:
====================
Since in dark mode we add some styles to improve the display, those
styles are getting applied in convert_inline.

Solution:
=========
Skip the stylesheets for table that have color only for now since
skipping all styles can produce more issues.

We skip also the background-color and border color for light mode too
because they will not display the same in dark mode.

Before:
======
![before_light](https://github.com/user-attachments/assets/c566c92e-ace9-4fc0-a123-b91563ee85a7)

![before_dark](https://github.com/user-attachments/assets/f6addda2-81f3-4bae-b90c-0696f48056fc)

After:
=====
![after_light](https://github.com/user-attachments/assets/a2fd629b-6a71-4fa9-b03a-8f940198e9e0)
![after-dark](https://github.com/user-attachments/assets/402d58ec-60f0-4088-abd2-2bae21964ca7)




opw-4137267

Forward-Port-Of: odoo/odoo#178520

When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns
an error, a traceback will appear.

Steps to reproduce the error:
- Install ```l10n_ke_edi_oscu```
- Set up Kenya eTIMS Integration
- Run ```KE eTIMS: Fetch KRA notices from eTIMS``` cron

Traceback:
```
KeyError: 'noticeList'
  File "odoo/tools/safe_eval.py", line 391, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(909,)", line 1, in <module>
  File "home/odoo/src/enterprise/saas-17.4/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py", line 35, in _cron_l10n_ke_oscu_get_notices
    notice_map = {notice['noticeNo']: notice for notice in data['noticeList']}
ValueError: <class 'KeyError'>: "noticeList" while evaluating
'model._cron_l10n_ke_oscu_get_notices()'
  File "odoo/addons/base/models/ir_cron.py", line 562, in _callback
    self.env['ir.actions.server'].browse(server_action_id).run()
  File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
    res = super().run()
  File "odoo/addons/base/models/ir_actions.py", line 989, in run
    res = runner(run_self, eval_context=eval_context)
  File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
    res = super(ServerAction, self)._run_action_code_multi(eval_context)
  File "odoo/addons/base/models/ir_actions.py", line 821, in _run_action_code_multi
    safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self))  # nocopy allows to return 'action'
  File "odoo/tools/safe_eval.py", line 405, in safe_eval
    raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```

https://github.com/odoo/enterprise/blob/019a7cdd5a3071c0948656bdcacc95b63c2e8842/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py#L35 When eTIMS API returns an error, data will be empty,
So, it will lead to the above traceback.

sentry-5804573762, 5809459581

Forward-Port-Of: odoo/enterprise#69727

### Steps to reproduce:

- Enable packages in the inventory settings
- Create a storable product tracked by Lot and put 4 units in stock: - 2 Units for "LOT001" - 2 Units for "LOT002"
- Create and confirm a sale order for 2 units
- Go to the barcode app > Operations > Delivery orders > your Delivery Order
- Register "LOT002" manually
> One unit will be added to your delivery moves.
- Put in pack
> You can unroll the move to see that one move line was created for 1
unit with a package and 1 unit is still missing.
- Register a second unit of "LOT002" manually to put in an other pack
> The line is updated to 2 units instead of 1 so that the additional unit can not be packed in an other pack

### Expected behavior:

You should be able to pack units of the same lot in different packages.

### Cause of the issue:

To determine which line is going to be updated by our lot registration the `_findLine` method is called. This method look for each line in pageLines and when it finds a candidate move line it continues to find a better candidate. However, fully packed moves should not be considered as valid candidates.

opw-4068334

Forward-Port-Of: odoo/enterprise#69522
Forward-Port-Of: odoo/enterprise#68535

This commit adds an additional step when aggregating the values for
sending invoice CFDI, and ensures the final result to be within the
allowed maximum rounding error of `0.01`.

Purpose:

When creating an invoice with the following amounts:

- line 1: 505.0, tax_16
- line 2: 495.0, tax_16
- line 3: 475.0, tax_16
- set tax_16.price_include to True

The CFDI result of the invoice when generated using "round globally"
method on either normal or global sending will be rejected by the
mexican authorities.

This is caused by an inherent flaw of how Odoo calculates line amounts.
The `compute_all` method in taxes rounds all the lines in cfdi_values to
2 digits precision in the final result, resulting in a loss of precision
when calculating the total amounts.

The mexican authorities requires us to make sure that:

1. the sum of the base/tax amounts in the lines (Conceptos) matches the
   total
2. the rounding of the total base and tax amount to be within 0.01
   rounding error

In the provided example, in Odoo, we will generate a total of 1271.54
base amount and 203.46 tax amount. This is not acceptable by the mexican
government because 1271.54 * 0.16 equals 203.4464, which when compared
with our result of the tax amount exceeds the maximum allowed rounding
error.

To fix this, we have to sacrifice our correctness and generate amounts
that will have disrepancies whenever we need it (for global rounding
method).

We will now re-calculate the base and tax amounts in `cfdi_values` based
on the total amount and generate new amounts with 6 digits precision,
and apply that on each line of Conceptos.

The 2 digit rounding precision limit on `Importe` and `ValorUnitario` 
XML will be changed to 6 digits to make sure we pass the first
requirement, as the mexican authorities will also calculate their total
and check if it matches our total. Due to this change, all of the test
files than contain this element needs to be udpated too.


task-id: 4071712

Forward-Port-Of: odoo/enterprise#69693
Forward-Port-Of: odoo/enterprise#68319