*=website

Steps to Reproduce :
 1. Go to `edit` mode.
 2. Drop at least four block snippets.
 3. Drop a badge in the header next to the _Contact Us_ button.
 4. Undo twice → the _Badge_ reappears.
 5. Undo twice more → the _Badge_ reappears again.
 6. Redo three times → the _Contact Us_ button is duplicated.

Issue:
The `Contact Us` button in the header was duplicated after multiple undo/redo actions. Moreover, the `Badge` snippet did not behave as expected during undo/redo.

Reason:
When the uncommitted draft was cleared before undo/redo, the `OdooEditor` observer triggered the `OdooField` observer to roll back and flush mutations. However, this rollback was considered a new mutation by the `OdooEditor` observer. On the next undo, the `OdooField` observer tried to sync with these artificial mutations, causing duplication of buttons and badges.

Fix:
Deactivate the `OdooEditor` observer during undo/redo operations to prevent recording unnecessary mutations. After discarding the draft, reactivate the `OdooEditor` observer. This avoids redundant syncs and resolves the duplication issue.

task-4558376

**Issue**
When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error.

**Steps to Reproduce**
1. Navigate to Accounting > Configuration > Journals.
2. Create a new journal.
3. Set the Type to Sales before entering the Name.
4. Save the journal.
5. Repeat the process to create another journal of the same type.
6. Observe that an error occurs: alias name is already used.

**Root Cause**
The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly.

**Fix**
Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured.

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

Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.

It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].

This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).

Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
    def _load_records_write(self, values):
        values.pop('active', None)
        super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804

task-2963840

(Follow-up of https://github.com/odoo/upgrade/pull/3829)

**Steps to reproduce**
- Have a helpdesk team for company A, with an email alias set up.
- Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with this email in company A or with no company.
- Send a message with the email of the `res.partner` to the alias of the helpdesk team.
Issue: the ticket is not created.

**Cause**
The `_check_partner_id_has_the_same_company` constraint fails, preventing the ticket from being created.

**Solution**
We stop using the `author_id`, since it is not guaranteed to respect the constraint.
https://github.com/odoo/enterprise/blob/a1fe558c8d6e27b435d350c23e19b93bbe611eb7/helpdesk/models/helpdesk_ticket.py#L755 This values comes from `_mail_find_partner_from_emails` in the mail module, which will prioritise a contact from the same company, but will not prevent one from another company being used. The existing code in `create` will call `_find_or_create_partner` to find/create one based on the name and mail.
`_mail_find_partner_from_emails` is used instead of `find_or_create` to be able to provide an additional domain to ensure company consistency.

opw-5154449