Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.

It could lead to very obscure bugs such as:

```python
def some_innocent_code():
    category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
    incapacity_codes = category_dict['partial_incapacity']
    incapacity_codes |= category_dict['total_incapacity']
    # ... then use incapacity_codes

def print_rule_param():
    print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])

print_rule_param()  # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param()  # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```

The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.

task-6329380

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#122669

When the address form is submitted, the button is disabled and a spinner is shown while the POST is in flight. On success, redirect() is called, which schedules a navigation via location.assign() asynchronously.

The browser's bfcache can snapshot the page at this point — while the button is still disabled — and restore that snapshot when the user presses back, leaving the button stuck in the loading state.

Fix: re-enable the button and remove the spinner before branching on result.redirectUrl so bfcache always captures a clean button state.

In Odoo master this was fixed implicitly by PR odoo/odoo#201730 (commit 1d79eddc62a0), which refactored the widget to use the Interaction class with makeButtonHandler(), which always restores the button after the handler's promise resolves.

Description of the issue/feature this PR addresses:

Current behavior before PR: During checkout, when pressing the return arrow to go back into the address editing panel, the "Save Address" button gets stuck in loading forever.

Desired behavior after PR is merged: The "Save Address" button is shown normal.


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

## Description

Law no. 30-26 of June 18, 2026 (art. 17) amended article 309 of the Dominican Tax Code. Effective **July 1st, 2026**:

- The income tax (ISR) withholding on fees, commissions and other remunerations for services rendered by individuals not in a dependency relationship is raised from **10% to 15%** (payment on account).
- The ISR withholding on rentals of movable and immovable property paid to individuals is raised from **10% to 15%** (now a definitive payment).

Official references:

- Amended article 309 CT (art. 17 of the law): "a) 15% *(antes 10%)* ... alquiler o arrendamiento ... provistos por personas físicas ... pago único y definitivo; b) 15% *(antes 10%)* sobre los honorarios, comisiones y demás remuneraciones y pagos por la prestación de servicios en general provistos por personas físicas, no ejecutados en relación de dependencia ... pago a cuenta."
- Law 30-26 at the Ministry of Finance: https://www.hacienda.gob.do/marco-legal/ley-no-30-26/
- PwC summary quoting the new art. 309 scale ("15%, previously 10%"): https://www.pwc.com/ia/es/publicaciones/Noticias-Tax-Legal/Tax-and-legal-2026/modificaciones-Ley-30-26.pdf
- DGII implementation calendar (notice 10-26 — calendar only, the rates are in the law text): https://dgii.gov.do/publicacionesOficiales/avisosInformativos/Documents/2026/10-26.pdf
- DGII confirming the new percentages are in force since 2026-07-01: https://ayuda.dgii.gov.do/conversations/discusiones/retenciones-segun-ley-3026/6a42be2e3365d30845e40234

## Implementation notes

- The existing XML IDs (`ret_10_income_person`, `ret_10_income_rent`) are kept unchanged, so on existing databases the standard chart template reload (`_pre_reload_data`) replaces the outdated 10% taxes through the usual `[old]` renaming mechanism.
- The tax group `tax_group_person_services` labels are updated from "(10%)" to "(15%)" accordingly.
- No other article 309 rates changed for the taxes present in this template (5% government, 10% dividends, 2% N07-07, 27% remittances remain in force).

This is the first contribution by Grupo de Consultoria Henca (https://www.consultoriahenca.com); the corporate CLA signature is included in `doc/cla/corporate/consultoriahenca.md` as instructed by `doc/cla/sign-cla.md`.

## Related PRs

- 17.0: https://github.com/odoo/odoo/pull/275986
- 18.0: https://github.com/odoo/odoo/pull/275987
- 19.0: https://github.com/odoo/odoo/pull/275988

**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab

**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.

Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).

This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```

**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.

(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)

[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6

opw-6247412