### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing CSS rules (Public View)**
   The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode.

### Fix

This PR fixes problems 2, 3 and 4 by:

* Removing the unused/irrelevant planning print styles
* Ensuring `web.assets_web_print` is loaded in portal
* Creating a new print bundle for the frontend view
* Hiding the knowledge header in the public view when printing (to improve layout)


The first issue is tackled in odoo/odoo#223434

opw-4816241

### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing Print Assets (Public View)**
   The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode.

### Fix

This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle.

The remaining issues are tackled in odoo/enterprise#92665

opw-4816241

**Problem:**
unbuilding a Manufactring order created through a subcontracting
process gives the wrong account move lines

**Steps to reproduce:**
- create a storable product (the comp) and set a cost
- create a storable product (the final product), set a cost
and set a vendor
- for the final product set the category as avco and automated
- for the final product create a bill of materials subcontracted
 and set the same vendor
- for the components add the comp for a quantity of 1
- create a Purchase order for the final product and the same vendor
and confirm
- validate the receipt
- From the receipt click on the valuation smart button and click on 
the book widget of the line of the final product
- notice how there is 3 journal items line including one 
crediting "stock interim (Received)"
- unarchive the operation type "subcontracting"
- open Manufacturing/Manufacturing Orders, delete the "to do" 
filter and search for a Manufacturing order with your final product
- unbuild it
- Open accounting/journal entries and select the journal entry for 
the unbuild

**Current behavior:**
There is only two account lines. 
There is no line balancing the "Stock Interim" line of the
manufacturing order.

**Cause of the issue:**
The override of _generate_valuation_lines_data in
mrp_subcontracted_account adds the stock interim line on the 
manufacturing order.
However when unbuilding, the qty is negative so we exit the function
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20

**fix**
Because subcontracted Manufacturing orders are not meant 
to be unbuilt, we prevent it

opw-4998137

**Issue**
When a sales tax is archived, it still shows up as a group when using "Group By → Customer Taxes" in the product list view.

**Steps to Reproduce**
1. Create a new sales tax.
2. Add the new tax onto a product.
3. Archive the sales tax.
4. Go to the product list view and group by Customer Taxes.
5. The archived tax is still displayed as a grouping.

Video for reference:
https://drive.google.com/file/d/1C-OA42UdjP19mPmvyjFnK7JY-kjCr9JL/view

**Root Cause**
Grouping on many2many fields (`taxes_id`) relies on raw SQL queries that fetch all related values, without considering the `active` flag of `account.tax`. As a result, archived taxes linked to products continue to appear as distinct groups.

**Fix**
Override `_read_group` to filter out inactive
taxes from the group-by results, while keeping the "No Tax" bucket
intact. This ensures that only active taxes are available for grouping

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

**Issue:**
Multiple errors occur when processing payroll for "Fully Flexible" employees
and overlapping leave scenarios:

1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation
   when sick leave overlaps with public holiday

**Steps to Reproduce:**
1. Go to the **Employees** app and create a new employee.
   * Set the working hours to **empty (fully flexible)**.
2. Go to **Contracts** and create a new contract.
   * Set the **Work Entry Source** to *Attendance*.
   * Save and make the contract **Running**.
3. Go to **Time Off** → **New**, and create a sick time off for the employee.
   * Example: from **25th to 29th**.
   * Approve the time off.
4. Go to **Configuration** → **Public Holidays**, and create a new public holiday.
   * Example: **27th**, which overlaps with the sick time off.
   * Work Entry Type = **Paid Time Off**.
5. Go to **Payroll** → **Work Entries**.
   * A **traceback** occurs.

**Root Causes:**
- In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types.

**Fix:**
- Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types

This resolves payroll blocking issue for deployments using the
Fully Flexible employee feature, where employees may have
overlapping leave types and no assigned working calendar.

Test : [PR](https://github.com/odoo/enterprise/pull/93902)

opw-4979974

### Steps to reproduce:
	- Install Time off apps
	- Create two consecutive allocations (e.g. one for 2025 and one for 2026)
	- Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan)
	- Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026)

### Cause:
When we are checking the leave duration after having a public holiday the  will return the attendance without
the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days.

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254

### Fix:
We check for public holidays in the interval we are fetching its attendance to avoid assuming it is an excess days in the leave

opw-5006119

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

Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740

The goal of this pr is to see for which company belongs each sale/purchase tax in a product when more than one company is selected.

This pr solves odoo task #4829985 and this issue https://github.com/odoo/odoo/issues/147673

Steps to reproduce:

1) Go to runbot odoo enterprise 18 instance and select companies "My Belgian Company" and "My Company (San Francisco)" taking position in "My Belgian Company".

2) Go to "Accounting / Customers / Products" and get into product with name "Bolt" and internal reference "CONS_89957". There is shown two taxes in "Sale Taxes" and "Purchase Taxes" fields but is not possible to distinguish for which company belongs each tax.

Current behavior:
It can not be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected.

Expected behavior:
It can be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected.

Task Adhoc side: 52262

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

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

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