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

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

*= 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#102095

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

Steps to reproduce:
- Configure POS → enable Allow Flexible Pricelist and assign the Default pricelist.
- Create product A with variants.
- Add product A to the Default pricelist.
- Set a fixed price for product A in that pricelist.
- Open POS session.
- Select product A in POS.

Observation:
- In ProductConfiguratorPopup dialog, pricelist price is not considered

Cause:
- After this [commit](https://github.com/odoo/odoo/commit/5e77c14912324bf967a55a1a40bb01071eca5c8b) the text appears from `get title()` method, which do not consider pricelist

Fix:
- we now consider pricelist for displaying title.

**Before**
<table>
<tr>
<td>
<img width="400" height="300" alt="image" src="https://github.com/user-attachments/assets/6faac3e4-a579-41db-a2ad-fdc9c24e422f" />
</td>
<td>
<img width="400" height="300" alt="image" src="https://github.com/user-attachments/assets/14035707-aa23-4fb3-97d7-d0ce2f6e6b46" />
</td>
</tr>
</table>

**After**
<img width="340" height="225" alt="image" src="https://github.com/user-attachments/assets/3beeaf76-fc1a-42a5-9f3c-dabc43389d36" />


opw-5270319

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

Forward-Port-Of: odoo/odoo#237899

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

Steps to reproduce:
---------------------------------
1. Install `hr_skills` module
2. Open the Employees app and open any employee record
3. Go to the Resume tab
4. In the Skills section, click Add for any skill type
5. Select a skill that is already added to the resume
6. Click Save & Close in the Select Skills wizard
7. A validation error is displayed, click Close
8. Close the Select Skills wizard.

Observation:
---------------------------------
After closing the wizard, another default skill is added to the resume even though a validation error was raised.

Issue:
---------------------------------
In the following code:
https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/hr_skills/static/src/fields/skills_one2many/skills_one2many.js#L79-L82 During record save, the validation error scenario was not handled properly. When a validation error occurred, changes made to the virtual record were not discarded, causing the initial (invalid) changes to be incorrectly retained instead of being rolled back

Solution:
---------------------------------
When a validation error occurs while adding a skill, discard all changes made to
the virtual record before throwing the error. This ensures that no unintended
skill is added.

opw-5423196

Forward-Port-Of: odoo/odoo#247464
Forward-Port-Of: odoo/odoo#240697

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`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105535
Forward-Port-Of: odoo/enterprise#102714

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

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

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

Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount` method, which recalculates the price and discount based on the Pricelist, effectively wiping out any manually entered commercial discounts.

This occurred because the `_compute_discount` method in `sale_subscription` depends on `order_id.start_date` to calculate pro-rated amounts for upsells. However, it was unconditionally calling `super()`, which runs the standard pricelist logic even when the line content itself (Product, Qty) had not changed.

This commit introduces a check to detect if the line content has actually been modified by the user (comparing against the database origin).
- If the line content (Product, Qty, UoM) is unchanged, we skip the `super()` call to preserve the manual discount.
- If the line content is changed (or it is a new line), we allow `super()` to run to update the price according to the pricelist.

This ensures that contextual changes (like shifting the start date) do not destroy manual data entered on the lines.

task: 5788384

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

*= 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#102095

When a fiscal position maps a tax-included tax to a tax-excluded tax (or
vice versa), the price unit must be adjusted to keep the base amount
consistent. This adjustment was missing in the POS frontend after the
tax computation refactoring in v18+.

Background:
In v17, the computePriceAfterFp method handled this price adaptation:
https://github.com/odoo/odoo/blob/36688ce4dad4b3d508b4fd3d778a06a5a7036408/addons/point_of_sale/static/src/app/store/pos_store.js#L1102-L1133

This method was removed in:
https://github.com/odoo/odoo/commit/ab0bdf019212

The refactoring introduced:
https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/account/static/src/helpers/account_tax.js#L472-L481

However, the POS module was not updated to call this helper when
preparing base lines for tax computation.

Steps to reproduce: 
1. Create a tax configured as "Included in Price" (21)
2. Create a tax configured as "Excluded from Price" (21)
4. Create a fiscal position that maps the included to the excluded tax
4. Add the fiscal position to a contact
5. Create a product with the included tax, priced at 100
6. In POS, add the contact as the client and add the product
7. Total incorrectly shows 121 (or 100 + tax) instead of 100

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

------------------------------------------------------------------------

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

**Steps to produce:**
- Install `website_sale` with demo data.
- Go to the shop page.
- Select product `Customizable Desk` > click `Add to cart`.
- In the wizard, change the quantity to 100 and directly click `Checkout`.

**Issue:**
- The cart shows the product with quantity = 1 instead of the edited value.

Root cause:
- When the user clicks Checkout, both `setQuantity` and `onConfirm` are triggered
  almost simultaneously.
- At [1], the `_setQuantity` method is called, but due to the await before the
  quantity update is completed, the update may not finish in time. As a result,
  the previous quantity is sometimes used during checkout instead of the
  newly selected one.

Solution:
- we can update the quantity immediately before awaiting `_updateCombination`,
  ensuring that the correct quantity is already set when onConfirm runs.

[1]: https://github.com/odoo/odoo/blob/f4eabe47a602301013afa63da6bdf87809903d29/addons/sale/static/src/js/product_configurator_dialog/product_configurator_dialog.js#L225

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

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Forward-Port-Of: odoo/odoo#241603

Steps to reproduce:
1. Create a storable product with tracking set to 'By Quantity'.
2. Update the Quantity on Hand (e.g., 100 units).
3. Change the product tracking to 'By Serial Number'.
4. Create a Repair Order for this product.
5. Add a line, select a specific Serial Number, and click Save.
6. Observe that the serial number disappears.

Cause:
When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation.

Solution:
In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid.

opw-5156267

**PROBLEM**
If you create/import a journal entry using a foreign currency, it can happen that the journal entry is balanced in said foreign currency but isn't balanced in the company currency, preventing you from creating/importing the journal entry. When creating the journal entry, you could add a line to balance this, but if you import it, you can't.

**STEP TO REPRODUCE**
1. Set the exchange rate: 1€ = 0.134068$
2. Import the journal entry named issue.csv (can be found in the ticket page or the PR).

**CAUSE**
Because we round each line individually, we may end up with a rounding issue that leads to debit/credit not being equal. opw-4668369

| Reference | account_move_journal.id  | Date    | Journal Items / Account | Journal Items / Currency | Journal Items / Amount in Currency |
|-----------|--------------------------|---------|-------------------------|--------------------------|------------------------------------|
| Bunq      | Miscellaneous Operations | 8/15/25 | 1010                    | EUR                      | -34.9                              |
|           |                          |         | 1050                    | EUR                      | 34.9                               |
|           |                          |         | 1100                    | EUR                      | 2.69                               |
|           |                          |         | 1200                    | EUR                      | 32.21                              |
|           |                          |         | 1300                    | EUR                      | -34.9                              |€

## Versions
17.0+
16.0 too but template change is not worth risking stable policy.

## Issue
There is a behavior mismatch between invoices and quotes/orders addresses display. Disabling "Customer Addresses" setting should only display one address on generated documents. Yet, it has no effect on quotes and orders while it has on invoices.

## Steps to reproduce
- Go to Settings:
  - Look for "Customer Addresses";
  - Ensure the box is checked (and save).
- Go to Sales / Orders / Customers:
  - Create a new customer and add addresses under the "Contacts & Addresses" tab:
    - Add one "Delivery Address";
    - Add one "Invoice Address" (with different values).
- Click the "Sales" smart button to create a new quote for that customer:
  - Add any product;
  - From the cog, click Print > PDF Quote.
  - Confirm the order (deliver if needed);
  - Create regular invoice;
  - Confirm the invoice;
  - From the cog, click Print > Invoices.
  - Both documents display a shipping address.

Start again with "Customer Addresses" setting disabled and watch the shipping address disappear from the invoice while still present on the quote document.
*N.B.: Same behavior with the preview*

## Fix
Mimic invoices' behavior in https://github.com/odoo/odoo/blob/1bd2d63eb80020e6e213c889e83cca2950d4dcd4/addons/account/views/report_invoice.xml#L12

opw-5400368

**Issue**
It is possible to have unreserved quantity, outside the stock location, considered as 'stock in transit' in the forecast report.
This is an issue because that means some quantities, that are not meant to be moved to the stock location, are linked to a delivery.

**Steps to reproduce**
- Activate 3 step receipt on your warehouse 
- Create a new product 'Test' and adds 1 Unit in WH/Input and 1 Unit in WH/Quality 
- Create a sales order for 2 Units and check the forecast report of Test
-> 2 units are recorded as 'stock in transit' links to the so delivery while they should not.

**Cause**
The forecast report is computed here:
https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L17-L24
The lines are computed here:
https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L125

Currently, stock in transit is calculated by:

Aggregating quantities per product and location (including unreserved quantities):
https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L327-L328

Removing the reserved stock, then summing per product:
https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L353-L354

Assigning the result as 'stock in transit' (since free_stock is 0 here):
https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L361

This method incorrectly includes unreserved quantities from intermediate locations.

**Solution**
Since we only want non-available quantity to be considered as stock in transit, we use the reserved quantity instead.
No need to substract the free quantity anymore since free quantity are no reserved by definition.

opw-5865378

Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.

Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)

When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17

This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.

OPW-5448916

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