When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually.

This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks.

Steps to reproduce:
1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user
2. As a user without that approval right, post a vendor bill and register a payment
3. Add the payment to a batch payment
4. Reconcile a bank statement line with the batch payment
5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line)
   - Expected: the bill stays Posted.
   - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook.

opw-6121448

Forward-Port-Of: odoo/enterprise#115241

The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right column of the form loses all the field labels, making it very difficult to fill out the information to configure a payment terminal.

This commit fixes the issue by removing the `group` elements from the view, instead just using the `field` elements directly as is done in other payment terminal modules.

Before (Safaricom selected):
<img width="678" height="504" alt="image" src="https://github.com/user-attachments/assets/9c41643f-1a98-4e44-9493-f0e6e8161a50" />

Before (Viva selected):
<img width="674" height="371" alt="image" src="https://github.com/user-attachments/assets/409f5c7a-da13-4f90-8145-a1ed5d6bbf7f" />




After (Safaricom selected):
<img width="674" height="531" alt="image" src="https://github.com/user-attachments/assets/a3118563-39a3-4c41-a807-296e531abe58" />

After (Viva selected):
<img width="665" height="447" alt="image" src="https://github.com/user-attachments/assets/51140a28-1fca-4d94-a81e-d45e081024a2" />


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

Forward-Port-Of: odoo/odoo#261746

sale: add sale order specific hook to extend page values
------

Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values

sale_timesheet: hide 'View Timesheets' button for users without access
-------

Steps to Reproduce:
-----------------
   - Create a product with the invoice policy set to Based on Timesheets
   - Enable Project and Tasks on the order.
   - Create and confirm a sale order using a portal user.
   - Log timesheets on the related task.
   - Create an invoice from the sale order.
   - Log in as the portal user and open the invoice.
   - Click the 'View Timesheets' button.
    
 Issue:
-------------
   The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.

Root Cause:
------------
 The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
    
 Fix:
-----------
   We replaced the timesheet_count check with a check that verifies  whether the user actually has access to any of the related timesheets.
    
task-4745519

Forward-Port-Of: odoo/odoo#261681
Forward-Port-Of: odoo/odoo#209552

Some countries lile Estonia, Nederlands or France apply a rounding from
the tax report by adding a line to the end of the query results representing
the sum of the roundings on each line of the tax report.

When having a company with branches, the rounding is applying in each
closing move (one per company/branch) but the value is coming from the
aggregated report lines, this leads to wrong computation of the closing
entries.

Cause:

In `_generate_tax_closing_entries` we loop over each company, therefore
`_compute_tax_closing_entry` is called one time for each company, but it
uses the report options containing all companies

Fix:

Use options with only the current company in
`_compute_tax_closing_entry`

Steps:

- Install FR localisation
- Select FR company and create two branches
- Create, for last month:
  - 1 bill for parent company (100 with tax 20% G)
  - 1 invoice per branch (200 and 300 with tax 20% G)
- Create a tax return with opining date at the beginning of the current
  month
- Submit the last return and go to the created closing entries
-> See that closing entries are wrong

opw-5976359

Forward-Port-Of: odoo/enterprise#115116
Forward-Port-Of: odoo/enterprise#110652

[FIX] project_timesheet_holidays: Exclude archived employees from time-off 

# Description of the issue/feature this PR addresses:
## Steps to Reproduce:
1. Create a time off for Employee A (it should affect the timesheets).
2. Create a new public holiday (global time off) that overlaps with Employee A’s time off.
3. Archive Employee A.
4. Delete the public holiday created in step 2.
5. An error related to timesheet generation appears.

## Expected Behavior:
- The public holiday / global time off should be deleted without any error.

# Desired behavior after PR is merged:
## Fix (Implemented):
When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees.

## Alternative Fix (Not Implemented):
Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved.

 ## Version:
 This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0  but didn't directly test

## Task:

[5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038)

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

Forward-Port-Of: odoo/odoo#261412
Forward-Port-Of: odoo/odoo#244203

Steps to reproduce:
===================
1. Open the To-do app and pick any task.
2. In the description add text and an icon with a bg color.
`(you can add this: <i class="fa rounded rounded-circle fa-user
bg-o-color-1 fa-4x" contenteditable="false">​</i>)`
3. Select all and click "Remove format".

Result:
-> Traceback due to an infinite loop.

Cause:
======
Remove format calls `removeAllColor()`, which loops forever at:
https://github.com/odoo/odoo/blob/626bde21a25366d0bb29662bae2057c247a1638e/addons/html_editor/static/src/main/font/color_plugin.js#L194-L194

Why:
_applyColor doesn't remove the icon's background class, so
hasAnySelectedNodeColor keeps returning true and the removal loop
never terminates.
This happens because `font` is already the `<i>` element with the `fa`
class, using `querySelectorAll` on it won't include the element itself,
so the icon is never checked or updated.
https://github.com/odoo/odoo/blob/6cdc6f55886ea48e90f9023a6c6142bf072745b9/addons/html_editor/static/src/main/font/color_plugin.js#L290

Solution:
=========
Check if the font itself has the fa class before doing the
`querySelectorAll`, and include it in the nodes to check for color.

Test Impact:
============
Before this fix, a `<span>` containing an icon was wrapped in a `<font>`
when applying color, treating the icon as a normal span (without size)
instead of applying the color directly.
https://github.com/odoo/odoo/blob/8792c2d38eb0aadac8d778d83fd76f270404ecd5/addons/html_editor/static/src/main/font/color_plugin.js#L397

opw-5928627

Forward-Port-Of: odoo/odoo#261405
Forward-Port-Of: odoo/odoo#248449

When we add a byproduct followed by SN directly in the MO it will not have the its location as production.

Steps to reproduce:
-------------------
* Create product tracked by Serial number
* Create a Manufacturing order
* Add the Product tracked by serial number on the MO as byproduct
* Confirm the MO
* Go to shop floor
* Add the by-product quantity and create a new serial number.
* Close production and go back to the MO in manufacturing
* Open stock moves -> the by-product does not have "production" for origin

Observation:
-------------
When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM.

When adding the byproduct in shopfloor, it will create the quant:
https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171
Additionaly when creating the quant it will decide the source location depending if the product its a byproduct:
https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192
The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids
https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110

#### Additional notes:

The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false


opw-5974582

Forward-Port-Of: odoo/enterprise#110122

Issue:
---
Ewallet line is included in delivery pricing.

Steps to reproduce:
1- Create a delivery method `based on rules`.
2- In pricing set rules:
- price <= 99 => delivery price = 30
- price > 99 => delivery price = 50

3- Create a eWallet with balance = 200.
4- Create a SO add a line with product. Set the SOL unit amount to 100.
5- Click on `add a shipping`. Add the created delivery method.
6- As you see, the delivery amount is correctly calculated.
7- Now apply the eWallet using `reward` button.
8. Update the shipping cost.

The shipping cost is 30, which is not expected.

Cause:
---
In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount.
However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`.

Fix:
---
We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards.

opw-6124209

Forward-Port-Of: odoo/odoo#260134