### Steps to reproduce:
	- Create an accrual plan with the following rule: 
	— The employee has 20 days off in the first year. Total 20. 
	— The employee has 21 days off in the second year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 21 + 5 = 26 
	— The employee has 22 days off in the third year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 22 + 5 = 27 
	— The employee has 23 days off in the fourth year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 23 + 5 = 28
	- Create an accrual allocation with the created plan
	- Check future allocation data using 'Balance at the'
	- Notice the following behaviour: — until 31/12/2025 it CORRECTLY shows 20 days available.

		— from 01/01/2026 to 30/06/2026 it CORRECTLY shows 26 days (21 days for renewal and 5 days not used in 2025)
		— from 01/07/2026 it INCORRECTLY shows no days available.

		— from 01/01/2027 to 30/06/2027 it CORRECTLY shows 27 days (22 days for renewal and 5 days not used in 2026)
		— from 01/07/2027 it INCORRECTLY shows 5 days.

		— from 01/01/2028 to 30/06/2028 it CORRECTLY shows 28 days (23 days for renewal and 5 days not used in 2027)
		— from 01/07/2028 it INCORRECTLY shows no days available.

		— from 01/01/2029 it CORRECTLY shows 28 days again.
		— In the following years, after 6 months, one year shows 5 days and the next shows nothing.

### Cause:
The first cause here is that when we have validity for the carryover then we will have two calls in each year one at the start of the year and another at the expiration date of the carryover. So, when we add the days to the allocation we don't consider the second call in the condition and we only check if the allocation.actual_lastcall is equal to one of the start dates for each year

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L588

The second cause where each two years one of them shows the number of carryover days from the previous year, this is happening because when we remove the expiring days for the first year we set the number of days to 0

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L516-L517

And it will be 0 until we loop again and add the days to allocation

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L521-L522

and since this is happening after we already set the expiring days which in this year will be 0 we won't remove those expiring days from the year's allocation data

### Fix:
We add a condition to check if the actual_lastcall is either a date in the start of the allocation or one of the expiration dates for the carryover.

Also, before we set the value of the expiring_carryover_days we call _add_days_to_allocation to calculate on the correct number of days for the plan level we are checking.

opw-4606886

Steps to Reproduce:
- Ensure the `sale_timesheet` module is installed.
- Log in as a user with Timesheet Administrator permissions but without access to the Project module.
- Attempt to open the Timesheets list view results in an `AccessError` due to missing read rights on `project.task`.
- Create a task in a private project linked to a timesheet and open its form view results in an `AccessError` due to missing read rights on `project.project`.

Cause:
- When a user has Timesheet Administrator access but lacks project access, they can view all timesheets, including those linked to tasks with private privacy visibility. However, these users do not have read access to the private tasks themselves.
- The `_compute_commercial_partner` method reads `task_id.partner_id.commercial_partner_id` and `project_id.partner_id.commercial_partner_id`. When a user without read access to `project.task` or `project.project` tries to compute this field, an `AccessError` occurs because the code tries to access these related records without bypassing access rights.

Solution:
- Use `sudo()` on `task_id` and `project_id` when accessing their `partner_id` fields inside the compute method to bypass access rights checks, preventing ` AccessError` for users lacking read permissions.

task-4798066

Forward-Port-Of: odoo/odoo#210826

Steps to reproduce:
-------------------
1. Create a free product
2. Add it to self_order
3. Make a self order with only that product -> Free order

Sicne it's a free order, you will not be asked to pay, which is normal.
However, the issue is, no picking is created for that order!!

Why the issue?
--------------
For a non free self order, we create a picking for it by calling
`_process_saved_order` [1] with `draft` argument set to `True`, either
after paying using the online payment method [2], or after paying it
from the payment wizard [3]. However, since for free orders, we're not
asked at any point to pay, and hence, we're not calling
`_process_saved_order` with `draft=True` at any point, and as
consequence, we're also not calling `_create_order_picking`, no picking
will be created for it.

The fix
-------
After, marking the free order as 'paid', we manually call
`_process_saved_order(True)`. We only do it for the free orders, since
the flow is working as expected for non-free order.

[1]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/point_of_sale/models/pos_order.py#L153C19-L153C31
[2]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/pos_online_payment/models/payment_transaction.py#L64
[3]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/point_of_sale/wizard/pos_payment.py#L70

opw-4739523

**Problem:**
When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card.
But when doing so, two problems arise:
- In the case of a gift card, *line[2].refunded_orderline_id* is not set, so we are trying to read the property of an undefined variable.
- Another problem is that the order can not have any line that have a positive subtotal in the case of a refund. This was not taking the gift cards into accounts, as it makes sense for them to be positive in such a case.

**Steps to reproduce:**
- Set your company to a Mexican company
- Make a purchase for a gift card
- Make another purchase for a random product
- Start the refund process and enter the gift card code we created before
- Try to finalize the purchase, a traceback appears
- If we were not trying to read an undefined variable, the purchase would still not go through as some lines are positive in a refund

**Why the fix:**
When refunding with a gift card, we should refill the gift card by the order's cost instead. With this in mind, it makes sense for the gift card to have a positive price even though we are in the context of a refund, which usually only permits negative priced lines.

opw-4892935

All-day calendar events were incorrectly causing unavailability for
appointment slots scheduled on the previous evening, due to mismatches
between local time and UTC.

Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC.
In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid
appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into
Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event.

The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries`
which than computes naive datetime boundaries based on the user's local timezone by taking
the end of the previous local day and the start of the next local day. 

This change resolves those edge cases where evening slots crossing
the UTC boundary were falsely marked as unavailable due to timezone
misalignment.

opw-4614544

Forward-Port-Of: odoo/enterprise#85654

After this commit: odoo/enterprise@9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048 [diff](https://github.com/odoo/enterprise/commit/9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048#diff-de4a628e7837c273b67d71f93efab85b6a9ee957ea702f502066ebcc632a76cbL64)

The condition that handles hiding the basic wage on the payslip was not added —possibly it was missed. That’s why the "Hide basic on PDF" feature doesn’t work, regardless of whether it’s enabled, as the necessary condition is missing in the template.

Steps to reproduce (on runbot):
- In a v18 runbot, open any payslip and go to the salary structure. Enable the "Hide basic on PDF" option.
- Return to the payslip and print it.
- You’ll see that the basic wage is still printed on the payslip.


**Before Fix:**

<img width="669" height="238" alt="payslipbefore" src="https://github.com/user-attachments/assets/2fce67a2-19d8-45d8-88fa-4fc6a1767e68" />

**After Fix:**

<img width="683" height="289" alt="payslipafter" src="https://github.com/user-attachments/assets/adcb0104-9c4e-4a35-ba78-b3f278f6bfda" />

opw-4953831

**Steps to Reproduce:**
- Install `sale_subscription`.
- Create a product (recurring product) with:
    - Type: Service
    - Invoicing Policy: Prepaid/Fixed Price
- Create a subscription plan Yearly with:
    - Billing Period: 1 year
    - Align to period start: enabled
- Create and confirm a subscription for the product using the Yearly plan.
- Create and confirm the first invoice (shows remaining days like 
    185 days – 06/30/2025 to 12/31/2025 in product description).
- Create and confirm second invoice (check 1 year – 01/01/2026 to 12/31/2026).
- Go back to the subscription and create an upsell.
- Confirm the upsell and generate its invoice.

**Observation:**
- The upsell invoice line shows the wrong duration: 
    1 year (06/30/2025 to 12/31/2026).
- This is incorrect because the expected duration is: 
  185 days (from 06/30/2025 to 12/31/2025) + 1 year (01/01/2026 to 12/31/2026)

**Issue:**
- The duration calculation is based on the ratio of the first date and the end 
  date, but for the Upsell's ratio is always 1, so it considers fix duration, 
  i.e 1 year, 1 month
https://github.com/odoo/enterprise/blob/4bb43da79dba7ac1d0772fde814b3da6bade7db6/sale_subscription/models/sale_order_line.py#L346-L347

**Solution:**
- Corrected the logic to calculate the upsell duration by combining the remaining
  current period (e.g., 185 days) with the standard 1-year period ratio.

Reference PR: https://github.com/odoo/enterprise/pull/68163/commits/cfed2d369960896f0f4d91a90eb24f3641627419
opw-4853426