#### Description of the issue/feature this PR addresses:
The "Request Appraisals" server action on hr.employee calls model._create_multi_appraisals(), a method that no longer exists. Running it raises AttributeError: 'hr.employee' object has no attribute '_create_multi_appraisals'.

#### Current behavior before PR:
Commit 8845eb2ac29 replaced the multi-appraisal flow with hr.appraisal.campaign.wizard: it deleted _create_multi_appraisals and repointed the employee list header button to action_open_appraisal_campaign_wizard, but left the action_create_multi_appraisals record in hr_appraisal/views/hr_employee_views.xml. Its code is now the only reference to the deleted method, so the action crashes whenever it is run.

#### Desired behavior after PR is merged:
The dangling action is gone. Requesting appraisals for several employees at once is done with the "Launch Campaign" button already present in the Employees list view; action_open_appraisal_campaign_wizard reads active_ids when active_model is hr.employee and pre-fills the selected employees.

Nothing references the removed xml id, and the record is not noupdate, so _process_end removes it from existing databases on update; no migration script is required. Verified on a 19.0 database: with the orphan record loaded, updating hr_appraisal with this change deletes it.

opw-6408609

Forward-Port-Of: odoo/enterprise#127983
Forward-Port-Of: odoo/enterprise#125630

When the AI agent switched from another view to a pivot view, the pivot view
could crash or open without any active measures.

The AI controller patch applies the agent's adjustments upon receiving the
`APPLY_AI_ADJUST_MODEL` bus event. However, the event could be processed while
the pivot model was still executing `_loadData()`.

In that case, the following sequence occurred:

* `_loadData()` started and awaited.
* The controller patch was executed.
* The patch called `toggleMeasures()`.
* `toggleMeasures()` waited for `_loadData()` to complete.
* `_loadData()` finished and updated the metadata with the available measures.
* `toggleMeasures()` resumed and wrote back the metadata snapshot it had taken
before waiting.

Since `toggleMeasures()` operates on a snapshot of the metadata, the measures
populated by `_loadData()` were lost when the snapshot replaced the current
metadata, leaving the pivot model without its `measures` metadata and causing
the view to crash.

Prevent this race condition by waiting for the pivot model initialization to
complete before applying the AI adjustments.

Also preserve the default active measures when the AI agent does not explicitly
request any measures instead of clearing them and opening an empty pivot view.

task-6384368

Forward-Port-Of: odoo/enterprise#125897

1- The benefit fields related to the hr.version have a domain that limits them to the whitelisted fields used to copy values from a template, which does not always include benefit fields. The advantage of the whitelist is that it factored in for the allowed countries, so instead of duplicating this logic to benefit fields and implementing it in every l10n, we can check which module the field comes from.

example:
The field [`company_car_total_depreciated_cost`](https://github.com/odoo/enterprise/blob/ce691cd6aaacfb86cd866698d2fcc3fe930912cb/l10n_be_hr_payroll_fleet/models/hr_version.py#L62) cannot be selected as `res_field_id` when it should be possible as we see in the [data](https://github.com/odoo/enterprise/blob/ce691cd6aaacfb86cd866698d2fcc3fe930912cb/l10n_be_hr_contract_salary/data/hr_contract_salary_benefit_data.xml#L6), it is not whitelisted because we dont want to copy its value from a template.

2- Another fix is the inverse of the public field, there's a traceback because the selection field is always converted to a string and cannot be used to browse as is.
```py
  File "/data/build/enterprise/hr_contract_salary/models/hr_contract_salary_benefit.py", line 238, in _inverse_res_field_public
    record.res_field_id = self.sudo().env['ir.model.fields'].browse(record.res_field_public)
    ^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields.py", line 1890, in __set__
    write_value = self.convert_to_write(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_relational.py", line 387, in convert_to_write
    return value.id
           ^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_misc.py", line 115, in __get__
    raise ValueError("Expected singleton: %s" % record) from None
ValueError: Expected singleton: ir.model.fields('1', '7', '3', '8', '4')
```

Forward-Port-Of: odoo/enterprise#127743

Currently, an error occurs when a user adds a rental product to the cart, opens the corresponding sales order, removes the rental period, and then opens the cart again.

Steps to replicate:
- Install `website_sale_renting` with demo.
- Open website > shop > add the product named `Projector`.
- Click Ecommerce in the menu bar > Orders .
- Remove the `Confirmed` filter > Click on the top order (should be containing the projector product.)
- Remove the `Rental Period` and go to the cart.

Error:
```
QWebError: Error while rendering the template:
AttributeError: 'bool' object has no attribute 'time'
Template: website_sale.shorter_cart_summary
```

Cause:
- When the user removes the rental period (`rental_start_date` and `rental_end_date`), both fields are set to `False`. When the cart is opened again, these values trigger the error in [line].

- Since the rental period has been removed from the order, the order is converted to a regular Sales Order (see [PR] and its [task]). Therefore, the Rental Period should no longer be displayed.

Solution:
- Use `is_rental_order` to determine whether to render the rental period instead of `has_rentable_lines`, since `has_rentable_lines `only checks whether the product is rentable [1], which is determined by the product's `rental_periodicity` [2].

- `is_rental_order` is a better check here because it indicates whether the rental period is actually defined on the order [3].

[line]: https://github.com/odoo/enterprise/blob/7c80c9ffa9e7812267f2ac285e3a3fc5ca501814/website_sale_renting/views/templates.xml#L207

[task]: https://www.odoo.com/odoo/all-tasks/6003684

[PR]: https://github.com/odoo/enterprise/pull/106381/commits/56ec41d81f7536f047a1586a12ea6f6e8414b844

[1]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L140-L143

[2]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order_line.py#L61-L64

[3]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L135-L138

sentry-7663524549

* = din5008_account_followup, din5008_industry_fsm

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

opw-6392649

Forward-Port-Of: odoo/enterprise#128209
Forward-Port-Of: odoo/enterprise#126006

The PstlAdr block written into pain.001 files never contains the
partner's state/province nor the second street line, even when they
are set on the record: _get_all_addr() now returns them, but
_get_PstlAdr() also needs to write them out. Some North American banks
reject wire transfers whose beneficiary address lacks the
state/province, so those payments fail regardless of how complete the
vendor record is.

Emit CtrySubDvsn when the address has a state, before Ctry as required
by the element order of the PostalAddress schema, and append street2
to the street address line.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Requires odoo/odoo#282518, which makes _get_all_addr() return the state and street2.

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

Forward-Port-Of: odoo/enterprise#128021
Forward-Port-Of: odoo/enterprise#127958

_get_all_addr() feeds the postal address block of generated pain.001
payment files, but does not return the partner's state nor the second
street line. The beneficiary state/province and street complement
(suite, unit, ...) therefore never appear in the generated file, even
when they are set on the partner, and there is no way to fix it from
the record. Some North American banks reject wire transfers whose
beneficiary address lacks the state/province, so those payments fail
regardless of how complete the vendor record is.

Return the state code and street2 alongside the other address
components, from the partner for the base implementation and from the
employee private address for the hr one, so the payment engine can
write them in the PstlAdr block.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Companion enterprise PR emitting the state in the generated file: odoo/enterprise#127958

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

Forward-Port-Of: odoo/odoo#282620
Forward-Port-Of: odoo/odoo#282518

Steps to produce:
---
- Install `website_sale_collect` module.
- Create and publish a product.
- Add it to the cart and proceed to checkout.
- Fill in the address and confirm.
- Select a `pick-up in store` delivery method.
- Click the edit icon on the contact details.
- Confirm without making any changes.

Issue:
---
- The pick-up point address appears as a selectable delivery address in
  the contact details list, which it should not.

Root cause:
---
- When a pick-up point is selected, `set_pickup_location` calls
  `_address_from_json` ([1]), which creates a child `res.partner` record with
  `type='delivery'` and sets `pickup_delivery_method_id` to identify it as a
  pick-up point address.

  Later, when the user returns to the address page, `_prepare_address_data`
  calls `_get_delivery_address_domain` ([2]) from `portal`. This method returns
  all child partners with `type='delivery'` without distinguishing between
  user-created delivery addresses and the auto-generated pick-up point addresses

  As a result, the pick-up point address incorrectly appears in the checkout
  address list.

Solution:
---
- As specified in [task], partners created through this flow should be archived.
  However, in the referenced [commit], the `active=False` flag was removed
  when creating the partner, causing newly created partners to remain active.

  Override `_get_delivery_address_domain` to exclude pick-up point addresses.
  Since auto-generated pick-up point addresses always have
  `pickup_delivery_method_id` set, they are filtered out from the checkout
  address list, while manually created delivery addresses remain unaffected.

[1]https://github.com/odoo/odoo/blob/fb6298e50a7c8ded2800254e8715336eeb37deb5/addons/website_sale_stock/models/res_partner.py#L16-L72
[2]https://github.com/odoo/odoo/blob/fb6298e50a7c8ded2800254e8715336eeb37deb5/addons/portal/models/res_partner.py#L51-L55

[task]: https://www.odoo.com/odoo/project/49/tasks/3645144
[commit]: https://github.com/odoo/odoo/commit/fb74a371407ee19c6b1a3ab9f5a7b314978cb5cb

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

* = de, din5008, din5008_purchase, din5008_repair, din5008_sale

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Observed behavior (commercial register):**

* The footer always shows `HRB-Nr.:` regardless of whether the company has a commercial register entry.
* The abbreviation `HRB-Nr.:` appears even for Austrian and Swiss companies, where the commercial register number is a German-specific concept.
* In the company form view, the field is labeled generically as "Company ID" instead of "Commercial Register Number" for German companies.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Cause (commercial register):**

* The footer renders `company.company_registry` unconditionally with no country guard and no label.

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

**Fix (commercial register):**

* Remove the hardcoded `HRB-Nr.:` label from the footer and instead render `company.partner_id.company_registry_label` (which is country-aware).
* Update the duplicate contact warning message to use the country-aware label via `company.partner_id.company_registry_label`, backed by a new `_get_company_registry_labels` override in l10n_de that registers `Commercial Register Number` for `DE`.
* In the company form view (`l10n_de`), hide the generic "Company ID" field for German companies and show a relabeled instance with `string="Commercial Register Number"` instead.

opw-6392649

Forward-Port-Of: odoo/odoo#282964
Forward-Port-Of: odoo/odoo#279085

### Issue:
In 19.3, the following hoot tests fail with a RunBot error:
- "called at right time (when canceling order)"
- "called at right time (when canceling order never sent to blackbox)"
- "called at right time (when canceling a combo order)"

### Cause:
Commit 0dfd71b9f4 removed `close` from `ControlButtonsPopup` as the Dialog patch now handles closing via `this.data.close()` With no remaining props to declare, `static props` was removed entirely

Without `static props`, Owl skips all prop validation but emits: "Component 'ControlButtonsPopup' does not have a
static props description"
`mountWithCleanup` forces `warnIfNoStaticProps` to `true` in hoot tests, causing the tests to fail

`close` is declared as optional since `dialog_service.js` always injects it via `subProps: markRaw({ ...props, close })` at runtime, but the component no longer uses it directly

### Steps to reproduce:
- Install `l10n_be_pos_blackbox`
- Enable Developer mode
- Open the JS test UI
- Run one of the failing tests

runbot-941231

Forward-Port-Of: odoo/odoo#277790