In `knowledge_calendar_command_tour`, we were experiencing two issues

1. First, when we change the properties of a new calendar item, we were running into an issues where the tour would fail due to not being able to locate the dropdown option to create a new property. This only occurs if you don't set a step delay on the tour. This happens because in the `editSelectMenuInput` helper, we first check if the dropdown is open bfore we proceed. Since the tour runs so fast, we detect that the dropdown for the first property is open, so we pass the check. However, this then closes since we've moved on to the next dropdown, and since nothing has been input into the next dropdown, the create option doesn't appear. Now, we ensure that the create option will be present before attempting to click it

2. Later in the tour, we attempt to edit the properties on a new calendar item. We previously used `edit` to edit the property name, however this resulted in the "Select a template" modal being opened, which broke the tour, since we needed to click elements behind it. Using `fill` instead to populate the text field doesn't produce this behavior, allowing the tour to proceed without error.

[runbot-939647](https://runbot.odoo.com/odoo/error/939647?debug=assets)

Forward-Port-Of: odoo/enterprise#128830

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

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

Steps to reproduce:
- Enable presets on a restaurant PoS and tick "Amount of Guests" on the preset used for tables
- On device A, open a table and enter the number of guests
- On device B, open the same table

Issue:
Device B pops the guest count numpad again, even though the guest count was already entered on device A.

Cause:
ensureGuestCustomerCount guarded the popup on order.uiState.guestSetted. uiState is only serialized to IndexedDB (SERIALIZED_UI_STATE_PROP, used by serializeForIndexedDB); it is never sent to the server, so the flag is local to one browser and a second device always considers the guest count as not yet asked.

customer_count is synced and could carry that information, but PosStore createNewOrder pre-filled it with the table seats, so it was never 0 for a table order and could not tell "not asked" from "answered".

Fix:
Stop storing the seats default on the record and expose it from getCustomerCount() instead, so customer_count == 0 means "no guest count entered yet". ensureGuestCustomerCount now guards on that synced value, so an order whose guest count was entered on another device is not asked for it again. Every display goes through getCustomerCount(), so the values shown on the Guests button, the receipt and the preparation ticket are unchanged.

opw-6470180

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

Forward-Port-Of: odoo/odoo#284793
Forward-Port-Of: odoo/odoo#283002

## Steps to reproduce:
	- Install Planning and Employee
	- Create a working schedule for example 38h/week (8h,8h,8h,8h,6h)
	- Create two employees and assign the created working schedule to them
	- Create a shift in planning for the two employees for a week
	- Notice in gantt view the total allocated hours for each day are not calculated correctly

## Cause:
When calculating each cell's duration we fetch the resources' intervals while doing this here https://github.com/odoo/enterprise/blob/1851d3046682020686f517dec3c744d88a38b049/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L354-L359 we loop over the first interval and instead of pushing to the intervals we overwrite on the whole list with the interval we fetched so when it comes to the next interval it won't find any intersection so it will set the resourceIntervals to an empty array. So here https://github.com/odoo/enterprise/blob/1851d3046682020686f517dec3c744d88a38b049/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L231-L234 it will mess up the percentage calculation which will lead to wrong allocated hours numbers.

## Fix:
Instead of overwriting on resourceIntervals we push to it the intervals returned to keep the intervals for each resource.

opw-6316368

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

Issue:
When a user selects a generic appraisal template other than the first one, confirming or resetting the appraisal silently replaces that selection with the first generic template. Filtering appraisals by the originally selected template then fails to return the appraisal.

Steps to reproduce:
* Configure multiple appraisal templates without department restrictions.
* Create an appraisal and select a template other than the first one.
* Confirm the appraisal.
* Filter appraisals by the selected template.

Cause:
`_compute_appraisal_template()` only preserved templates directly linked to the appraisal's department. Generic templates have no department relation, so a valid selected template was discarded whenever the computation was triggered by a state dependent department recomputation. The generic fallback then stored the first template instead.

https://github.com/odoo/enterprise/blob/5c57ccbb13269af28de0a6c7f35454be52424f43/hr_appraisal/models/hr_appraisal.py#L195-L209

Solution:
We need to distinguish the generic default loaded on an unsaved form from a compatible generic template already stored on an appraisal. Preserve the latter across recomputations while retaining department template priority during creation and rejecting templates that no longer match the appraisal's department or company.

opw-6449041

Forward-Port-Of: odoo/enterprise#127566

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

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

Step to reproduce:
 - create a faulty token that won't work and link it to a subscription
 - launch the recurring invoice cron
 - the following traceback occurs

```
last_tx_sudo = (self.transaction_ids - existing_transactions).sudo()
```

When the payment fails, the system rollback and we store the last_tx_sudo value in a dedicated variable. After rollback, the record does not exists anymore. Therefore, accessing the value fails.

```
  File "/home/odoo/src/enterprise/saas-18.2/sale_subscription/models/sale_order.py", line 1703, in _handle_automatic_invoices
    if not last_tx_sudo or last_tx_sudo.renewal_state in ['pending', 'authorized']:
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1439, in __get__
    self.compute_value(record)
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1603, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 4575, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 69, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-18.2/sale_subscription/models/payment_transaction.py", line 25, in _compute_renewal_state
    if tx.state in ['draft', 'pending']:
       ^^^^^^^^
  File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1406, in __get__
    raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
```

Moreover, since https://github.com/odoo/enterprise/pull/45236/files#diff-c36fd7952cc2bef40716419a668de41963d49e1aa4177d9319d503fc260da588R1678-R1682

```
if not last_tx_sudo or not last_tx_sudo.renewal_state not in ['pending', 'authorized']:
```

has become

```
if not last_tx_sudo or last_tx_sudo.renewal_state in ['pending', 'authorized']:
```

But it feels strange to unlink the invoice when the payment succeed.


This PR fixes it.

Forward-Port-Of: odoo/enterprise#83913

Changing a project's visibility fails when its documents folder contains a shortcut.
The visibility change is never applied and the following error is raised:
"You can not update the access of a shortcut, update its target instead."

### Reproduction steps

- Create a project and add a document to its folder.
- Create another document outside the project's folder.
- Create a shortcut to that document in the project's folder.
- Change the project's visibility.

### Cause

Changing a project's visibility updates the access rights of its folder and documents together.

The shortcut access check is meant to reject operations performed only on shortcuts. However, reading `shortcut_document_id` on a recordset returns the shortcut targets found across that recordset. Therefore, the presence of a single shortcut makes the check reject the whole operation.

This prevents regular documents and the project folder from having their access updated.

### Fix

Only reject access updates when all records involved are shortcuts.

This preserves the protection against changing shortcut access directly while allowing project access updates to include shortcuts alongside regular documents and folders.

opw-6472637

Forward-Port-Of: odoo/enterprise#129448
Forward-Port-Of: odoo/enterprise#128756

**Description of the issue/feature this PR addresses:**

`avatar.mixin._avatar_generate_svg()` generates an auto-initial SVG avatar for any record without a real uploaded image (used by `res.partner`, `res.users`, and anything else inheriting `avatar.mixin`). The generated SVG opens with a single-quoted XML declaration: `<?xml version='1.0' encoding='UTF-8' ?>`.

When this content is served via `/web/image/...`, `guess_mimetype()` needs to determine its Content-Type since it's a computed value with no stored attachment metadata. On systems where the installed `libmagic` library classifies that specific single-quoted byte pattern as `text/xml` rather than `image/svg+xml`, the wrong Content-Type reaches the browser.

**Current behavior before PR:**

On affected `libmagic` versions/databases, an auto-generated avatar (a contact or user with no uploaded photo) gets served with `Content-Type: application/octet-stream` (or `text/xml`) instead of `image/svg+xml`. Browsers can't render that inline as an image, so instead of showing the colored-initial avatar, the browser downloads it as an unrecognized file. This affects any place these avatars are displayed: contact/user form and kanban views, chatter message authors, Discuss, etc.

Confirmed reproducible with `libmagic` 538 (`python-magic`), where the single-quoted declaration is classified as `text/xml`, while the exact same content with double-quoted attributes is correctly classified as `image/svg+xml`.

**Desired behavior after PR is merged:**

`_avatar_generate_svg()` now generates its markup with double-quoted attributes throughout, which is correctly sniffed as `image/svg+xml` regardless of the installed `libmagic` version. Auto-generated avatars render inline in the browser as intended.

No other code depends on the exact quoting of this generated SVG - `res_users.py` and `hr_employee.py` both only assign the returned bytes to an image field without inspecting their content. Avatar fields are computed and non-stored, so nothing needs to be migrated - every record gets the corrected markup on its very next read, with no backfill required.

Updated the two existing `test_avatar_mixin.py` tests that asserted the exact (single-quoted) SVG string, and added `test_generated_partner_avatar_mimetype` to assert the generated avatar is actually sniffed as `image/svg+xml`, so this can't silently regress. Ran locally: all 6 tests in `TestAvatarMixin` pass.

Forward-Port-Of: odoo/odoo#283741
Forward-Port-Of: odoo/odoo#283149

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

Problem:
`_compute_electronic_product_code` built `tracking_number_list` by filtering out move lines without a lot_id/lot_name, but kept iterating over the full, unfiltered `move_line_ids`. As soon as a tracked product had an untracked move line mixed in with tracked ones (e.g. a manufacturing byproduct move line with no lot), the two lists fell out of sync: at best tracking numbers got assigned to the wrong move line, at worst `tracking_number_list[i]` went out of range and raised an IndexError.
Solution:
Exclude untracked move lines from `move_line_ids` before building `tracking_number_list`, so both stay the same length and index- aligned. Untracked lines get their own explicit "no tracking number" error instead of breaking the alignment for the rest.

Steps to reproduce:
Open runbot V19 -> go to moves history (Inventory) -> add `electronic_product_code` to list view using studio -> remove filter/select all records -> https://anotepad.com/notes/jwxyskc2

Forward-Port-Of: odoo/enterprise#123859

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