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

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

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

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

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

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

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

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

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

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

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

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

# 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

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

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

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

__
## Short functional explanation of the error
When setting a time off for a user, it doesn't prevent customers from selecting an appointment slot during this time off with said user.

## Reproduction Steps
1. Go to Users. Create a user U and a corresponding employee E.
2. Click on the smart button Employee, and in Work Information tab, under Schedule, set the Working Hours as a working schedule you'll remember. Let's call it WS.
3. In debug mode, go to Employees > configuration > Working Schedules. Select the working schedule WS and click on Time Off.
4. Click on new. Give the time off a name, and in the field Working Hours, enter the working schedule WS. As resource, select the employee E.
5. Go to Appointments and click on New. Let the Availability based on Users, and add user U to users. Hit save and preview.

### Expected behavior
The date on which the user has a time off shouldn't be selectable.

### Unexpected behavior
The date is selectable, and the slots a user can select appear as usual.

## Origin of the issue
In the method
https://github.com/odoo/enterprise/blob/99231105268a74b24a396903cecc3699b16121b0/appointment/models/appointment_type.py#L1088
 we only check if the user has a meeting for a time slot,
but no holiday.
This issue doesn't appear if the availability is based on resources: we do check leaves on resource for a given time slot with https://github.com/odoo/enterprise/blob/99231105268a74b24a396903cecc3699b16121b0/appointment/models/appointment_type.py#L1481

__
opw-5419376

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

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