Currently, an error occurs when user opens Time Off per Employee Analysis.

**Steps to Reproduce:**
 - Install `l10n_fr_hr_holidays` with demo data.
 - Switch to a `French company`.
 - Create a time off for any employee (if none exists).
 - Go to `Time Off` > `Reporting` > `By Employee`.

`TypeError: HrLeave._get_durations() got an unexpected keyword argument 'additional_domain'`

After [this commit], _get_durations accepts an additional_domain parameter. However, this parameter is 
not defined in the _get_durations method in the French and Indian localizations. When a user opens 
Time Off by Employee in the French or Indian localization, the compute method is executed to calculate 
leave durations, and additional_domain is passed as an argument [1], which raises the error [2] [3].

This commit adds the additional_domain parameter to the Indian and French localizations. In the French 
localization, it also passes check_leave_type, as its value is passed internally within the method [4].

[this commit]: https://github.com/odoo/odoo/commit/1c3f5633ef87f6d9c5a6169eefd51cd42ef442d5#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R575

[1]- https://github.com/odoo/odoo/blob/8db5a8cf07fa9c2b677b061b5897f757cb1f7260/addons/hr_holidays/report/hr_leave_employee_report.py#L94

[2]: https://github.com/odoo/odoo/blob/80e29d864b3e54ea68d2731da4c0f2f917f5d56a/addons/l10n_in_hr_holidays/models/hr_leave.py#L218

[3]: https://github.com/odoo/odoo/blob/80e29d864b3e54ea68d2731da4c0f2f917f5d56a/addons/l10n_fr_hr_holidays/models/hr_leave.py#L112

[4]: https://github.com/odoo/odoo/blob/9d4103c061c5fbe9913fa721ea3e6d417bc89e93/addons/hr_holidays/models/hr_leave.py#L531

sentry-7213025295


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

Steps to reproduce:
-------------------
1. Install `l10n_in` and `l10n_in_hr_holidays`
2. Switch to an Indian company
3. Create a user and related employee without Time Off rights
4. Log in with the new user and create a past time off
5. Approve the time off as an time off manager/admin
6. Open the validated time off record as the employee

Issue:
------
Opening a validated time off raises the following UserError:
 ```python
You must have manager rights to modify/validate a time off that already begun.
```

Cause:
------
The `_get_durations` method in `l10n_in_hr_holidays` was updating the
`l10n_in_contains_sandwich_leaves` field every time it was executed.

When a user opened a validated time off record, this triggered a `write()` operation. Since non-manager users are not allowed to write on already started validated leaves, this caused a [UserError](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/hr_holidays/models/hr_leave.py#L793-L798)

The field `l10n_in_contains_sandwich_leaves` does not need to be updated
when `l10n_in_is_sandwich_leave` is False.
See [[1]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L156-L157) & [[2]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L62)

And this [part of the code](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L160-L173) is responsible to update `l10n_in_contains_sandwich_leaves` value.

**NOTE:**
Opening future validated time off records as a non-manager user triggers
`AccessError` as it is not allowed to update the validated time off record.

Solution:
---------
Ensure that `l10n_in_contains_sandwich_leaves` is updated
only when `indian_leaves` is applicable.

opw-5373055





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

Forward-Port-Of: odoo/odoo#246078
Forward-Port-Of: odoo/odoo#240056

**Issue**
Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected duration.

**Steps to reproduce**
1. Create two workcenters marked as alternatives (100% and 50% efficiency).
2. Create a BOM operation that produces 100 products with a 1h expected duration each, on the 100% workcenter.
3. Create and plan an MO using this BOM.
4. In Planning > Planning by Workcenter (Gantt), drag the workorder to the 50% efficiency workcenter. → Expected duration remains 100h instead of 200h.
5. Drag the same workorder back to the 100% workcenter. → Expected duration becomes 200h instead of 100h.

**Cause**
`date_finished` is recomputed in `write()` using the *previous* workcenter’s efficiency, because the duration calculation happens before the new `workcenter_id` is applied: https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L471

Since the Gantt progress bar uses the interval [`[date_start, date_finished]`](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L672C13-L674C107) to compute the expected duration (via `_web_gantt_progress_bar_workcenter_id`), the displayed duration becomes wrong.

opw-5224272

Forward-Port-Of: odoo/odoo#245236
Forward-Port-Of: odoo/odoo#239021

## Problem

A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this flow:

- A user (Person A) opens an Odoo record. The chatter contains an image previously sent by a correspondent (Person B) whose email client or mail server rewrote the image URL to point to a security proxy.
- Firefox tries to load the image. The URL points to `cisco.com/...`. (for example)
- The proxy scans the link and redirects the browser back to the original Odoo URL: `odoo.com/web/image/...`.
- Firefox follows the strict (now deprecated) `rfc6265bis` rule: it looks at the whole redirect chain.
Since it sees a cross-site hop (cisco.com), it flags the final request as cross-site.
    -> Because Odoo's session_id is `SameSite=Lax`, Firefox refuses to send
    the cookie on this "false" redirect
- Odoo receives the request at `/web/image` without a session_id.
- Odoo creates a new, empty session to process the request.
- At the end of the request, because save_session is True by default, Odoo sends a `Set-Cookie: session_id=NEW_EMPTY_ID` header in the response.
- The browser receives this `Set-Cookie` header, and this time *applies a different policy*: it considers the header as same-origin, allowing it to overwrite the previously valid session cookie with this new one that corresponds to a fresh, unauthenticated session.
- The user is instantly logged out of their current Odoo tab.

## Context on Web Compatibility

This "redirect chain consideration" was a controversial part of the `RFC6265bis` draft.
Chrome and Safari never fully implemented it because telemetry showed it broke ~1% of the web. In March 2024, the HTTP Working Group (HTTPWG) officially decided to remove this requirement from the spec (reverting to a more permissive model) because it was deemed not web-compatible. Firefox, however, still enforces this strict behavior in many versions.

## How to we fix this

We set `routing={'save_session': False}` on the `/web/image controller`.

- This prevents Odoo from sending the `Set-Cookie` header if the session is dirty or new.
- Even if Firefox sends the request without a cookie, Odoo won't "reply" with a new session ID.
- The user's legitimate session cookie remains untouched in the browser.

## Sources
- HTTPWG Decision (March 2024): https://github.com/httpwg/http-extensions/issues/2104
- Reverting RFC6265bis: https://github.com/httpwg/http-extensions/pull/2750

opw-5184217
opw-4698750
opw-5166151

Forward-Port-Of: odoo/odoo#242582
Forward-Port-Of: odoo/odoo#242061

Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.

opw-5496999
opw-5401425

Forward-Port-Of: odoo/odoo#247139
Forward-Port-Of: odoo/odoo#244052

Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps:
1. In chrome, use an existing task with empty description or create a task in the project (first create the task title in the kanban view, then click edit), enter 4 lines of text
2. In one of the middle lines, delete one character --> undo --> add a new character
3. Save the task, open the task in Safari incognito, log in as demo (not admin), go to the task and click the description field
4. TraceBack: IndexSizeError: The index is not in the allowed range.

After this commit: we use the range of the DOM selection to set the
offsets of activeSelection. If the DOM selection is too wrong to be
corrected, e.g. the selection's anchor node isn't the same with range's
start container (or end container if direction is right to left), we do
not set new activeSelection but just return the previous activeSelection

task-5428788


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

Forward-Port-Of: odoo/odoo#247484
Forward-Port-Of: odoo/odoo#246056

When all variants of a product template are deleted, opening the Shop page on the website raises a traceback.

Steps to reproduce the error:
- Install ``website_sale`` module
- Go to settings > Enable variants
- Create a product template > In Attributes & Variants Tab > add one attribute with two values > Save
- Click on the variants smart button > select all > delete
- Go to Website > Shop

Traceback:
```py
AssertionError: Invalid falsy real id
```

https://github.com/odoo/odoo/blob/b6598c11a3580cfc6ff1ffeb67b0d388c55383d1/addons/website_sale/controllers/main.py#L456 After [commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f), falsy IDs are no longer allowed in ``browse()``.
When all variants of a product template are deleted, ``product._get_first_possible_variant_id()`` returns False.
This falsy value is later passed to ``browse()``,
which triggers the above traceback.

[1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f

sentry-7201563878

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

Steps to reproduce

Scenario A

1. Go to Website → drop an Image Gallery snippet → A default height value
appears in the `"Height"` input.

2. Select an image → change its order in the carousel → The snippet height
is automatically reset to `70%` of the screen height.

Scenario B

1. Change the height value of the snippet from the `"Height"` option.

2. Select an image → change its order in the carousel → The snippet
height is again reset (and the option value is overridden).

Issue

The original height behavior was introduced in [1] to make the slideshow
mode auto-adapt to `70%` of the viewport height.

This diff also removed height CSS for other modes where the height
should depend on the content [2]

Subsequent adaptations:

[3] added a default height (`500px`) in XML,

[4] removed it during a design refactoring,

[5] restored the possibility to control the height of the image gallery
snippet using the `"Height"` option.

Keeping the same JS logic that forces the snippet height, led to the
behavior explained above: even when the user manually sets a height, any
action triggering `slideshow()` (e.g., image reorder) forces the height
back to 70% of `window.innerHeight`.

Fix

1. Remove the outdated JS code that automatically updates the height.

2. Keep the slideshow behavior consistent with [2] by excluding it from
the height CSS removal logic.

The snippet now starts with a default height and only changes when
edited through the `"Height"` input.

Additional fixes

This commit also fixes a few minor issues in the new carousel items
template introduced in [4]: items having an `"undefined"` class, and a
missing margin style in the main snippet template.

[1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf
[3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
[4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609
[5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c

task-3414281

Forward-Port-Of: odoo/odoo#243914
Forward-Port-Of: odoo/odoo#126766

### Steps to reproduce:

1. In the settings enable: Multi-steps route
2. Put your warehouse in 2-step deliveries
3. Create a kit product:
   - With one component
   - There is one component in the stock
4. Create and confirm a SO with 1 x K
5. Process the pick and ship
6. Return the delivery
7. Set the sol qty to 0
#### > Two unexpected pickings are created to put the kit in output

### Cause of the issue:

Decreasing the sol quantity to 0 will call the `_action_launch_stock_rule` in order to create and run procurements related to that quantity change. However, the quantity currently handled by other procurements is determined here by the `_compute_kit_quantities`:
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_mrp/models/sale_order_line.py#L154-L166 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/mrp/models/stock_move.py#L578-L580
Now, the issue is that `_compute_kit_quantities` does not handle move chains properly, as all delivery moves contribute to the `incoming_qty` and all return moves contribute to the `outgoing_qty`. This results in an `incoming_qty` of 1 (for the pick) + 1 (for the ship) and an `outgoing_qty` of 1 (for the 1-step return), that is a `qty_processed` of 1. As a result, the procurement will be generated for a quantity of `0 - 1` (rather than 0):
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388-L402 
which leads to the unexpected picking creations.

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

Forward-Port-Of: odoo/odoo#246141

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value.

opw-5172669

Forward-Port-Of: odoo/odoo#247472
Forward-Port-Of: odoo/odoo#246270

Steps to reproduce:
--------------------------------
1. Install `industry_fsm_sale` module
2. Go to Settings > Configure Document Layout
3. Select the Bubble document layout and save
4. Open any Field Service task
5. Use the Products smart button to add one or more products
6. Click the Settings icon > Print > Field Service Report

Observation:
--------------------------------
In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals

Issue:
--------------------------------
The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders

Solution:
--------------------------------
Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout


Before:
<img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" />


After:
<img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" />


opw-5401612

Forward-Port-Of: odoo/enterprise#105616

**Steps to reproduce:**
* Install the *stock_barcode_mrp* module.
* Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*.
* Create two operation types with *Type of Operation* set to *Manufacturing*.
* Create two manufacturing orders.
* In each manufacturing order, under the *Miscellaneous* tab 
set a different *Operation Type* created above.
* Ensure sufficient *On Hand Quantity* exists for a product used in manufacturing.
* Open the *Barcode* application.
* Open one of the created manufacturing operation types.

**Observed behavior:**
* The kanban view displays **all** manufacturing orders whose picking
types are active, instead of only those related to the selected operation type.

**Cause:**
* In 19.0, the context key *`'search_default_picking_type_id': self.id`* was removed  
from `_get_action` function in this [commit](https://github.com/odoo/odoo/commit/9ed7109b8f11260084374f2d7fa7073a9ad3c240)
* Previously, this context value restricted results to the current picking type by default.
* The method `get_action_picking_tree_ready_kanban` in *stock_barcode_mrp* 
now overrides the domain with only *`('picking_type_id.active', '=', True)`*.
* This domain checks that the picking type is active but does not filter by 
the selected picking type, causing unrelated MOs to be shown.

**Fix:**
* This ensures only manufacturing orders belonging to 
the selected operation type are displayed.

---

opw-5819358

Forward-Port-Of: odoo/enterprise#105327

Currently journal items shown don't belong to the account group that
they should belong to, and from saas-18.3 an error will be generated
after following the below steps or step mentioned in ref PR [1].

- Install `Accounting (accountant)` with demo data
- Create account groups e.g., name as `Test 1` and code prefix `1 to 1`
- Go to the general ledger report
- Click on `Journal Items` of the account group line `1 Test 1`

Error from saas-18.3:
`ValueError: Cannot convert account.account.group_id to SQL because it is ...`

This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the
`account.account` model to the search domain. However, in 18.0, commit [2] modified
this field so that it is no longer stored. As a result, when a search domain includes
this `non-stored` field, Odoo skips the domain evaluation and logs a error at code
line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0.

Also, starting from saas-18.3, passing such a non-stored field in a domain raises an
explicit error at code line [4], instead of being silently ignored.

This commit resolves the issue by introducing an SQL query that
returns the account ids related to `record_id(account group id)`
include `record_id` as `None`.

[1]: https://github.com/odoo/enterprise/pull/100191
[2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767
[3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174
[4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201

sentry-7100657414

Forward-Port-Of: odoo/enterprise#103137

**Issue**
Users without 'Admin' Sign rights could in some cases not access the sample template.

**Steps to reproduce**
1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it.
2. Add some sign items to the template, and send it for a signature request.
3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'.

Access Error:
Blame the following rules:
- sign.item: group_sign_user: Create and manage template items

**Cause**
When the template has an associated sign request, it is copied.
The problem is that the user currently doesn't have enough rights
to create sign items for the copied template:
https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101

**Change**
Change the `user_id` of the new template to allow creating the sign items for it.

opw-5254566

Forward-Port-Of: odoo/enterprise#105656
Forward-Port-Of: odoo/enterprise#102227

### Issue:
When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0

### Cause:
In `export_boe()`, the `report_lines` were get based on the `section_report` options
However, `section_reports` do not store the date
or return periodicity of the selected report
As a result, using their options always fetched data for the current period instead of the specified year

### Note:
`_generate_mod_390_page2()` also had issues:
some lines were missing or incorrectly indexed

The mod 360 format, it strict in the structure with specific index so it may produce invalid documents

The latest documentation for mod 390:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` and switch to ES Company
- Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025)
- Open Tax Return, switch to Mod 390, and set year to 2025
- You should see data in the 2 first sections
- Use the gear icon, and download the BOE
- Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report

opw-5457374

Forward-Port-Of: odoo/enterprise#106676
Forward-Port-Of: odoo/enterprise#104928

*= quality_control, quality_mrp_workorder, mrp_workorder

Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown.

**Steps to produce:**
* Install `Quality` and `Manufacturing` with demo data
* Go to MRP > Configuration > Operations > Manual Assembly
* Create a pass/fail quality point with a failure message
* Create and confirm an MO for `Table Top`
* Go to Shop Floor > Activate work centers if inactive > Manual Assembly
* Fail the assembly using the quick-action button

Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing)

**Observed Behavior:**
* No failure message is displayed when the quality check is failed.

**Root cause:**
* This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears.

**Solution:**
* Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions.


**Before:**
<img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" />

**After:**
<img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" />


[1]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 
[2]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 
[3]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 
[4]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 
[5]:
https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161

opw-5403465

Forward-Port-Of: odoo/enterprise#106711
Forward-Port-Of: odoo/enterprise#102095

# Steps to reproduce:
* Install **Accounting** and **l10n_be_reports**.
* Enable **debug mode**.
* Go to **Accounting → Reporting → Belgium → Partner VAT Listing**.
* Create invoices with invoice lines with no product set on it, just a label, so that **more than 10 Belgian partners** appear in the report and ensure each partner has a **VAT number**.
* Open the report **Options** tab and set **Load More Limit** to **5**.
* Click **Load More** until all partners are visible.
* Click **Returns** and create a return for the month you have created invoices for, and submit it.
* Download the generated XML.

# Observed behavior:
* The XML file contains only the first batch of partners.
* Partners shown after clicking **Load More** are missing from the export.

# Cause:
* In v17, the XML export button was defined as:
https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/l10n_be_reports/models/partner_vat_listing.py#L53-L59
* This meant clicking the button would go through the [export_file](https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/account_reports/models/account_report.py#L4927)
 method, which sets `options['export_mode'] = 'file'` before calling the export function. The test in v17 explicitly sets `export_mode = 'file'` to simulate what `export_file` does in production.
 
* In v19, the architecture changed:
  - The XML export is now triggered via the account.return workflow and a submission wizard [1.](https://github.com/odoo/enterprise/blob/19.0/l10n_be_reports/wizard/vat_listing_submission_wizard.py)
  - The wizard's `print_xml` method calls [_get_closing_report_options()](https://github.com/odoo/enterprise/blob/19.0/account_reports/models/account_return.py#L1601) which does NOT set `export_mode = 'file'`.
  - The controller then calls `dispatch_report_action(options, file_generator)` directly, bypassing `export_file`.
 
* Why the test changed:
  - In v17 test: `export_mode = 'file'` was set to mimic the `export_file` →  `partner_vat_listing_export_to_xml` flow.
  - In v19 test: `export_mode = 'file'` should NOT be needed in the test because the fix is to set `export_mode = 'file'` inside `partner_vat_listing_export_to_xml` itself.


# Fix:
* Enable **export mode** when generating the XML.
* Ensures all partners are included regardless of the load limit.

opw-5494247

Forward-Port-Of: odoo/enterprise#106134

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

Forward-Port-Of: odoo/enterprise#106085
Forward-Port-Of: odoo/enterprise#105017