## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/446def9ad1 [REL] 19.3.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9af0bc5b97 [FIX] package: 19.3 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9a69c22cd2 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/ae520eaad2 [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/54af665a85 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/babbc57eee [FIX] chart: zoomable chart height issue with rjsmin minification [Task: 6306092](https://www.odoo.com/odoo/2328/tasks/6306092)
https://github.com/odoo/o-spreadsheet/commit/4fd1a3439e [FIX] package-lock: revert changes [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4dc969c14e [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)
https://github.com/odoo/o-spreadsheet/commit/be5939bcfb [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

Forward-Port-Of: odoo/enterprise#121735

Steps to reproduce:
===================
1. Add several delivery addresses & billing addresses
2. Add a product to the cart and go to checkout.
3. Select a specific delivery address and a different invoice address.
4. Pay and click "Skip" immediately on that page.
5. Open the resulting sales order.

=> The delivery address is reset to the company's first delivery child
   instead of the one selected during checkout.

Root cause:
===========
`partner_shipping_id` and `partner_invoice_id` are stored computed fields
(compute + store + readonly=False) that depend on `partner_id`. Any write
that includes `partner_id`, even writing the same value, retriggers the
compute and overwrites a manually selected address with the result of
`partner_id.address_get()`.

`_get_and_cache_current_cart` resurrects the customer's draft cart when it
is no longer referenced in the session and re-runs
`_update_address(partner, ['partner_id'])` on it to refresh the
pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`,
which clears the session cart key while the order is still draft, so the
next cart access takes that abandoned-cart branch and the redundant
`partner_id` write discards the selected delivery/invoice address.
Waiting a few seconds lets the order reach the 'sale' state first, so
the draft search no longer matches and the address is kept, which is why
the issue is timing dependent.

Fix:
====
In `_update_address`, when partner_id is written, keep the delivery and
invoice addresses already set on the cart if they still belong to the new
partner's company (same `commercial_partner_id`) by writing them in the same
`write()` so the recompute does not override them. Addresses that do not
belong to the new partner are still recomputed to the partner's defaults.

opw-6267188

Forward-Port-Of: odoo/odoo#270300

Problem:
Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns.

Cause:
Portal users are restricted to their own res.users record. Reading create_uid and last_edition_uid of internal users raises an AccessError. This was not raised in 19.0.
Specifically, the `many2one_avatar_user` field widget defines `write_date` in `relatedFields`, which forces the RPC to read the `write_date` field of the target user. Since portal users cannot read other users' records, it raises an AccessError.

Solution:
Only include `write_date` in the field widget's `relatedFields` if the current user is an internal user. For portal users, `relatedFields` will be empty, avoiding the AccessError.

Steps to reproduce:
1. Create a Knowledge article.
2. Add an "Item list" element.
3. Add some items to the list.
4. Share the article with a portal user.
5. Open the article as the portal user.
6. Observe that only the list header is visible and the items are not displayed.

opw-6199714

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

Forward-Port-Of: odoo/odoo#269479

### Description of the issue/feature this PR addresses:

The stock move value was inline-editable in the moves list, which is
misleading. Editing it directly behaves inconsistently across cost
methods: for FIFO products the edit updates the remaining value, but
for AVCO products there is no mechanism to propagate it, so the change
has no effect. The direct edit also bypasses the audited revaluation
channel, the Adjust Valuation wizard (product.value), which records the
user, date and justification.

Disable direct modification by marking the field read-only by default,
so manual revaluation always goes through Adjust Valuation. Internal
valuation writes are unaffected.

### Current behavior before PR:

The value field is editable in the stock move list view.

<img width="1890" height="460" alt="image" src="https://github.com/user-attachments/assets/8ddc6495-4beb-4481-bdbf-2a44b70f3784" />

### Desired behavior after PR is merged:

The value field should not be editable. Users should use the Adjust Valuation wizard to ensure the operation is auditable.

@qrtl QT6826

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

Forward-Port-Of: odoo/odoo#267360

## Issue
When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Open the Timesheets systray
3. Click *Reset* and set a description, a project and/or a task, then close the systray
4. Open the systray again
5. **The description/project/task set in step 3 do(es) not appear anymore.**

## Cause
Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`:

https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174

## Fix
After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore.

opw-6284016

When a "Products" snippet is dropped above the variant selector on a product page, selecting a variant displays one of the snippet's products instead of the chosen variant (its image/price take over the page).

Steps to reproduce
===================
1. Create a product with 2+ variants and publish it.
2. Edit the product page, drag any block above the variant selector and add the "Products" dynamic snippet, then save.
3. Select a variant. => The page shows the snippet's first product instead of the variant.

Root cause
==========
`ProductPage._getCombinationInfo` reads the product ids from `parent.querySelector('button[name="add_to_cart"]')`, with `parent` being the whole `.js_product`. `querySelector` returns the first match in DOM order, and the dynamic "Products" snippet's cards reuse the same `button[name="add_to_cart"]` markup with their own product ids. When the snippet sits above the variants, its button comes first, so `/website_sale/get_combination_info` is called with the snippet product's ids and the page is updated with that product's data.

The interaction was introduced in saas-19.1 (See [1]) and the lookup switched from the unique `#add_to_cart` id to the by-name selector in (See [2]), which is what started matching the snippet's cards.

Fix
===
Pick the first `add_to_cart` button that is not inside a product card (`.oe_product_cart`), i.e. the main product's button.

[1]: https://github.com/odoo/odoo/commit/4682748e6e3c#diff-7e1a99da9e95d0c4df79ee4d7aa718e46bcb8b7f1ed78cde58782e075c833cd1R326
[2]: https://github.com/odoo/odoo/commit/1c732cf75a4a4faa960d6a98f08ae9dbe99b2b69#diff-7e1a99da9e95d0c4df79ee4d7aa718e46bcb8b7f1ed78cde58782e075c833cd1R329

opw-6248285

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

Forward-Port-Of: odoo/odoo#268518

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

Forward-Port-Of: odoo/enterprise#121735

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/b76d689853 [REL] 19.2.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d398a74044 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/5235a56ab4 [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/7ac62df228 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/18b9293819 [FIX] chart: zoomable chart height issue with rjsmin minification [Task: 6306092](https://www.odoo.com/odoo/2328/tasks/6306092)
https://github.com/odoo/o-spreadsheet/commit/11fb7c91cf [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

### Issue:
When printing the Planning report (PDF) and grouping by a field other than Employee (e.g., Role, Project, or a Char/Selection field), the server crashes with a `TypeError` or `AttributeError`.

### Cause:
The `action_print_plannings` method hardcoded the assumption that the `group_by` key would always be a `resource.resource` recordset.
1. When the user grouped by other fields, it returned strings, booleans, or empty recordsets, causing crashes when the code blindly called `.id` and `.display_name`.
2. During the sorting phase, mixing `False` (for unassigned empty recordsets) with strings caused a `TypeError`.
3. For multi-day shifts, the method failed to extract the actual resource to calculate the shift splits if the grouping was not explicitly set to `resource_ids`.

### Fix:
- Implement safe attribute checks (`hasattr`) when extracting group IDs and display names.
- Ensure unassigned empty recordsets properly fall back to the "Undefined" string and empty strings during sorting to prevent TypeErrors.
- Universally fallback to extracting the resource directly from the slot (`slot.resource_ids[:1]`) for multi-day time splitting when grouped by non-resource fields.
- Add a unit test to ensure stability when grouping by `role_id` with multi-day shifts.

Task: 6244057

### Issue:
On invoices in SA and AE, the invoice title was always rendered in English even when the customer's language is Arabic

### Cause:
In 19.2, the report view `report_invoice_document` was refactored to require `t-set` declarations before `t-call`
In 19.1, `o` was reassigned early with the customer language via `t-value="o.with_context(lang=lang)"`, so all subsequent calls on `o` inherited the correct language
https://github.com/odoo/odoo/blob/3d2d8cc498a56faac31e95fb854a94e4011d812d/addons/account/views/report_invoice.xml#L4-L6

After the refactor, `o` no longer carries the customer language context at the point where `l10n_gcc_settings` is evaluated `_l10n_gcc_get_invoice_title()` was therefore called with the connected user's language instead of the customer's

### Steps to reproduce:
- Install `l10n_sa` or `l10n_ae` and switch to the corresponding company
- Create and confirm an Invoice (any data)
- Set the customer language to Arabic
- Print the Invoice

Before the fix, the invoice title is displayed in English

opw-6333472

Issue:
---
Not having at least one variant created for a product template with
dynamic attributes can cause issues as it's expected a product template
to have at least one variant.

To reproduce:
1- Create a dynamic attribute with values.
2- Create a product and without saving:
 - Enable track inventory.
 - Add the dynamic attributes and values.

3- Save the product.
4- Click on forecasted quantity smart button:
 - There is a traceback.

5- Click on Replenish:
 - Unexpected behavior.

6- Click on `Product On Hand Quantity`:
 - No product will be shown if you try to add quantity.

Cause:
---
This is caused because there is no variant created. In the steps,
if you save the template once before adding dynamic attributes, a
single variant will be created which allows it to work without issue.

Fix:
---
we can fix the TB by hiding the forecasted qty smart button,
when there is no variant.

However, there will be still issue with `Replenish` flow, which
requires a variant. We could do the prevent the issue by ensuring
there is at least one variant.

opw-6260253

Forward-Port-Of: odoo/odoo#272614
Forward-Port-Of: odoo/odoo#268879

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d6cb26450f [REL] 19.1.25 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c82e76cc60 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/bd4f6fb56a [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/357cb2273b [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/9cb37b2cd5 [FIX] chart: zoomable chart height issue with rjsmin minification [Task: 6306092](https://www.odoo.com/odoo/2328/tasks/6306092)
https://github.com/odoo/o-spreadsheet/commit/65527a70a3 [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly sets `tax_ids` from the product, and the computed `tax_ids_after_fiscal_position` displays the mapped taxes in the UI. However, because `tax_ids` is readonly, the web client does not include it in the save payload. As a result, the taxes are silently dropped on save and `tax_ids_after_fiscal_position` recomputes to empty.

Steps to reproduce:
1. Create and pay a POS order with a product that has taxes
2. Go to the backend (Point of Sale > Orders) and open that order
3. Initiate a return for the order
4. In the return order, add a new product (exchange scenario)
5. Observe that taxes are correctly shown on the new line
6. Click Save
7. The taxes disappear from the order line

The fix adds `force_save="1"` to the `tax_ids` field in both the list and form views of `pos.order.line`, consistent with how `price_subtotal` and `price_subtotal_incl` are already handled in the same views.


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

Forward-Port-Of: odoo/odoo#261672
Forward-Port-Of: odoo/odoo#253680

In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid in previous splits. Functionally, the cashier can keep splitting and paying the same line again and again because the parent draft order is not updated consistently in that path.

Steps to reproduce:
-------------------
* Enable POS Restaurant with l10n_de Fiskaly
* Create a table order (e.g. 3 meals + 3 drinks)
* Open Split Bill, move 1 meal + 1 drink, and pay
* From Orders tab, open the remaining parent order and repeat split + pay
* Reopen the parent order from Orders tab

> Observation:
The parent order still contains quantities that were already split/paid, so the same items can be paid multiple times from the Orders tab.

Why the fix:
------------
The Fiskaly `syncAllOrders` override diverged from core sync behavior in the split flow: it ignored explicit `options.orders` and did not await transaction creation for inactive transactions. In the split-bill path this could skip or desynchronize parent-order updates, leaving stale quantities on the parent order.
The fix restores expected sync semantics by honoring `options.orders` and awaiting transaction creation before deciding sync eligibility.

opw-6175880

Forward-Port-Of: odoo/enterprise#117206

The previous memory profiler was causing a lot of performance issues.
This is because tracemalloc tracks the allocations that happens at the
python interpreter level by attaching to the cpython allocators. This
first meant each allocation that happens through python has to go
through a callstack while holding the GIL and preventing the thread and
other threads from operating. This callstack does multiple things,
first is walking the allocation back from the current frame up until
the specified frame depth at the start of collection. The other is
updating the internal object that keeps track of the allocations and
what cause them up until now which degrades the performance even more
when the allocator keeps running for a long time. Increasing the frame
depth also means the partitioning becomes even more fragmented in the
internal object and leads to higher memory usage. This in turns means
lower performance as well. The issue becomes more evident when the
overhead of tracemalloc blocks any execution even turning it off
because the gil cannot be released until the full allocation execution
happens.

Currently this would happen on long enough requests or a high enough
depth.

Two PRs were made to try to address this issue.

1- https://github.com/odoo/odoo/pull/251950 : This PR tries the
solution of having a lower frame depth but matching the frames based on
a window of frames so that we can reconstruct an approximation of the
flamegraph, for example: matching window of 2 frames
1 - > 2 - > 3 - > 4
2 - > 3 - > 4 - > 5
would mean that we would match frames 2 and 3 in both stack traces and
append the first frame to the second callstack which would look like
1 - > 2 - > 3 - > 4 - > 5
Neverthless this was deemed to have too big of an assumption in the
building heuristic.

2- https://github.com/odoo/odoo/pull/253120: This PR was supposed to be
introducing memray as a profiler. Memray is the best tool for this
usecase. First because it attaches on the native system allocation
calls, and uses a file to append to on allocations. This solves both of
the issues that we had in the beginning but the issue with memray is
that it's an external tool that was deemed unnecessary to add.

The final solution is this PR:
The PR assumes a heuristic that in worker mode, a single worker handles
one thread which mean that the process memory can be fully attributed
to the request. The heuristic is also based that on a high enough
sampling rate, the delta can be fully attributed to the current frame.
This is a close enough approximation to know where to look but not what
is the actual memory usage by line.

Forward-Port-Of: odoo/odoo#253604

## Description of the issue/feature this PR addresses:
Setup plus video
1. Go to settings, enable "Automatic Valuation" and "Storeable Locations".
2. Navigate to Product Categories.
3. Create a new product category with the costing method Standard Price and the inventory valuation Automatic.
4. Navigate to Products, click into any product.
5. Add the new product category to this product under General Information.
6. Add any tax in the purchase tax field.
7. In the Accounting tab of the product, add any account to the Price Difference Account field.

https://drive.google.com/file/d/1i2DHEt0g9G5Edad_QB3QaFkOT49cbMAZ/view?usp=sharing

Instructions to reproduce error
1. Navigate to Purchase.
2. Add a customer, then add the configured product.
3. Add a tax to the line. Ensure that the tax and price_unit are nonzero.
4. Confirm the order.
5. Receive the product.
6. Create the bill.
7. Edit the tax on the vendor bill, then save the changes. Notice that the changes are kept.
8. Select Confirm. Notice that the changes to the tax line are not kept, and that the COGS lines appeared (with taxes applied to them).
9. Reset the bill to draft.
10. Click into the configured product and remove the product category.
11. Repeat steps 7-8 . No COGS lines, and the tax line is the manually set value.

## Current behavior before PR:
COGS lines with taxes have no net effect on any tax lines as they cancel each other out. However, their creation triggers the recalculation of all tax lines, undoing any manual adjustments to tax lines.

## Desired behavior after PR is merged:

This commit ensures that COGS lines are not considered base tax lines, so that their creation does not trigger the recalculation of other base tax lines.

opw-5387248


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

Forward-Port-Of: odoo/odoo#271262
Forward-Port-Of: odoo/odoo#262442

# How to reproduce
- Create a new Receipt
- Save
- Delete the new Receipt

# The issue
A traceback is shown :
`TypeError: Cannot read properties of undefined (reading 'label')`

# Cause
This is caused by the custom status bar for pickings `StockPickingLockedStatusBarField`. In its template, we replace the display of the current label : https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L20-L23 https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L4-L9

The issue is that the base implementation of the current label properly handles the case were no item is currently selected:
https://github.com/odoo/odoo/blob/7630f8fe2d5198b7a1ed538241795dc26a497fa0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L298-L300

But the picking implementation does not :
https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.js#L12-L14

And it seems that the template is quickly rendered without any selected item before deletion.

opw-6345192

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#272874
Forward-Port-Of: odoo/odoo#269456

The full composer builds default_partner_ids by doing recipient.persona.id over allRecipients. When a recipient is not linked to a partner, the chatter input inserts it with persona: false here:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/static/src/core/web/recipients_input.js#L151

false.id is undefined, so the wizard gets a bad id and clicking the recipient tag crashes with `Invalid ids list: false`.

The persona is false because /mail/partner/from_email returns no partner for unresolved emails when the user does not have base.group_partner_manager. That matches the gate _prepare_post_data already uses for the simple post flow:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/controllers/thread.py#L153,L155

The full composer just was not handling that case.

Filter out persona-less recipients from default_partner_ids so the wizard only sees real partner ids. The full composer now drops them the same way the simple post path already does.

Steps to reproduce:
1. As Administrator, create a user with the Sales group only (no Contact Creation).
2. Log in as that user.
3. Open a CRM lead whose Email is set but Customer is empty.
4. Click Send message.
5. Click the expand icon to open the full composer.
6. Click the recipient tag in the To field.

=> Recipient shows as Unnamed and clicking it raises an RPC error.

Ticket [link](https://www.odoo.com/odoo/project.task/5974081)
opw-5974081


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

Forward-Port-Of: odoo/odoo#251780

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c80dc2e26b [REL] 18.3.53 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a075f2eeae [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/7fd938ed02 [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/f706fda1b0 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/d8da52b51c [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#121886
Forward-Port-Of: odoo/enterprise#117879

Issue Before This Commit:
-------------------------------------------
Opening the Master Production Schedule (MPS) view caused the page to crash, preventing users from accessing the feature.

Steps to Reproduce:
--------------------------------------
1. Install the mrp_mps module.
2. Go to Manufacturing -> Planning -> Master Production Schedule.
3. Observe that the page crashes with the following error: Element '<xpath expr="//Dropdown/t[@t-set-slot='content']/t[node()]" position="before"> <GroupMenu items="this.env.model.data.groups[0]"/> </xpath>' cannot be located in element tree

Cause of the issue:
----------------------------
The XPath override was targeting the `Dropdown` component. After the component was renamed to `SearchBarDropdown` in this [PR](https://github.com/odoo/odoo/pull/269592), the XPath no longer matched, causing the view inheritance to fail and the MPS page to crash.

After This Commit:
------------------------------------
Update the XPath to target `SearchBarDropdown` instead of `Dropdown`, restoring the view inheritance and preventing the crash when opening the Master Production Schedule.

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121837
Forward-Port-Of: odoo/enterprise#120967

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/ad313f6500 [REL] 18.0.72 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d1524238a3 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/f164e6b3a0 [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/dc7a2b1c99 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/9027b97d4a [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)
https://github.com/odoo/o-spreadsheet/commit/855ec0dadf [FIX] package-lock: re-run npm install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4af8d893d8 [FIX] rolldown: Fix cjs file extension [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/48f0cd7b8a [FIX] package-lock: update with removing node_modules [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/08175c6cb8 [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

**Steps to Reproduce:**
- Install the Accounting and Contacts modules.
- Enable Quick Encoding for Customer Invoices and Vendor Bills in the company 
  settings.
- Create a new customer: Assign a salesperson.
- Ensure:
  - The salesperson is not a login user.
  - The customer language, salesperson's language, and Login user's language 
    are different. Example:
     - Customer language: English
     - Salesperson language: French
     - Login user language: French
- Create a customer invoice using the Upload Document functionality.
- Select the customer created above.
- Use Quick Edit mode and enter an amount and Click Confirm.

**Issue:**
- When the invoice notification is rendered in a language different from the one
  used during the write operation, the notification rendering flow calls 
  _notify_by_email_prepare_rendering_context().
- During rendering, the code executes:
```
self.tax_totals.get('total_amount_currency', 0)
```
- Since tax_totals is protected, the ORM returns False instead of the expected
  dictionary, leading to:
```
AttributeError: 'bool' object has no attribute 'get'
```

**Root Cause:**
- This issue occurs in Quick Edit mode because tax_totals is [not read-only](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/views/account_move_views.xml#L1359) 
  in Quick Edit mode and is included in [the values](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/web/static/src/model/relational_model/record.js#L708) sent by the web client during write().
- During create()/write(), _get_protected_vals() marks tax_totals as protected.
- Since tax_totals is a [@api.depends_context('lang')](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L975) computed field, it 
  maintains a separate cache per language. [During write()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3955), the [field becomes 
  protected](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3863) by [env.protecting()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/odoo/orm/fields.py#L1738). While the protection is still active, the mail 
  notification flow renders the email using the recipient's language. If the 
  corresponding language-specific cache entry for tax_totals is not available, 
  the ORM cannot recompute the protected field and returns False instead 
  of the expected dictionary.

- The rendering code assumes tax_totals is always a dictionary and directly 
  calls  .get(), leading to the crash.

**Solution:**
- Exclude tax_totals from _get_protected_vals().
- tax_totals is already handled explicitly after create()/write(), so protecting 
  it is unnecessary. This allows the field to be recomputed during notification 
  rendering when required.

**Result:**
- Invoice notifications render correctly in all languages.
- No RPC crash occurs when rendering notifications after Quick Edit.

**Runbot reproduction: [video](https://github.com/user-attachments/assets/5f045efb-37de-40aa-b135-1368b1601d61)**

**opw-6209647**

### Steps to reproduce:
- Download 'Sales' and 'Timesheets' apps
- Create a service product invoiced on delivered quantities with timesheet tracking
- Create and confirm a SO for quantity 1
- Log 20h on timesheets
- Invoice the SO
- Create a credit note for 11 hours => only 9 hours are invoiced
- Log 5h more on timesheets
- Back to the SO > create invoice again
> All the 25hrs are to invoiced, although 9 of them were invoiced before

### Cause of Issue:
When generating the new invoice, `_recompute_qty_to_invoice` calls `_get_delivered_quantity_by_analytic` which retrieves the analytic values for the SO line.

The values retrieved are later used to determine the delivered quantity, which is later assigned to be `line.qty_to_invoice` without taking into account the already invoiced hours. https://github.com/odoo/odoo/blob/7a6518e39d34575a3977e7c4a0053a45223e203c/addons/sale_timesheet/models/sale_order_line.py#L176-L186

### Fix:
Ensures that hours that have already been completely invoiced are deducted from the quantity to invoice.

opw-6253650

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Since 17.0, `webp` images can be uploaded at any resolution, whereas every other format is refused above IMAGE_MAX_RESOLUTION (50 Mpx) when the attachment is created on the server.

Root cause
===========
`ImageProcess` grouped webp together with empty sources and SVG and set `self.image = False`, returning before the `verify_resolution` check. As a result the resolution limit enforced for `png/jpeg/...` was never applied to `webp`.

Fix
===
Split `webp` out of the skip branch: it is still not processed as before, but its resolution is now read from the RIFF header with `get_webp_size()` and checked against `IMAGE_MAX_RESOLUTION`, so oversized webp images are refused on upload like any other format.

Steps to reproduce
===================
1. Edit any page with the website editor
2. Upload a `webp` image larger than 50 Mpx (e.g. 8000x8000)

=> The image is accepted, while a `png/jpeg` of the same size is refused

task-4134430

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