When printing many receipts quickly using a USB printer, this error was occasinally occuring:

```
WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status
ERROR   ? root: Could not set configuration: [Errno 16] Resource busy
```

This would cause `python-escpos` to be disabled and fallback to just CUPS printing.

The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways:
- IoT thread with `python-escpos` and CUPS try to access the printer at the same time.
- Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time).

Both of these scenarios should now prevented:
- Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it.
- We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time.

task-5490942

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

Forward-Port-Of: odoo/odoo#245122
Forward-Port-Of: odoo/odoo#244031

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

Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal

This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.

One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
  File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```

This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)

This fix will avoid any additional traceback like this one.

opw-5865316

Forward-Port-Of: odoo/odoo#245469

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

[FIX] test_l10n_be_hr_payroll_account: fix the test of 13th month full leave

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.
    4 - In hr.leave model -> _compute_date_from_to -> hour_from, hour_to = holiday._get_hour_from_to(holiday.request_date_from, holiday.request_date_to) -> In here hour_from and hour_to is (0,0) when the calendar (id = 1) standard 40h/week is used.
    5 - Since it returns (0,0) and converted to UTC in the next line, the date_to becomes 1 day before the expected date_to.
    6 - After finding that, the standard 40h/week calendar returns (0,0) for work start hour and work end hour, I looked to 'resource.calendar' model.
    7 - In function _get_default_attendance_ids, hour_from and hour_to returns 0,0 for typical 40 hours/week calendar which is not true.
    8 - This standard calendar with id = 1 is used in other 4 tests in class Test13thMonth and they were failing as well, now all of them are fixed.

Bug solution:
    1 - Fixing the hour_from and hour_to of standard 40h/week calendar from (0,0) -> (8, 16).

task - 5853076
Runbot Error

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

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

## Context
There are two modes in VoIP: _Production Mode_ and _Demo Mode_. Demo Mode enables you to simulate a call in the UI without actually calling someone. This is useful for showing customers the features and for developers to test the UI 💡

Though useful, this feature can be confusing. Users may not realize they aren't in Production Mode, and developers may forget to switch back to Demo Mode when testing the UI.

535a7aef3e410d997baa093cc111527814c29253 improved the situation by displaying "Demo Mode" in the Softphone header when Demo Mode is enabled. It was intended to include a tooltip explaining how to configure Production Mode when hovering over it. However, although the tooltip text is present in the code, it was not correctly mapped to the "demo indicator"  ¯\\\_(ツ)\_/¯

## In this PR
After this commit,
- the tooltip text is correctly provided to the "demo indicator", enabling it to be displayed on hover;
- the tooltip text is slightly reworded in the hope of making it clearer.

[Task-5804537](https://www.odoo.com/odoo/project/5778/tasks/5804537)
Fix https://github.com/odoo/enterprise/pull/95742

Forward-Port-Of: odoo/enterprise#105284

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

We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_.

That error is raised in the class UserAgent

```js
    isInProgress(callId) {
        return (
            (this.mainSession?.call?.id === callId && this.mainSession.isInProgress) ||
            (this.transferSession?.call?.id === callId && this.transferSession.isInProgress)
        );
    }
  ```

because both this.mainSession and callId are undefined in the test context.

### Root cause

In the class CallStatusBadgeField
```js
    get statusLabel() {
        const isInProgress = this.isInProgress(this.props.record.data.id);
        const { direction, state } = this.props.record.data;
        return Call.getStatus({ direction, isInProgress, state });
    }
```
isInProgress is called with this.props.record.data.id but id can not be found in this.props.record.data so that when there
is no main voip session, the crash occurs.
Actually, for a real record, the id is given by this.props.record.resId and for a virtual record (a record not already created in db) the id is given by this.props.record.virtualId. Note that resId and virtualId are never both defined.

### Fix

Since a session is always linked to a read record, we pass to isInProgress the id given by this.props.record.resId but we have to protect us from the case were the record is virtual. Hence the use of the optional chaining operator in case the sessions would not be defined.

runbot-error-238415