**Steps to reproduce:**
- Install the `l10n_es_reports` and `accountant` modules.
- Switch to an ES Company.
- Navigate to Accounting > Reporting > Spain > `VAT Books`.

**Error:**
`Element '<xpath expr="//button[@t-if='this.props.line.chatter and !this.ui.isSmall']" position="replace"/>' cannot be located in element tree`

**Root Cause:**
After commit [1], the condition `this.ui.isSmall` was removed from the template `account_reports.AccountReportLineNameCustomizable` at [2]. However, the 
inherited template `l10n_es_reports.VatBooksLineName` was not updated 
accordingly and still references the old condition, which leads to the error.

**Fix:**
This commit prevents errors and ensures that users can open 
the `VAT Books` report by applying a fix similar to [2].

[1]:
https://github.com/odoo-dev/enterprise/commit/fd0afa474600586e8703ec377f962c8d7d94307a

[2]:
https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/account_reports/static/src/components/account_report/line_name/line_name.xml#L81

opw-6169697
opw-6170173

Forward-Port-Of: odoo/enterprise#115412

**Steps to reproduce:**
* Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*.
* Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.).
* Save the settings.
* Create a *customer invoice*.
* Post the invoice.
* Send the invoice through *E-Invoicing (EDI)*.
* Open the generated *Invoice PDF* and the *form view*.

**Observed behavior:**
* The *IRN number* is correctly present in the *Invoice PDF*.
* However, it is *not saved/displayed* in the invoice form view.

**Cause:**
* The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available.

**Fix:**
* Inherit *_l10n_in_edi_send_invoice*.
* Add a condition after the invoice is sent and the JSON response is received.
* When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case).

opw-6097923

Forward-Port-Of: odoo/enterprise#115522
Forward-Port-Of: odoo/enterprise#114350

Steps to reproduce:
1. Install `appointment`
2. Create an appointment type with the followings
3. Schedule type flexible and a slot of 20 min.
4. Share this appointment and try to book appointment for 20 min.

Issue:
- 404 Error occurs after selectiong the slot

Cause:
- In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using
  slot.duration when building the booking URL for flexible slots.
  However, slot.duration is rounded to 2 decimals, so a 20-minute slot
  is serialized as 0.33 instead of its exact value.
  During validation, the end datetime is recomputed from this rounded duration,
  which no longer matches the original slot boundaries. This mismatch causes
  the slot to be considered invalid and the controller raises NotFound.

Solution:
- Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision.

opw-5924312

Forward-Port-Of: odoo/enterprise#108870

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#259083
Forward-Port-Of: odoo/odoo#257873

Problem:
Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small.

Solution:
Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold.

Before:
<img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" />

After:
<img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" />

Steps to reproduce:
- Change languange (French to have a long placeholder).
- Settings > Customer Invoices > Default Terms & Conditions.
- Check "Add a Note".
- Resize the screen to smaller size.
- Observe the power buttons overlap with the translate button.

task-6117734

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

Forward-Port-Of: odoo/odoo#261881
Forward-Port-Of: odoo/odoo#259094

[FIX] project_timesheet_holidays: Exclude archived employees from time-off 

# Description of the issue/feature this PR addresses:
## Steps to Reproduce:
1. Create a time off for Employee A (it should affect the timesheets).
2. Create a new public holiday (global time off) that overlaps with Employee A’s time off.
3. Archive Employee A.
4. Delete the public holiday created in step 2.
5. An error related to timesheet generation appears.

## Expected Behavior:
- The public holiday / global time off should be deleted without any error.

# Desired behavior after PR is merged:
## Fix (Implemented):
When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees.

## Alternative Fix (Not Implemented):
Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved.

 ## Version:
 This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0  but didn't directly test

## Task:

[5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038)

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

Forward-Port-Of: odoo/odoo#261909
Forward-Port-Of: odoo/odoo#244203

When we add a byproduct followed by SN directly in the MO it will not have the its location as production.

Steps to reproduce:
-------------------
* Create product tracked by Serial number
* Create a Manufacturing order
* Add the Product tracked by serial number on the MO as byproduct
* Confirm the MO
* Go to shop floor
* Add the by-product quantity and create a new serial number.
* Close production and go back to the MO in manufacturing
* Open stock moves -> the by-product does not have "production" for origin

Observation:
-------------
When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM.

When adding the byproduct in shopfloor, it will create the quant:
https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171
Additionaly when creating the quant it will decide the source location depending if the product its a byproduct:
https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192
The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids
https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110

#### Additional notes:

The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false


opw-5974582

Forward-Port-Of: odoo/enterprise#110122

When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language.

### Steps to reproduce

1. Install the "Surveys" module and activate a second language (e.g., Dutch).
2. Create a survey and ensure its invitation template has translations for both languages.
3. Create two contacts: one with English as their language and another with Dutch.
4. On the survey, click "Share" and add both contacts as recipients.
5. Send the invitations.
6. The contact with Dutch preferred language receives the email in English.

### Cause

By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one.

opw-5868581

Forward-Port-Of: odoo/odoo#260028
Forward-Port-Of: odoo/odoo#246778

Issue:
---
Ewallet line is included in delivery pricing.

Steps to reproduce:
1- Create a delivery method `based on rules`.
2- In pricing set rules:
- price <= 99 => delivery price = 30
- price > 99 => delivery price = 50

3- Create a eWallet with balance = 200.
4- Create a SO add a line with product. Set the SOL unit amount to 100.
5- Click on `add a shipping`. Add the created delivery method.
6- As you see, the delivery amount is correctly calculated.
7- Now apply the eWallet using `reward` button.
8. Update the shipping cost.

The shipping cost is 30, which is not expected.

Cause:
---
In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount.
However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`.

Fix:
---
We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards.

opw-6124209

Forward-Port-Of: odoo/odoo#260134

### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.

### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?

### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67

### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.

opw-6050537

Forward-Port-Of: odoo/odoo#260145

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#108493
Forward-Port-Of: odoo/enterprise#103333

Steps to reproduce:
- Create a product P1 with a BoM containing component C1
- Set C1 route to MTO + Buy:
    - add any vendor
- Have 10 units of C1 in stock

- Confirm a Manufacturing Order for 2 units of P1
- The MO confirmation triggers the move for C1, which gets assigned from stock
- Increase the quantity_producing on the MO
- This updates product_uom_qty on the move and calls _run_procurement

Expected behavior:
- No Purchase Order should be created since stock covers the demand

Current behavior:
- A Purchase Order is created even though stock is sufficient
- In case of partial stock, the full procurement_qty is used instead of the uncovered delta

Fix:
- Track mts_else_mto moves separately before calling _action_assign()
- After _action_assign(), subtract the newly covered quantity (move.quantity - old_qty)
  from the procurement_qty before running the stock rule
- Skip the procurement entirely if the adjusted qty <= 0

opw-6042283

Forward-Port-Of: odoo/odoo#261538
Forward-Port-Of: odoo/odoo#258871

Currently, an error occurs when exporting VSME reports if the base year is not a valid 4-digit year.

**Steps to Reproduce:**
1. Install the ESG module with demo data.
2. Create new "**VSME Reports**" with `Base Year = 1`.
3. Now, click on "**Print**".

**Error:**
`ValueError - Invalid isoformat string: '1-01-01'`

**Cause:**
The base year is directly used to build a date in [1], resulting in `datetime.date(1, 1, 1)`. In [2], this is formatted to **"1-01-01"** and used in a domain search, which raises a ValueError due to an invalid ISO date format.

**Fix:**
- Adds a **constraint on base year** to ensure only valid years (1000–9999) are allowed for new VSME Report records.
- Adds a **helper validation method** to verify base year before performing computations on existing records.

[1]: https://github.com/odoo/enterprise/blob/4cef86708a9fe3cd00855fa18e2a8cbd4fd77e66/esg_hr/models/esg_report.py#L515
[2]: https://github.com/odoo/enterprise/blob/4cef86708a9fe3cd00855fa18e2a8cbd4fd77e66/account_accountant/models/res_company.py#L176-L184

sentry-7419431039

Forward-Port-Of: odoo/enterprise#114453

When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]`

This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]`

The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets

This commits fixes this two ways:

Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors

Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]`

Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example
`.test_method[test, with brackets\], and backslash\` will work the same way.

So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced.

Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests.

A followup pr will introduce the params to the canonical tag, and escape it as needed

Forward-Port-Of: odoo/odoo#262101
Forward-Port-Of: odoo/odoo#261516

## Problem:
During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests.

## Solution:
Enforce the `limit` when fetching if it is present.

## Steps to reproduce:
- Have a product with many quant records
1. Open a picking for this product in Barcode
2. Change the lot/serial

The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve.

## Benchmark:
<table>
	<thead>
		<tr>
			<th># of quants</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>17193</td>
			<td>~9s</td>
			<td>~400ms</td>
		</tr>
	</tbody>
</table>

opw-6041705

Forward-Port-Of: odoo/odoo#261904
Forward-Port-Of: odoo/odoo#259983

[FIX] documents: scroll to uploaded record

How to reproduce:
- install documents
- open the "All" folder and ensure there is enough folder to not see any file
- open the detail panel
- drag&drop file in that folder
The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel.

We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel.

[FIX] documents: fix icon position in thumbnail

How to reproduce:
- install documents
- open the chatter of a document
- click on log a note, and upload a file
The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border).

We fix here the position the icon/button.

[FIX] documents: fix "you" badge layout

How to reproduce:
- install documents
- change the name of Mitchell Admin to a very long name
- open the share panel owned by Mitchell Admin
The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct).

We fix here the layout of the badge in such configuration.

Task-5152517

Forward-Port-Of: odoo/enterprise#115103
Forward-Port-Of: odoo/enterprise#107686