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

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

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

**Issue**
When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total.

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#97951
Forward-Port-Of: odoo/enterprise#85873

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

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

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

This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the codebase. The most significant changes focus on ensuring that document folio numbers are correctly managed in accordance with available CAFs, making the certificate model more robust, and updating code style for clarity and consistency.

This improvement is mostly made because CAFs have expiration dates and fixed folio numbers. If the expiration date is reached but the folios were not fully consumed, the system will try to generate a document with following number in the sequence but an error will be raised because that number belongs to an expired CAF, althought the user had already uploaded a new CAF.
To fix this, whenever the system looks for the highest number to set to a document, it previously check if that number is between the folio numbers of a valid CAF file.

### Chilean electronic document sequence management

* Added `_get_last_sequence` method to `account_move.py` to ensure that the folio number used for Chilean electronic documents (DTE) is valid and corresponds to an available CAF. If no CAF is available for the current folio, the sequence is reset using the document type's prefix and starting number.

### Certificate model validation

* Made `subject_serial_number` a required field in the `Certificate` model, enforcing that every certificate has a valid owner document and improving data integrity. We made this change to prevent the field being empty after loading the certificate in Odoo, since it is required by the SII to validate invoices.

Steps to reproduce:
1. Go to Rental module > Configuration > Enable Rental Transfer
2. Create a product and Update quantity by assigning "By Unique Serial Number"
3. Create a rental order
4. Unhide the "Reserved Lot" field, select the lot created earlier, and confirm
5. Open the Delivery(Stat button), assign lots to both deliveries
6. Create a second rental order (same or different user), assign the same lot, confirm, and process delivery
7. Create a third rental order, enter the same reserved lot → traceback occurs

Issue:
- Traceback with error `ValueError: Expected singleton: stock.move(88, 90)`.

Cause:
- The compute method `_compute_available_reserved_lots` accessed `move_id.date_deadline` directly, assuming a singleton. When multiple stock moves existed for the same lot, it triggered a singleton error.
- When the same lot is linked to more than one delivery, the system crashed when checking available reserved lot.

Solution:
- Handled multiple stock.move.line records per lot by iterating over them instead of assuming a singleton.
- Replaced direct access to move_id.date_deadline with an any() check to safely evaluate deadlines.
- This prevents singleton errors when the same lot is linked to multiple deliveries and ensures correct availability calculation.
 
opw-4963263

Forward-Port-Of: odoo/enterprise#94299

## Issue:
When you use the Smart button `Quality Checks` on a `stock.move` to validate QC, marking a test as Fail doesn't move the `stock.move` to the failing location even if the QC is now failed
This affects all quantity-based checks (Measure or Pass/Fail)

## Cause:
The `do_fail()` method marks the check as failed but does not call `_move_line_to_failure_location()`, so the move line stays in the original location

## Fix:
Trigger the failure wizard when failing a QC via the buttons
This allows the user to confirm the failure and select the appropriate failing location if multiple are configured

## Steps to reproduce:
- Enable Storage Locations in Settings
- Create a Product and a Quality Point (Product: Quality, Operations: Receipt, Control per: Quantity, Type: Measure, Tolerance: 0.0 to 1.0, Failure Locations: WH/Failure)
- Create a New Receipt for the Product and Mark as Todo
- Open 'Quality Checks' via the Smart button, select the QC, enter a measure value above the tolerance (e.g., 2.0), and click Measure.
- The QC should be marked as failed
- Before the fix, the details of the line in the Receipt doesn't change to the failing location
You can also do the same flow with a QP of type Pass/Fail and the Fail button

opw-4920391

Description of the issue/feature this PR addresses:

After a refactor, the month view no longer displayed homeworking locations as in previous versions. This PR fixes the issue and adapts the component using the updated version of the FullCalendar library.

Also fixes a small issue of when different locations with same icons are grouped together when they shouldn't

Current behavior before PR:

All days in the calendar month view displayed the 'Set location' button, regardless of whether a location record existed for the day or not.

Locations of a different type sharing the same icon (Office, Building 1...):

<img width="262" height="135" alt="before" src="https://github.com/user-attachments/assets/51745152-5f90-4917-9627-07aa0959eb3d" />

Desired behavior after PR is merged:

Locations are shown in the month view, and can be interacted with in the same way as in the week/day views, both for single and multicalendar:

<img width="1230" height="504" alt="multicalendar" src="https://github.com/user-attachments/assets/34108f57-2c25-400e-9fbe-106e2233c677" />

<img width="1232" height="382" alt="singlecalendar" src="https://github.com/user-attachments/assets/f4a0cf32-636f-49ce-a4cc-e53a9ac45643" />

Locations of a different type sharing the same icon:

<img width="256" height="132" alt="after" src="https://github.com/user-attachments/assets/643dd304-aeeb-48ec-abef-755e3eb5fdf0" />

---
Task ID: 5215931

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

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

## Versions
18.0 to saas-18.3
Fixed by 7b56a6afda919f3c09d08eb1256416e0a2b4b1d9 introducing a new logic with https://github.com/odoo/odoo/blob/26f9cab34a8cd594192d9e2a844494196b9ca5b6/addons/sale/controllers/product_configurator.py#L329

## Issue
Duplicating an attribute on a product leads to a traceback when adding the product to a SO.

## Steps to reproduce
*Ensure variants are activated in the settings*
- Create a new test product:
  - Attributes & Variants (on 2 distinct lines):
    - "Brand": 1;
    - "Brand": 2 & 3.
- Create a new SO:
  - Add the test product.

## Cause
The product has 2 attribute lines referring to the same attribute. As both attribute lines point to the same attribute, `ptals.attribute_id.read()` returns only one value for two ptals. The `zip()` call therefore drops the extra ptal, producing an incomplete mapping. When the configurator later tries to access this missing ptal entry, it crashes https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/sale/controllers/product_configurator.py#L321.

opw-5373672

In some case, a database can be in a state where some auto install module are not installed
- when the user uninstall a module
- when module was added in stable and a database was created before the addition.

It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules.

This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested.

This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules.

It is open to discussion to change this to a config option, with or without a module list

**Initial solution (alternative to avoid a config)**
--dev skipautoinstall

**Current solutions**
(command line param)
--skip-auto-install

**Maybe in the future but unlikely**
(more flexible)
--skip-auto-install=all
--skip-auto-install=web_enterprise,iap

(krma suggestions)
--skip-auto-install=*
--skip-auto-install=web_*,iap

Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places)

Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust.

Steps to reproduce:

In a module, add a field with tracking=True on any model
Change this field on any record, to force the creation of a tracking value
Remove the field from the code
Update the module
Result:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/service/server.py", line 1313, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/odoo/modules/registry.py", line 114, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/odoo/modules/loading.py", line 536, in load_modules
    env['ir.model.data']._process_end(processed_modules)
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2558, in _process_end
    self._process_end_unlink_record(record)
  File "/home/odoo/custom/odoo/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
    return super()._process_end_unlink_record(record)
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2487, in _process_end_unlink_record
    record.unlink()
  File "/home/odoo/custom/odoo/addons/mail/models/ir_model_fields.py", line 52, in unlink
    'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
  File "/home/odoo/custom/odoo/addons/mail/models/models.py", line 181, in _mail_track_get_field_sequence
    self._fields[fname], 'tracking',
KeyError: 'field_name'




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

In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an Access Error when trying to open an invoice. Among the Accounting groups, only  *Accounting / Read-only* does not inherit from *Accounting / Invoicing*, which means that only the users in *Accounting / Read-only* could not access the invoices.

By granting read rights to both *Accounting / Invoicing* and *Accounting / Read-only*, we ensure that any user belonging to an Accounting group can see the invoices from the Veri\*factu module.

### Steps to reproduce:
1. Install *Accounting* (`accountant`) and *Spain - Veri\*Factu* (`l10n_es_edi_verifactu`).
2. Go to Settings > Users & Companies > Users and select a user.
3. In the *Access Rights* tab, set the user's *Accounting* access right to *"Read-only"*.
4. Log out, then log back in as the user selected in step 2.
5. Go to Accounting > Customers > Invoices and select any invoice.
6. An access error pops up.

opw-5343391