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

Prior to this commit, the left sidebar in Discuss had a max width of 300px.

This commit allows larger widths based on the screen width. This is dependent on screen width, similar to o-mail-ActionPanel.o_resizable_panel.

It also removes the styling setting the max width to 300px.

This helps make discuss more configurable, and makes it possible to see more of the description in live chat conversations. The sizes are set to match the max size of the right panel, so that they don't overlap, and there's suitable space in the center for the chat itself.

Related to 221559
task-6180965

(Screenshots below show the worst case-scenario, where both the left and right panels are expanded to their max size)

Before (Screen width > 1200px):
<img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/952d6c4b-60fd-47b9-aff7-8e034a2ee752" />

After:

Screen width > 750px:
<img width="1291" height="964" alt="image" src="https://github.com/user-attachments/assets/1120da2d-a434-4b3b-b387-f1d29bf0cb91" />

Screen width > 1200px:
<img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/47c6c981-0c62-43b6-8634-c6d644c342bb" />

Screen width > 1600px:
<img width="1291" height="964" alt="image" src="https://github.com/user-attachments/assets/2945c964-5847-456b-b982-09086f335860" />

Screen width > 2300px:
<img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/c8cbc63f-025b-463d-9a3a-c84fce87d223" />

**Steps to reproduce**
- Settings: Timesheets > Invoicing policy = only validated TS.
- Have a service product with an invoicing policy based on timesheets.
- Create a sales order using this product.
- From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them.
- Invoice the SO, using a timesheets period that includes both TS.
- Notice that the quantity of the invoice line includes the non-validated timesheet.

**Cause**
The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1

**Change**
Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain.

opw-6116670

Forward-Port-Of: odoo/odoo#261621
Forward-Port-Of: odoo/odoo#259224

Steps to reproduce:
- Set a journal with documents folder sync.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
Adding an image via log note sets it as the main attachment, but it 
is intentionally orphaned (res_model=False) to prevent UI clutter. 
`documents_account` incorrectly syncs this unlinked file, creating a 
workspace document with a missing model.

During "Send & Print", the official invoice PDF replaces the image as
the main attachment. The document versioning logic intercepts this swap
and attempts to re-parent the new PDF to match the orphaned document.
This destroys the PDF's linkage to the invoice, causing a crash when
the system later attempts to fetch the PDF.

Solution:
Since the base module now suppresses premature document creation during 
the message post, we explicitly handle the sync ourselves. We override 
`_fix_attachments_on_record_from_files_data` to iterate over the 
validated attachments and trigger document creation only for files 
that retained their `res_model`. We also add a check inside 
`_update_or_create_document` to strictly block orphaned attachments.

opw-5930888

Before this PR, the design of the pills were not consistent and a bit confusing. Instead, the recording pill is replaced by a red recording circle, the transcribing pill is replaced by the "Transcribing..." text and the On hold pill is taken out.  In the active state of the Hold and Record/Stop button the text is changed respectively to text-warning and text-danger. Before, the "transcribing" status depended on the recording status to be displayed, now it can be displayed whether or not the call is being recorded.

task-5882281

| | Before | After |
|--------|--------|--------|
| Hold | <img width="389" height="689" alt="Screenshot 2026-03-17 at 15 39 44" src="https://github.com/user-attachments/assets/27f3f08e-40ae-440d-8024-2f16484b8e32" /> | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 17 33" src="https://github.com/user-attachments/assets/4ff3e9ba-a2e4-4d0d-9e3d-eccc32c9e8c8" /> |
| Hold + Transcribing | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 18 33" src="https://github.com/user-attachments/assets/96344c97-d56e-4887-bb16-94518b48faec" /> | <img width="389" height="689" alt="Screenshot 2026-03-17 at 15 38 01" src="https://github.com/user-attachments/assets/5246614b-d18e-42ef-b84e-1ed783a700d2" /> |
| Hold + Record | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 25 01" src="https://github.com/user-attachments/assets/cde4cd38-9162-4f36-bd91-faba26d71556" /> | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 24 31" src="https://github.com/user-attachments/assets/af8fa55a-73cd-452d-924d-735d5ea2ff09" /> |
| Hold + Record + Transcribing | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 18 38" src="https://github.com/user-attachments/assets/09dd22f6-c865-476e-8b02-1ffc92a0da1a" /> | <img width="389" height="689" alt="Screenshot 2026-03-16 at 17 36 08" src="https://github.com/user-attachments/assets/62d7bc4c-2912-4324-8736-e40627048c49" /> |
| Record | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 24 59" src="https://github.com/user-attachments/assets/dc8672d9-a8ba-484e-a1f1-ce3789aaa688" /> | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 24 27" src="https://github.com/user-attachments/assets/102aea8f-98bf-4898-902f-7981fce37176" /> | 
| Record + Transcribing | <img width="389" height="689" alt="Screenshot 2026-03-16 at 16 18 50" src="https://github.com/user-attachments/assets/0e24d78a-0a43-4a8e-ab85-7fb5b059d959" /> | <img width="389" height="689" alt="Screenshot 2026-03-16 at 17 36 05" src="https://github.com/user-attachments/assets/d2f56fdf-ad6b-4aaa-9eeb-39c47407c903" /> | 
| Transcribing | <img width="389" height="689" alt="Screenshot 2026-03-17 at 15 39 00" src="https://github.com/user-attachments/assets/38ed1208-8b8c-4d34-89f9-e0c756bef49b" /> | <img width="389" height="689" alt="Screenshot 2026-03-17 at 15 37 54" src="https://github.com/user-attachments/assets/f0eb6ebd-6a51-49e0-ac74-44ebfed7a23b" /> | 
| Forced Record + Forced Transcribing | <img width="389" height="689" alt="Screenshot 2026-03-17 at 15 47 39" src="https://github.com/user-attachments/assets/57635d0d-60ac-4c2c-81b0-016dde2461a9" /> | <img width="389" height="689" alt="Screenshot 2026-03-17 at 15 44 27" src="https://github.com/user-attachments/assets/59cba9d5-5d4f-4589-a5f0-c9484007c618" /> |

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#115548
Forward-Port-Of: odoo/enterprise#110122

This function is meant to compute the quantity from one UoM to another UoM, the rounding method parameter is meant to be used in that context.

If both UoM are the same, it should use the usual HALF-UP rounding method.

Explanations regarding the bug occurring in the related ticket:
- The OCR was matching a purchase order for which one of the lines had a quantity of exactly 6.
- When this PO was matched and imported on the vendor bill, the quantity of the related invoice line was rounded to 6.00000000000001. Under normal circumstances, the value would have stayed at 6 after rounding, but because the OCR runs within the context of a `_disable_discount_precision`, this kind of rounding discrepancy is possible.
- The billed quantity is then computed based on the quantity on the invoice line, 6.00000000000001. As it is rounded upwards to the nearest two decimals places, the final value is 6.01 instead of the expected 6.

opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387)

# Setup
Have 2 companies : A & B

# How to reproduce
- Set your website's company to Company B
- Create product X :
	- Company : Company A
	- Published
	- Name : xyz
- Go to Users > Any User > Acces Rights > Allowed Companies => leave only Company A
- Connect as that user on the website
- Go to the Shop tab and search xyz

# The problem
The product X is displayed, even though we currently use the company B's website and the product is limited to company A. 
This causes problem later when Sales Order are created using that product.

If you set the Allowed Companies of the user to both Company A and Company B, then the product is correctly hidden

# Why
When you search something in the search bar, the server does a `_search_with_fuzzy()` that ends up calling a simple `model.search()`.
In our case, this search should not return product X because there is an `ir.rule` that hides product not in the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/product/security/product_security.xml#L34-L38

But the `website` module has some particular rule about setting the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/website/models/ir_http.py#L249-L261

So, in our case, since the user does not have company B in its allowed companies, then
`allowed_company_ids` = Company A. So `('company_id', 'parent_of', company_ids)` is trucy and the product is displayed

# Proposed solution
Doing the search with `with_company` raise an AccessError because the company is not present in the allowed_companies. Chaging the allowed companies logic seems risky because it
may lead to unintended side effects.

We instead enforce the website's company in the search's domain

opw-6115647

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

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#257342

**Steps to reproduce:**
* Install the **l10n_cz** module.
* Create a customer invoice for a Czech company.
* Print the invoice.

**Observed behavior:**
* The **Tax ID (DIČ)** is displayed **twice** in the invoice header in default layout.
* **VAT** is displayed **twice** in the invoice headed in folder layout.

**Cause:**
* The `registry_vat_external_layout` template adds `company.vat` to `company_address_list`.
* Base external layouts already include `company.vat` in the same list.
* This results in duplicated DIČ rendering.

**Fix:**
* Remove the redundant VAT `<li>` from `registry_vat_external_layout`.
* Keep only the Czech-specific **Company ID** (`company_registry`) entry, which is not provided by base layouts.

Before:
<img width="900" height="261" alt="image" src="https://github.com/user-attachments/assets/9b5b81aa-a79d-4c93-8109-3c97d79356f4" />

After:
<img width="804" height="221" alt="image" src="https://github.com/user-attachments/assets/4b62eddc-6117-4f52-a8fb-2b03812aad8b" />

opw-6125766

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.

opw-6074833

**Steps to reproduce:**
- create a storable product avco auto 
- make sure that a purchase tax is set in 'General Information'
- create and confirm a PO for 30 quantities with a price of 0
- receive the products
- create and validate a delivery for 10 units of the product
- from the PO create the bill 
- set a date and save
- set a price of 100
- on the Bill set the total tax at 500 (it's bellow 'untaxed amount' 
on the bottom right of the bill and should be 450 before you 
change it, if the tax is 15%)
- confirm the bill

**Current behavior:**
The total tax was reset to 450

**Expected behavior:**
It should stay 500 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because :
When we confirm the bill, because the price is different than 
the one on the PO, _apply_price_difference does 2 things : 
(1) it creates an svl (with corresponding amls) for the quantities
that are still in stock (here 20)
(2) it adds amls on the bill (crediting stock interim received and 
debiting expense) to compensate the cogs deficit for the already 
out of stock quantities (here 10).
cf https://github.com/odoo/odoo/pull/126536 for more details

When we create those amls from (2),  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**Fix:**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-5413798

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359