[FIX] website: improve carousel accessibility
    
    To improve keyboard accessibility on carousels, the indicators container
    is not focusable anymore, and the indicators themselves now only have
    one focusable button at a time.
    The tab order is thus: previous button > active indicator > next button.
    (The previous and next button may both appear before.)
    You can still navigate among indicators with the left and right arrows,
    which also moves the focus to the newly targetted indicator.
    
    Note that other accessibility improvements remain to be done on the
    carousels (add a pause/play button on auto-sliding carousels, place the
    buttons before the carousel slide in the tab order, add some aria
    attributes (roledescription, live), adaptative labels...).

[FIX] website: make focus visible on carousel arrows
    
    When focusing manually (with tab / shift+tab) the previous/next arrows
    in carousels, it is hard to follow where the focus is, because there is
    no outline and the contrast is too small.
    
    This commit adds a specific outline if the button is `:focus-visible`
    (with both black and white to work on any background).

[IMP] website: pause carousel on focus within
    
    Carousels are paused on hover (or touchstart), but if the focus is
    inside one, it won't pause. That can make it hard to navigate within
    interactive carousels during the sliding interval (e.g. the dynamic
    products, which by default has 4 different products with 3 different
    focusable links/buttons).
    This commit applies the same behavior on focusin as Bootstrap's default
    on mouseover, and on focusout as on mouseout.

[IMP] website: support home/end keys on carousels

    When the focus is in a carousel, pressing the "home" key displays the
    first slide and pressing the "end" key displays the last slide.

task-5470023

Forward-Port-Of: odoo/odoo#244939

Currently, after validating a transaction with a manual operation, the
aml resulting from the manual operation can still be selected and
matched with other transactions.

Steps to reproduce:
- Create a transaction for 500 dollars
- Create a manual counterpart line for the bank statement line with
  label "test123" and validate
- Create another transaction of -1000 dollars and label "test123"

Issue: The manual counterpart line matched before is being suggested
against the new transaction. The perfect match reconciliation model will
reconcile the manual counterpart line with the new bank statement line.

Analysis:
During the retrieval of possible aml to match we only look at the aml
reconciliation state. Manual counterpart lines created during the
validation of a previous statement line are still selectable candidates,
causing false positive matches in automated reconciliation models.
Test in Enterprise: https://github.com/odoo/enterprise/pull/115847

opw-6045050

Forward-Port-Of: odoo/odoo#264522
Forward-Port-Of: odoo/odoo#262295

Issue:
-----------------------------------
At certain times of the day (e.g., around midnight UTC), the test would fail deterministically
```
test_allocation_stats_with_duplicate_leave_type_names
    self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10)
AssertionError: 0.0 != 10
```

Cause:
-----------------------------------
This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date)

At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10.

Solution:
-----------------------------------
Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood.

Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759)
Related PR: https://github.com/odoo/odoo/pull/261680

Forward-Port-Of: odoo/odoo#265717
Forward-Port-Of: odoo/odoo#265703

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

Forward-Port-Of: odoo/odoo#265233
Forward-Port-Of: odoo/odoo#262147

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#264083

Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's `product_id` is NULL. This approach might loop over variants which we are not trying to find a bom for. In additon to that, due to the fact that multiple boms might have the same `product_tmpl_id`, this approach might consider the same variants in the inner loop redundantly even though we matched the variant with a bom in a previous itration.

Worst case, this might result in a time complexity of $O(N * M)$ where N is the number of boms and M is the number of variants.

To improve the performance, I only considered the variants given in the paramater `products` and in addition to that, I created a new dictionary mapping a `product_tmpl_id` to its bom if the bom doesn't have a variant set. By doing this, I can loop over the `products` given and if it doesn't have a bom set then it will be set to the one its template had taken from the previos loop.

In a method call with the following constraints
    - **2** products the method was finding a bom for
    - The 2 products had the same template and the template contained **550** active variants
    - The boms were only related to the template rather than the variants themselves.

| Input Size | Before | After |
| :--- | :--- | :--- |
| 100 | 0.78s | 0.03s |
| 1000 | 8.53s | 0.11s |
| 10000 | 80.99s | 0.73s |

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

Forward-Port-Of: odoo/odoo#247465

Before this commit:
1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3)
2. Send the order to Jofotara

Jofotara rejects the invoice because the AllowanceCharge/Amount on the invoice line is a small negative value like -0.000000001 with the error `"EINV_MESSAGE":"discount cannot be negative"`

This happens because _add_document_line_gross_subtotal_and_discount_vals computes the discount as: gross_subtotal - total_excluded_currency

where gross_subtotal goes through two independent rounding steps (round unit price, then round unit_price * qty). When the quantity is indivisible, the reconstituted gross_subtotal can land just below total_excluded_currency by a floating-point epsilon, producing a tiny negative discount. The same subtraction also produces a legitimate negative value for refund lines (negative quantity), which was already handled by abs() in _add_pos_order_discount_vals for the document-level total but was left unguarded at the per-line level.

After this commit:

Apply abs() to vals[f'discount_amount{currency_suffix}'] in _add_pos_order_line_allowance_charge_nodes so that discount_amount_currency is always non-negative.

opw-6183423

Forward-Port-Of: odoo/odoo#265159

Currently, error occurs when user removes date on Accrued Expense Entry wizard.

Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.

Error:
```
  File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
    if not record.reversal_date or record.reversal_date <= record.date:
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'

```

Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.

Solution:
- Added a conditional check for `date` before the date comparison.

[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67

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

Forward-Port-Of: odoo/odoo#262568

Issue is really similar to commit 21877c09863222a237fe99334787ac46935dcca4 except here the compensations 
amls are created in _stock_account_prepare_anglo_saxon_in_lines_vals
because of a difference between bill price and product cost

**Steps to reproduce:**
- create storable product with category standard auto
- on the category, set an account in the field 'price difference account'
- set a cost of 10
- set a purchase tax
- confirm a PO for 1 @ 15 and validate receipt
- create bill, set a date, save
- on the Bill set the total tax at 100 (it's bellow 'untaxed amount'
on the bottom right of the bill and should be 2.25 before you
change it, if the tax is 15%)
- confirm the bill 

**Current behavior:**
tax was reset to 2.25

**Expected behavior:**
It should stay 100 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because:
 When we confirm the bill, 
_stock_account_prepare_anglo_saxon_in_lines_vals() creates 
two amls : 
- one debiting 5 on the account set in the field 'price difference 
account'
- one crediting 5 in the stock interim received account
(This makes sense and is there to realign with the fact that, on the 
account move linked to the svl, the amount credited from stock 
interim received is rightfully 10 because that's cost of the product 
and it's a standard price product)

When we create those amls from,  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**fix**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-6014710

Forward-Port-Of: odoo/odoo#263306

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606

Forward-Port-Of: odoo/odoo#264803
Forward-Port-Of: odoo/odoo#259370

1. Apply the below diff.
2. Login using the same account in two independent tabs (e.g. one regular tab, and a private one).
3. In the first tab, change the account password.
4. In the second tab, go to `/web/binary/upload_attachment` (any `type='http', auth='user'` controller would do) => 500 error.

> AttributeError: 'HttpDispatcher' object has no attribute 'env'

```
diff --git a/odoo/http.py b/odoo/http.py
index b0fd6197aea8..1ea817ec85cd 100644
--- a/odoo/http.py
+++ b/odoo/http.py
@@ -2309,7 +2309,7 @@ class HttpDispatcher(Dispatcher):
         """
         if isinstance(exc, SessionExpiredException):
             session = self.request.session
-            was_connected = session.uid is not None
+            was_connected = True
             session.logout(keep_db=True)
             response = self.request.redirect_query('/web/login', {'redirect': self.request.httprequest.full_path})
             if was_connected:
```

It is necessary to apply the diff because most places that raise `SessionExpiredException` also pro-actively `logout()`, i.e. they reset `session.uid` and when the exception reaches handle-error `was_connected` is always `False`. For the bug to occur, we need a way to be in the `was_connected == True` case but we found no way in standard Odoo (this also explains how this bug is still present, 2 years later). The diff is the easiest way we found to reproduce it.

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