### Steps to reproduce:
- Install the `l10n_mx_hr_payroll_account_edi` module
- Create and compute a payslip for any employee
- In the payslip, click the action button and then attempt to edit the payslip lines
> Error: NameError("name 'number_of_days' is not defined")

### Cause of Issue:
In Odoo, each salary rule executes its `amount_python_compute` script within an isolated `safe_eval` context. Several rules (such as `HOLIDAYS_ON_TIME`, `GAS_PERIOD`, and `TAX_GAS`) attempt to reference local variables like `number_of_days`, `days_in_month_ratio`, `accrued_days_in_period`, and `unpaid_days_in_period` without actually defining them locally.

This triggers a `NameError` during the payslip line evaluation entirely blocking the computation process.

### Fix:
Inject these calculated values directly into the evaluation environment dictionary so they are globally available to all salary rules. This resolves the `NameError` while avoiding the massive performance penalty of duplicating repetitive date calculations and database loops inside the context of dozens of individual XML records.

Note: In version 19.0, a forward-port adjustment will be needed to accommodate for an additional context variable that isn't present in this version.

opw-6483367

### Steps to reproduce:
- Create an accrual plan with the following configurations:
    - Accure time: start of accural period
    - Carryover date: allocation date
- Create the first milestone which grants 12 days, Daily frequency, starting 1 year after the allocation date, with yearly cap set to 12 days, and carryover lost
- Create an accrual allocation for an employee via the allocation Form, setting `date_from` to 01/01/2025
- Check the employee's Time Off dashboard "Balance at date" for tomorrow, or for any other day still within the current year
> The balance shows 24 days instead of 12, i.e. twice the amount that was
  actually accrued. The balance is only correct for today, and becomes correct again for dates falling after the plan's next carryover date

### Cause of Issue:
When the allocation Form is filled in, `_onchange_date_from` runs `_process_accrual_plans` on the in-memory record, which correctly computes both `number_of_days` and `yearly_accrued_amount` together (the latter tracks how much of the current year's cap has already been granted, and is reset to 0 on each carryover date).

However, `yearly_accrued_amount` is a plain stored field that is never added to any `hr.leave.allocation` form view. Since the webclient/Form only sends the fields present in the view as part of the `create()` vals, the onchange-computed value for `yearly_accrued_amount` is silently dropped on save, while `number_of_days` (a visible field) is persisted correctly. The allocation therefore ends up with `number_of_days = 12` but `yearly_accrued_amount = 0`.

Later, `_get_future_leaves_on` builds a temporary copy of the allocation to preview a future balance. For any target date still within the current accrual year, it sees `yearly_accrued_amount == 0`, concludes the yearly cap is entirely unused, and grants a fresh 12 days on top of the 12 already persisted, doubling the projected balance to 24.
https://github.com/odoo/odoo/blob/5b8e455975e2b45c13e20e8ff5873903bb27ac5d/addons/hr_holidays/models/hr_leave_allocation.py#L689-L711

This same class of issue was already identified and fixed for three sibling bookkeeping fields on this exact view (`expiring_carryover_days`, `carried_over_days_expiration_date`, `already_accrued`), but `yearly_accrued_amount` was missed.
https://github.com/odoo/odoo/blob/5b8e455975e2b45c13e20e8ff5873903bb27ac5d/addons/hr_holidays/views/hr_leave_allocation_views.xml#L100-L105

### Fix:
Add `yearly_accrued_amount` as an invisible field on `hr_leave_allocation_view_form`, following the same pattern already used for `already_accrued`, so its onchange-computed value is included in the `create()` vals and the field stays in sync with `number_of_days` from the moment the allocation is created.

opw-6411314

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

Steps to reproduce
-------------------

- Install im_livechat module;
- Copy the code from the livechat channel's widget tab;
- Paste it in an external website's code;
- Start a conversation and send a PDF file from Odoo;
- Try to download it from the external portal, a 400 error
is received;
- Try to open it with the viewer, the file isn't found.

Why is it happening
---------------------

Starting with version 18.4, onClickDownload delegates file retrieval to the download service, executing a POST request which needs CSRF validation.

The current route doesn't allow requests from external domains.

In addition, the 'Content-Disposition' header is not allowed for cross-origin requests. This is required to get the downloaded file's name.

Regarding the file's opening in the viewer, we currently use '/web/static/lib/pdfjs/web/viewer.html'. When called from an external website, the browser treats this as a relative URL and requests it from the client portal rather than the Odoo backend.

opw-6444167

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