Description of the issue/feature this PR addresses:

A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed.

The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document.

That model only grants read access to account.group_account_invoice and account.group_account_readonly.

Steps to reproduce:
- install `l10n_es_edi_verifactu`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create an ES company and an ES customer
- give the salesman access to the ES company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the ES company for the ES customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An error access is raised:

Failed to read field account.move.l10n_es_edi_verifactu_document_ids

You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records.

This operation is allowed for the following groups:
	- Invoicing/Billing
	- Technical/Show Accounting Features - Readonly

Contact your administrator to request access if necessary.


In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails  for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed.


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

Forward-Port-Of: odoo/odoo#280879

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

### Steps to reproduce

1. Install *Sales* and *Timesheets*
2. Create a service product: Invoicing Policy = *Based on Timesheets*, Create on Order = *Task*
3. Create a sale order for it (quantity 1) and confirm it
4. On the generated task, log **4.5 h on 15/06** and **3.5 h on 23/07**
5. *Create Invoice* with no timesheet period → 8 h, and post it
6. On that invoice: *Reverse* → *Partial Refund*, set the quantity to **3.5 h** and post it → 4.5 h invoiced
7. Log **1 h on 31/07** → 9 h delivered
8. *Create Invoice* again, with a **Timesheets Period of 01/06 → 31/07**

### Current behavior

The invoice bills **9 h**: the 4.5 h that were invoiced and not credited are billed a second time.

### Expected behavior

The invoice bills **4.5 h** — the quantity delivered minus the quantity invoiced.

### Cause of the issue

Posting a partial credit note clears `timesheet_invoice_id` on every timesheet the reversed invoice
had linked (`sale_timesheet/models/account_move.py`, `action_post`), because a credit note carries a
quantity and never a set of timesheets, so there is no way to tell which hours it credited.

All of those hours therefore become candidates again in `_recompute_qty_to_invoice`, which assigns
their sum to `qty_to_invoice` without comparing it to what is still due on the line.

### Fix

Timesheet links cannot express a partially invoiced timesheet, so they are used only to select the
hours a period concerns, while the quantity that may still be billed is
`qty_delivered - qty_invoiced`. The period lookup is capped by that remainder, and kept at zero or
above so that an over-invoiced line is corrected by a deliberate credit note rather than as a side
effect of invoicing a period.

### Tests

Five tests are added to `addons/sale_timesheet/tests/test_sale_timesheet.py`.

Three of them fail without the fix:

| test | without the fix |
| --- | --- |
| `test_period_invoice_does_not_rebill_refunded_invoice_hours` | `9.0 != 4.5` |
| `test_period_invoice_after_refund_is_computed_per_line` | `4.0 != 1.5` |
| `test_period_invoice_after_refund_of_an_over_invoiced_line` | `8.0 != 1.0` |

The other two cover behaviour that is not exercised today and that the fix must not break: an
over-invoiced line (which must be left out rather than credited, and must not prevent the other
lines of the order from being invoiced) and the reversed invoice's own `invoice_date`, which must not
influence the quantity billed for a period.

The full `sale_timesheet` suite passes (86 tests).

Forward-Port-Of: odoo/odoo#280721
Forward-Port-Of: odoo/odoo#280536

**Steps to Reproduce:**

1. Send a message to Marc demo with Mitchell admin or vice-versa, read the message from reciever's side.
2. Click on seen-by indicator from sender's side, make sure the dialog appears and then Press `'ESC'`.
3. Chat window closes whereas the dialog should have closed.

Since #169737, pressing 'esc' on the seen-by dialog closes the chat window instead of the dialog.

The chat window's root element has a keydown handler that closes the window on `'escape'`, and catches focus by default whenever something non-focusable is clicked inside it (e.g. the seen-by indicator). The seen-by dialog's content had no focusable element, so it never grabbed focus for itself, leaving focus on the chat window. Pressing 'escape' therefore closed the chat window instead of the dialog.

This commit fixes the issue by adding tabindex on the template, letting the dialog grab focus like other dialogs/popovers already do, so `'escape'` is handled by the dialog first.

task-4895004

Forward-Port-Of: odoo/odoo#278847

## Steps to Reproduce:
- Install the Time Off module.
- Create an Accrual Plan without any milestones.
- Create an Accrual Allocation using the newly created accrual plan.
- Approve the allocation.
- Add a milestone to the accrual plan.
- Create a new Time Off request after the allocation start date.
- Save the record.

## Error:
`TypeError - '>' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
`lastcall` is initialized by method `_add_lastcalls()`, which is only called at create and write. When an accrual allocation is created with an accrual plan that has no milestones, `_add_lastcalls()` returns early because `level_ids` is empty, leaving `lastcall` set to `False`. - [1]

If a milestone is added later, `lastcall` is compared with `first_level_start_date`, resulting in a comparison between boolean and datetime, which raises an error.

## Fix:
When `lastcall` is not set, default it to `first_level_start_date`.

[1] - https://github.com/odoo/odoo/blob/27036bea232572ba692fbb95387911eb453266bf/addons/hr_holidays/models/hr_leave_allocation.py#L703-L706

sentry-7615375197

Forward-Port-Of: odoo/odoo#280674