**[FIX] handle Turkey timezone when tzdata-legacy not installed**

In #236660 we switched from pytz to zoneinfo.

The library `pytz` has `Turkey` in **pytz.all_timezones_set**. 
On the other hand starting from ubuntu 24.04 as tzdata was split and `Turkey` was [moved](https://documentation.ubuntu.com/release-notes/24.04/#tzdata-package-split) out of tzdata to tzdata-legacy. 

If we run a db which has reference to `Turkey` timezone, on a server which is ubuntu 24.04 and tzdata-legacy not installed, we will get an error as we did not have fallback for `Turkey` while we have for `Türkiye`. Because zoneinfo will not have `Turkey` in `zoneinfo.available_timezones()`

Issue was discovered during upgrade of db which has res.partners with timezone=`Turkey` from 19.0 to saas~19.1. The upgrading docker container was nobel and it did not have tzdata-legacy.

For fixing the issue we added fallback for `Turkey`. 
Tbh I do not think we need a fallback for `Türkiye` but I wanted to not change the old behaviour.


###

**[FIX] handle America/{Catamarca,Godthab} timezones**

As we moved from `pytz` to `zoneinfo` in **saas~19.1**
we have 2 more timezones which were existing in `pytz`
but not in `tzdata` adn we do not have fallback for them.
They are in `tzdata-legacy`:
- America/Catamarca
- America/Godthab

We added fallback for them.
We already have a failing upgrade request because of
America/Catamarca.

Turkey:
```
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 742, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_thread.py", line 495, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 503, in _compute_recurrence
    event_values = event._get_recurrence_params()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1341, in _get_recurrence_params
    event_date = self._get_start_date()
                 ^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1573, in _get_start_date
    return start.replace(tzinfo=UTC).astimezone(ZoneInfo(self.event_tz)).date()
                                                ^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Turkey'
```

Catamarca:
```
Traceback (most recent call last):
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 2735, in read
    self._origin.fetch(fields)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 3067, in fetch
    fetched.mapped(field_name)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5479, in mapped
    return [getter(record) for record in records]
            ^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1794, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1965, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/res_users.py", line 455, in _compute_tz_offset
    user.tz_offset = datetime.datetime.now(ZoneInfo(user.tz or 'UTC')).strftime('%z')
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key America/Catamarca'
```

tbg-2529

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#256821

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#114363
Forward-Port-Of: odoo/enterprise#113408

### Steps to reproduce:

- Create a button, set its URL to #, and click Apply.
- Place the cursor right after the link.
- Press Backspace until the button/link is removed.
- Entire editor also gets removed.

### In previous version:

- Issue is due to [1](https://github.com/odoo/odoo/commit/7685e562b1036d08724ba91ed5064b6fe20c2ce2
) change in `isEmptyBlock` (because of `isButton`).
- When we had `<a>#[]</a>` and pressed backspace, `deleteRange` was called.
- Then `fillShrunkBlocks` ran and `isEmptyBlock` returned true (no isButton).
- So `<br>` was added and block never became fully empty.

### In current version:

- Because of `isButton` condition, some empty blocks are not treated as empty.
- So `<br>` is not added & block stays actually empty. Then `removeFEFF` runs & `nodeSize` becomes false &  `cleanEmptyAncestors` removes parent even editable.

### After this PR:

- Case like `<a>[]</a>`, backspace is handled by override which directly removes `<a>`. Since this skips `deleteRange`, manually call `fillShrunkBlocks` there.
- Now after removing `<a>`, block is properly detected as empty and `<br>` gets added.

task-6109145

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

Forward-Port-Of: odoo/odoo#259055

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#114757
Forward-Port-Of: odoo/enterprise#111846

Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.

## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
    - Car with (Red and Blue Color attributes)
    - Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm

## Observed Behavior:
ZeroDivisionError: float division by zero

## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.

The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.

**Why this causes a traceback when unbuilding?**

When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.

As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.

Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.

However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.

[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800 
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647

## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.

This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.

This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.

Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)

opw-6044754

Forward-Port-Of: odoo/odoo#260639
Forward-Port-Of: odoo/odoo#255981

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#113231
Forward-Port-Of: odoo/enterprise#111833

[FIX] website: translate links inline on media replacement
    
    On the website builder, files added through the `/file` command would go
    through the domPlugin `insert` method, which would call
    `before_insert_processors` and apply `.o_translate_inline` as expected.
    But there is another flow to add a document on the page: replace an
    image (or video, or icon), then select the "Documents" tab and upload
    a file. With this flow, `insert` is not called, so we have to add the
    class through some other resource.
    
[FIX] html_editor: target documents with right class
    
    The class `.o_image` was still associated with documents (in the context
    of the file selector) and the expected tag of a document was `A`, in
    spite of it not being true in `html_editor` since the introduction of
    the file box in [1].
    
    This has also been updated in the website builder since the introduction
    of the `html_builder` module in 18.4, which swapped uses of `web_editor`
    components for `html_editor`.
    
    As a side-effect, in website, a double click on a file did not open the
    media dialog on the "document" tab, unlike other media (images, videos,
    icons). In such a case, the file was also not shown as already selected
    in the media dialog (because it targetted the wrong tag name). Both of
    those behaviors were lost as we used the new file box design in 18.4.
    
    [1]: https://github.com/odoo/odoo/commit/7f9afa21dffba2f74f9fb8a68809db4af6c7c225
    
task-5876278

Forward-Port-Of: odoo/odoo#261015
Forward-Port-Of: odoo/odoo#245904

Steps to reproduce:
-------------------
1. Create a new trial DB with demo data and French localization
2. Archive Marc Demo if you create the DB locally (this happens 
   automatically on Odoo.com trials due to the user seat limit probably)
3. Select the demo company only (unselect the main one)
4. Open Accounting and click the Purchases journal from the dashboard

Access Error about reading Marc Demo.
Unarchiving him would work around this issue.

Why the bug
-----------
demo_invoice_deferred and demo_bill_deferred set invoice_user_id to Marc
Demo (base.user_demo). Marc Demo belongs to the main company and can't be
read from another company when archived.

On 19.0 these records only existed in the main company, where Marc Demo
is accessible. Commit 9aed0c0135d7b084dee544c6566fad96c62ec1fd migrated the demo to `template`, so now
they are created in every company.

Still, it only breaks because of commit [3732ca85b03b](https://github.com/odoo/odoo/commit/3732ca85b03b), which added
write_date to the avatar widget for cache busting. Before, the widget
only needed display_name (read with sudo), so the rule was not checked.

The fix
-------
Use base.user_admin for demo_invoice_deferred (never archived, stays
readable from any company), and False for demo_bill_deferred (a bill has
no salesperson).

opw-6106870

Why this commit:
When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view.

e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12.
So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices  after 12 PM.

After this commit:
To resolve this discrepancy we use the context_today date to get the user
 local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too.
 
 Steps to reproduce (Possible in runbot) :
1. Select etc/GMT-12 timezone in preferences
[when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)]
2. Create a PO and Validate the quantity received.
3. Go to accounting>review>bills to receive.
4. the newly created PO won't be listed here.

OPW: 6083526

Forward-Port-Of: odoo/enterprise#114763

Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels

Steps to reproduce:
1. Install Sales
2. Log in as Marc Demo
3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu
4. An access error is raised Same issue happens for Product Variants

Issue:
https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling
`_can_execute_action_on_records`:
https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239

Solution:
Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed
This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2

opw-6111333

Forward-Port-Of: odoo/odoo#260513
Forward-Port-Of: odoo/odoo#260342

**[FIX] handle Turkey timezone when tzdata-legacy not installed**

In #236660 we switched from pytz to zoneinfo.

The library `pytz` has `Turkey` in **pytz.all_timezones_set**. 
On the other hand starting from ubuntu 24.04 as tzdata was split and `Turkey` was [moved](https://documentation.ubuntu.com/release-notes/24.04/#tzdata-package-split) out of tzdata to tzdata-legacy. 

If we run a db which has reference to `Turkey` timezone, on a server which is ubuntu 24.04 and tzdata-legacy not installed, we will get an error as we did not have fallback for `Turkey` while we have for `Türkiye`. Because zoneinfo will not have `Turkey` in `zoneinfo.available_timezones()`

Issue was discovered during upgrade of db which has res.partners with timezone=`Turkey` from 19.0 to saas~19.1. The upgrading docker container was nobel and it did not have tzdata-legacy.

For fixing the issue we added fallback for `Turkey`. 
Tbh I do not think we need a fallback for `Türkiye` but I wanted to not change the old behaviour.


###

**[FIX] handle America/{Catamarca,Godthab} timezones**

As we moved from `pytz` to `zoneinfo` in **saas~19.1**
we have 2 more timezones which were existing in `pytz`
but not in `tzdata` adn we do not have fallback for them.
They are in `tzdata-legacy`:
- America/Catamarca
- America/Godthab

We added fallback for them.
We already have a failing upgrade request because of
America/Catamarca.

Turkey:
```
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 742, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_thread.py", line 495, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 503, in _compute_recurrence
    event_values = event._get_recurrence_params()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1341, in _get_recurrence_params
    event_date = self._get_start_date()
                 ^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1573, in _get_start_date
    return start.replace(tzinfo=UTC).astimezone(ZoneInfo(self.event_tz)).date()
                                                ^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Turkey'
```

Catamarca:
```
Traceback (most recent call last):
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 2735, in read
    self._origin.fetch(fields)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 3067, in fetch
    fetched.mapped(field_name)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5479, in mapped
    return [getter(record) for record in records]
            ^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1794, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1965, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/res_users.py", line 455, in _compute_tz_offset
    user.tz_offset = datetime.datetime.now(ZoneInfo(user.tz or 'UTC')).strftime('%z')
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key America/Catamarca'
```

tbg-2529

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#256821

### Steps to reproduce:

- Create a button, set its URL to #, and click Apply.
- Place the cursor right after the link.
- Press Backspace until the button/link is removed.
- Entire editor also gets removed.

### In previous version:

- Issue is due to [1](https://github.com/odoo/odoo/commit/7685e562b1036d08724ba91ed5064b6fe20c2ce2
) change in `isEmptyBlock` (because of `isButton`).
- When we had `<a>#[]</a>` and pressed backspace, `deleteRange` was called.
- Then `fillShrunkBlocks` ran and `isEmptyBlock` returned true (no isButton).
- So `<br>` was added and block never became fully empty.

### In current version:

- Because of `isButton` condition, some empty blocks are not treated as empty.
- So `<br>` is not added & block stays actually empty. Then `removeFEFF` runs & `nodeSize` becomes false &  `cleanEmptyAncestors` removes parent even editable.

### After this PR:

- Case like `<a>[]</a>`, backspace is handled by override which directly removes `<a>`. Since this skips `deleteRange`, manually call `fillShrunkBlocks` there.
- Now after removing `<a>`, block is properly detected as empty and `<br>` gets added.

task-6109145

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

Forward-Port-Of: odoo/odoo#259055

Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.

## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
    - Car with (Red and Blue Color attributes)
    - Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm

## Observed Behavior:
ZeroDivisionError: float division by zero

## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.

The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.

**Why this causes a traceback when unbuilding?**

When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.

As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.

Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.

However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.

[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800 
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647

## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.

This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.

This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.

Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)

opw-6044754

Forward-Port-Of: odoo/odoo#260639
Forward-Port-Of: odoo/odoo#255981

Steps to reproduce
1. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415

Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.

opw-5895622

Forward-Port-Of: odoo/odoo#255273

The `o_mail_wrapper_td` element in the `ThemeWrapper` template had a hardcoded `bg-white` class. The intent was for the wrapper background to default to white, but doing it this way meant the color didn't participate in the CSS variable system. Whenever a user set a custom Content Background color and a border-radius on a text block, the corners would reveal white underneath instead of the actual Content Background color.

Removed the `bg-white` class from the template and set white as the proper default for the `--wrapper-background-color` variable instead, so the wrapper is still white by default but correctly responds to the Content Background color picker.

Steps to reproduce:
1. Create a new Mailing
2. Set the Content Background color to something other than white
3. Add a Text block
4. Set a border-radius value on the block

=> white shows behind the rounded corners instead of the Content Background

Ticket [link](https://www.odoo.com/odoo/project.task/5868955) 
opw-5868955

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

Forward-Port-Of: odoo/odoo#247808

Creating or updating an attendance record resets previously approved overtime entries in the same week back to the 'to_approve' status.

### **Steps to reproduce:**
1) Install Attendance with demo data.
2) Set 'Extra Hours Validation' to 'Approved by Manager' in settings. 
3) Ensure an overtime rule is set for the Admin user. 
4) Create an attendance for Admin with some overtime.
5) Navigate to management and approve overtime.
6) Create another attendance with overtime for Admin in the same week. 
7) Navigate back to management.

### **Observed Behavior:**
Previously approved overtime reappears in the list, requiring approval again.

### **Expected Behavior:**
Previous overtime should remain in the 'approved' status, provided its calculated duration has not changed.

### **Root Cause:**
When an attendance is added or modified, the [_get_overtimes_to_update_domain](https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/hr_attendance/models/hr_attendance.py#L268-L286) method
evaluates the entire week regardless of the ruleset. This means any
daily attendance update wipes and recreates the entire week.

### **Fix:**
Check the ruleset of the employee. If no rule has `quantity_period` set to
**'week'**, restrict the domain to the specific days of the attendances being
modified, rather than the entire week.

**opw-6054497**

Forward-Port-Of: odoo/odoo#259872
Forward-Port-Of: odoo/odoo#256281

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114730
Forward-Port-Of: odoo/enterprise#113083

Steps to reproduce:
1- Install invoicing app
2- Add French language in the settings
3- Create a customer with language set as French
4- Create a product and define french translations of the name and the description in Sales tab
5- Create an invoice for that customer and choose the product you created
6- You will find the translated product name and description under the product name
7- Edit the description, save and preview the invoice
8- The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR]

Description of the issue:
When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase.

Expected behaviour:
User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name.

Why this happens?
1- When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description.
2- After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.]

Fix:
Use the product name returned in the label for trimming and concatenation to handle both original/translated text scenarios.

References:
original PR: #248401
partial revert: #254158

opw-5480494

Forward-Port-Of: odoo/odoo#256837

Steps to reproduce:
- Create a storable product "P1"
- Update on-hand quantity to 2 units
- Create a delivery with 2 units of P1 and keep it in draft state

Problem:
The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move.

Explication:
For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty`

In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty`

So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available.

https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31

Solution:
When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available.

opw-5159142

Forward-Port-Of: odoo/odoo#258504
Forward-Port-Of: odoo/odoo#257354

## Overview
Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS data loading flow.

## Steps to Reproduce
1. Install `pos_blackbox_be`
2. Open POS  
3. Access the Mobile Menu (QR code) or Self-Ordering page  

## Current Behavior
- A traceback is raised  
- The interface does not load  

## Root Cause
The method `_load_pos_self_data_fields` returns the field:
iface_fiscal_data_module

However, from SaaS-19.1 this field was renamed to:
iot_fdm_be_id

This mismatch causes the POS self-ordering data loading to fail.

## Fix
Updated the returned field to match the new field name.

# Before
return fields + ['iface_fiscal_data_module']

# After
return fields + ['iot_fdm_be_id']

## Impact
- Restores proper loading of Mobile Menu (QR ordering)  
- Fixes Self-Ordering interface crash

opw-6044883  

## Reproduction Video
https://drive.google.com/file/d/1R5TYVIXvtts12YLF5iB4GKZirMZePoGr/view?usp=sharing

Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.

## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
    - Car with (Red and Blue Color attributes)
    - Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm

## Observed Behavior:
ZeroDivisionError: float division by zero

## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.

The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.

**Why this causes a traceback when unbuilding?**

When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.

As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.

Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.

However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.

[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800 
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647

## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.

This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.

This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.

Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)

opw-6044754

Forward-Port-Of: odoo/odoo#260639
Forward-Port-Of: odoo/odoo#255981

In Mexico, the basic salary must be calculated based on the total calendar days of the period. This ensures that both worked days and non-working days (e.g. Sundays) contribute equally to the total payment. This calculation also applies to the daily schedule, as the proportional daily wage must be divided equivalently across the hours of the day.

Current behavior:
When an employee has an unpaid leave, the basic salary is incorrectly prorated using only the registered days/hours.
Example: For a monthly wage of 30,000 MXN in a month with 22 scheduled days (21 attendances + 1 unpaid leave), the implicit daily rate becomes 1,363.63 (30,000 / 22). This leads to an incorrect basic salary of 28,636.36 MXN for the days worked. This also happens with unpaid leave for x hours, e.g., for 2 hours, the unpaid leave is calculated as 2 hours * (30,000 / (22 days * 8 hours)) = 340.90 MXN, which is incorrect.

Expected behavior:
The basic salary should be derived from the full period (e.g., 30 days for a month, 15 for a bi-weekly period).
Example: For a 30,000 MXN wage, the daily rate should be 1,000 MXN (30,000 / 30 days). If there is 1 unpaid leave, the basic salary should be 29,000 MXN (29 days * 1,000 MXN), regardless of the number of scheduled working days in the calendar. For unpaid leaves by hours, e.g., for 2 hours, the unpaid leave should be calculated as 2 hours * (30,000 / (30 days * 8 hours)) = 250.00 MXN.

To achieve this, the calculation of the days in the `_get_worked_day_lines` is:
* Adjust worked days/hours for out-of-contract entries where necessary, ensuring that rest days(Sundays) are included in the count.
* Get all worked hours in the lines.
* Calculate the number of days to pay based on the total hours and the hours per day.

### Case: payslip does not cover the complete pay period
Current behavior:
If a payslip is created for a partial period, the total amount is the full period wage.

Expected behavior:
The total amount should be pro-rated based on the days of the period. For example, if a payslip is created for 25 days(with a monthly schedule pay), the total amount should be the daily salary multiplied by 25 days.

To achieve this, `_compute_amount` is updated to calculate the wage based on the `l10n_mx_daily_salary`.

Changes on tests:
* Add:
  * `test_monthly_payslip_with_partial_leave`, `test_partial_payslip`, `test_partial_payslip_new_hire_month_31_days` and `test_partial_payslip_new_hire_month_28_days`.
  * `test_hourly_payslip_by_attendance` to validate when `Work Entry Source` is set to "attendance".
* Update:
  * `test_hourly_payslip`, `test_monthly_payslip` and `test_partial_payslip_new_hire` to align with the new calculation.
  * Adjust payslips dates to match the `schedule_pay` in `test_regular_payslip_subsidy` and `test_weekly_schedule_pay_no_code`
  * Fix a one-day difference in `TestMxEdiHrPayrollCommon`(16 days instead of 15 days for a bi-weekly schedule), and update the corresponding CFDI values.
* Refactor tests and add new helpers.

### Error on [warning issues generation][1] and [`_compute_is_wrong_duration`][2]

The warning: `"The duration of the payslip is not accurate according to the structure type."` appears with these custom periods for Mexican Payroll, although the period is correct:
* `10_days`
* `14_days`
* `bi-weekly`

Steps to replicate:
* Install `l10n_mx_hr_payroll` module.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Employees and open "Cesar Osbaldo Cruz Solorzano".
* Click on "Payroll" tab, change the "Pay Schedule" to any option listed above, for example "Bi-weekly".
* Go to Payroll > Payslips > Payslips and create a new pay run.
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and the Period '01/01/2026 -> 01/15/2026'.
* Click on "Continue", select Cesar and click on "Select".
* It appears the warning issue.

Problem:
The warning is raised because of `slip.date_from + slip._get_schedule_timedelta() != slip.date_to` condition, because `_get_schedule_timedelta` function calls [`self._schedule_timedelta(schedule, self.date_from)`][3] without the `country_code` argument.
In the Mexican Payroll [_schedule_timedelta is overriden][4] but it is necessary to call it with the country code to use the custom periods; similar to how the [`date_end` is computed][5].

Solution:
Call `_get_schedule_timedelta` passing the `country_code`

[1]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1367
[2]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1454
[3]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L275
[4]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/l10n_mx_hr_payroll/models/hr_payslip.py#L58
[5]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip_run.py#L211

target: 19.0
task-6073601

Forward-Port-Of: odoo/enterprise#112524

The `o_mail_wrapper_td` element in the `ThemeWrapper` template had a hardcoded `bg-white` class. The intent was for the wrapper background to default to white, but doing it this way meant the color didn't participate in the CSS variable system. Whenever a user set a custom Content Background color and a border-radius on a text block, the corners would reveal white underneath instead of the actual Content Background color.

Removed the `bg-white` class from the template and set white as the proper default for the `--wrapper-background-color` variable instead, so the wrapper is still white by default but correctly responds to the Content Background color picker.

Steps to reproduce:
1. Create a new Mailing
2. Set the Content Background color to something other than white
3. Add a Text block
4. Set a border-radius value on the block

=> white shows behind the rounded corners instead of the Content Background

Ticket [link](https://www.odoo.com/odoo/project.task/5868955) 
opw-5868955

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

Forward-Port-Of: odoo/odoo#247808

Steps to reproduce:
1- Install invoicing app
2- Add French language in the settings
3- Create a customer with language set as French
4- Create a product and define french translations of the name and the description in Sales tab
5- Create an invoice for that customer and choose the product you created
6- You will find the translated product name and description under the product name
7- Edit the description, save and preview the invoice
8- The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR]

Description of the issue:
When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase.

Expected behaviour:
User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name.

Why this happens?
1- When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description.
2- After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.]

Fix:
Use the product name returned in the label for trimming and concatenation to handle both original/translated text scenarios.

References:
original PR: #248401
partial revert: #254158

opw-5480494

Forward-Port-Of: odoo/odoo#256837

### Issue:
When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead

For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040`

### Cause:
The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report

### Note:
The example above uses a Belgian fiscal position to reproduce the issue

Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default

A related fix makes the Intervat settings available in that case
Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15

### Steps to reproduce:
- Disable demo data and install `accountant`
- Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040)
- Click the alert to install the Belgian taxes
- Create and confirm an invoice for a Belgian customer:
  - Fiscal Position: Belgium
  - Any product with a Belgian tax
  - Invoice Date: 01/01/2026
- Open the Tax Report and select `VAT Return (BE)` for January
- Click `Returns` and select the full year
- Mark the December return as Completed from the three-dot menu
- Review January and fill the missing company data (TIN: 1111111, phone and email)
- Click `Validate -> Lock -> Submit`

### Before the fix:
The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`).

opw-6076540

Forward-Port-Of: odoo/enterprise#112610

**Steps to reproduce:**
* Install  `stock` module.
* Go to  Settings and enable: 
     * Storage Locations (Warehouse).
     * Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
     * Set Type of Operation to Internal Transfer.
     * In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
     * Select the newly created Operation Type.
     * Add the created Product with quantity 4.4.
     * Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
     * Select the same Operation Type.
     * Add the same Product with quantity 48.8.
     * Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
     * Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.

**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).

**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:

https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205

- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.

**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats

- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.

---
opw-5932329

Forward-Port-Of: odoo/enterprise#114040
Forward-Port-Of: odoo/enterprise#110241

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114075

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114730
Forward-Port-Of: odoo/enterprise#113083

Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document.

The problem with that approach is that we will regularly send status updates to DIAN after the invoice was successfully submitted via the status cron here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L484
Those status updates are expected to fail a certain number of times (typically when no commercial status information is available, or in other terms when `l10n_co_dian_commercial_state` is still in `'pending'`).
As a result, an invoice successfully transmitted to DIAN could still end up with a `l10n_co_dian_state` not set to `'invoice_accepted'`.

This leads, among other things to a QR code that cannot be reprinted as the logic here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L225 determines which template to render based on that state.

The issue cannot be easily reproduced or tested as `l10n_co_dian.document` are generated almost only in prod scenarios.

The most common setup where the error happens is for invoices that have 2 DIAN documents:
1. the first (oldest, bottom-most) one reflects acceptance of the invoice sending by DIAN (`state = 'invoice_accepted'`)
2. the second one (most recent, top-most), which reflects the latest query for commercial status update by the cron and which failed (`state = 'invoice_rejected'` and the error message reflects the lack of commercial events)

opw-6108318
opw-5931442
opw-6034035

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114730
Forward-Port-Of: odoo/enterprise#113083

[FIX] documents: scroll to uploaded record

How to reproduce:
- install documents
- open the "All" folder and ensure there is enough folder to not see any file
- open the detail panel
- drag&drop file in that folder
The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel.

We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel.

[FIX] documents: fix icon position in thumbnail

How to reproduce:
- install documents
- open the chatter of a document
- click on log a note, and upload a file
The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border).

We fix here the position the icon/button.

[FIX] documents: fix "you" badge layout

How to reproduce:
- install documents
- change the name of Mitchell Admin to a very long name
- open the share panel owned by Mitchell Admin
The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct).

We fix here the layout of the badge in such configuration.

Task-5152517

### Issue:
Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2
https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf

Importing such files raises an error:
`Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.`

### Cause:
The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent
https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698

The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error

### Steps to reproduce:
- Install `l10n_be_coda` and switch to the `BE company`
- Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data)
Before the fix, the error is trigger

opw-6071761