Issue:
---
Due to this issue, generating PDF Quote using Quote Builder with dynamic fields leads to a traceback.

This was partially fixed by: e16edc7b0d9f56cb7769068ecf7d64ff8b0f6359

Steps:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quote builder tab, select a document. This document should have dynamic fields. e.g. you could use`Office Furnitures Header` document.
4- Print -> PDF Quote.

Cause:
---
In previous fix, we fixed the traceback when no dynamic field is set. However, if you have a dynamic field, then inside
`PdfWriter._update_field_annotation()`, the font is get from `DR` dict inside acroform:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L917-L929
Even if we are not setting a font, we need to have an empty `DR` dict inside acroform, in order to avoid calling `get` on a none object, which is leading to the traceback.

Also in previous fix we were losing `NeedAppearances` inside `AcroForm` by creating new dict which wasn't right.

opw-6392001

Forward-Port-Of: odoo/odoo#278881

Onsite events created from the "Onsite" view or the employee resume selector do not appear immediatlely after creation

This occurs because currently the domain for onsite events requires that the event to have multiple slots as well as to have at least one employee registered to it. Therefore, newly created records often fail these criteria and remain hidden.

In further versions, this pr: https://github.com/odoo/odoo/pull/246285/ changes the domain of the event selector in the employee resume by removing the dependency on the multiple slots and filtering by the specific employee for registration.

This change is not stable to backport as it indroduces the `employee_id` field as an invisible field in the xml to be able to compare in the domain.

This commit partly changes both domains to not require the multiple slots anymore, while still showing all events for which an employee is registered. This commit also ensures that when an event is created from the Onsite view or selector, the current user's employee will be registered to it.

Steps to reproduce
- Go to employees->Learning->Onsite
- Select New and create an event
- Go back to Onsite Courses
- You will not see the created event (unless it is multi_slot and an employee was registered)

opw-5915686

Forward-Port-Of: odoo/odoo#284200
Forward-Port-Of: odoo/odoo#258952

### Steps to reproduce:

- In the settings: Enable Storage Locations
- Create a customer location "Customer stock" with "Customers" as its parent location
- Create a delivery operation type "Deliver Super Customer" and set its default destination location to "Customer stock"
- Go to Inventory > Overview > Deliver Super Customer > New
- Set a contact on the transfer
#### > The destination location switches from "Customer stock" to "Customers"

### Cause of the issue:

The `location_dest_id` of `stock.picking` depends on its `partner_id`. So that changing the partner recomputes the locations of the transfer. However, as soon as the destination of the operation type has a `customer` usage, the `property_stock_customer` of the contact replaces it unconditionally:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L949-L963 
However, the `property_stock_customer` falls  back to an `ir.default` pointing at the default `Customers` location when nothing is set on the contact:
https://github.com/odoo/odoo/blob/1c40fab04b71def8f3645c4c4bb0c1441057f307/addons/stock/data/stock_data.xml#L71-L72vs

The override comes from 8a0775aa1dd9, which replaced an `elif` fallback on the contact by an "unconditional" substitution as this fallback had become unreachable once `default_location_src_id` and `default_location_dest_id` were made required:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L34-L41

opw-6421090

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

Forward-Port-Of: odoo/odoo#283886
Forward-Port-Of: odoo/odoo#280016

**Steps to reproduce:**
- Create a SO and add the Event Registration - Standard product and specify an event
- Confirm the SO then select "Create/Update registrations"
- Cancel the SO, then "Set to Quotation"
- Select "Preview" and confirm the Sale Order again
- There will not be any new registration created when there should be one.

**Behavior:**
Usually when a sale order is confirmed the `action_sale_order_event_registration` form will be opened which when filled correctly creates registrations. However in certain cases: confirming from the customer portal, or simply closing the form when it is opened, will not trigger `action_make_registration` which creates registrations if it is not already the case

`action_confirm()` should be creating the registrations correctly on its own anyway by calling ´init_registrations()´ : https://github.com/odoo/odoo/blob/beed378cde592bc96c1e79a976ac775264b843ed/addons/event_sale/models/sale_order_line.py#L49-L66

This function tries to create each missing registrations by looking at the amount in the so_line and deducting the already created registrations, however since some of them can be cancelled, this computation is wrong. And leads to registration not being created when they should.

opw-6444127

Forward-Port-Of: odoo/odoo#280426

Steps to reproduce:
1. Install Documents
2. In the Documents list view, select a document to display the inspector.
3. Edit a field such as Owner or Customer which uses a Many2one widget.
4. In the field dropdown, click "Search More..." to open a modal dialog.
5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers).

Issue:
- The modal dialog immediately closes, and the contact cannot be selected.

Root cause:
- When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack.

Solution:
- Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer.
Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear
the main selection and destroy the inspector field.


opw-6253360

Forward-Port-Of: odoo/enterprise#128812
Forward-Port-Of: odoo/enterprise#119262

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1

### Cause of the issue:

This is the exact use case already fixed in
85dd3369ed17b98b2ce485be04f140cf4cfa8aa3, which stamped the finished move with a `location_final_id` pointing at WH/Stock so that the move contributes to the forecast there even though its `location_dest_id` is the intermediate WH/Post-Production.

That fix was reverted in practice by 42275f83dc5350822a625e19d65148e8b41ab1d4, which replaced the value with `mo.location_dest_id`:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_move.py#L466-L467

Its reasoning was that in a single-warehouse setup `location_dest_id` equals the warehouse stock location, so the behaviour would be unchanged. That holds in 1 and 2 steps, where the extra step is on the component side and only moves `default_location_src_id` to the pre-production location. It breaks in 3 steps, the only mode that also moves `default_location_dest_id`, to the post-production location: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L246-L247 and `_compute_locations` propagates it to the MO:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/mrp_production.py#L334-L341

WH/Post-Production is a sibling of WH/Stock under the warehouse view location, not a child of it. Since `location_final_id` takes precedence over `location_dest_id` for the non-done part of the move chain:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L331-L334 the finished move stopped being counted in the WH/Stock forecast.

Why the test did not catch it:

`test_3_steps_manufacturing_forecast` stayed green through the whole regression, because it scoped `virtual_available` with a `location_id` context key. `_get_domain_locations` only reads `location` and `warehouse_id`; `location_id` is silently ignored: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L284-L287 The call therefore fell through to the branch scoping the forecast to every warehouse view location:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L303-L309 and the warehouse view location is the common parent of both WH/Stock and WH/Post-Production. The assertion held regardless of where `location_final_id` pointed, so the test was a false positive from the start: it also passes with 85dd3369ed17b98b2ce485be04f140cf4cfa8aa3 fully reverted. Using the `location` key makes it fail without the fix and pass with it.

### Fix:

Neither fix proposition was right on its own; each one was correct only in its own scenario. The`mo.warehouse_id.lot_stock_id` resolves the warehouse from the components, so it points at the wrong warehouse as soon as the finished product is produced for another one. `mo.location_dest_id` is the post-production location as soon as the warehouse manufactures in 3 steps, so it drops the quantity from the forecast of the manufacturing warehouse itself.

What separates the two is not the warehouse but whether the destination is a transit step. In 3 steps the finished product only reaches the stock through the post-production push rule: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L57 so the final location is the stock of the warehouse owning that destination. Any other destination is already final and is kept as is, which leaves cross-warehouse MOs and destinations set to a sub-location of the stock untouched.

The rule's destination is read rather than `warehouse.lot_stock_id` because a push move takes its destination from the rule and not from the operation type:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_rule.py#L256-L260
so the forecast stays correct when the store step is reconfigured to land somewhere else than the warehouse stock.

The rule is looked up on `pbm_route_id` by its `picking_type_id` instead of through `warehouse.sam_rule_id`, because that field is no longer set. It used to be an entry of `_generate_global_route_rules_values`, and it is that entry which made the generic warehouse machinery create the rule and store it back on the warehouse:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_warehouse.py#L403-L410
11e69870db1c49d9a6af79ffd263e4e162b34b6b removed it when the post-production step stopped being a pull rule on the Manufacture route and became a push rule generated from `get_rules_dict`. Only the field declaration was left behind, and nothing writes it any more:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L21-L22
so reading it would silently give an empty recordset. The lookup is not delegated to `_get_push_rule` to avoid a search per finished move.

opw-4882390

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

Forward-Port-Of: odoo/odoo#283952
Forward-Port-Of: odoo/odoo#283234

Steps to reproduce
---
1. Install sale_timesheet_enterprise.
2. Go to Timesheets > Configuration > Settings (as Admin).
3. Disable the "Billing Rate Indicators" setting and enable timesheet assistant.
4. Log in as a normal user with "Timesheets > Own timesheet" access.
5. Open the Timesheets app.

Issue
---
The "Configuration" menu is completely hidden. The regular user cannot access the "Assistant Rules" menu unless they turn on debug mode.

Cause
---
When the billing rates feature is turned off, the _load_menus_blacklist function hides the Enterprise Configuration menu. The logic used an and condition, meaning the menu was only kept visible if the user was an Assistant AND had Manager/Admin rights. This locked out standard users.

Fix
---
Change the blacklist condition. Allow the Enterprise Configuration menu to stay visible if the user needs it for the Assistant feature (when UoM is not Days), OR if the user is a Manager/Admin.

References to check other issues
https://github.com/odoo/enterprise/pull/120609
https://github.com/odoo/enterprise/pull/117984

task - 6470183

Forward-Port-Of: odoo/enterprise#128096

When a user manually sets a price on an optional line (overriding the pricelist), and then changes the quantity in the portal preview, the manual price is lost and gets reset to the pricelist price.

Steps to reproduce:
---
- Install Sales module and enable Pricelists.
- Create a product with qty-based pricelist rules:
   - min qty: 1  → price: 100
   - min qty: 10 → price: 80
- Create a quotation with an optional section containing this product.
- Manually change the product price to 150 (overriding pricelist).
- Mark the section as optional and preview the quotation.
- Change the quantity to 10 in portal preview.

Issue:
---
- The manually set price (150) is incorrectly reset to the pricelist price (80).

Root cause:
---
- After [commit], if there is no config parameter set and if there is an active pricelist, we simply call `_reset_price_unit()` without checking whether the price was manually set or not.
- Additionally, `_reset_price_unit()` calls `update()` which writes `price_unit` and `technical_price_unit` one by one as separate `write()` calls. The `write()` method has a guard([1]) that strips a lone `technical_price_unit` write unless `sale_write_from_compute` is set in context. Without this flag, `technical_price_unit` is silently discarded, causing it to drift from `price_unit`. On the next qty change, this mismatch is detected as a manual price, permanently blocking further pricelist updates.

Solution:
---
- Check whether the price was manually set before calling `_reset_price_unit()`, and pass `sale_write_from_compute=True` in context so both `price_unit` and `technical_price_unit` are written correctly.

[commit]: https://github.com/odoo/odoo/commit/93b6bdd6a4909bc0b45b90ab6a2d0734a218292d
[1]https://github.com/odoo/odoo/blob/fffd987cc98d1ea0cd04e24dda2ed8b64a219cdc/addons/sale/models/sale_order_line.py#L1391-L1399

opw-6426634

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

Forward-Port-Of: odoo/odoo#281107

Opening a tax report from a return and submitting it could act on a different
return than the one on screen.

_get_return_from_report_options searches by company, period and report with
limit=1, but that combination is not unique: l10n_nl declares two return types
on l10n_nl.tax_report, nl_tax_return_type and nl_tax_correction_return_type, so
a VAT return and its correction both match. Which one is returned is then
decided by _order (is_completed, date_deadline, name, id).

For a Dutch VAT correction it resolves to the original VAT return of the same
quarter, so send_xbrl submits and flags that record instead of the correction.

The options already carry the return type they were built for, in the
return_periodicity filter, so restrict the search to it when it is set.
l10n_nl_reports kept a return_id option for the same reason when computing the
already declared amount of a suppletie; it can use
_get_return_from_report_options now.

opw-6421300

Forward-Port-Of: odoo/enterprise#129278
Forward-Port-Of: odoo/enterprise#127073

When unreconciling a payment from an invoice with a cash basis tax,
the tax cash basis (CABA) entry is reversed. The reversal is supposed to
land in the same period as the origin entry so the tax report nets to
zero for that period.

Steps to reproduce:

- Enable cash basis and create a cash basis tax (exigibility on payment)
- Post an invoice dated in the past with that tax
- Reconcile a bank statement line to the invoice
- Resequence the cash basis entry so the month is dropped from the
  name (CABA/08/2026/0001 -> CABA/2026/0001)
- Unreconcile the statement line

Issue:

The reversal CABA entry created on the last unreconcile is dated today
instead of the origin entry's month. In the tax report the original tax
amount stays in the statement's month while the reversal amount appears
in the current month, so the two no longer cancel out.

Analysis:

While under a monthly journal sequence a past date returns
the last day of that month, under a yearly sequence a past date within
the current year returns the latter between the move date and today,
moving the reversal out of the origin period.

opw-6301553

Forward-Port-Of: odoo/odoo#284840
Forward-Port-Of: odoo/odoo#281250

### Issue:
When moves share the same `sequence_number` in a journal but have different suffixes (e.g. `INV/2026/00010` and `INV/2026/00010A`), the `made_sequence_gap` flag was incorrectly set

### Cause:
`_update_sequence_made_gap`, introduced in commit https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac selects the previous and next moves ordered by `sequence_number` without filtering by suffix

This causes two issues:
- Moves from different suffix sequences are used as neighbors, leading to incorrect gap detection
- Duplicate `sequence_number` values across suffixes are not accounted for, so only one move is considered per number

### Steps to reproduce:
- Install `account`
- Post 12 invoices to get a sequence up to `INV/2026/00012`
- Reset `INV/2026/00012` to draft, rename it to `INV/2026/00010A`
- Reset `INV/2026/00010A` to draft, rename it to `INV/2026/00009A` and confirm
Before the fix: `INV/2026/00011` is red
Expected: `INV/2026/00011` should not be red because `INV/2026/00010` exists
- Delete `INV/2026/00009`
Before the fix: `INV/2026/00010` is red
Expected: `INV/2026/00010` should be red (gap in no-suffix sequence)
- Reset `INV/2026/00009A` to draft and confirm it again
Before the fix: `INV/2026/00010` is not red
Expected: `INV/2026/00010` should still be red (different suffix)

### Notes:
Suffix changes are treated as distinct sequences following the same gap rules as any other sequence
This was agreed with R&D — the gap flag is meant to signal inconsistencies within a sequence, not across suffixes

opw-6454823

Forward-Port-Of: odoo/odoo#282503

### Before this fix
---

The `_get_so_mapping_from_project()` method returns a mapping where the key is
the move line ID and the value is a `sale.order` record (or `None`).

Because of the issues described below, a valid `sale.order` could be available
for reinvoicing, but the corresponding move line might still not be mapped to
that sale order. As a result, the move line is not added to the reinvoiceable
sale order.

However, the implementation has two issues:

#### 1. Projects are overwritten when they share the same analytic account

`project_per_accounts` is built as a dictionary mapping an analytic account ID
to a single project. If multiple projects reference the same analytic account,
each new assignment replaces the previous one. As a result, only the last
project associated with a given analytic account is retained.

**Example:**

* Analytic Account **AA1** is linked to **Project A** and **Project B**.
* The dictionary becomes `{AA1: Project B}`.
* **Project A** is lost, even though it also references **AA1**.

**Steps to reproduce:**

1. Create an analytic account **AA1**.
2. Create **Project A** and **Project B**, both linked to **AA1**.
3. Create **Sale Order SO1** linked only to **Project A**.
4. Create a vendor bill (or expense) that generates an AML using **AA1** for a
   product configured with **Reinvoice Costs = At Sales Price**.
5. Validate the document.

**Expected behavior:**
The product should be added to **SO1** for reinvoicing.

**Actual behavior:**
The move line is not mapped to **SO1**, so no sale order line is created.

#### 2. Previously found projects are overwritten during iteration

The `project` variable is reassigned on every iteration of the loop. After the
loop completes, it only contains the project (or lack of one) corresponding to
the last processed analytic account. This can cause valid projects found earlier
in the loop to be discarded.

**Example:**

* Move line has analytic accounts **AA1** and **AA2**.
* **AA1** maps to **Project A**.
* **AA2** has no linked project.
* After the loop, `project` is `None`, even though **Project A** was found.

**Steps to reproduce:**

1. Create analytic accounts **AA1** and **AA2**.
2. Create **Project A** linked to **AA1** only.
3. Create **Sale Order SO1** linked to **Project A**.
4. Create a vendor bill (or expense) whose AML is distributed between **AA1**
   and **AA2**, where **AA2** is processed after **AA1**.
5. Validate the document.

**Expected behavior:**
The move line should still be mapped to **SO1** because **AA1** references
**Project A**.

**Actual behavior:**
The last processed analytic account (**AA2**) overwrites the previously found
project, causing the move line not to be linked to **SO1**.

### After this fix
---

* `project_per_accounts` stores **all** projects associated with each analytic
  account instead of keeping only the last one.
* The project lookup preserves all valid project candidates instead of
  overwriting previously found results during iteration.
* As a result, the method can resolve the related `sale.order` in more cases,
  improving the overall accuracy of the mapping.

> **Note:** This change prevents valid project associations from being lost
> when multiple projects share an analytic account or when multiple analytic
> accounts are processed for the same move line.

**OPW:** 6294615

Forward-Port-Of: odoo/odoo#277110

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

Forward-Port-Of: odoo/odoo#283684
Forward-Port-Of: odoo/odoo#276905