**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

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

**Steps to reproduce:**
- create a product tracked by lot 
- create a lot with a quantity of 2
- create a new sale order
- add two sale order lines, both for a quantity of 1 of the product
- confirm
- open the picking in barcode
- scan the stock location
- scan the lot 
- scan the lot another time
- validate

**Current behavior:**
a backorder is created

**Expected behavior:**
No back order should be created 

**Cause of the issue:**
After scanning the lot for the first time we have the following situation: 
two lines : 
- one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1
- one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1
both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2
All of this is correct.

when scanning the lot for the second time: 
_findLine iterates through the lines to select the right 
line to use.
 _findLine calls _lineIsNotComplete on the first line to check 
if it's complete (this first line is complete).
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684
But _lineIsNotComplete will actually do the check on the 
parent line (which is not complete), so the return value will 
be true. 
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338
As a consequence, the quantity will be added in the first line and 
we will have a qty_done of 2 in the first line 
and a qty_done of 0 in the second line. 
Which will lead to the creation of a back order

opw

Forward-Port-Of: odoo/enterprise#100626
Forward-Port-Of: odoo/enterprise#99774

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

**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template

**Observation:**
- Traceback for faulty template


**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587

when this content is parsed using DOMParser in browser, 

https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63

we might get different result.
For a very basic template like this:
```
<div>
    <t t-if="ctx.get('error')">
        <pre t-out="ctx['error'] or ''" />.
    </t>
    <t t-else="">
        <span>some text</span>
    </t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
    <t t-if="ctx.get('error')">
        <pre t-out="ctx['error'] or ''">.
        <t t-else="">
            <span>some text</span>
    </t>
</pre>
    </t>
</div>
```

Issue roots because of use of self-closing tags, which are valid for xml but not for html

**Fix:**
- we forcefully replace all self-closing tags(which are not void elements)  with a closing tag.
- see  list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element



opw-5234345


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

In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]

To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101162
Forward-Port-Of: odoo/enterprise#99871

Currently, an error occurs when creating a time off request for an employee.

Steps to Reproduce:

 - Install the `hr_holiday` module.
 - Go to `Management > Time Off`.
 - Create a `new time off` and `remove the start date`.
 - Now `change the employee`.

`AttributeError: 'bool' object has no attribute 'date'`

This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3].

This commit ensures that the system only checks whether the time off is in the past when a start date is provided.

[1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597

[2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279

[3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237

No Task ID

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

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