Versions
--------
- 17.0+

Steps
-----
1. Have a database with GeoIP enabled;
2. have a promotion program that gives a discount on a specific product;
3. use a VPN to browse /shop from California before 7:00 UTC;
4. add the product to your cart;
5. go to checkout;
6. pay for the order.

Issue
-----
Order cannot be confirmed due to incomplete payment.

Cause
-----
The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order.

Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order.

Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed.

Solution
--------
If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates.

For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone.

For website orders, if defined, use the eCommerce salesperson's time zone instead.

Also fix an issue where expired coupon lines weren't getting removed from the order.

opw-4765873
opw-4781346
opw-4939268

Forward-Port-Of: odoo/odoo#229749
Forward-Port-Of: odoo/odoo#222428

**Steps to reproduce:**
1. In Settings, enable "Work Orders".
2. Create a product with a BOM that has 2 operations: op1 and op2.
3. Create and confirm an MO for 1 unit.
4. Start op1 and change the Real Duration of op2.
5. Try to save.

**Issue:**
- Traceback : 
`'<' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause of the issue:**
Starting the first operation launches a call of the `button_start` method creating
a `resource.calendar.leaves` to set on the `leave_id` of this first operation:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_workorder.py#L630-L641

Then, setting the duration of the second operation from the form view of the MO
and saving triggers a call of the write of the MO containing the
`[Command.update(op_2.id, new_duration)]` as vals.This, in turn, calls 
`_plan_workorders`:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L939-L942
while the first operation has a set `leave_id` but the second do not

However, the `min` operator will be applied to both the set and the unset values,
comparing a `boolean` with a `datetime`:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L1581-L1588

**Solution:**
Only workorders with a `leave_id` (i.e., those planned in work-center schedule)
should be considered when computing MO `date_start` and `date_finished`.
Workorders without a `leave_id` are not yet scheduled and therefore should not influence MO start and end dates.

As both `date_start` and `date_finished` of a workorder are related to the `leave_id` record. As per `mrp_workorder._compute_dates`, these dates reflect the work-center scheduling (`leave_id.date_from` and `leave_id.date_to`).
https://github.com/odoo/odoo/blob/6a075fa3c090920499ccbd5fe673819da7e3f95e/addons/mrp/models/mrp_workorder.py#L250-L260
Therefore, when computing MO dates, it logically follows that only workorders with an assigned `leave_id` should be used. This avoids mixing unscheduled operations (`leave_id = False`) with scheduled ones, preventing invalid comparisons and ensuring accurate production timing.


**opw-5068080**

Forward-Port-Of: odoo/odoo#226436

This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer
First, before this PR, if the option to skip the receipt screen
was ticked, then the receipt would never print.
This was caused by the printing logic being implemented on
the receipt screen instead of on the pos itself.

steps to reproduce:
1. install l10n_it_pos
2. configure one pos
3. configure the IT printer
4. select to skip the receipt screen (print automatically)
5. open the pos
6. make a sale
=> no ticket printed and the chrome console shows a printer error

With this new verison the printing logic was moved to the pos
so that printing of fiscal receipts with the italian fiscal printer
works, even when receipt screen is skipped.

This put to light another potential bug related to how the `order` variable was treated.
Before this PR, the printReceipt logic in the module would not
pass the order to be printed.
This can become a problem upon context changes, where `pos.get_order()`
does not return the completed order, but a newly created one.
This can for example happen when skipping the receipt screen with
the option to "print automatically" (iface_print_auto).

After this PR, we keep order as an argument, so we always print
the last completed order and not a newly created one.

opw-4882480

Forward-Port-Of: odoo/enterprise#95985
Forward-Port-Of: odoo/enterprise#91412

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Forward-Port-Of: odoo/odoo#230081

### Steps to reproduce:
1. Install mrp + purchase
2. Create a new product (A)
   1. Add the Buy route on the product
   2. Add a vendor line on the Purchase tab
   3. Set the quantity on hands to 2000
3. Create a second product (B) with manufacturing route
4. Create a BoM for this product (B)
   1. Add the product (A) as the component with 1 quantity
   2. Create a new operation with a duration of 600:00
5. On the product B's page, click Replenish
   1. Put 10 quantities to replenish
   2. Select the manufacturing route and confirm
6. Go to the BoM and open the BoM overview
7. 'Impossible to plan. Please check the workcenter availabilities.'

https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715


### Before this commit:
When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed.

### After this commit:
If the quantity producible cannot be planned, we retry automatically with the requested quantity.

opw-5031724

Forward-Port-Of: odoo/odoo#229745
Forward-Port-Of: odoo/odoo#227433

The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized

### Steps to reproduce

1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body.

The sending of that email will fail with a `UnicodeEncodeError` error

### Cause

Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment.

While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process.

### Fix

Instead of attaching the raw bytes, we now:
* Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object.
* Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically.

opw-4655868

Forward-Port-Of: odoo/odoo#230384
Forward-Port-Of: odoo/odoo#223790