**Issue:**

During migration to Odoo 19, the SA tax tag migration logic is present in: "migrations/2.1/pre-migrate.py" was not executed during the migration of databases because this:
  * SA compact tax tags were not renamed
  * VAT tax grids still use old tags
  * Localization reload was partially updating taxes
  * manual intervention was required

Added logs/debugging in:
* 2.1/pre-migrate.py
* 2.1/end-migrate.py
* 2.2/end-migrate.py

- Verified in both local and customer databases that only the 2.2 migration path was executed during upgrade, while the 2.1 migration scripts were skipped because the Odoo 19 manifest upgrade path already targeted the 2.2 migration version.
- 19:https://github.com/odoo/odoo/blob/67510fd36f7af31f83ef110602f9922ed5a43024/addons/l10n_sa/__manifest__.py#L6

**Solution:**

- Bumped the l10n_sa module version to 2.3 to apply these changes to databases that are already in production.
- Moved `migrations/2.1/pre-migrate.py` to `migrations/2.3/pre-migrate.py` to ensure the SA tax tag migration logic is executed during the `2.3` upgrade flow.
- Moved `migrations/2.2/end-migrate.py` to `migrations/2.3/end-migrate.py` to align with the `2.3` version bump and refresh the SA tax mappings correctly during migration.
   * SA tax tags migrate correctly
  * VAT tax grids update automatically
  * invoices use new tags correctly
  * No manual localization reload required

OPW - [6117408](https://www.odoo.com/odoo/project/70/tasks/6117408), [6224788](https://www.odoo.com/odoo/project/70/tasks/6224788)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Description of the issue/feature this PR addresses:

A file upload through `FileInput` (and therefore every `many2many_binary` field) still calls `onUpload` after the component has been destroyed. When the form or dialog holding the field goes away while the upload request is in flight, the response crashes the web client with two "Odoo Client Error" popups and the uploaded attachment is orphaned.

Steps to reproduce on a stock database (19.0, and 17.0 carries the same code):

1. Open an Email Template form (Settings > Technical > Email Templates), page *Options*, field *Attachments*. Any `target="new"` wizard with a `many2many_binary` field shows the same thing, e.g. the Recruitment *Refuse* wizard.
2. Pick a file that takes a moment to upload (a few MB, or a slow connection).
3. Before the file tile appears, leave the form through the breadcrumb, or close the wizard with Escape, its close button, or its action button. Nothing in the field shows that an upload is still running, so users do this routinely.

Current behavior before PR:

When the upload response arrives, two errors are raised:

```
UncaughtPromiseError > Component is destroyed
    at webRead <- _loadRecords <- _applyCommands <- addAndRemove
TypeError: Cannot set properties of null (setting 'value')
    at FileInput.onFileInputChange
```

Cause: `FileInput` posts the file through the `http` service, which is not protected against a destroyed component (unlike `orm`), so the response still reaches `onFileInputChange` after the component, the field and the form controller are gone. It then calls `onUpload`, which for `Many2ManyBinaryField` links the attachment through the form controller's protected ORM (hence the rejection), and it clears a file input ref that no longer exists (hence the TypeError).

We hit this in production on three different wizards over a few months. The client error logs users saved all carry the same trace, and the audit log shows the dialog's action completing a fraction of a second before the upload landed.

Desired behavior after PR is merged:

After the upload resolves, `onFileInputChange` stops when the component is destroyed: nobody is left to receive the uploaded files, and this matches how the protected services already treat a destroyed component. No error is raised, and `onUpload` is not called.

A Hoot test in `file_input.test.js` mounts a `FileInput` behind a `t-if`, starts an upload, unmounts the input while the upload is pending, resolves the upload, and asserts that `onUpload` was not called. It fails before the fix with the two errors above and passes after.

`master` already guards the ref write through its signal-style refs, but still calls `onUpload` on the destroyed component, so the first error remains there.

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

## Steps to reproduce:

- Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company
- Go to the PoS, select that partner
- Make a sale and ask for an invoice
- The downloaded invoice will be a pro-forma invoice

## Why the fix:

The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice.
https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204

As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do.

This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback.

We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow.

With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities.

opw-6428369

Forward-Port-Of: odoo/odoo#281420

# Description

**Steps to Reproduce**

1. Install Belgium Localization, then go to **Settings → Accounting/Invoicing**.
2. Enable **Verify VAT Numbers** (`vat_check_vies`).
3. Go to **Accounting → Configuration → Fiscal Positions** and confirm or create an **Intra-Community** fiscal position with:
   - Detect Automatically (`auto_apply`): enabled
   - VAT Required (`vat_required`): enabled
   - Country Group: EU, no specific country configured
4. Open an incognito/private browser window and make sure the session is unauthenticated.
5. Go to the website's `/shop` page and add any product to the cart.
6. Proceed to checkout until reaching the Address step (`/shop/address`).
7. Enter a delivery address in an EU country different from the company's country (e.g. company in Belgium, delivery address in the Netherlands).
8. In the VAT Number field, enter a real, valid, VIES-registered VAT number corresponding to the delivery country (e.g. a valid NL VAT number for a Netherlands address).
9. Click **Save Address / Continue** and proceed to the Payment step (`/shop/payment`).
10. Check the tax applied to the delivery line and the resulting order total.

**Issue**

The delivery product and the overall order are taxed at the standard/domestic VAT rate instead of the expected 0% intra-community rate — even though the customer provided a valid, VIES-registered EU VAT number matching the delivery country.

**Root Cause**

In `base_vat`, `res.partner.create()` unconditionally removes `vies_valid` from the ORM's pending computation queue via `env.remove_to_compute()`, relying on a subsequent `write()` to trigger the actual VIES check. This holds for the standard backend flow, where creation is followed by a `write()` — but the website guest checkout flow differs:

- `website_sale` creates the guest partner through `_create_new_address()`.
- The partner is created via a single `create()` call, with no follow-up `write()`.
- `_compute_vies_valid()` is therefore never triggered.
- `vies_valid` remains permanently unset (`NULL`), despite a VAT number being provided.

Downstream, `account.fiscal.position._get_vat_required_valid()` reads this unset value as falsy, so the Intra-Community fiscal position's `vat_required` condition fails and is rejected in favor of another applicable position (e.g. EU B2C or Domestic).

**Solution**

After partner creation, explicitly trigger `_compute_vies_valid()` when the partner has a VAT number and the operation is not part of a file import (`import_file` context) — performing the VIES check immediately instead of relying on a `write()` that guest checkout never issues.

**Result**

Guest customers providing a valid EU VAT number now get `vies_valid` computed immediately at creation. Fiscal position detection correctly identifies the Intra-Community position, and the expected 0% VAT treatment is applied to the delivery and order.

OPW: 6522992

Forward-Port-Of: odoo/odoo#286201

Context:
With https://github.com/odoo/odoo/commit/682d6ec1ddb825674999e0db1fc0cc48c3be67c5
we introduced `ODOO.FILTER.VALUE.V18` which behaves like
`ODOO.FILTER.VALUE` was behaving before 19.0

All spreadsheets upgrading from <19.0 to 19.0 have their ODOO.FILTER.VALUE
functions converted to the V18 version. The goal is to preserve the backward
compatibility for existing spreadsheets.

The issue:
The dashboard Accounting was updated[^1] to work with the new behavior but the
file was not updated to the latest version.

It means the data goes through upgrade[^2] and the function is converted,
even though the rest of the dashboard is designed to work with the new version.

The file was updated by commit https://github.com/odoo-dev/enterprise/commit/58811392bf7813cff39d874916b8dde117921d69, but
it requires a module update for existing databases.

This commit attempts to fix the issue for existing databases.

[^1]: https://github.com/odoo-dev/enterprise/commit/c4e69e36dbd79386193ffbd16e54809dbba8dba8
[^2]: spreadsheet has a client-side upgrade mechanism when it's
open.

#### Description of the issue:
- Color detection only checked the closest element of the selected text nodes, assuming the color is always applied on their direct parent.
- This is not always the case: the color can be applied on a `<font>` wrapping an inline element (e.g. a neutral style span created inside button links), or on the list item itself when its content is wrapped in a block (e.g. a heading).
- As a result, remove format could not remove such colors, and the background color button of the toolbar was not showing its border as no background color was detected for the selection.
- Removing the color of a partially selected list item wraps the targeted text nodes in a default colored `<font>`. With a collapsed selection there is no targeted content: the whole text node holding the cursor was wrapped, so the text around it lost the color of the list item.
- That default colored `<font>` was also created inside the `<font>` already wrapping the text, hiding the other colors of the latter from the removal: its background color was never removed and remove format ended up throwing an infinite loop error.

#### Desired behavior after PR is merged:
- Introduce the `closestColoredElement` util, which returns the closest element applying a color to a node by looking up its ancestors, stopping on `o_default_color` as such an element resets the color of its content, and limited to the closest paragraph related element, list item (color) or table cell (background color).
- Use it for the remove format detection and for the background color of the toolbar, which are now correct when the color is not applied on the direct parent of the text.
- With a collapsed selection in a colored list item, insert an empty default colored `<font>` at the cursor position, so that only the text typed there is uncolored, leaving the existing text untouched.
- Split the `<font>` wrapping the targeted text instead of nesting a new one inside it, and only skip the nodes of a `o_default_color` element when removing the text color, as such an element does not reset the background color.


task-6312677

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

Currently on creating  new helpdesk team everytime a new website menu is created.

### **Steps to Reproduce:**
1) Install website_helpdesk
2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 
3) Create 2 helpdesk team with `Website Form` option enable. 
4) Navigate to Website.

### **Observed Behavior:**
Two Help menus are created.

### **Expected Behavior:**
Multiple menus should not be created.

### **Root Cause:**
The menu creation logic relies on the following [condition](https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/website_helpdesk/models/helpdesk.py#L111-L112)
`team_count_by_website` is built from `_read_group(..., ['website_id'], ...)`,
which keys its result by the `website_id` *recordset*, not its id. Looking it
up with `team_count_by_website.get(website.id, 0)` therefore always misses and
falls back to `0`, so `team_count <= 1` is always `True` regardless of how
many teams already exist for that website. The only thing left guarding menu
creation is `any(team.website_menu_id for team in teams)`, which only looks at
the teams in the current create/write call, not every team on that website.
So saving a second team in a separate call always creates another menu.

### Fix:
Make the website menu a resource shared by every team with the website form
enabled on a given website, instead of "owned" by whichever team created it:
- Before creating a new menu, look up other teams (active or archived) that
  already point to a menu, matched through the `website_menu_id` relation
  between teams rather than a hardcoded `/helpdesk` URL, so a customized menu
  URL doesn't cause a duplicate to be created. Reuse that menu when found.
- Only delete a menu once no team (active or archived) still references it,
  checked before removing a team's own reference.

**opw-6303846**

Forward-Port-Of: odoo/enterprise#130207
Forward-Port-Of: odoo/enterprise#121120