With Jordan Company setup:
- Set dummy values on the Jordan electronic invoicing settings
- Enable USD, set a rate and currency precision to 5
- Set the Product Price decimal accuracy to 5
- Make an invoice in USD adding a line as follows:
  - Price 0.13793
  - Qty 9
  - Discount 100%
  - Tax: 16%
- Confirm
- Send & Print, activate e-invoice (JoFotara (Jordan EDI))

Issue will raise:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
Template: account_edi_ubl_cii.ubl_20_MonetaryTotalType
Path: /t/t/cbc:TaxInclusiveAmount
Node: <ns0:TaxInclusiveAmount xmlns:ns0="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" t-att-currencyID="vals[\'currency\'].name" t-out="format_float(vals.get(\'tax_inclusive_amount\'), vals.get(\'currency_dp\'))"/>
```

This occurs because on high currency precision we may work with numbers that are represented in scientific notation (-2e-09) that when converted to string may keep the literal form unless using a specific format

opw-4739342

Forward-Port-Of: odoo/odoo#209624

Versions
--------
- 16.0+

Steps
-----
1. Have multiple companies;
2. create an eWallet program available to all companies;
3. set its email template to "Gift Card: Gift Card Information";
4. create & confirm an order containing the "Top-up eWallet" product;
5. switch to a different company;
6. create an new order for the same client.

Issue
-----
Access Error

Cause
-----
Commit eaa6f6c5a415f added the `_get_mail_author` method to ensure gift card emails always have an author. When using the gift card template for eWallets, this can cause an issue for 2 reasons:

1. When creating an eWallet via the top-up product, its `order_id` is the order that created the eWallet. This order may belong to a different company than the one it is getting used for.
2. The `send_reward_coupon_mail` method fetches its coupons by calling `_get_reward_coupons` on the order. This returns any applied eWallets, therefore calling `_send_creation_communication` whenever the eWallet gets used. The reason it returns applied eWallets as a "reward coupon" is because `_update_programs_and_rewards` creates `sale.order.coupon.points` records with 0 points when applying a `loyalty.card`, which then get assumed to be a reward, despite not granting any points: https://github.com/odoo/odoo/blob/9e22dbb7b6fb581d2f11bf0ec48b230047686050/addons/sale_loyalty/models/sale_order.py#L499-L504

Solution
--------
1. In the `_get_mail_author` yield to `super` if the order's company isn't in `self.env.companies`.
2. In the `_get_points_programs` and `_get_reward_coupons` methods, filter out `coupon_point_ids` that don't grant any points. (Alternatively, we could avoid creating `sale.order.coupon.points` records with 0 points, but this might be risky for stable.)


opw-4731588

Forward-Port-Of: odoo/odoo#209515
Forward-Port-Of: odoo/odoo#208637

### Steps to reproduce:
- Install "l10n_din5008"
- In Settings > Layout, select DIN5008 as the report and change the two possible colors
- Create a quotation, print it
- The address is colored

### Cause
This [commit](https://github.com/odoo/odoo/commit/92e4c3cb3bec0b3d5537a50fd441a22fa6509ed1) reduced the size of the address by replacing `div` with `span` which is applied `font-size: 0.8em;`. 
But also `color: $o-default-report-secondary-color;` ([see](https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/l10n_din5008/static/src/scss/report_din5008.scss#L47-L50)). 

### Solution
Don't use `span` in the CSS to select the text.
Instead we create a new class `colored_address` to apply the color and apply the same font size on the entire address block.
This way the addresses will always have the same font size and the color should only be applied where we want it to.


Before:
![image](https://github.com/user-attachments/assets/bff1bba2-14e0-49c7-9b99-052c9431d0a0)
After:
![image](https://github.com/user-attachments/assets/12dacd2e-08df-4fcf-bae1-02c9699742ef)

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4725169)
opw-4725169

Forward-Port-Of: odoo/odoo#209020

Similar to: https://github.com/odoo/odoo/pull/184830

We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.

https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/web/static/src/core/py_js/py_builtin.js#L77-L79

However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s

In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:

`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.

This commit handles:
- website/model_page.py:
-
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L13-L18


https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L47-L57

The enterprise commit (https://github.com/odoo/enterprise/pull/82564)
handles two other cases:

- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2

- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`

In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:

- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in et la the python server

- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)

- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`

- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
-- context_today()
-- relative_delta()
-- datetime

opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091

Forward-Port-Of: odoo/odoo#207601
Forward-Port-Of: odoo/odoo#204172

Before this commit, the test_automatic_invoice_token test would fail
  with the following traceback:
  
  FAIL: TestSubscriptionController.test_automatic_invoice_token
  Traceback (most recent call last):
    File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 157, in test_automatic_invoice_token
      subscription = self._portal_payment_controller_flow()
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 235, in _portal_payment_controller_flow
      self.assertEqual(subscription.invoice_ids.sorted('id').mapped('state'), ['posted'])
  AssertionError: Lists differ: ['posted', 'posted'] != ['posted']
  
  First list contains 1 additional elements.
  First extra element 1:
  'posted'
  
  - ['posted', 'posted']
  + ['posted']
  
  The issue was detected when the test was running on the last day of the
  month.
  
  When we were not on the last day of the month, in the controller /my/subscriptions/<int:order_id>/transaction
  invoice_to_pay was None because there was only once invoice already paid.
  As a result, amount_to_invoice was 0.0 in this code:
  amount_to_invoice = invoice_to_pay.amount_total if invoice_to_pay else order_sudo.amount_to_invoice
  a tx with an amount equal to 0 would be created in the controller and
  in payment_transaction.py, during the postprocess, a "partially paid tx" would be found as the amount would not match (2.3 and 0.0).
  
  We prefer to fix the test by making sure an amount is set in the parameters of the controller. It will make the flow more coherent and realistic.
  
  \# Explanation
  
  When /my/subscriptions/<int:order_id>/transaction was called the second
  time in the test, no amount kwarg was provided. As a result the
  following line would be called in the controller:
  
  amount_to_invoice = invoice_to_pay.amount_total if invoice_to_pay else order_sudo.amount_to_invoice
  
  invoice_to_pay is always None and therefore the amount_to_invoice is
  equal to order_sudo.amount_to_invoice
  
  When we look,at _compute_amount_to_invoice, we have:
  
  is_invoice_due = (
                  not order.last_invoice_date
                  or (order.next_invoice_date <= today and order.last_invoice_date <= today)
              )
              if not is_invoice_due:
                  line.amount_to_invoice = 0.0
                  continue
  
  We will compare when the code run on the 30th of march or on the 31th of
  march.
  
  \## 30th of March
  
  next invoice date is 2025-04-30
  start date is 2025-03-30
  last_invoice_date is 2025-03-30
  next_invoice_date <= today is False
  last_invoice_date <= today is True
  
  is_invoice_due = (
                  not order.last_invoice_date
                  or (order.next_invoice_date <= today and order.last_invoice_date <= today)
  )
  
  Therefore is_invoice_due is False and we enter the condition and set the amount_to_invoice equal to 0.0
  
  \## 31th of March
  
  next invoice date is 2025-04-30
  start date is 2025-03-31
  last_invoice_date is False
  next_invoice_date <= today is False (same)
  last_invoice_date <= today is False because last_invoice_date is not set
  
  Therefore, is_invoice_due is True and we set amount_to_invoice to the recurring total of the SO.
  
  The issue is occuring because next invoice date is 2025-04-30 in both situations !
  2025-03-30 + relativedelta(months=1) is equal to 2025-03-31 + relativedelta(months=1)
  
  In the definition of last_invoice_date, we compare the next invoice date - billing_period to today:
  
  last_date = order.next_invoice_date and order.plan_id.billing_period and order.next_invoice_date - order.plan_id.billing_period
  \# When we start the 30th of March:
  \# last_date = 30th of april - 1 month = 30th of march
  \# When we start the 31th of March:
  \# last_date keep the same value because the next_invoice_date is the
  same.
  
  start_date = order.start_date or fields.Date.today()
  if order.state == 'sale' and last_date and last_date >= start_date:
      order.last_invoice_date = last_date <-- 30th of March >= 30th of March (today when we start on the 30th
  else:
      order.last_invoice_date = False <-- 30th of March is not larger than 31th of March (today when we start on the 31th)
  
  runbot error: 162144

Forward-Port-Of: odoo/enterprise#84542

Steps to reproduce the bug:
- Create a quality point with the following settings:
    - Measure on: Operation
    - Picking Type: Manufacturing
    - Product Category: "All"

- Create a storable product “P1”:
    - Product Category: "All"
    - BoM: - components: - 1 unit of P1

- Create a manufacturing order to produce one unit of P1
- Confirm it

Problem:
The manufacturing order is confirmed, but the corresponding quality check is not created.

This issue occurs when a quality point is configured with "Measure on:
Operation". In that case, the quality check should be created for
manufacturing orders here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L49-L51

However, an empty record is passed for the product parameter.
As a result, the domain defined here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L19-L21

is evaluated with both product and category set to False, which
prevents the created quality point from being matched and thus no
quality check is created.

https://github.com/odoo/enterprise/blob/6ee3472937118e758399a9577251efad8c4c1195/quality_control/models/quality.py#L175-L177

opw-4762914

Forward-Port-Of: odoo/enterprise#85186
Forward-Port-Of: odoo/enterprise#84683

Similar to: https://github.com/odoo/odoo/pull/184830

We've recently introduced a new operator: “is within” in the domain 
selector, which can be used to find out whether a date is within a 
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.

https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79

However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s

In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:

`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via 
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.

The community commit (https://github.com/odoo/odoo/pull/204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18

https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50

This commit 
handles two other cases: 

- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2

- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`

In all three cases, the problem is the same: the problem is not only 
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:

- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server

- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)

- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`

- For the moment, the values we use are the same as those used by 
`is_within`, i.e.:
  - context_today()
  - relative_delta()
  - datetime
  - time


opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091

community: https://github.com/odoo/odoo/pull/204172

Forward-Port-Of: odoo/enterprise#84203
Forward-Port-Of: odoo/enterprise#82564