Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

Customers placing an order without logging in and with the "Pick up in store" delivery method are not notified when the delivery is confirmed

Steps to reproduce:
1. Install eCommerce and Sales
2. Go to Settings > Website > Delivery and enable "Click & Collect"
3. Go to Settings > Inventory > Shipping and enable "Email Confirmation"
4. Go to Website > Configuration > Payment Providers and Install Demo
5. Go to Website > Configuration > Delivery Methods and open "Pick up in store", set YourCompany as warehouse and publish it
6. Go to Sales > Products, open product "Office Lamp", click on "Update Quantity" in the status bar and add 5 units
7. Log out
8. Go to the shop, add product "Office Lamp" to the cart and checkout
9. Fill in the address form and continue checkout
10. Select "Pick up in store" as delivery method and select a location
11. Confirm the order and pay with Demo
12. As user Mitchell Admin, go to Sales, remove the default filter and open the newly created sale order
13. Open the related delivery with the smart button and validate it
14. No delivery order confirmation was sent to the customer (check emails)

Issue:
Pickup addresses are always inactive, preventing the partner from receiving email confirmation

Solution:
Disable archiving of pickup addresses

opw-6095396

Forward-Port-Of: odoo/odoo#265392
Forward-Port-Of: odoo/odoo#263005

Description of the issue/feature this PR addresses:
Fixes an issue where the sale order reference computation was fetching the invoice journal based on the logged-in user's current company instead of the company associated with the specific payment provider or transaction context. This caused incorrect reference processing or errors in multi-company environments when a user was logged into one company but processing an order from another.

Current behavior before PR:
The function searches for the account.journal using self.company_id.id. Since self in this context (likely a payment provider or transaction record) might be evaluated under the active user's environment context, it fetched the journal from the user's currently active company (allowed_company_ids), disregarding the actual company related to the sale order or the transaction.

Desired behavior after PR is merged:
The invoice journal search uses the correct company context (e.g., order.company_id.id or the specific company linked to the payment record), ensuring that the sale order reference is processed using the appropriate journal from the correct company, regardless of which company the logged-in user is currently switched into.




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

Forward-Port-Of: odoo/odoo#269558

Version:
----------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Enable `Storage Locations` from Inventory settings
- Create a tracked storable product with on-hand 8 units in `Shelf 1`
- Create Delivery 1 for 5 units and click `Mark as To Do`
- Create Delivery 2 for 5 units and click `Mark as To Do`
- Verify reservations:
  - Delivery 1 reserves 5 units
  - Delivery 2 reserves remaining 3 units
- Relocate all 8 units from `Shelf 1` to `Shelf 2` using the `Relocate` action from `stock quant`
- Reopen both deliveries

Issue:
------
After relocating stock between internal locations, reservations are reassigned
in the wrong order:
- Delivery 2 becomes fully reserved with 5 units
- Delivery 1 is reduced to 3 reserved units

This incorrectly swaps the original reservation priority between deliveries.

Cause:
------
The relocation wizard starts from:
`stock.quant.relocate.action_relocate_quants()`
which calls `move_quants()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/wizard/stock_quant_relocate.py#L70

`move_quants()` validates an internal stock move through `_action_done()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_quant.py#L1572

During validation, `_synchronize_quant()` moves the stock quantity from
`Shelf 1` to `Shelf 2`.

However, the already reserved delivery move lines still reference `Shelf 1`.
This temporarily makes the source quant negative (`available_qty < 0`),
triggering `_free_reservation()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L695-L700

Inside `_free_reservation()`, move lines are ordered using
`current_picking_first`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L816-L821

Since both deliveries share the same scheduled date, the fallback ordering
uses `-cand.id`, causing Delivery 2 (higher id) to be processed before
Delivery 1 (lower id).

The reservation cleanup therefore happens in this order:
- Remove Delivery 2 reservation (3 qty)
- Remove Delivery 1 reservation (5 qty)

The corresponding moves are then added to `move_to_reassign`
in the same order:
`[Delivery 2, Delivery 1]`
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L849

Later, `move_to_reassign._action_assign()` processes the moves in recordset
order:
- Delivery 2 reserves 5 units first
- Delivery 1 only gets the remaining 3 units

As a result, reservation priority is unintentionally reversed after relocation.

Fix:
----
Before calling `_action_assign()`, reverse `move_to_reassign` 

This ensures reassignment preserves the original reservation order:
- Delivery 1 is reassigned first and recovers 5 units
- Delivery 2 receives the remaining 3 units

The reservation state therefore remains consistent before and after
internal stock relocation.

---

opw-6218256

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

Forward-Port-Of: odoo/odoo#270061
Forward-Port-Of: odoo/odoo#265169

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Forward-Port-Of: odoo/enterprise#120065
Forward-Port-Of: odoo/enterprise#118813

Summary
=======

`_check_if_used_in_website_form`, the ondelete hook on
`ir.model.fields` that guards against deleting a field referenced by
a website form, performs poorly on realistic databases. It can take
multiple minutes to validate a single field deletion, blocking user
actions such as removing a Studio field.

This commit restricts the scan to columns that can actually contain
website form markup, bringing the hook from multi-minute to
sub-second without any loss of coverage.

The Problem
===========

Deleting any `ir.model.fields` record triggers this validation hook,
which must ensure the field is not referenced inside any website
form. The implementation iterates every stored HTML column returned
by `website._get_html_fields()` and runs one case-insensitive
`ILIKE '%data-model_name="<model>"%'` search per column against
`<model>.<html_field>`, then parses each match with `lxml` and
validates it with XPath.

Two root issues cause the multi-minute cost:

- **Unbounded scan surface**: all stored HTML columns are scanned
  (~95 on realistic databases), even though the vast majority of them
  declare `sanitize=True` and `sanitize_form=True` (the defaults).
  When both flags are True, `<form>` tags are stripped on write and
  the column can never physically contain website form markup.
- **Per-column `ILIKE` cost**: `ILIKE` on large TEXT/JSONB columns
  performs a sequential scan. A single large HTML column is enough
  to make the hook run for several minutes on its own.

Improvements
============

- Scan only columns that can actually contain forms:
  - `ir.ui.view.arch_db` , primary target; all website forms are
    stored there.
  - HTML fields whose sanitization either is disabled
    (`sanitize=False`, e.g. `blog.post.content`,
    `website.custom_code_head`) or explicitly allows forms
    (`sanitize_form=False`, e.g.
    `product.template.website_description`, `hr.job.description`,
    `event.event.description`). Any other HTML field strips `<form>`
    on write and will never contain a form.
- Batch searches: group the deleted fields by model once and emit a
  single `OR`-domain search per candidate column, instead of one
  search per (field, column) pair.
- Parse each returned record with `lxml` and validate with XPath
  directly. The `ILIKE` domain already filters out non-matching rows
  DB-side.

Benchmarks
==========

Profiled on a database containing ~95 stored HTML columns and ~5.2k
views. The hook was invoked read-only via
`field._check_if_used_in_website_form()` on a custom field.

| Metric                         |     Before |      After |
| :----------------------------- | ---------: | ---------: |
| Hook wall time                 |     ~444 s |    ~173 ms |
| HTML columns scanned           |         95 |          5 |
| SQL queries issued             |         96 |          6 |

Key results:

- Hook wall time reduced from multi-minute to sub-second
  (~2,570× faster on the profiled database).
- Scan surface reduced from ~95 columns to a handful (1 +
  the form-capable HTML fields installed on the database, typically
  under 10).

opw-6086536

Forward-Port-Of: odoo/odoo#268666
Forward-Port-Of: odoo/odoo#259846

Several related fixes around the AvaTax connection settings:

- Surface an unconnected "Avalara Included" setup instead of silently using Direct credentials. Filling Direct credentials, switching to Included, then not completing the connection (link/migrate/create) left the company looking configured through those leftover credentials: the user believed they were on Included while a request either silently used Direct or crashed on the unset IAP proxy user (ensure_one). Direct credentials now only count in Direct mode, so the not-connected state raises the usual RedirectWarning pointing to the configuration.

- Group nexus locations by country in the connection test result. The list dumped every nexus row flat, so countries appeared alongside their own regions and each jurisdiction repeated once per tax type (e.g. "California" dozens of times). Group by country, drop the country-wide rows, dedupe and sort, with a short summary line.

- Make the "Help me choose" documentation link version-aware via the documentation_link widget instead of the /latest/ alias, which redirects to the latest major release (19.0) where the AvaTax docs don't exist.

task-6295272