Steps to reproduce:
1 Install documents_hr and hr_sign on saas-19.1.
2 Go to Settings → Documents → disable Human Resources. 
3 Open the Documents app and delete the Employees - My Company folder. 
4 Upgrade the database to saas-19.2.

Issue:
- During the upgrade, the post-init hook attempts to embed the HR Sign action into predefined document folders. Since the Employees - My Company folder has been deleted (or is inactive), the folder lookup returns no record, leading to the following error:

```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1664, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 186, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 465, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 244, in load_module_graph
    getattr(py_module, post_init)(env)
  File "/home/odoo/src/enterprise/saas-19.2/documents_hr_sign/__init__.py", line 12, in _embed_sign_post_init
    folders.with_user(SUPERUSER_ID)._embed_action(sign_action.id)
  File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1643, in _embed_action
    folder.action_folder_embed_action(folder.id, action_id)
  File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1614, in action_folder_embed_action
    return self.get_documents_actions(folder_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1522, in get_documents_actions
    raise UserError(_('This folder does not exist or is not accessible.'))
odoo.exceptions.UserError: Esta carpeta no existe o no es accesible.
```

Root cause:
- As part of documents_sign, the documents_hr_sign action is embedded into predefined document folders (introduced in https://github.com/odoo/enterprise/pull/101890).
- The folder lookup relies on [_search()](https://github.com/odoo/odoo/blob/85992d5f5f8caeacdcc570fb9fefb4cfcec6460c/odoo/orm/models.py#L4681-L4691), which filters out inactive records 
  through the active test. Consequently, [search_fetch()](https://github.com/odoo/odoo/blob/85992d5f5f8caeacdcc570fb9fefb4cfcec6460c/odoo/orm/models.py#L1441-L1451) returns no matching

  folder when the predefined folder has been deleted or deactivated.  It will
  try to get document actions of predefined folder here, so if the folder is
https://github.com/odoo/enterprise/blob/6d334a17d10faec33d60f4a8d7d263c091bb456e/documents/models/documents_document.py#L1592
  inactive it will not be able to read the folder here.
https://github.com/odoo/enterprise/blob/6d334a17d10faec33d60f4a8d7d263c091bb456e/documents/models/documents_document.py#L1494

Fix:
- Instead of attempting to embed the Sign action into all company employee folders, filter out inactive folders before calling _embed_action().

- This ensures the post-init hook only processes active employee document folders. If a predefined folder has been deleted or deactivated, it is skipped preventing the upgrade from attempting to embed an action into an inaccessible folder and avoiding the resulting UserError.

opw-6358063
upg-4449902

Version - 19.0

Steps to reproduce(runbot):
- Install `l10n_au_hr_payroll`
- Go to Payroll -> Configuration -> Super Accounts
- Create a Super Account by filling all the required fields
- You will encounter the issue
**TraceBack:**
```
('hr.menu_hr_employee_payroll', 485, 'Employees > Employees', 756):
 Traceback (most recent call last):
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 346, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 537, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 570, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6688, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1744, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1915, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 484, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4954, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/19.0/l10n_au_hr_payroll/models/hr_employee.py", line 118, in _compute_proportion_warnings
    proportions[emp.id] * 100,
 KeyError: 4
```
Issue:
During the refactoring from `read_group()` to `_read_group()`, the `proportions` dictionary became keyed by `hr.employee` records instead of employee IDs. While the condition was updated to use `proportions.get(emp)`, the warning message still accessed the dictionary using `proportions[emp.id]`, resulting in a `KeyError`.

Fix:
Use the employee record consistently when accessing the `proportions` dictionary after switching to `_read_group()`.

Task ID - 6390373
Refrence:
https://github.com/odoo/enterprise/pull/72217/changes#diff-8ae3564d54e47eec919ef273d44f6276d8c6df60e21c5c8c8f7292b1c38cf541R460

Forward-Port-Of: odoo/enterprise#124478

In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started.

Case 1:
- Have website A and website B
- Create an appointment page website A
- Log in via website B
- As public user, make an appointment in Website A
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url.
This parameter is then used as fallback when we need to retrieve the base url without an active record

Case 2:
- Have website A and website B
- Create an event and assign it to website B
- As public user, access the event and register to it
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event.
This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A)

Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf

opw-4146760
opw-4336369

Forward-Port-Of: odoo/enterprise#124714
Forward-Port-Of: odoo/enterprise#122669

### Description of the issue/feature this PR addresses:
This PR addresses an issue where expected Mexican work hours and attendance fields fail to generate correctly in contexts where a draft payslip does not yet exist. Specifically, this was preventing the correct evaluation of work hours when an off-cycle payslip is initially generated for a given time period.

### Current behavior before PR:
The _preprocess_work_hours_data method aborts early if no hr.payslip record is found for the period. Because the method relies on an instantiated payslip to fetch calendar info, duration validation, and rule parameters, work hours cannot be properly calculated during the initial generation of off-cycle payslips. As a result, off-cycle payslips will under-calculate the total wage for a given pay period. 

### Desired behavior after PR is merged: 
The strict dependency on the payslip record is removed. If a payslip is absent, the logic will now safely fall back to the contract version's base data:
- The calendar defaults to the contract version's resource_calendar_id.
- The duration falls back to standard (is_wrong_duration = False).
- The l10n_mx_schedule_table rule parameter is fetched globally from the environment (hr.rule.parameter) instead of using the payslip helper.

This ensures that expected work hours are calculated consistently across all payroll workflows, even before the payslip is fully instantiated.

opw-6351402

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

**Problem:**
When a template is restricted to a department, appraisals for employees of that department do not use it — a generic (global) template is used instead.

**Steps to reproduce:**
1. Create an appraisal template and restrict it to a department.
2. Make sure at least one global (no department) template also exists.
3. Open a new appraisal and select an employee of that department.
4. Observe the appraisal template stays on the global one.

**Current behavior:**
The global template that was auto-selected before an employee was chosen is kept, ignoring the department-restricted template.

**Expected behavior:**
The template restricted to the employee's department is selected.

**Cause of the issue:**
On a new appraisal the template is computed before an employee (and therefore a department) is set, so a global template is pre-selected. When the employee is then chosen, `_compute_appraisal_template` reruns but the `appraisal.appraisal_template_id or ...` clause short-circuits on the already set global template and never falls through to the department's template.

**Fix:**
Evaluating the department's template before the existing value ensures a department-restricted template takes precedence over a template that was only auto-selected as a default. The existing value is still preserved when the department has no template of its own, so deliberate choices are untouched.

opw-6293936

Forward-Port-Of: odoo/enterprise#121377

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#277131
Forward-Port-Of: odoo/odoo#269100

### Steps to reproduce

1. Trigger an error whose browser object has no `stack` property (for example, a `DOMException` such as `AbortError`).
2. Let the web error service format its traceback.

### Current behavior

`formatTraceback()` calls `error.stack.split(...)` unconditionally, which raises a second `TypeError` and masks the original error.

### Expected behavior

The original error is formatted and reported even when the browser does not provide a stack trace.

### Fix

Use the existing technical name and message as the traceback when `stack` is absent. A focused regression test covers an `AbortError`-like object without `stack`.

### Tests

- `git diff --check`
- `node --check addons/web/static/src/core/errors/error_utils.js`
- `node --check addons/web/static/tests/core/errors/error_service.test.js`
- `@web/core/errors` HOOT suite: 24 tests, 107 assertions passed.

---

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

Forward-Port-Of: odoo/odoo#276864

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277425

### [FIX] web: fix mocked dates in tests

Dates are mocked in all unit tests by default; either to a default static
value, or to one defined in the test/suite. To do so, the `window.Date`
constructor is overridden to have the arguments auto-filled with the current
mock date paramters.

Before this commit, an additional offset was always added to the given
arguments to reflect:
- the time elapsed from the beginning of the test;
- any virtual offset added by a helper such as 'advanceTime'.

The issue is that the spec of the Date constructor wants that the returned date
object has to match all given arguments, and any omitted argument will be
defaulted to the current date/time. This was not the case in tests, as the
offset was always added, regardless of the given arguments.

With this commit: only the arguments that are NOT given and that have been
defaulted to current (mocked) date/time will be offset by the adequate value.
Furthermore: as these mocked parameters are meant to reflect UTC values, the
offset now also considers the *actual* browser offset to generate a local date
from the mock date parameters.

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

Forward-Port-Of: odoo/odoo#277041
Forward-Port-Of: odoo/odoo#275391

### Issue before this commit:
Sending a TicketBAI invoice to a customer with a Spanish address and a VAT number starting with 'N' (Non-resident entity) resulted in a rejection with error B4_2000027. The XML incorrectly generated the national <DesgloseFactura> tag instead of the required <DesgloseTipoOperacion> tag.

### Steps to reproduce the issue:
1. Download Accounting, l10n_es and l10n_es_edi_tbai
2. Change name to ES Company into “NOMBRE APELLIDOUNO APELLIDODOS” (this is to make sure the certificate for Ticketbai works)
3. Go to Settings → Spain Localization → set Tax Agency for = Bizkaia
4. Change VAT number for customer Mulhacén Digital S.L. into N0011452J (must be a foreign entity ID)
5. Go to Settings > Technical > System Parameters and set the parameter 'l10n_es_edi_tbai.epigrafe' to 165360
6. Create a new invoice for that client and try to send it to TicketBAI
7. Error:  B4_1000002: Todos los registros incluidos en la petición son incorrectos. B4_2000027: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando la factura es completa y, además, existe destinatario extranjero (tipo IDOtro o que sea NIF que empiece por N) o la Clave de IVA es 02.

### Cause of the issue:
The _l10n_es_is_foreign() method evaluated these customers as domestic because their country was set to Spain and their VAT did not start with "ESN". It failed to recognize a standalone "N" prefix as a valid foreign identifier.
https://github.com/odoo/odoo/blob/75ae45861e2f417aa2b90bdb2b2869718e091c09/addons/l10n_es/models/res_partner.py#L7-L10


### Reason to introduce the fix:
Adding the 'N' prefix to the _l10n_es_is_foreign() check ensures the system correctly treats these entities as foreign for tax purposes. This generates the correct XML structure automatically, without forcing users to unnaturally prepend "ES" to a legally valid NIF.

opw-6326359

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

Forward-Port-Of: odoo/odoo#275231