(Originally started at https://github.com/odoo/enterprise/pull/105183 in preparation of https://github.com/odoo/enterprise/pull/103404, those were replaced by this one for part 1 and https://github.com/odoo/enterprise/pull/105217 for part 2 (not done yet))

Main goal of this part 1: allow no-microphone calls when auto-redirect (desk phone)
    
When a user calls someone and that their profile is configured to use their desk phone (in which case it will call the desk phone and then call the callee to redirect them to the desk phone call), it simply did not make sense to ask for the microphone: it won't be used. This commit makes it so the call proceeds without microphone so it can be automatically redirected immediately.

Then needed commit to fix related things:

[FIX] voip: properly leave in-call after all UserMedia errors
    
    Steps to reproduce:
    - Call someone via the softphone
    - When asked, reject the use of the microphone
    - An error appears, close it
    => You are now on the in-call screen and you have no way to leave it
       even though the call is terminated.
    
    This cames from a combination of [1] and [2]. The parent commit from
    here provides some additional details: `activeSession` is not set at
    the same place anymore (which is wanted to ask the microphone before
    reaching the in-call screen), but because of [2] it ends up being set
    while it should not. See extra details below.
    
    This commit takes the opportunity to fix two other related issues:
    - When calling, if the microphone was rejected (but existing), it
      used to make a traceback before [1]. After [1], it overrode the error
      indicating the problem by another one. This originated from [2] which
      blocked "NotAllowed" microphones, ignoring the other causes and
      ignoring the fact the traceback occurred because all the "invite"
      calling stack was not properly awaited/guarded. Now, after [1],
      everything is properly awaited/guarded so this can simply be removed.
      As a bonus, we mark all microphone errors already handled so they are
      not removed by another less understandable error later.
    - Kinda the same thing and actually found by [1] too: when *accepting*
      a call, microphone issues were shown but then overridden by less
      understandable error messages too. This is now fixed the same way.
    
    [1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e
    [2]: https://github.com/odoo/enterprise/commit/6570a9735de62130b6451202fb33fac70a0e7901

[FIX] voip: properly access voip Session during UserMedia failure
    
    Commit [1] changed quite a lot of things when it comes to call creation
    and acceptation, sip session and call record creation order, etc. The
    problem here is due to a particular change: before, the `activeSession`
    was set before trying to `invite`/`accept`. It is now only set before
    for `accept`, but not for `invite`. This makes it so that rejecting the
    microphone during call acceptation works but rejecting the microphone
    while trying to call not work. Indeed the `hangup` call being done on
    microphone access check failure, it needs the `activeSession` to be set.
    This resulted in the call (and its record) not being updated as we wish,
    but terminated on SIP.js side.
    
    However, simply restoring the `activeSession` being set earlier would
    not be ideal: it came with the advantage of not starting the in-call
    screen and dial ringtone before the microphone was actually accepted
    when trying to call.
    
    Instead this commit makes it so the VoIP Session object is passed
    through SIP options objects and then accessible in the UserMedia failure
    callbacks. Maybe using the VoIP Session object inside a callback used by
    SIP.js to configure the inner SIP session is not ideal but it can always
    be improved later.
    
    Note: after calling and blocking the microphone, you are stuck on the
    in-call screen after discarding the error, this will be fixed in another
    commit.
    
    [1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e

[IMP] voip: simplify `mediaStreamFactory` definition
    
    Instead of having a getter returning a function, make that function part
    of the `UserAgent` object directly (and pass it (bound properly) to
    the SIP.js library).

[FIX] voip: convert bad call to `triggerError` to new API
    
    Commit [1] introduced a call to VoIP's `triggerError` but used the old
    API, that was changed at [2].
    
    Steps to reproduce:
    - Make a call to someone without a microphone on your computer (not
      blocked by the browser: disabled on the OS side) (or tweak
      `mediaStreamFactory` to simulate that).
    => The error message contains no helpful information.
    
    This commit uses the right API to display the error correctly.
    
    [1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e
    [2]: https://github.com/odoo/enterprise/commit/49e1595f31c9f8a23d9b18a33b859d3d01221024
    
task-4947771

While using the keypad search input, the user can now navigate the
potential suggestion + more buttons using the up/down keys of their
keyboard.

Also:

[IMP] voip: improve softphone keyboard management
    
    Make the softphone closer to a dialog and other overlay elements of the
    Odoo webclient:
    - Now trap the focus inside the softphone (using tab cycles inside the
      softphone itself).
    - Make sure event handlers of the home screen menu in enterprise are not
      in conflict (e.g. the next commit after this one will allow using
      up/down to navigate keypad search results, the home screen should not
      mess with that).
    - The Escape key now allows to hide the softphone.

[IMP] voip: prevent focusing the backspace button
    
    It is never useful to focus the keypad search's backspace button using
    the keyboard: you would have to tab your way through the search input
    itself anyway, in which case it is easier to use the backspace key on
    your keyboard instead of trying to use the UI one.
    
    Doing this, this also allows to focus the first search result with one
    tab press while inside the input, instead of having to go through the
    backspace button.

And potential follow-up at https://github.com/odoo/enterprise/pull/105047
    
task-5441808

**Steps to reproduce:**
- Create a storable product "P1"
  - Product category: AVCO

- Create a purchase order with 100 units of P1 at $10
- Confirm the PO and validate the receipt
- Go to Inventory -> Reporting -> Stock

- P1 unit cost is $10 and total value is $1000

- Click on $1000
  - Select the first stock move
  - Action -> Adjust valuation
    - New value: $2000 -> Save

- Go back to Inventory -> Reporting -> Stock

**Problem:**
- The unit cost becomes $2,000 and the total value $200,000

When a valuation adjustment is made on an AVCO product, a `product.value`
record is created with the new total valuation value.

However, `product.value.value` can represent two different things:
- for a standard price update, `value` contains the new unit cost
- for a stock move valuation, `value` contains the total value of the move

When `run_avco` processes a `product.value` coming from a move valuation,
it incorrectly treats the value as a unit price and multiplies it by
the quantity

opw-5460829

Forward-Port-Of: odoo/odoo#244957

Currently, an error occurs when uploading `encrypted or incomplete` 
PDF files (missing EOF marker) while creating a quotation document 
header or footer.

**Steps to reproduce:**
- Install the `sale_pdf_quote_builder` module.
- Navigate to: Sales > Configuration > Headers/Footers.
- Upload encrypted file [1], or incomplete file [2].

**Error:**
`PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm`
`PyPDF2.errors.PdfReadError: EOF marker not found`

**Root cause:**
At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly 
call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises 
an error.

**Fix:**
This commit prevents errors when users upload unreadable or encrypted PDF files.

[1]:
https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing

[2]:
https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11

sentry-6928220164
opw-5227601

Forward-Port-Of: odoo/odoo#245264
Forward-Port-Of: odoo/odoo#230712

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#104845
Forward-Port-Of: odoo/enterprise#99820

### Issue:
Due to this issue, by clicking twice on `Reward` button on SO, reward line unit price will be reset to zero.

#### To reproduce:
1- Create a `Buy X Get Y` program:
   rule: minimum quantity: 3, product: `Large Desk Wood`
   reward: 1 `Large Desk Wood` for free
2- Create a SO, and add a line with 3 `Large Desk Wood`
3- Click on `Reward` button. A new line should be automatically
   created. The unit price should be the product sale price and
   line `Amount` should be 0.
4- Re-click on reward. The reward line price unit is set to zero.

Expected: The reward line price unit should remain as product sale price with a discount of 100 and line.amount of 0.

### Cause and Fix:
In `_reset_loyalty`, price_unit is set to zero.
The method `compute_amount` depends on `price_unit`, which means setting `price_unit` will make amount to be recomputed: https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L843-L844 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L848 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/account/models/account_tax.py#L1613

Which leads to `_compute_price_unit`. In this compute, the unit price will not be recomputed if `technical_price_unit` and `price_unit` differ.
https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L606-L611 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L588-L595

So IMO if we want to recompute `price_unit`, we need to also reset `technical_price_unit` in `_reset_loyalty`.

opw-5467623

Forward-Port-Of: odoo/odoo#244290

This PR fixes the bug of not making the source location persistent when changing it from the form view.

To reproduce the bug:
1- Create a product tracked by lot.
2- Create 3 different lot locations with each having a quantity of 100. 
3- Create an out delivery of 140 and notice 100 are assigned from the first lot and 40 are assigned from the second lot.
4- Set the scanning source location to be mandatory in Barcode for deliveries.
5- Go to Barcode app, navigate to the delivery, you find it mandatory to scan a source location.
6- Scan the source location for the first lot location, choose the product and click on the edit pen icon.
7- Choose another lot location as your source location, let it be the third lot location and confirm.
8- Choose to assign the qty by clicking on the +100 button.
= See that the new chosen source location is not persistent.

The fix:
After this PR, if you follow the steps up to step 7 and after you confirm your new source location, the Barcode makes the lines inactive again and asks you to scan the source location (since it's mandatory) and it also shows the new source location on the line.

Another fix this commit addresses is that when you scan a source location, only the lines with this location are active to choose/edit not all the lines.

Task-4809491

Forward-Port-Of: odoo/enterprise#97777

### [FIX] mail: properly handle col overflow in bootstrap row
Problem:
The grid conversion logic only finalized a row when iterating through the
last column in the input list. If a row reached exactly 12 grid spans
while more columns remained (e.g., a `col-12` in the middle), the logic
did not start a new row. As a result, remaining columns overflowed the
current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of
any size, it would crash because the algorithm did not reset the index to the
start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

### [FIX] mail: ensure -md variant of col and offsets are prioritized
Prior to this commit, if an element had a mix of `col-x` and `col-md-y` classes,
the regexes used in `convert_inline` would not guarantee that they would be used
consistently.

How to reproduce:
- create a new mailing and add the "three columns" snippet
- resize from the right the middle column (reduce the size and revert back to
  the original size)

Issue:
- when sending the email, the columns are not aligned horizontally in a desktop
  layout

Solution:
Prioritize usage of `-md` variants to compute the size of a column/offset, when
available (these are the one used by the mass_mailing editor for desktop mode),
and use any otherwise.

opw-5439481

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>
Co-authored-by: Walid Sahli <wasa@odoo.com>

Forward-Port-Of: odoo/odoo#241851

### Issue:
The stripe payments are failing to due setting currency decimals.

#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
   to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through stripe. As you see payments fail.

### Cause:
This is due to rounding the amount before sending to stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment_stripe/models/payment_transaction.py#L160-L165

We are rounding the amount to the minor currency unit.

However, we make a compare between `tx_amount` and the amount paid through stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment/models/payment_transaction.py#L726-L732

Which are not equal. We should use minor current unit as `precision_digits` to fix this issue.

opw-5496825

Forward-Port-Of: odoo/odoo#245593
Forward-Port-Of: odoo/odoo#245059

Steps to Reproduce
 1. Create a database in Odoo 19.0 with the stock_account module installed.
 2. Enable Dropshipping from Inventory → Settings.
 3. Create a product with a category whose Cost Method is set to Average Cost (AVCO).
 4. Create a user with Inventory / User access rights only (no Inventory Administrator rights).
 5. Create a dropship order using the product and validate the picking.

```
You are not allowed to access 'Product Value' (product.value) records.

This operation is allowed for the following groups:
	- Inventory/Administrator

Contact your administrator to request access if necessary.
```

Issue:-
During picking validation, moves are getting [done](https://github.com/odoo/odoo/blame/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock/models/stock_picking.py#L1265) if move is is_dropship enable which lead to [update_standard_price](
https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L169)  if product cost_method is [avco.](https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/product.py#L462-L476) So, it call run_avco during that getting [the _get_manual_value](
https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L409) it through access error

Fix:-
To fix this sudo is added during getting _run_avco

opw-5431121
upg-3762999



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

Forward-Port-Of: odoo/odoo#242841

Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master);
1 - Install and update l10n_be_hr_payroll,l10n_be_hr_payroll_account,test_l10n_be_hr_payroll_account,hr_holidays,resource modules in localhost 2 - Execute the test test_13th_month_full_leave and it will fail, also in the same class (Test13thMonth) many other tests were failing.

Bug cause:
1 - In test test_13th_month_full_leave, for all year the sick day timeoff is allocated. (year: 2025), generate work entries for 2025 and expecting payslip amount must be 0 but it is not. 
2 - When I looked to _get_paid_amount -> _get_paid_amount_13th_month -> _compute_presence_prorated_fixed_wage: Some days in the year was not counted as sick day and since few days are not counted, the payslip amount is > 0. 
3 - By diving deeper: in function _get_calendar_days: date_to = min(date_max, leave.date_to.date()), from this line, I observed that leave.date_to is calculated 1 days before sometimes.

Bug solution:
1 - In _get_calendar_days, leave.date_from and leave.date_to is converted to the employee's timezone from UTC.

task - 5853076
Runbot Error

## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

Forward-Port-Of: odoo/odoo#245163
Forward-Port-Of: odoo/odoo#233769

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Forward-Port-Of: odoo/enterprise#105129
Forward-Port-Of: odoo/enterprise#98463

## Versions
saas-18.3+

## Issue
Non admin users get an access error when trying to validate a direct debit mandate.

## Steps to reproduce
As admin user:
- Navigate to "Users":
  - Select Marc Demo:
    - Under "Access Rights", in the "Accounting" section, set his "Accounting" role to "Invoicing & Banks";

As Marc Demo:
- Navigate to "Direct Debit Mandates":
  - Create a new mandate for Deco Addict and its first IBAN record;
  - Click on the "Validate" button.

## Cause
Issue introduced by the `action_validate_mandate` method override from b63eb2d6b91be28f4837309b5d972cc0b05846e0 Non admin users have no permissions on `payment.provider` while `_read_group` checks read rights on model via https://github.com/odoo/odoo/blob/ac084b1010faf49b63844ecc96284d567e59de2e/odoo/orm/models.py#L1632

## Fix
Allow `payment.provider` access only on mandate validation as only `account.group_validate_bank_account` users can create a new mandate.

opw-5255694

Forward-Port-Of: odoo/enterprise#105428
Forward-Port-Of: odoo/enterprise#103673

**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
  routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#239648

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

[FIX] web: make mock model field sort browser-independent
    
    The sorting done by `orderByField` for mock models was incorrect: when
    two values were empty and compared: the old comparator returned 1 when
    v1 === false, even if v2 === false too. That makes the comparator
    inconsistent (as it basically says "a > b" and "b > a"), so Array.sort
    is free to reorder differently per engine.
    
    This was discovered while making a unit test where it was actually
    working on Chrome and not on Firefox because of that (and switching
    some contact records creation order would make it work on Firefox and
    not on Chrome).

[IMP] web: review press/keydown HOOT helpers regarding selection changes
    
    Commit [1] made it so HOOT keydown helper somewhat handles selection
    changes in input and textarea when pressing arrow keys.
    It assumed that:
    - "up" and "left" have the exact same behavior: going left 1 character
      or to the start if the CTRL key is held.
    - "right" and "down" have the exact same behavior: going right 1
      character or to the end if the CTRL key is held.
    
    The logic is really wrong or at least very incomplete. The minimal
    behavior is:
    - "left" goes 1 character left; if the CTRL key is held, it jumps to the
      previous word.
    - "right" goes 1 character right; if the CTRL key is held, it jumps to
      the next word.
    - "up" goes to the start of the line (independently from the CTRL key).
    - "down" goes to the end of the line (independently from the CTRL key).
    
    This commit implements something in between: the correct behavior,
    without the notion of lines and words, limiting the helper behavior
    change and the line of code added:
    - "left" goes 1 character left; if the CTRL key is held, it jumps to the
      start.
    - "right" goes 1 character right; if the CTRL key is held, it jumps to
      the end.
    - "up" goes to the start (independently from the CTRL key).
    - "down" goes to the end (independently from the CTRL key).
    
    Meaning those limitations:
    - "CTRL+left" is only correct if no whitespace in all the chars before.
    - "CTRL+right" is only correct if no whitespace in all the chars after.
    - "up" in textarea is only correct if on first line.
    - "down" in textarea is only correct if on last line.
    
    [1]: https://github.com/odoo/odoo/commit/ab7d02f49182845e48b31e331d3ccad8d2f36560
    
Related to task-5441808

**Steps to reproduce:**
1. Install the `Accounting` module.
2. Enable cash basis taxes in
   `Accounting → Configuration → Settings → Taxes → Cash Basis`.
3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a
   `Cash Basis Transition Account`.
4. Create an invoice with the cash basis tax and a payment term such as
   `30% now, balance in 60 days`.
5. Record a full payment on the invoice instead of just the first installment.
6. Review the generated cash basis journal entries.

**Observed behavior:**
* Cash basis entries are created for the full tax amount, not proportionally.
* Paying the full invoice with payment terms causes duplicated tax entries.

This came from the fact that we didn't consider a move would be fully paid by
several lines at the same time, like with installments.

We now only put the leftover amount when the move is fully paid and we're on
the last partial.


Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches

opw-5061136




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

Forward-Port-Of: odoo/odoo#244733
Forward-Port-Of: odoo/odoo#236536

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#243939
Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#104395
Forward-Port-Of: odoo/enterprise#101620