**Steps to reproduce:**
* Install the **Accounting** module.
* Go to **Accounting > Configuration > Settings**.
* Download the **Import Journal Items** template.
* Keep the default journal codes in the template (e.g. *MISC*, *SAL*, *BNK*).
* Import the file containing these existing journal codes into it by **Accounting > Configuration > Settings > Initial Setup > Import > Import Journal Items > Upload data file**.

**Observed behavior:**
* Existing journals have their names overwritten by the values provided in the import file.
* For example, a journal with code **MISC** and name *Miscellaneous Operations* is updated to name **MISC** after import.

**Cause:**
* Journals are looked up by their `code`, but `_load_records()` passes both `name` and `id` for all rows.
* As a result, existing journals are updated instead of preserved.

**Fix:**
* Pass only `id` for journals already found by code.
* Pass `name` only when creating new journals.
* This prevents unintended updates to existing journal names.

opw-5345876

Forward-Port-Of: odoo/enterprise#100143

\* = html_builder, html_editor, website

Before this fix, applying a shape on a GIF image in the website editor
failed.

The issue came from the `_processImage` function, which is called before
applying a shape. In this function, GIFs were handled as a special case,
but that branch returned a different value than expected, causing the
shape application to fail on GIFs.

This commit fixes the return value for the GIF-specific branch so it
matches the expected structure, making shape application work
consistently across all image types.

As a side effect, this also fixes the display of GIF file sizes in the
website editor. When selecting an image or setting one as a background,
the builder sidebar normally shows the image size. For GIFs, it showed
"NaN kb" due to the same broken function.
A past [PR](https://github.com/odoo/odoo/pull/223424) worked around this by hiding sizes for GIFs entirely. Since the
root cause is now fixed, the size is correctly displayed again.

task-[5071548](https://www.odoo.com/odoo/project/974/tasks/5071548)

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

This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports:

[FIX] l10n_eu_oss_reports: Correct Tax Unit Detection for OSS Reports
OSS reports lack a country, causing _get_available_tax_units to return no results. As a consequence, only the environment's main company was considered. This fix ensures that when multiple companies belong to the same tax unit, their OSS reports are correctly consolidated under that shared unit.

[FIX] account_reports: Link Tax Unit Returns to the Main Company
When generating domestic tax returns for a company that is part of a tax unit, the main company of the unit should be used since it is responsible for filing. This update ensures tax return generation is always aligned with the appropriate main company.

[FIX] account_reports: Enforce Main Company When Generating Report Options
get_options previously relied on the order of companies within a tax unit, assuming the first entry was the main company. Because this order is not guaranteed, the call is now explicitly scoped using with_company to ensure the main company is always used when preparing report options.

Forward-Port-Of: odoo/enterprise#99715

Steps to reproduce:

case 1:

1. Select all text in the footer.
2. Apply an animation (e.g. slide).
3. Re-select the same text (e.g. by triple-clicking or drag-selecting).
4. Observe that the animation option resets unexpectedly.

Case 2:
1. Select all text in a paragraph.
2. Apply a text highlight.
3. Re-select the same text (e.g. by triple-clicking or drag-selecting).
4. Apply an animation (e.g. on scroll).
5. Re-select the same text again.
6. Observe that the animation option resets unexpectedly.

Cause:
The previous comparison between `selection.textContent()` and
`ancestor.innerText` did not account for differences in whitespace and
formatting, leading to false mismatches even when the selected and
ancestor text appeared identical.

Fix:
Normalized both the selection and ancestor text by collapsing multiple
whitespace characters and trimming leading/trailing spaces before
comparison. This ensures that visually identical text is treated as
equal, maintaining the animation option state when re-selecting the
same text.

The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade, those strings will be translated in different languages and will trigger an error[^1] when they cannot be accessed in the dict. This can also fail during a local upgrade, not necesarily during an upgrade in the platform.

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
    self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Akun'
```

[^1]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L423
[^2]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L393-L397

Forward-Port-Of: odoo/odoo#238368

Description of the issue/feature this PR addresses:

When multiple `product.template.attribute.line` records reference the same `product.attribute`, the product configurator raises a `KeyError` at line 321.

Root cause: `ptals.attribute_id` returns a unique recordset (Odoo deduplicates), so `zip(ptals.ids, ptals.attribute_id.read(...))` produces fewer entries than expected when attributes are shared across lines.

```python
# Before: zip stops at shorter list, missing entries in attrs_map
attrs_map = dict(zip(ptals.ids, ptals.attribute_id.read(['id', 'name', 'display_type'])))

# After: preserve 1:1 mapping by iterating each ptal
attrs_map = {ptal.id: ptal.attribute_id.read(['id', 'name', 'display_type'])[0] for ptal in ptals}
```

Current behavior before PR:

`KeyError` raised when accessing `attrs_map[ptal.id]` for attribute lines whose ID was truncated by the `zip`.

Desired behavior after PR is merged:

Product configurator correctly maps all attribute lines regardless of whether they share the same underlying attribute.




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

Forward-Port-Of: odoo/odoo#238292

[FIX] website, website_crm: fix crash on save if property field in form
---

__Before commit:__
1. Go to CRM app
2. Open a lead
3. Add a new property field by clicking on the cogwheel at the top left
and then *Edit Properties*
4. Open the website builder
5. Drag a new form
    - Set *Action* to *Create an Opportunity*
    - Set *Sales Team* to *Sales*
6. Add a new field and set *Type* to the newly created property field
7. Save
=> Traceback:
`ValueError: Unable to whitelist field(s) ['xxxx'] for model 'crm.lead'`

__Cause:__
We are trying to whitelist a property field which is not an actual field
to the `crm.lead` model but rather a property of one of the `crm.team`.

__Fix:__
Filter the property fields to whitelist.

---

[FIX] html_builder: make builder_list work with non-integer ids
---
__Before commit:__
1. Go to CRM app
2. Open a lead
3. Click on the cogwheel at the top left and then on *Edit Properties*
    - Set *Field Type* to *Selection*
    - Add two values
4. Open the website builder
5. Drag a new form
    - Set *Action* to *Create an Opportunity*
    - Set *Sales Team* to *Sales*
6. Add a new field and set *Type* as the newly created property field
7. Click on *Add New Radio*
=> There are still items to add although there are already all included.
8. Click on an item
=> Two tracebacks appear:
- `TypeError: Cannot use 'in' operator to search for '_id' in null`
- `TypeError: Cannot read properties of null (reading 'id')`

__Cause:__
When adding item to the selection, the id is casted to `Number` although
it can be a string if the field type is a property.

__Fix:__
When comparing two ids, cast both side of the comparison to strings to
make sure a match can always be found.

task-5248526

Currently an error is generated when the user tries to create or write fields
 with wrong domain.

Steps to produce an error
- Install sale_management and create a new field with the below detail
    - Model: `Sales order`
    - Field Type: `one2many`
    - Related Model: `sale.order`
    - Relation Field `partner_id`
    - Domain: `[('sale_order_id', 'in', sale_order_ids)]`
- Click on save

This error occurs because we have a constraint in the domain, and it is triggered
 when the user modifies the domain at code line [1]. Inside this constraint, we use
 `safe_eval` to evaluate the domain. During this evaluation, an error is raised because
 the user entered an incorrect domain.

This commit fixes the above issue by wrapping `safe_eval` inside a `try–except` 
block and raising a `ValidationError` with an appropriate message when an error occurs during domain evaluation.

[1]- https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/odoo/addons/base/models/ir_model.py#L651-L654

sentry-6964956583

Forward-Port-Of: odoo/odoo#237937
Forward-Port-Of: odoo/odoo#236891