**Issue**:
Making a product a kit could prevent confirming deliveries.

**Steps to reproduce**:
- Make sure the account application is installed
- Create a product P without kit
- Create a SO and confirm it
- Make the product P a kit
- Validate the delivery associated to the SO
-> A traceback occurs: the record does not exist anymore

**Cause**:
While confirming the delivery:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown

**Aditionnal information**
Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation.
Therefore, no stock valuation errors will be created.

opw-6063602

Forward-Port-Of: odoo/odoo#258403

Steps to reproduce
==================

- Install hr_payroll
- Use a mobile viewport
- Go to Employees
- Open a record
- Switch to the Salary Adjustments notebook tab

=> TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)'

Cause of the issue
==================

The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used)

See

https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212

Solution
========

Since there is no delete action on the kanban view, there is no need for an override.

While we are at it, there was no kanban view defined. Thus a default view was used

https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846

It only contained the field description. Since that one is optional, records without a description were almost invisible..

Thus we also add a basic kanban view

opw-6047295

Forward-Port-Of: odoo/enterprise#113317

### 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#111846

Issue:
----------------------------------------
Creating a night shift from a template produces a shift spanning over one additional day.

Steps to reproduce:
----------------------------------------
- Create a planning shift template form 23h to 1h the next day (2h)
- It must have a span over 2 working days
- Create a shift and use this template
- The shift spans over one more day

Cause:
----------------------------------------
In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day.

Solution:
----------------------------------------
We should call `plan_days()` without the hour specified so we make sure the first day is included in the count.

opw-6134844

Forward-Port-Of: odoo/enterprise#114616

[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#259840
Forward-Port-Of: odoo/odoo#245904

Steps to produce:
---
- Install the `Sales` module.
- Go to `Invoicing > Configuration > Payment Terms`.
- Open `Immediate Payment` and enable Early Discount.
- Set `Reduced Tax` to `Always (upon invoice)`.
- Go to Invoicing > Configuration > Taxes.
- Create a 21% tax with `Tax included`.
- Create a product with a sale price of 7.50 and assign the tax.
- Create a Sale Order with this product > Set Immediate Payment as payment term.

Issue:
---
- The untaxed amount is computed as 6.22 instead of 6.20.

Root cause:
---
- At [1], in `_add_base_lines_for_early_payment_discount`, the base lines generated for early payment discount were missing the `special_mode='total_excluded'`.
- Consequently, the tax engine interpreted these amounts as tax-included and attempted to recompute the untaxed base, resulting in an incorrect untaxed amount.

Solution:
---
- Add `special_mode='total_excluded'` to the base lines created for early payment discount computation.
- This ensures the discount amounts are treated as already tax-excluded.

[1]https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/addons/sale/models/sale_order.py#L515-L550

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

Forward-Port-Of: odoo/odoo#260480
Forward-Port-Of: odoo/odoo#255724

Version:
----------
- saas-19.2+

Steps to reproduce:
----------------------

1. Install `stock_dropshipping` and `sale_management` modules.
2. Create a Customer (res.partner) with a proper address block.
3. Create a dropship product (route: Dropship).
4. Create a Sales Order for the created customer.
5. Add the dropship product.
6. Confirm the Sales Order to generate a Purchase Order.
7. Open the generated PO/RFQ and print the report.

Issue:
------
The shipping address is missing in the printed PO/RFQ report.

Cause:
--------

The `t-call` syntax is updated to use the new semantic, which passes
values *as attributes/parameters* on the `<t>` (with `t-call`) tag itself,
instead of relying on nested `t-set` directive.

- Old (Deprecated): Used nested `<t t-set='var_name' t-value='x'/>` tags
inside the calling element to define variables.
- New: Variables are passed as attributes directly on the element where
the `t-call` is located (e.g., `<t t-call='module.template' var_name='x'/>`).

A warning is added to alert developers when using the old deprecated
syntax.

see Reference: https://github.com/odoo/odoo/pull/197296

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/c6892b30-10d6-4fb4-881c-1433d4fe07a0" />
  </div>
  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/6109fcc3-5773-44a8-b07b-6566ed855d3f" />
  </div>
</details>


> NOTE: We can also move test into `purchase_stock`

----

opw-6075017

---

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

edit : the issue was fixed by https://github.com/odoo/odoo/pull/257103
So this commit only contains these use cases tests

**Steps to reproduce:**
- enable consignement setting
- create a tracked avco product with a cost of 10
- click on the quantities smart button and then 
"update quantity" to open the quants view
- create one line with a quantity of 1 and no owner
- create one line with a quantity of 1 and an owner 
outside the company

**Current behavior:**
problem A: 
open the 'stock' view and look for your product, 
the unit cost is 5

problem B: 
navigate back to the quants view of the product, unhide
the value column, the value is 5 for the non consigned
quant

**Expected behavior:**
problem A: 
the unit cost should be 10 (because consigned product 
shouldn't be taken into account when computing the 
unit cost)

problem B: 
the non consigned quant value should be 10 
for the same reason 

**Cause of the issue:**
problem A: 
Inside _compute_value(), to compute total_value_by_company_id, 
we use _with_valuation_context()
https://github.com/odoo/odoo/blob/6c107cd70e2228d3428e53cf8095aba17f678d8a/addons/stock_account/models/product.py#L196-L203
which excludes consigned products
https://github.com/odoo/odoo/blob/6c107cd70e2228d3428e53cf8095aba17f678d8a/addons/stock_account/models/product.py#L362-L364
So when we iterate through 'products' and fetch 
qty_available for our product the value is 
going to be 1. 

But when computing avg_cost at the end of 
the method, we iterate through 'self', so we 
don't have this context anymore and the value 
of qty_available is 2. 
https://github.com/odoo/odoo/blob/6c107cd70e2228d3428e53cf8095aba17f678d8a/addons/stock_account/models/product.py#L271-L273
That's because qty_available is computed 
with _compute_quantities() which depends on 
context (including owner_id)
https://github.com/odoo/odoo/blob/53f7d1dd2f972921ba91f6083a49f50749a3f503/addons/stock/models/product.py#L148-L152

problem B: 
when computing the value of the quant, 
there is no context specifying that the consigned
quantities should be excluded
https://github.com/odoo/odoo/blob/53f7d1dd2f972921ba91f6083a49f50749a3f503/addons/stock_account/models/stock_quant.py#L61-L62

opw-6049413

Forward-Port-Of: odoo/odoo#257013

### 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:
-------------------
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 Sales journal from the dashboard

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

Why the bug
-----------
The sales demo invoices 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 this did not break because the avatar widget only needed
display_name (read with sudo). Commit https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4 added write_date to it
for cache busting, so now the read is real and the rule fails.

The fix
-------
Use base.user_admin instead: it's never archived, so it stays readable
from any company.

opw-6106870

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

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#260517
Forward-Port-Of: odoo/odoo#255478

When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times.

Steps to reproduce:
-------------------
* Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule"
* Create three products : final, semi, component
   - final: mtso, manufacture
   - semi: mtso, manufacture
   - component: mtso, buy, on hand quantity to 4
* Create a bom for final:
   - 10 components
   - 1 semi
* Create a bom for semi:
  - 10 components
* Create and confirm a MO for 1 "final"
-> Issue the purchase order is only for 12 components and not 16.

Observation:
-------------
When confirming our MO, it will create a manufacture procurement for the products.
The procurement will recursively create procurements and stock moves for each of its components.
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571
Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity:
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663
And each procurement, if it is of the manufacture type, will create corresponding procurements for their components.

Once all the procurements and stock moves have been created, the stock move will confirmed and assigned.
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629


-> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels.

opw-5514788

Forward-Port-Of: odoo/odoo#253958