When possible, avoid using context keys skipping the whole mail.thread
stack. Since a few years various usage of those keys have been added
through odoo addons quite often without clear purpose in mind when
asked to authors or when reading commit messages. Partly because
people tend to copy-paste code patterns without really understanding
the purpose of those.

See individual commits for more details.

USAGE IN TESTS

Lots of tests use the 'tracking_disable' or 'mail_notrack' context
keys. However I bet most of those are there just because they
were copy pasted, and without any thinking about the usage

 * it is used on non-thread models (which shows writer did not check
   what it was about);
 * it is copy-pasted in multiple unit tests creating one data each
   time (which shows performance are not the matter here as the
   writer could use a setupClass);
 * most usage is done when creating records, although there is no
   tracking at create time. And even if someday tracking at create
   comes back it would not be a performance issue on a test db
   compared to current test workload (too much tests, tours that
   are slow, ...). It also deactivates creation message log and
   initial follower (if not root) but those insert should be fast;
 * mail.thread is part of the real life stack and should be tested
   in functional addons. It notably has an impact on followers
   which means ACLs, partner_id field setup, field computation
   and invalidation, cache usage, ...

Better remove most of them, and keep only relevant one (e.g. batch
creation, simulating environment like Payroll, ...).

Task-6094598
Followup of Task-3645865

Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date.

**Steps to Reproduce:**
- Install the MRP module (with demo data).
- Activate "**Custom Work Order Dependencies**".
- Create a new MO for the _Drawer_ product with _SEC-ASSEM_ BoM.
- Confirm and plan the MO.
- Remove both start and end dates of any dependent operation.
- Manufacturing > Planning > Work Orders > Gantt
- Enable **Auto-Reschedule (Keep Buffer)** and reschedule the first operation (in 'Drill 1').

**Error:**
`TypeError - '>' not supported between instances of 'bool' and 'datetime.datetime'`

**Cause:**
At [1], `date_start` and `date_finished` can both be set to False because a condition that bypasses the UserError when both dates are empty (unlike earlier versions). As a result, during rescheduling, a False value is compared with a datetime, leading to a TypeError at [2].

Fix:
This commit adds a condition before date comparisons to ensure the dates are defined.

[1]: https://github.com/odoo/odoo/blob/3f256437a7e6c124affca8d5304476a67375753f/addons/mrp/models/mrp_workorder.py#L281-L284
[2]: https://github.com/odoo/enterprise/blob/ef2efe113684104032d798b5aa237c67a3bc240a/web_gantt/models/models.py#L484-L491

sentry-7377739830

Forward-Port-Of: odoo/enterprise#112729

When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

Forward-Port-Of: odoo/enterprise#113895
Forward-Port-Of: odoo/enterprise#113521

Currently, an error occurs when user tries to open unassigned opportunities assigned to a team.

Steps to replicate:
- Install `crm` with demo.
- Open `CRM > Sales > Teams` and click `Sales` team.
- Remove the `salesperson` from any lead, then return to `Teams` via breadcrumbs.
- On the kanban card for Sales, click “Unassigned Leads”.

Error:
```
  File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_team.py', line 728, in action_open_unassigned_opportunities
    context = self.env['crm.lead']._evaluate_context_from_action(action)
  File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_lead.py', line 727, in _evaluate_context_from_action
    return literal_eval(context_str)
  File '/home/odoo/src/odoo/saas-19.2/odoo/_monkeypatches/ast.py', line 28, in literal_eval
    return orig_literal_eval(expr)
  File 'ast.py', line 66, in literal_eval
    node_or_string = parse(node_or_string.lstrip(' \t'), mode='eval')
  File 'ast.py', line 52, in parse
    return compile(source, filename, mode, flags,
IndentationError: unexpected indent (<unknown>, line 8)
```

Cause:
- Error occurs after a recent [PR].
- As we called `literal_eval()` on the context string that we passed on to the `act_window` [1], it tries to parse the string using python like rules, the context is received as this:

```
"{\n 'search_default_team_id': [False],
 \n'default_team_id': False,
 \n'default_type': 'opportunity',
 \n'default_user_id': 2,
 \n'show_lead_gen_button': True
 }\n       "
    ^^^^^^^
```

- The extra whitespace/indentation (coming from the `act_window` context definition) makes the string invalid for strict parsing, causing `literal_eval()` to fail.

- Additionally, in the above given context string the `search_default_team_id` and `default_team_id`are  both `False`  because we called `_evaluate_context_from_action()` method on an empty recordset and when we try to [substitute] `active_id` with `self.id`(which is False because we dont have any record) we get another JS Error that is caused by not receiving any results for the search default on team.

Solution:
- Using `strip()` function removed the extra whitespaces.
- Passed the `team_id` through context (as we cant add new parameters to a function in stable) and assigned it in place of `active_id`.

[1]: https://github.com/odoo/odoo/blob/746ea418da2af2a6d36daea4dc544bdf3bc28495/addons/crm/views/crm_team_views.xml#L41-L48
[PR]: https://github.com/odoo/odoo/pull/240202/changes#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2R724
[substitute]: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/crm/models/crm_lead.py#L726

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

Forward-Port-Of: odoo/odoo#259288

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

PR #212726 removed a Many2One field and replaced it with an existing binary field (`l10n_it_edi_attachment_file`) and a new Char field (`l10n_it_edi_attachment_name`) to store E-invoice files as XMLs. This change was made for security reasons.

This pre-existing binary field was already used for importing SDI documents, which caused errors resolved in PR #252806.

The new char field was not set during the SDI import process in PR #212726. This can cause errors when exporting invoice documents, as our code sees content in the binary field and expects the name to also be present. See [`_get_invoice_legal_documents()`](https://github.com/odoo/odoo/blob/f48f221c91b8d123bcaf1c4d8ed6c7dfba763ae6/addons/l10n_it_edi/models/account_move.py#L411).

This commit ensures that the name of an imported SDI document is set in the move's `l10n_it_edi_attachment_name` field.

opw-6023263
[link](https://www.odoo.com/odoo/my-tasks/6023263)

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

Forward-Port-Of: odoo/odoo#258882
Forward-Port-Of: odoo/odoo#257586

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

When possible, avoid using context keys skipping the whole mail.thread
stack. Since a few years various usage of those keys have been added
through odoo addons quite often without clear purpose in mind when
asked to authors or when reading commit messages. Partly because
people tend to copy-paste code patterns without really understanding
the purpose of those.

See individual commits for more details.

USAGE IN TESTS

Lots of tests use the 'tracking_disable' or 'mail_notrack' context
keys. However I bet most of those are there just because they
were copy pasted, and without any thinking about the usage

 * it is used on non-thread models (which shows writer did not check
   what it was about);
 * it is copy-pasted in multiple unit tests creating one data each
   time (which shows performance are not the matter here as the
   writer could use a setupClass);
 * most usage is done when creating records, although there is no
   tracking at create time. And even if someday tracking at create
   comes back it would not be a performance issue on a test db
   compared to current test workload (too much tests, tours that
   are slow, ...). It also deactivates creation message log and
   initial follower (if not root) but those insert should be fast;
 * mail.thread is part of the real life stack and should be tested
   in functional addons. It notably has an impact on followers
   which means ACLs, partner_id field setup, field computation
   and invalidation, cache usage, ...

Better remove most of them, and keep only relevant one (e.g. batch
creation, simulating environment like Payroll, ...).

Task-6094598
Followup of Task-3645865

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

[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

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/odoo#257720

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/enterprise#113047

Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1].

To do so it limits the opacity to the layout actions, but the style was not applied because ActionList has more CSS specificity that requires using `--o-mail-ActionList-Button-opacity` variable for the non-hover opacity value. Since this was not defined, this default to opacity 100%, thus not applying the reduced opacity when not mouse-hovering.

This commit fixes the issue with `--o-mail-ActionList-Button-opacity` of `.75`, so that opacity is slightly reduced when no mouse-hovering.

[1]: https://github.com/odoo/odoo/pull/259866

Before / After (mouse-hover on "Picture-in-Picture", see lack of visual distinction)

<img width="58" height="32" alt="Screenshot 2026-04-22 at 11 21 47" src="https://github.com/user-attachments/assets/e04b0f8c-c754-4ea4-8870-752610418587" />
<img width="57" height="28" alt="Screenshot 2026-04-22 at 11 21 25" src="https://github.com/user-attachments/assets/a5aa9987-ddaf-45f8-9e2a-260fd04dcfb9" />

Forward-Port-Of: odoo/odoo#260599

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

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

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

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

### 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 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#258002
Forward-Port-Of: odoo/odoo#255478

**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#113927
Forward-Port-Of: odoo/enterprise#110241

Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date.

**Steps to Reproduce:**
- Install the MRP module (with demo data).
- Activate "**Custom Work Order Dependencies**".
- Create a new MO for the _Drawer_ product with _SEC-ASSEM_ BoM.
- Confirm and plan the MO.
- Remove both start and end dates of any dependent operation.
- Manufacturing > Planning > Work Orders > Gantt
- Enable **Auto-Reschedule (Keep Buffer)** and reschedule the first operation (in 'Drill 1').

**Error:**
`TypeError - '>' not supported between instances of 'bool' and 'datetime.datetime'`

**Cause:**
At [1], `date_start` and `date_finished` can both be set to False because a condition that bypasses the UserError when both dates are empty (unlike earlier versions). As a result, during rescheduling, a False value is compared with a datetime, leading to a TypeError at [2].

Fix:
This commit adds a condition before date comparisons to ensure the dates are defined.

[1]: https://github.com/odoo/odoo/blob/3f256437a7e6c124affca8d5304476a67375753f/addons/mrp/models/mrp_workorder.py#L281-L284
[2]: https://github.com/odoo/enterprise/blob/ef2efe113684104032d798b5aa237c67a3bc240a/web_gantt/models/models.py#L484-L491

sentry-7377739830

Forward-Port-Of: odoo/enterprise#112729

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