Doing an euclidean division on floats with the native operators is unreliable: because of IEEE-754 representation errors, `value1 % value2` can return a spurious remainder (e.g. `50.4 % 16.8 == 16.799999999999997` instead of 0.0) and `int(value1 / value2)` can truncate the quotient one step too low (e.g. `int(0.3 / 0.1) == 2` instead of 3). `float_div` returns the `(quotient, remainder)` pair free of those errors.

The key is to never run a lossy `%` or `//` on the raw floats. Instead both operands are first snapped onto the precision grid with `float_round` and then scaled to integers: since a grid-snapped value is a multiple of `rounding`, dividing it by `rounding` counts how many grid steps it spans. That division is still noisy (`4.35 / 0.05 == 86.99999999999999`), so the result is passed through `builtins.round` to coerce it to the exact integer step count. The euclidean division itself is then a plain integer `divmod`, which is exact, and the remainder is scaled back to real units. This is why the correction is applied to the inputs and not to the output: rounding the result of a native `%` would only round an already-corrupt value, and would still misreport the quotient in the corner cases the util exists to handle.

Dividing by `rounding` is meaningful for any precision, not only powers of ten: the grid step can be `0.05`, `0.25`, `0.5`, `0.03`, ... and `value / step` counts the steps in every case. This mirrors the normalize/denormalize scheme `float_round` already uses internally.

The util shares `float_round`'s inherent limitation: the scaled step count must stay representable as an exact `float` integer, so exactness is lost past ~2**53 grid steps (extreme magnitudes at a fine precision). This is the IEEE-754 double-precision ceiling and is well outside any realistic quantity or price range.

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

Forward-Port-Of: odoo/odoo#280456
Forward-Port-Of: odoo/odoo#277160

Removing a tag from a document in the list view raises "onDelete is not a function" and the tag is not removed.

### Steps to reproduce

- Open Documents in list view with the Tags column shown.
- Select a document that has tags.
- Click the tags cell to edit it, then click a tag's delete button.

=> The error is raised.

### Cause

`onGlobalClick` calls `leaveEditMode()` for every click, in-row clicks included, because it runs before the guard that ignores them (the base list renderer returns early on in-row clicks).

A tag's delete button, and its `onDelete` callback, only exist while the field is editable. Clicking it fires `onGlobalClick` first, which leaves edit mode and turns the field read only, so `onDelete` becomes undefined. The click then reaches the button and calls it, raising the error.

### Fix

Return early on clicks originating inside a data row, before `leaveEditMode()`, as the base list renderer does. Clicks outside a row still leave edit mode.

opw-6399042

**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.

**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.

**Current behavior:**
The cancellation email is rendered in the organizer's language.

**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.

**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.

**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.

opw-6323179

Forward-Port-Of: odoo/enterprise#125927
Forward-Port-Of: odoo/enterprise#124116

Steps to reproduce:-
- Open any report.
- Click on a particular line to unfold more than once very fast(or throttle network to 3G)
- Once line is unfolded click again to fold that line.
- Line is not folding.

Cause:-
- When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked).
- Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold  the same line, resulting in unfolding the same line multiple times.
- In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible.

Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times.

task-6260425

Forward-Port-Of: odoo/enterprise#126765
Forward-Port-Of: odoo/enterprise#120392

* = account_invoice_extract, l10n_nl_reports

Example of steps:
- Install web_studio and `accountant`
- Open the corresponding form view in Studio
- With debug mode toggle "Show invisible Elements" and edit
"Invisible" on the second partner_id field
- Traceback

`normalize()` compares the combined arch without the studio
customization to the one with it, in order to compute the smallest
possible set of xpaths. To do so, it calls `apply_inheritance_specs`
(the low-level function from `odoo.tools.template_inheritance`)
directly on the statically combined arch.

Some models add or duplicate nodes dynamically in `_get_view()`
(Python postprocessing, run after the static view combination). A
studio operation can target such a node, since it is what the user
actually sees and clicks on. But that node has no counterpart in the
purely static combined arch used by `normalize()`, so
`apply_inheritance_specs` raises a ValueError.

`edit_view()` only catches `ValidationError` to fall back to an
un-optimized (but valid) studio arch instead of failing the request.
Since the low-level function raises a plain `ValueError` here, that
fallback never triggers, and the exception is not caught anywhere.

To fix this, we will keep the behavior from version 18.0 and catch the
ValueError raised by `apply_inheritance_specs` in
`normalize_with_keyed_tree` and re-raise it as a ValidationError, like
`ir.ui.view.apply_inheritance_specs` already does elsewhere. This lets
`edit_view()`'s existing fallback handle the case gracefully instead
of crashing.

Additionally, the two models responsible for the dynamically-added nodes
described above are fixed at the source. `account_invoice_extract`'s
duplicated `partner_id` field and `l10n_nl_reports`'s injected
`company_id` field are now marked with `data-used-by`, the same
attribute `_add_missing_fields` already sets in `ir_ui_view.py` for the
fields it adds.
Studio already skip rendering and computing xpaths for any node carrying
this attribute (since https://github.com/odoo/enterprise/pull/92862),
so these nodes are no longer exposed to the user and can no longer
produce a studio operation that `normalize()` is unable to locate.

opw-6332911

Forward-Port-Of: odoo/enterprise#122829

**Before this change**
We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values.

This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record.

**After this change**
Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record.

Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state.

opw-6390453

Forward-Port-Of: odoo/enterprise#125374

Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer listed.

### Steps to reproduce

- In Documents, share a folder with a portal user and set an expiration date.
- Wait until the expiration date has passed.
- Share the same folder with the same user again from the invite box.

=> The dialog says the member was added, but the user has no access and does not appear under "People with access".

### Cause

The invite box has no expiration field. When re-inviting a user, it updates the existing `documents.access` record and passes `None` for the expiration, which keeps the old `expiration_date`. If that date is already in the past, the user remains expired even though the invite reports success.

### Fix

Pass `False` instead of `None` when inviting a member so the existing record's expiration date is cleared. Re-inviting an expired user now restores access. Setting an expiration from the "People with access" list is unchanged.

opw-6387559

Forward-Port-Of: odoo/enterprise#125140

Problem:
When scanning the first product, the second move line is clicked immediately after. https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode_picking_batch/static/tests/tours/tour_test_barcode_batch_flows.js#L1529-L1541 If this happens before the first scan has finished, its quantity is incorrectly applied to the second move line that is clicked. This causes a 0 - 3 split instead of a 1 - 2 split, which results in there only being 6 move lines instead of 7.

We updated our quantity on the `currentLine`
https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1478

When finding `currentLine`, we go through `_findLine` and use `this.selectedLineVirtualId`, which is the one that is currently selected in the UI https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1705-L1712

Purpose:
By adding this step, we wait until the first line’s quantity to be updated before it moves on and clicks on the second product.

runbot-941211

Forward-Port-Of: odoo/enterprise#126847
Forward-Port-Of: odoo/enterprise#124162

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `purchase` and `stock`
- Create a Purchase Order for a storable or consumable product
- Set the ordered quantity to a negative value (e.g. `-10`)
- Confirm the Purchase Order.
- Open the Deliveries and search using the Purchase Order name

Issue:
------
An outgoing return picking is correctly created for 10 units, but an
additional empty incoming receipt is also generated and linked to the
Purchase Order.

Cause:
------
When a Purchase Order is confirmed, `purchase.order.button_approve()` calls
`purchase.order._create_picking()`:
https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/purchase_stock/models/purchase_order.py#L179

Inside `_create_picking()`, if no open picking exists yet,
Then first creates an incoming receipt using `_prepare_picking()`:
https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/purchase_stock/models/purchase_order.py#L382

The generated receipt is configured with:
- source location: Vendor
- destination location: Stock
- picking type: Incoming
- origin: Purchase Order reference

Stock moves are then created on that receipt through:
https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/purchase_stock/models/purchase_order.py#L387-L388

For negative PO quantities, the move is initially created with a negative
demand:

```
Vendor -> Stock, quantity -10
````

During `stock.move._action_confirm()`, stock identifies such moves in
`neg_r_moves`:
[https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1604](https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1604)

Those moves are automatically converted into return moves by:

* swapping source and destination locations,
* converting the quantity to positive,
* assigning the return picking type when available:
  [https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1612-L1614](https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1612-L1614)

The resulting move becomes:

```
Stock -> Vendor, quantity 10
```

The converted move is then reassigned through:
[https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1630](https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1630)

This correctly creates the outgoing return picking.

However, the original incoming receipt created earlier by
`purchase_stock` is left without any moves, resulting in an empty
ghost receipt linked to the Purchase Order.

Solution:
---------
- Track whether `_create_picking()` created a new incoming receipt during
the current confirmation flow.

- After stock move confirmation, if that newly-created receipt no longer
contains any moves, unlink it and remove it from the pickings to
confirm.

- This preserves the valid outgoing return picking while preventing empty
incoming receipts from being generated.


NOTE:
------

This Issue not reproduce from saas-19.3. 
Fix in this [commit](https://github.com/odoo-dev/odoo/commit/81caaaa3f7212ad5d9d72cd446b65c5fb0a9bef9)

---

opw-6131329

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

Forward-Port-Of: odoo/odoo#265704

### Issue:
A user who can modify `tax_exigibility` but does not have `account.group_account_readonly` is blocked from switching to `on_payment`
There is no way to complete the operation as the account field is not visible and cannot be filled before saving
 
### Cause:
When `tax_exigibility` is set to `on_payment`, the view expects `cash_basis_transition_account_id` to be filled before saving`_constrains_cash_basis_transition_account` then validates that the account is reconcilable
 
`cash_basis_transition_account_id` was restricted to `account.group_account_readonly`, hiding it from other users
The field is never rendered, so it cannot be filled
The `required` constraint is never evaluated client-side and `_constrains_cash_basis_transition_account` raises a `ValidationError` on save because the account is empty
 
There is no reason to restrict `cash_basis_transition_account_id` independently — if a user can modify `tax_exigibility`, they must also be able to set the linked account
 
### Steps to reproduce:
- Install `account`
- Enable Cash Basis in Settings
  (On RunBot ensure no default account is set)
- Enable Developer Mode in Settings
- Go to Settings > Users & Companies > Users
- Open the current user and disable both:
  `Show Accounting Features - Readonly` and `Show Full Accounting Features` (if set)
- Go to Invoicing > Configuration > Taxes
- Open any tax and go to Advanced Options
- Change Tax Exigibility to Based on Payment

Before the fix, the account selector is not displayed and saving raises an error
 
opw-6359173

Forward-Port-Of: odoo/odoo#274728

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

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

Forward-Port-Of: odoo/odoo#280351

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

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

Forward-Port-Of: odoo/odoo#280329

### Steps to reproduce:

- Create 3 AVCO products: Super Kit, Kit, Comp
- Super Kit BoM: 2 x Kit
- Kit BoM: 1 x Comp
- Create and confirm a purchase order for 1 X Super Kit at 100
- Validate the receipt of 2 Comp
- Go to the valuation
> Both units of Comp are valued at 100 for a total of 200

### Cause of the issue:

The issue has been introduced by:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063 To be more precise, the price unit of each unit of Comp is expected to be computed by the `_get_price_unit`. This method used to rely on the `product_qty` appropriately:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063#diff-687527af1723e60816358020c4d83687479df62ca0cfd71079f0a82afb4b3efeL27 However, backorder adapt the move demand and hence did not provide the appropriate demand in this flow that computation logic was changed to rely on the `bom` and `bom_line` quantities:
https://github.com/odoo/odoo/blob/29977a6a80442af49ecefa7fef54f085483d8f77/addons/purchase_mrp/models/stock_move.py#L20-L40 This new computation is not correct in case of nested boms since the `bom_line` only carries the unit demand on the last explosion stage.

### Additional issue:

If nested kit boms lead to the creation of 2 moves with the same `cost_share` and `bom_line_id`, these moves will be merged without summing their `cost_share` leading to an under pricing of the kit since its related `stock_move`'s `cost_share` will not sum up to 100 percents anymore.

This issue is tested in `test_avco_purchase_nested_kit_explode_cost_share_backorder_2` and fixed similarly to demand merging:
https://github.com/odoo/odoo/blob/613f3cb7b2f4813ce6c8f53718a6cca841b081ad/addons/stock/models/stock_move.py#L1122-L1134

### Note:

We also modify the test `test_valuation_with_backorder` to be understandable and to make appropriate asserts.

opw-6253776

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

Forward-Port-Of: odoo/odoo#279890
Forward-Port-Of: odoo/odoo#276242

**Issue**
Confirming a SO that generates a batch of MOs from a BoM with a
batch size could lead to creating an invalid number of pickings: all the
MOs end up sharing a single picking instead of getting one each.

**Steps to reproduce**
- Use 2-step manufacturing
- Create a storable product with the MTO + Manufacture routes
- Add a BOM that has a batch size of 10 that consumes one component
- Create and confirm a SO of 100 units of that product
-> 10 MOs are created, but each one points to the same "Pick Components" transfer instead of getting its own.

**Cause**
This commit dd6ee071f949752d31497d9f975ba7fc41ebcd98 batches the confirm of productions: 
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/mrp/models/stock_rule.py#L120
thus `assign_picking` is called in batches: 
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/mrp/models/mrp_production.py#L1653
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1736-L1737
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1550-L1556
since, the `reference_ids` are the same for each MO/stock.move (they all come from the same procurement):
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1712-L1713

Consequently, all the moves end up in the same recordset `moves`:
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1527
Creating only one picking:
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1577

opw-6403427

Forward-Port-Of: odoo/odoo#279179

Issue
-----
Branch companies can have quants of a product limited to their parent company, but they don't show in the per location report.

Steps to reproduce
-----
- Create a branch company
	- Create a WH for the branch
- Create a tracked product
	- Company set to parent only
- Switch to the branch company
	- Add a quant of the product in branch stock
- Open Inventory > Reporting > Locations

> The product is not shown although there is a quant in the branch

Cause
-----
The menu button triggers `action_view_quants`

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/views/stock_quant_views.xml#L493-L495

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L399-L402

The problem here comes from the fact that in `_get_quants_action`, we limit the products to those of only the active companies, instead of allowing to view those of parent companies aswell.

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L1330

Such a change works because the domain is specifically for the product's (`product_id.company_id`) and not the location's.

-----
Ticket:
opw-6131525

Forward-Port-Of: odoo/odoo#280083
Forward-Port-Of: odoo/odoo#277531

Steps to reproduce the error: (Python Version: 3.14.X)
- Install ``accounting_firm`` industry with demo data

Code for server action to generate the error:
```py
for i in [1]:
    try:
        pass
    except Exception:
        pass
    if i:
        pass
```

Traceback:
```py
ValueError: forbidden opcode(s) in'...': JUMP_BACKWARD_NO_INTERRUPT
```

https://github.com/odoo/industry/blob/701f7595453772e42ce72aa75df346a504e5bd82/accounting_firm/demo/ir_actions_server.xml#L105-L108
The server action contains a ``for`` loop with a ``try/except`` block followed by additional statements in the loop body,
this combination generates the ``JUMP_BACKWARD_NO_INTERRUPT`` opcode, which is not included in ``_SAFE_OPCODES`` at [1].
When the server action is evaluated by ``safe_eval``, it calls the ``assert_valid_codeobj`` method, which validates the compiled bytecode against ``_SAFE_OPCODES``. Since ``JUMP_BACKWARD_NO_INTERRUPT`` is not present in the allowed opcodes, ``assert_valid_codeobj()`` raises a ``ValueError`` at [2] before the server action is executed .

Solution:
``JUMP_BACKWARD_NO_INTERRUPT`` opcode is added in the ``_SAFE_OPCODES`` and it is also added in the ``_SAFE_QWEB_OPCODES``.
It was added in Python 3.11: https://docs.python.org/3/whatsnew/3.11.html#new-opcodes

``JUMP_BACKWARD_NO_INTERRUPT`` is a control-flow opcode that only changes
the interpreter's execution flow by jumping back to a previous instruction.
It is the equivalent to ``JUMP_BACKWARD`` opcode. Its only semantic difference is
that the interpreter does not perform an interrupt check at that instruction.
It does not introduce any new capabilities or perform operations such as
attribute access, imports, function calls, or object creation.
Ref: https://docs.python.org/3.12/library/dis.html#opcode-JUMP_BACKWARD_NO_INTERRUPT

Similar commit that adds some necessary opcodes: 
https://github.com/odoo/odoo/commit/86498d24946e510025add5d24ef0d4bcce8ad05f

[1]: https://github.com/odoo/odoo/blob/2ccbc4660077bd48529e9de43d4309fbfafc75ca/odoo/tools/safe_eval.py#L135
[2]: https://github.com/odoo/odoo/blob/2ccbc4660077bd48529e9de43d4309fbfafc75ca/odoo/tools/safe_eval.py#L244-L246

sentry-7614026125

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

Forward-Port-Of: odoo/odoo#277192

### Issue:
A partner with VAT set to '/' incorrectly matches a fiscal position with `VAT required`, instead of one without

The '/' value is the placeholder suggested by the UI to indicate that the partner is known to have no VAT, but it was treated as a valid VAT by the fiscal position matching logic

### Cause:
`_get_fpos_ranking_functions` uses `_get_vat_valid` to rank fiscal positions based on VAT presence
`_get_vat_valid` returned `True` for any non-empty VAT value, including '/'
The '/' case was not excluded, causing it to be treated as a valid VAT number

### Steps to reproduce:
- Install `account`
- Create two fiscal positions with auto-apply:
-- Name: FP VAT, VAT required: True, sequence: 1
-- Name: FP no VAT, VAT required: False, sequence: 2
- Create a partner with VAT: '/'
- Create an Invoice for that partner and check the Fiscal Position

Before the fix, `FP VAT` is selected instead of `FP no VAT`

opw-6204531

Forward-Port-Of: odoo/odoo#280494
Forward-Port-Of: odoo/odoo#280065

## Issue
When logging timesheet from the *Recorded* smart button on a Sale Order containing multiple service items, the recorded hours will be added to the first sale order line, regardless of the task ID set on the timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P:
    - *Product Type*: Service
    - *Create on Order*: Task
    - *Project*: Any
3. Create a SO:
    - *Customer*: Any
    - Add the product P on two different lines and give them two different descriptions D1 and D2
    - Confirm the SO, this will create two tasks with the names D1 and D2
4. On the SO, click the *Recorded* smart button and create two entries:
    1. Task D1, 2 hours spent
    2. Tsk D2, 3 hours spent
5. **Back on the SO, there are 5 hours registered for the first SOL (with the description D1), which does not match the entries we created from the smart button.**

It is worth noting that when we create the Timesheets entries from the project itself (instead of the SO's smart button), the hours are correctly distributed among the different SOLs.

## Cause
The SOL linked to the timesheet entry (`account.analytic.line`) is computed by `_compute_so_line`:

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/hr_timesheet.py#L79-L82

This method sets the correct SOL under the condition that `is_so_line_edited` is False and `_is_no_billed()` returns True.

When opening the *Recorded* smart button from a SO, the `is_so_line_edited` is set to True by default, even if no SOL was modified.

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/sale_order.py#L113-L117

As that value is never set to False, when trying to compute the SOL for the timesheet entry, the entry is skipped and the default SOL (which is the first one) is used instead.

opw-6133473

Forward-Port-Of: odoo/odoo#274759

Before this commit, this test sometimes failed because it couldn't find a dialog containing "camera" within 200ms.

In the test scenario, we click to open the BarcodeDialog, which uses the BarcodeVideoScanner. The latter, in its `onMounted`, checks whether it has the necessary permission, which isn't the case as the `getUserMedia` function is mocked in the test to return a rejected promise. As a consequence, the `onError` callback given in props is called, which changes the state of the parent component, which re-renders itself so display "Unable to access camera" instead of the BarcodeVideoScanner.

To make this test more robust, we do 2 things:
1) load the zxing library before running the test, which avoids the BarcodeVideoScanner component to load it in onWillStart. 2) explicitly wait for the 2 animationFrames, as in the scenario, we must wait for the BarcodeDialog to be rendered twice, and those renderings are now synchronous.

runbot error-237933

Forward-Port-Of: odoo/odoo#280613