Description of the issue/feature this PR addresses:
    
The Google Merchant Center feed builds the extra image URL list of each product, and must skip the `product.image` records holding a video, as their image is only a thumbnail of that video. It filters those out by accessing `image_128`, which is wrong on two counts:
    
- A video record does have an `image_128`: the thumbnail, fetched from the video URL or uploaded by the user. Video thumbnails were therefore listed in the feed as if they were product images.
- Binary fields are read and base64-encoded in full by default, so the binary content of every extra product image was loaded into memory just to evaluate a truthiness check. On a database with ~4261 products with images, rendering the feed exhausts the worker memory limit and raises an out-of-memory error.
    
Current behavior before PR:
    
`_get_extra_image_1920_urls()` keeps every extra image whose `image_128` is set, including video thumbnails, and forces the ORM to fetch and base64-encode the full content of every extra image attachment.
    
<img width="2038" height="1462" alt="image" src="https://github.com/user-attachments/assets/e3b375e5-ac17-4b5c-b0c3-59264d7e36f7"/>
    
Desired behavior after PR is merged:
    
The records are filtered on `video_url`, the field that actually flags a video, so videos are properly excluded and no image binary is read at all.

opw-6513194

Forward-Port-Of: odoo/odoo#286782

_(updates on July-17th and July-28th for points 2. and 3. in `hr_expense`)_

# Introduction
**1\.** A fix to `hr_org_chart` was initially proposed.
I think it is mergeable because it fixes the user-experience properly like expected in Odoo standard.

Other commits are suggested to `hr_expense`.
They were designed to allow more flexibility in the management of `hr_employee.company_id` (in multi-company context) and allow not to duplicate the `hr.employee` of each companies of the `res.users`.
**2\.** The [FIX] silences a multi-company access error when searching for Expense validators => it seems safe
**3\.** The [IMP] largely allow more flexibility for a "Expense: Team Approver" when creating expenses on behalf of its subordinates

# 1. in hr_org_chart [FIX]
Prevents multi-company error when recursively searching for ancestors.

<img width="1035" height="789" alt="image" src="https://github.com/user-attachments/assets/d5517f79-7efc-4223-ae77-0af8b25a3d1e" />

### Issue description

In a multi-company environment, when one of the `hr_employee.company_id` of a hierarchy is not in the allowed companies of a Manager's `res_users.company_ids`, this Manager can view `hr.employee` in the list view but cannot open their forms.

This happens when:
- `hr_org_chart` module is installed
- the Org Chart is displayed on the 1st page of the `hr.employee` form, like when the HR settings "Skills Management" is disabled (in `res.settings`) => thus the whole form becomes inaccessible from the manager

When a `hr.employee` form is opened, a multi-company access error is thrown to him, even if the `company_id` of the opened `hr.employee` is in the user's `res_users.company_ids`, because of the hierarchy's `company_id`.
It should be expected that the part of the Org Chart which is not allowed to be seen would just be hidden. 

### Steps to reproduce
Data setup:
- Employee "A" in company A
- Manager "M" in company A, manager of "Employee A"
- Manager of manager "MM" in company A, manager of "Manager M"
- And now, in company B (let's say a Holding), the "Director" is manager of "Manager MM"
- "Manager M" is only given access access to Company A
- the module "hr_org_chart" is installed

Actions:
- Login with Manager M
- Browse to Employees list and try and open the form of "Employee A" (up to tab _"Professional information"_, if it is not the 1st of the notebook)

### Proposed fix

This PR re-uses the already existing method `_check_employee` which contains all the logic to solve the issue. Maybe the call to this method was forgotten?
This PR simply call this method when finding an ancestor, in the controller of `hr_org_chart`. This fix is thus very limited to the call to the public method `hr_org_chart.get_org_chart()` made by the Org Chart widget.

### Desired behavior after PR is merged

The part of the Org Chart not allowed to be seen by "Manager M" is hidden.


# 2. hr_expense [FIX]

<img width="541" height="415" alt="image" src="https://github.com/user-attachments/assets/d594815b-2b77-4088-878b-9b192b64d6a3" />

### Issue description
As an employee, I click on the button "View Report" on my expense.
I get a multi-company access error, preventing me to view and edit my expense report.
This is because the manager of the department I belong is in a company I'm not allowed to see.

This can also happen just when opening my Expense (instead of Expense Report).

### Current behavior before this PR
The employee is blocked to continue editing its Expense or to submit it to a Report.

### Current behavior after this PR
The employee can edit and submit its Expense no matter the `company_id` of its hierarchy.
Technically: the `can_approve` field on the expense sheet uses a localized `.sudo()` method to bypass multi-company limits when searching if the current user is a validator.



# 3. hr_expense [IMP]

<img width="1028" height="549" alt="image" src="https://github.com/user-attachments/assets/1096c0d4-d025-46a9-8559-6bab5de71577" />

### Improvement summary
In multi-company environment, allow a "Expense: Team Approver" to create Expenses for its subordinates (`hr_expense.employee_id`) **no matter the `hr_employee.company_id` of its subordinates**.
The domain of `hr_expense.employee_id` keeps the security of `check_company=True` => thus the Manager only sees `hr.employee` having their `company_id` in the manager's allowed companies (`res_users.company_ids`).

### Current behavior before this PR
Context: a 8-companies environment where the `hr.employee` of each hierarchy chains are splitted in many different companies, like:
- top-level (admin board): 1 company
- middle management: approx. 2 companies
- down level: the other companies
The "down level" have `hr.employee` but no `res.users`. The "middle management" have `res.users` and must create the Expenses of their "down level" subordinates on their behalf.

Issue: as a manager, as per Odoo proposal, I need to have a `hr.employee` in the same company of my subordinates to be able to create Expense of their behalf.
However, this is very inconvenient because as a Manager, I can have employees in various companies. And my own manager it not in the same company than me, so the same issue applies recursively.

### Behavior after this PR is merged
The domain of the field `expense_id.employee_id` is more permissive. As a Manager, it allows me to select the Employee I manage in my active company, no matter if I have or not myself a `hr.employee` in this company.

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

Forward-Port-Of: odoo/odoo#286293
Forward-Port-Of: odoo/odoo#266261

There was a difference between the actual and expected NET.

**Causes**
- rules existed for both SOCSO Act 800 and EIS, but Act 800 seems to be the official name of the Employment Insurance System (source: https://www.perkeso.gov.my/images/dokumen/Rate_of_Contribution_ACT_800.pdf). Keep the ACT 800 one as its matches the expected amount.
- there was a double counting of the SOCSO employee contributions (4 and 800) , as `l10n_my_rule_socso_employee` (the sum of both) was added to the total deductions.

**Change**
Before: 3500/month wage results in a 3108 NET.
<img width="1181" height="533" alt="before" src="https://github.com/user-attachments/assets/cdf4420f-e2cf-4dc7-9488-6bde3f1f9961" />
After: 3500/month wage results in a 3090.85 NET:
	- 6.90 SOCSO Act 800 Employee
	- 6.90 SOCSO Act 800 Employer
	- 17.25 SOCSO Act 4 Employee
	- 60.35 SOCSO Act 4 Employer Which seems consistent with online sources (https://payroll.my/)
<img width="1181" height="425" alt="after" src="https://github.com/user-attachments/assets/7fb41186-dbb4-4d7a-ac9a-14fb56efc4bc" />

Other fix: while not affecting the calculation, 'SOCSO Employer Share' appeared as incorrect, the two rules SOCSO_800_EMPLR and SOCSO_4_EMPLR should have the same sign.

opw-5976362

Forward-Port-Of: odoo/enterprise#129688
Forward-Port-Of: odoo/enterprise#118138

Steps to reproduce:
===================
1. Go to the payment providers and set "Pay on Site" to disabled.
2. Go to Apps, clear the filter, look up "website_sale_collect" and upgrade it. This also happens on its own, as upgrading any custom module that depends on it upgrades it too.
3. Go back to the payment providers.

=> "Pay on Site" is enabled again, and published as well from 19.0 on. Customers are offered it at checkout and place orders that are never paid, without the merchant ever enabling anything.

Root cause:
===========
`data/payment_provider_data.xml` is loaded in update mode because it carries no `noupdate`, and it hardcodes the state of the provider:

    <field name="state">enabled</field>

So every upgrade of the module writes that value back over whatever the merchant configured. Every other provider ships its data with `noupdate="1"` and leaves the state alone, this module is the exception.

The file has been loaded this way since the module was added:

- [1] created the module with an updatable provider record.

Fix:
====
Load the file with `noupdate="1"`. The record is still created, enabled, when the module is installed, it is simply not written again on later upgrades. The flag is read from the file rather than from the `ir.model.data` row, so databases where the provider already exists are covered on their next upgrade, no data migration needed.

[1]: 087c48c4ed2e
opw-6528110

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

Forward-Port-Of: odoo/odoo#286913

Current behavior:
--
With an active automation rule (base_automation) whose action creates an activity (e.g. a "Time Off Approval" activity) on hr.leave creation, every newly created time off request has a duration of 0 days / 0 hours, regardless of the requested dates.

Expected behavior:
--
The leave duration is computed from the requested dates, unaffected by the presence of an activity-creating automation rule.

Steps to reproduce:
--
- Create an automation rule on hr.leave, trigger "On Creation & Update".
- Add an action that creates an activity (type "Time Off Approval").
- Create any time off request for an employee with a working schedule.
- The request shows a duration of "0 days" (or "0 hours").

Cause of the issue:
--
When an automation with a "Create Activity" action runs on leave creation, base_automation schedules the activity after the record is created. Creating the activity reads the leave record, forcing an early flush of its pending computes. At that point date_from/date_to are not yet settled, so the duration compute (number_of_days/number_of_hours) reads empty dates and stores (0, 0). As these are stored fields, they are marked done and never recompute.

Fix:
--
In create(), after the record is created and its dates are settled, recompute the duration explicitly so any zero stored by an early flush is overwritten with the correct value.

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

Forward-Port-Of: odoo/odoo#286749
Forward-Port-Of: odoo/odoo#284373

Steps to reproduce:
------------------------------------
1. Install Time off module
2. Create New Fully Flexible Employee
3. Click on the Time off smart button
4. Create time off for multiple days (eg. Mon - Friday)

Observation:
------------------------------------
Number of days still shows 1 Days.

Issue:
------------------------------------
Issue occurs because `work_time_per_day_mapped` returns one interval per day for
standard and flexible schedules in multi-day time off requests, so the interval
count correctly matches the number of leave days.
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/hr_holidays/models/hr_leave.py#L460-L461

However, for fully flexible schedules, it returns a single interval
containing the total hours across all days, causing the leave duration to
always be computed as 1 day regardless of the actual number of days requested.

Solution:
------------------------------------
For fully flexible employees, count the actual calendar days and subtract public
holidays when applicable.

opw-6060552

Forward-Port-Of: odoo/odoo#255826

TL;DR
When downloading a `.zplii` shipping label from the chatter on a Delivery Order
(using FedEx), the browser automatically adds .txt to the end of the filename,
saving it as `.zplii.txt`

Step to reproduce:
- install `delivery_fedex_rest` with demo
- open shipping method menu -> Fedex Us -> label format = `zplii` -> save
- create a SO, click on 'Add Shipping", 
- select fedex as shipping method -> get rate -> add -> confirm SO
- go to delivery and validate
- notice, in thread, a attachment with ZPLII extension appears
- download (.txt is appended to file)

Issue:
- `fedex_rest_send_shipping` post message with documents with extension as 
`fedex_rest_label_file_type` i.e. `ZPLII`
https://github.com/odoo/enterprise/blob/735490d7ba9bdc6d0df7a0bd07c0d4e36d1ed2d4/delivery_fedex_rest/models/delivery_fedex.py#L193-L195
- when the attachment is created for this document , it's mimetype is computed
to be `text/plain` from [guess_mimetype](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/tools/mimetypes.py#L192) method, as data is plain ASCII code
- moreover, when downloading, [_get_stream_from](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/addons/base/models/ir_binary.py#L89) tries to guess extension
using [get_extension](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/tools/mimetypes.py#L210) which return `None` as len('zplii') > 4, [see](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/tools/mimetypes.py#L221)
- finally, as we got `None`, and mimetype is `text/plain`, `.txt` is appended [here](https://github.com/odoo/odoo/blob/5de4a5f6caee09881e7e147062f9eab9f8916a61/odoo/addons/base/models/ir_binary.py#L149)

Fix:
- we use `zpl` as extension for file instead of `zplii` as there is not 
difference between them from printing perspective
- as length of 'zpl' is <=4 , `get_extension` will considered it as valid

opw-6410968

Forward-Port-Of: odoo/enterprise#126620

Steps to reproduce:
- A coupon program with a coupon assigned to a customer
- In the PoS, set that customer on the order
- Enter the coupon code, its reward line is added
- Remove the reward line
- Click the customer button

Issue:
The customer list does not open. The PoS crashes with "TypeError: Cannot read properties of undefined (reading 'id')" raised while rendering PartnerLine.

Cause:
`partnerId2CouponIds` maps a partner to the ids of its `loyalty.card` records. It is filled at boot and on every `loyalty.card` create, but nothing ever removes an id from it: the models only trigger a create event. Removing the reward line of a code activated coupon deletes that card from the local models (`_setValue` in the order summary), so its id stays in the map while the record is gone. `getLoyaltyCards` pushed `models["loyalty.card"].get(id)` unconditionally, hence an `undefined` entry in the list the PartnerLine template iterates over with `t-key="_loyaltyCard.id"`.

Fix:
Skip the ids whose record no longer exists. The partner keeps its remaining cards, and the path where no card was deleted is unchanged. The stale id is not pruned from the map: it is reached through the reactive store proxy, and mutating it there would notify subscribers in the middle of a render.

opw-6517564

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

Forward-Port-Of: odoo/odoo#287503
Forward-Port-Of: odoo/odoo#286971