Steps to reproduce:
---
- Install `website_sale` module.
- Enable `Product Variants` and `Prevent Sale of Zero Priced Product` in settings.
- Create new attribute > set `Variant Creation` as `Never` and also add value with extra price.
- Create a product with sales price = 0, assign the attribute, and publish it.
- As a public user (incognito), try to add the product to the cart.

Issue:
---
- In terminal error `The given product does not exist therefore it cannot be added to cart` is raised.

Root cause:
---
- In `_is_add_to_cart_allowed()`[1], the method calls `_get_contextual_price()` [2] to check if the product's price is zero when `prevent_zero_price_sale` is enabled.
- However, `_get_contextual_price()` is called without the no-variant attribute values in the context, so it does not account for their `price_extra`. For a product with list price as 0 and attribute with extra price, the price is incorrectly computed as 0, causing `_is_add_to_cart_allowed()` to return `False`.

Solution:
---
- Before calling `_is_add_to_cart_allowed()`, set the product's context with the no-variant attribute values via `_get_product_price_context()`, so that `_get_contextual_price()` correctly includes the price extra in its computation.

[1]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/controllers/cart.py#L117-L120

[2]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/models/product_product.py#L149-L150

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

Forward-Port-Of: odoo/odoo#282705
Forward-Port-Of: odoo/odoo#278620

Steps to produce:
---
- Install `sales` module.
- Go to Settings and enable `Units of Measure and Packaging`.
- Set a long name for `units` UoM.
- Create a Sale Order and add a product via the catalog.

Issue:
---
- Long UoM names are not fully visible in the catalog view.

Root cause:
---
- The outer `<div>` has `d-flex` but lacks `w-100`, causing it to overflow
  its container.

Solution:
---
- Added `w-100` to the outer `<div>` to prevent overflow.
- Adjusted the quantity selector layout for better visibility.

Before:
---
<img width="388" height="141" alt="image" src="https://github.com/user-attachments/assets/dafae08a-3c9d-4163-8894-daa2e4d26f62" />

After:
---
<img width="382" height="154" alt="image" src="https://github.com/user-attachments/assets/abd6f034-be4b-49bf-be9c-c9779de0f30d" />

Enterprise PR: https://github.com/odoo/enterprise/pull/121139

opw-6253382

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

Forward-Port-Of: odoo/odoo#282565
Forward-Port-Of: odoo/odoo#267118

## Current behavior:
On a Monday–Friday working schedule, a Daily accrual plan that is based on worked time grants accrued time on Saturday as well, even though Saturday is not a working day. The employee accrues on 6 days per week instead of 5 (Sunday is correctly skipped. Only Saturday is wrong).

## Expected behavior:
The employee accrues only on the 5 working days (Mon–Fri) → 5 grants per week. Saturday and Sunday should add nothing.

## Setup:
- Working schedule: Standard 40h/week, Monday–Friday, 08:00–17:00.
- All timezones set to Australia/Brisbane (UTC+10) and matching: employee, working schedule, and user are all the same timezone.
- Accrual plan milestone: accrue 5 Hours, Daily, "At the end of the accrual period", "Based on worked time = Yes".

## Steps to reproduce:
- Create the working schedule and accrual plan above, with the calendar timezone set to Australia/Brisbane.
- Assign the accrual allocation to an employee, Starting on a Monday.
- On the Time Off dashboard, use "Balance at the (date)" to project the balance day by day across a weekend (Friday → Saturday → Sunday → Monday).

## Cause of the issue:
Accrual period boundaries were built as naive UTC midnights instead of local calendar midnights.

## Fix:
Localize accrual period boundaries in the employee/resource timezone before calling resource calendar APIs.

This bug is reproducible in multiple versions. PRs for:
- v19.0: https://github.com/odoo/odoo/pull/279029
- v18.0: https://github.com/odoo/odoo/pull/279036

opw-6316062

Forward-Port-Of: odoo/odoo#279029

**Steps to reproduce:**
1. Install Sales and payment_authorize modules
2. Enable "Online Payment" in the settings and Configure the payment method to be Authorize.net
3. Create a sale order, confirm it and create the invoice
4. Pay the invoice with an eCheck (ACH) payment method through the Authorize.net provider
5. Wait for the payment to be settled by Authorize.net (_around 24 hours_)
6. Initiate a refund of the payment

**Issue:**
The refund fails with error `E00003: "The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber' element is invalid - The value XX is invalid according to its datatype 'String' - The actual length is less than the MinLength value`

**Expected behavior:**
The refund should be processed successfully regardless of whether the original payment was made by credit card or eCheck (ACH)

**Why this happens:**
- The `refund()` method in `AuthorizeAPI` builds the refund request using a `creditCard` payment payload
- When the original transaction was an ACH/eCheck payment, the `creditCard` key is absent from the transaction details returned by Authorize.net
- The resulting request is rejected by Authorize.net because it does not satisfy the minimum length constraint for `cardNumber`

**Fix:**
- Detects whether the original payment used `creditCard` or `bankAccount`
from the transaction details and build the appropriate payload according
to Authorize.net API documentation: https://developer.authorize.net/api/reference/index.html#payment-transactions-credit-a-bank-account

opw-6359726

Forward-Port-Of: odoo/odoo#277742

When the FIFO vacuum creates the "Expenses Revaluation" journal entry for an anglo-saxon delivery whose cost is adjusted by a later receipt, the JE was built using `env.company` instead of the company of the vacuumed SVL.

Steps to reproduce:
- Enable multi-company and activate anglo-saxon accounting on two companies A and B.
- In company B, on the product category: set FIFO costing + Automated  valuation, and set the stock input / stock output / stock valuation accounts and the stock journal. The Stock Output account must have "Allow Reconciliation" enabled.
- In company B, on the product: set an Expense Account and set the Cost (e.g. 10.0) this is the price the delivery will be valued at while the stock is negative. The product must have no quantity on hand in company B.
- While working in company B, sell and deliver 1 unit of that product: the delivery is valued at 10.0 and creates a  negative valuation layer.
- Still in company B, create and post the customer invoice of that sale, so the Stock Output line of the delivery entry gets reconciled with the Stock Output line of the anglo-saxon COGS entry of the invoice.
- Switch the active company to A, and from there create a purchase order of that product for company B at a different price (e.g. 15.0), then validate the linked receipt into company B's warehouse.
- The vacuum compensates the negative layer, but the resulting "Expenses Revaluation of ..." journal entry is posted in company A instead of company B.

This fix forces the company context to `vacuum_svl.company_id` when fetching the product accounts and preparing the move lines so the JE is always created in the company of the SVL being vacuumed.

opw-6066970
opw-6419188

Forward-Port-Of: odoo/odoo#259133

### Issue:
When multiple partners share the same email address, `_mail_find_partner_from_emails` may resolve to the wrong partner when the input is a formatted email like "`Name <email>`"

This affects use cases like email templates using `{{object.company_id.email_formatted}}` as sender, where the wrong company partner could be selected

### Cause:
The lookup in `done_partners` only matched on `email_normalized`, which cannot distinguish partners sharing the same email but with different names

The `email_formatted` field carries both name and email, allowing an exact match when the input is a formatted email

### Steps to reproduce:
- Install `account`
- Create an Email Template (Applies to: account.move, From: {{object.company_id.email_formatted}})
- Create a second company B with the same email as the default (e.g. info@yourcompany.com)
- In Settings (logged in as company B), set a Fiscal Position (e.g. US Taxable)
- Create an Invoice on company B
- In the chatter, click Send message, click the expand arrows button, use the three dots menu to select the template
- Send and check the Sender in the chatter

Before the fix, the sender resolves to the default company even though the invoice belongs to company B

opw-6260992

Forward-Port-Of: odoo/odoo#269509