Guests never receive any bus notification when the websocket is not handled by Odoo itself but by a proxy that forwards subscriptions through `/websocket/peek_notifications` and dispatches the notifications on its own (which is how Odoo.sh serves databases).

The peek controller calls `ir.websocket._prepare_subscribe_data()` directly, bypassing `_subscribe()`, the only method decorated with `@add_guest_to_context`. The guest cookie is present on the request but never read, so the returned channel list only contains the anonymous channels (broadcast, res.groups) and lacks the guest's personal ones: ("mail.guest", id), ("discuss.channel", id) and presence. The proxy therefore never registers those channels, and every notification targeted at the guest is silently dropped.

Before this commit, discuss calls with a guest are broken: a 2-person call never connects (p2p offers/answers/ICE are delivered over the bus); in a 3+ person call, any guest who joined before the SFU threshold stays stuck in dead p2p (they never receive the `sfu_hot_swap` notification) while a guest joining as 3rd+ participant works, since the join RPC returns the SFU credentials synchronously.

We override `peek_notifications` with `add_guest_to_context` so the route is aware of guests.

opw-5490739

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

Forward-Port-Of: odoo/odoo#275184
Forward-Port-Of: odoo/odoo#274743

**Steps to reproduce:**

1. Install the **Attendance** app in saas-19.2 with demo data.
2. Log in as a user who has **Administrator** rights in the Attendance app but no access rights in the Employees app.
3. Go to **Attendance → Configuration → Overtime Rulesets**.
4. Open any overtime ruleset.

An `AccessError` is raised:

```
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3373,
in check_access
    raise result[1]()
 odoo.exceptions.AccessError: You are not allowed to access
'Employee Record' (hr.version) records.

This operation is allowed for the following groups:
	- Employees/Administrator
	- Employees/Officer: Manage all employees

Contact your administrator to request access if necessary.
```
**Issue:**

A new feature introduced an employee count stat button on `hr.attendance.overtime.ruleset` in [v19.2](https://github.com/odoo/odoo/pull/236555/changes).

Users who have administer right in Attendance app but do not have access to Employee records trigger an access error when opening the ruleset.

**Solution:**

The fix restricts the visibility of the [Stat button ](https://github.com/odoo/odoo/blob/7c6f31d730304bca3f6c996800e76d1e40ce4adf/addons/hr_attendance/views/hr_attendance_overtime_rule_views.xml#L114)to users with the required Employee groups, preventing the access error while keeping the feature available for authorized users.

opw- 6358550
upg- 4449776


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

Forward-Port-Of: odoo/odoo#275320

## Problem:
when snippets with identical images are added in the e-commerce website product page, the "Optimize SEO" option in debug mode causes an error to occur with a traceback. The traceback calls out a duplicate key in the `t-foreach` of a loop over `state.altAttributes`. the `t-key` for this loop is `img.id` which is generated by the `/website/get_alt_images` controller endpoint.

## Steps to reproduce:
1. Go to a product page and click on "go to website" smart nav btn.
2. Add a snippet with an image in the `description_ecommerce` field
3. Add a snippet with the same image in the `website_description` field.
4. In debug mode, open `site > Optimize SEO`
5. An error `Got duplicate key in t-foreach` is thrown.

## Solution:
The solution was simple to add a qualifier in the compound key generated by the controller action for the `id` field. The chosen qualifier in this case was `model['field']`. `field` is the position in the template where the image came from.

So now the keys for the two identical images go 

FROM
 
> `${model}-${id}-${index}`
>
> 1st image of `website_description`:
>    `product.template-6-0`
> 
> 1st image of `description_ecommerce`:
>    `product.template-6-0`

TO

> `${model}-${id}-${field}-${index}`
>
> 1st image of `website_description`:
>    `product.template-6-website_description-0`
>
> 1st image of `description_ecommerce`:
>    `product.template-6-description_ecommerce-0`

task-6325786

Forward-Port-Of: odoo/odoo#275941
Forward-Port-Of: odoo/odoo#272846

Step to reproduce:
- install pos_discount and l10n_es_edi_tbai_pos with demo data
- start pos, add a product and a discount of 10%
- fulfill the order
- go to backend and open that order
- from "TicketBai" page, open the "TicketBAI Post File" xml file

Observation:
- `ImporteUnitario` and `ImporteTotal` were exported as positive values for discount lines.

cause:
- Commit [1] assumed tax details are always positive.
- This is not generally true, in case we have price_unit < 0
- The logic relied on `is_refund`, which depends on `qty * price`.
- `_l10n_es_tbai_get_values` then multiplied values by `-1` again for refunds.
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L177-L181
- For discount lines, `is_refund = True` and `price = -10`, resulting in `-10 * -1 = 10`.

Fix:
-  Ensure tax detail values are always returned as positive values, matching the assumption introduced in commit [1]

[1] https://github.com/odoo/odoo/commit/03d55104e49aa65aa4c6475e199747fe9132e754

opw-6226003

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

Forward-Port-Of: odoo/odoo#275451
Forward-Port-Of: odoo/odoo#265777

Steps to reproduce:
1. Create a new version on an employee with a future start date
2. Ensure the new version has a different working schedule
3. After the new version becomes active, observe that the working schedule on the employees record is different from the one on the employee's resource record

Every employee has an associated resource record associated with them. Normally, the employee's working schedule (`hr_employee.resource_calendar_id`) should always be in sync with their associated resource record (`hr_employee.resource_id.calendar_id`). When we update the employee's working schedule through the UI on a currently active version, it will also update their associated resource record with the same working schedule. However, if we change the working schedule for a future version, when `_cron_update_current_version_id()` runs and changes the active version, there is no mechanism to update the associated resource with the new working schedule. This change will ensure we keep the working schedules in sync, as if they are not, strange behaviors can occur.

One side effect of this problem: When a new version becomes active, and working schedules become de-synced, this can cause the Attendance gannt view to display incorrect unavailable intervals for an employee (this appears as a grayed-out time slot). This is because `_attendance_intervals_batch()` pulls from the working schedule of an employee's associated resource record, rather than the employee record itself. This is what occurred on the linked ticket.

[opw-6352770](https://www.odoo.com/odoo/my-tasks/6352770?debug=assets)

Forward-Port-Of: odoo/odoo#275430

# How to reproduce
- In the settings, enable Absence Mangement
- Create an employee with a Contract
- Create a Time off for that employee for yesterday
- Manually run the scheduled action "Attendance: Detect Absences for employees"
- Go to the attendance dashboard for that employee

# The issue
An attendance with no overtime was created for yesterday for that employee with a log note
saying "This attendance was automatically created to cover an unjustified absence on that day."
However, the absence was justified as the employee took a time off.

# Cause of the issue
When running the `_cron_absence_detection` cron job, we create "empty" attendances for the employees
that were absent yesterday. If those attendance's `overtime_hours` are 0, then we unlink them :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L659-L666

But, since `check_in` and `check_out` cannot be the same, we cannot really create an empty attedance.
We instead create an attendance of 1 second :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L652-L653

This will create an overtime of 0.003 seconds if there was a leave that day (which is our case).
This duration will be reflected in the attendance's `overtime_hours`. The issue is that we simply do
`== 0` when trying to find the attendances without overtime, so we don't unlink them.

The issue was introduced by :
https://github.com/odoo/odoo/commit/8d7859a569d9ac7303ca0b9be6c56496be14c544

Because `round(0.003, 3)` => 0 but `round(0.003, 4)` => 0.003

The issue is not present in 18.0+ because we don't create overtime if the duration is
`float_is_zero(overtime_duration, 2)` :
https://github.com/odoo/odoo/blob/39cce855aa27aa4af9225a61a3e1425383a9f49f/addons/hr_attendance/models/hr_attendance.py#L405

opw-6321883

Forward-Port-Of: odoo/odoo#275133
Forward-Port-Of: odoo/odoo#272089

Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product.

## Steps to produce:
- Install Inventory without demo data
- Settings Enable 'Packages'
- Create a product:
   - Cheese burger
   - On hand > Create a new quant
   - Package: 'Burgerbox' and 'On Hand Quantity`: 1 and save
- Set the On Hand quantity to zero and save
- History > Revert the Inventory adjustment line from WH/stock to Inventory adjustment by selecting it and reverting via actions.
- Products > Packages > BurgerBox

## Observed Behaviour:
After reverting an inventory adjustment that set the product's physical quantity to 0, the package contains two lines for the same product with quantities 1 and -1.

This is inconsistent because a package should not contain a product with a negative quantity.

The package should be restored to its original state and contain only the expected positive quantity.

## Root cause:
When the user reverts the move line, `action_revert_inventory` is called. This method creates the revert move and then marks that move as done at [1].

Marking the move as done subsequently marks all related move lines as done at [2]. During this process, the system first unreserves the quantity from the virtual location / inventory adjustment and then removes the quantity from that location (resulting in a -1 quantity move line at that location). This is performed through `_synchronize_quant`, which is responsible for synchronizing the physical inventory with the move line at [3].

The `_synchronize_quant` method uses the move line's `package_id` when updating the corresponding quant at [4]. As a result, `_update_available_quantity` creates a new quant with the following values at [5]:
```
{
    'product_id': 1,
    'location_id': 14,
    'lot_id': stock.lot(),
    'package_id': 1,
    'owner_id': res.partner(),
    'in_date': datetime.datetime(2026, 6, 22, 12, 42, 11),
    'quantity': -1.0,
}
```
This creates a quant with a negative quantity that is linked to the package because `package_id` is set on the newly created quant. Consequently, the move line with the negative quantity becomes associated with the package.

[1]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L1016-L1035 
[2]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move.py#L1956 [3]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L662-L666 
[4]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L678-L687 
[5]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_quant.py#L1130-L1143
## Solution:
Remove the source `package_id` when creating revert moves for inventory adjustment locations.

When an inventory adjustment sets a product's quantity to 0, the adjustment is completed without a destination package, meaning the product is effectively removed from the package. Therefore, the corresponding revert move should not retain the package as its source. Keeping the package as the source is inconsistent because package information should not exist on a virtual inventory adjustment location, and the original inventory adjustment removes the product from the package (there is no destination package).

By removing the source `package_id` from the revert move, the system avoids creating negative quants associated with the package during quant synchronization. This also ensures that, after the inventory adjustment is reverted, the quantities of products inside the package are restored correctly and match their state prior to the adjustment.

opw-6285739

Forward-Port-Of: odoo/odoo#274663
Forward-Port-Of: odoo/odoo#271440

### Issue:
When creating a new Indian company, the `Half Up` cash rounding is reassigned to the new company instead of being duplicated
Previous Indian companies lose access to it, causing errors when opening invoices that reference the cash rounding if the user doesn't have access to that company

### Cause:
`cash_rounding_in_half_up` was defined as a `data` record with a fixed XML ID (`l10n_in.cash_rounding_in_half_up`) `_get_in_account_cash_rounding` referenced that XML ID directly and set `company_id` to the current company on each chart of accounts installation
This reassigned the single shared record to the new company instead of creating a new one

Moving the definition to the `@template` decorator without a module-prefixed XML ID lets the chart of accounts system create one record per company, as intended

### Steps to reproduce:
- Install `l10n_in` and switch to `IN Company`
- Check the Cash Rounding records grouped by company
- Create a new Indian company
- Enable both `IN Company` and the new company
- Check the Cash Rounding records grouped by company again

Before the fix, only the last created Indian company has the Cash Rounding record

opw-6318857

Forward-Port-Of: odoo/odoo#272866

Steps to reproduce:
- Create a promotion program (e.g. "10% discount on your order", reward_point_mode "per order") and restrict its rule to a specific product A; leave the minimum quantity at 0
- Open a PoS session and add any other product B to the order

Issue:
The discount was applied even though the order contained none of the rule's valid products.

Cause:
In `pointsForPrograms`, a rule was only gated on its quantity and amount thresholds (`totalProductQty < rule.minimum_qty`), never on the actual presence of a valid product in the order. Program templates (promotion, promo_code, next_order_coupons) create rules with minimum_qty = 0, so a product-restricted rule passed with zero matching items and, in "order" point mode, granted its points unconditionally. The same hole existed in `_canGenerateRewards` for scanned coupon programs, where rules act as conditions.

The backend does not have this issue: `_program_check_compute_points` in sale_loyalty skips any rule whose valid products are not present in the order.

Fix:
Mirror the backend behavior in the PoS frontend: skip a product-restricted rule in `pointsForPrograms` when no (non-reward) order line matches its valid products, and make `_canGenerateRewards` return false in the same situation. Gift card and eWallet flows are unaffected since their "money"/"unit" point modes already gave 0 points when the trigger product was absent.

opw-6357241

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

Forward-Port-Of: odoo/odoo#275073

# How to reproduce
- In the settings, enable Absence Mangement
- Create an employee with a Contract
- Create a Time off for that employee for yesterday
- Manually run the scheduled action "Attendance: Detect Absences for employees"
- Go to the attendance dashboard for that employee

# The issue
An attendance with no overtime was created for yesterday for that employee with a log note
saying "This attendance was automatically created to cover an unjustified absence on that day."
However, the absence was justified as the employee took a time off.

# Cause of the issue
When running the `_cron_absence_detection` cron job, we create "empty" attendances for the employees
that were absent yesterday. If those attendance's `overtime_hours` are 0, then we unlink them :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L659-L666

But, since `check_in` and `check_out` cannot be the same, we cannot really create an empty attedance.
We instead create an attendance of 1 second :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L652-L653

This will create an overtime of 0.003 seconds if there was a leave that day (which is our case).
This duration will be reflected in the attendance's `overtime_hours`. The issue is that we simply do
`== 0` when trying to find the attendances without overtime, so we don't unlink them.

The issue was introduced by :
https://github.com/odoo/odoo/commit/8d7859a569d9ac7303ca0b9be6c56496be14c544

Because `round(0.003, 3)` => 0 but `round(0.003, 4)` => 0.003

The issue is not present in 18.0+ because we don't create overtime if the duration is
`float_is_zero(overtime_duration, 2)` :
https://github.com/odoo/odoo/blob/39cce855aa27aa4af9225a61a3e1425383a9f49f/addons/hr_attendance/models/hr_attendance.py#L405

opw-6321883

Forward-Port-Of: odoo/odoo#275133
Forward-Port-Of: odoo/odoo#272089

When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused them to be grouped separately. This caused a discrepency between the tax amount computed in the frontend and the one computed in the backend.

Steps to reproduce:
-------------------
* Change the rounding method to globally
* Create a 21% tax not included in price
* Create a product with a price of 76.01 and the tax created above
* Create a loyalty program with a 10% discount
* Create a POS order with the product above and apply the loyalty program
* Validate the order and generate the invoice
> Observation: The invoice states that 0.01$ is still due

Why the fix:
------------
In `round_tax_details_tax_amounts`, we try to detect any delta with the expeced tax amount. To do that we group the base lines based on a grouping key. The grouping key `is_refund` was incorrectly set to `true` for reward lines, which caused them to not be grouped. The delta was then not detected and tax amounts were not adjusted. We now make sure not to consider reward lines as refund.

opw-6052112

Forward-Port-Of: odoo/odoo#275350
Forward-Port-Of: odoo/odoo#271577

### Steps to reproduce:
- Download 'Sales' application
- From 'Configuration' > 'Settings', enable 'Promotions, Loyalty & Gift Card'
- From 'Products' > 'Gift cards & eWallet', Configure an eWallet program with a top-up product
- Have a customer with an existing eWallet balance
- Create a new sale order for that customer and add the eWallet top-up product
- Pay the order using the customer's eWallet
> The order gets discounted by the eWallet, effectively allowing the user to top up their balance
using the balance itself (infinite money glitch).

### Cause of Issue:
When computing the discountable amount for payment programs (like eWallets and gift cards), `_discountable_order` includes the total order amount. However, it did not exclude the program's own top-up products (`trigger_product_ids`) from the discountable lines.

### Fix:
If an order consists solely of top-up products, attempting to apply the eWallet now correctly raises a `UserError` ("There is nothing to discount").

opw-6341410

Forward-Port-Of: odoo/odoo#273419

Step to reproduce:
- install pos_discount and l10n_es_edi_tbai_pos with demo data
- start pos, add a product and a discount of 10%
- fulfill the order
- go to backend and open that order
- from "TicketBai" page, open the "TicketBAI Post File" xml file

Observation:
- `ImporteUnitario` and `ImporteTotal` were exported as positive values for discount lines.

cause:
- Commit [1] assumed tax details are always positive.
- This is not generally true, in case we have price_unit < 0
- The logic relied on `is_refund`, which depends on `qty * price`.
- `_l10n_es_tbai_get_values` then multiplied values by `-1` again for refunds.
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L177-L181
- For discount lines, `is_refund = True` and `price = -10`, resulting in `-10 * -1 = 10`.

Fix:
-  Ensure tax detail values are always returned as positive values, matching the assumption introduced in commit [1]

[1] https://github.com/odoo/odoo/commit/03d55104e49aa65aa4c6475e199747fe9132e754

opw-6226003

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

Forward-Port-Of: odoo/odoo#275451
Forward-Port-Of: odoo/odoo#265777

Guests never receive any bus notification when the websocket is not handled by Odoo itself but by a proxy that forwards subscriptions through `/websocket/peek_notifications` and dispatches the notifications on its own (which is how Odoo.sh serves databases).

The peek controller calls `ir.websocket._prepare_subscribe_data()` directly, bypassing `_subscribe()`, the only method decorated with `@add_guest_to_context`. The guest cookie is present on the request but never read, so the returned channel list only contains the anonymous channels (broadcast, res.groups) and lacks the guest's personal ones: ("mail.guest", id), ("discuss.channel", id) and presence. The proxy therefore never registers those channels, and every notification targeted at the guest is silently dropped.

Before this commit, discuss calls with a guest are broken: a 2-person call never connects (p2p offers/answers/ICE are delivered over the bus); in a 3+ person call, any guest who joined before the SFU threshold stays stuck in dead p2p (they never receive the `sfu_hot_swap` notification) while a guest joining as 3rd+ participant works, since the join RPC returns the SFU credentials synchronously.

We override `peek_notifications` with `add_guest_to_context` so the route is aware of guests.

opw-5490739

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

Forward-Port-Of: odoo/odoo#275184
Forward-Port-Of: odoo/odoo#274743

Steps to reproduce:
1. Create a new version on an employee with a future start date
2. Ensure the new version has a different working schedule
3. After the new version becomes active, observe that the working schedule on the employees record is different from the one on the employee's resource record

Every employee has an associated resource record associated with them. Normally, the employee's working schedule (`hr_employee.resource_calendar_id`) should always be in sync with their associated resource record (`hr_employee.resource_id.calendar_id`). When we update the employee's working schedule through the UI on a currently active version, it will also update their associated resource record with the same working schedule. However, if we change the working schedule for a future version, when `_cron_update_current_version_id()` runs and changes the active version, there is no mechanism to update the associated resource with the new working schedule. This change will ensure we keep the working schedules in sync, as if they are not, strange behaviors can occur.

One side effect of this problem: When a new version becomes active, and working schedules become de-synced, this can cause the Attendance gannt view to display incorrect unavailable intervals for an employee (this appears as a grayed-out time slot). This is because `_attendance_intervals_batch()` pulls from the working schedule of an employee's associated resource record, rather than the employee record itself. This is what occurred on the linked ticket.

[opw-6352770](https://www.odoo.com/odoo/my-tasks/6352770?debug=assets)

Forward-Port-Of: odoo/odoo#275430

Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product.

## Steps to produce:
- Install Inventory without demo data
- Settings Enable 'Packages'
- Create a product:
   - Cheese burger
   - On hand > Create a new quant
   - Package: 'Burgerbox' and 'On Hand Quantity`: 1 and save
- Set the On Hand quantity to zero and save
- History > Revert the Inventory adjustment line from WH/stock to Inventory adjustment by selecting it and reverting via actions.
- Products > Packages > BurgerBox

## Observed Behaviour:
After reverting an inventory adjustment that set the product's physical quantity to 0, the package contains two lines for the same product with quantities 1 and -1.

This is inconsistent because a package should not contain a product with a negative quantity.

The package should be restored to its original state and contain only the expected positive quantity.

## Root cause:
When the user reverts the move line, `action_revert_inventory` is called. This method creates the revert move and then marks that move as done at [1].

Marking the move as done subsequently marks all related move lines as done at [2]. During this process, the system first unreserves the quantity from the virtual location / inventory adjustment and then removes the quantity from that location (resulting in a -1 quantity move line at that location). This is performed through `_synchronize_quant`, which is responsible for synchronizing the physical inventory with the move line at [3].

The `_synchronize_quant` method uses the move line's `package_id` when updating the corresponding quant at [4]. As a result, `_update_available_quantity` creates a new quant with the following values at [5]:
```
{
    'product_id': 1,
    'location_id': 14,
    'lot_id': stock.lot(),
    'package_id': 1,
    'owner_id': res.partner(),
    'in_date': datetime.datetime(2026, 6, 22, 12, 42, 11),
    'quantity': -1.0,
}
```
This creates a quant with a negative quantity that is linked to the package because `package_id` is set on the newly created quant. Consequently, the move line with the negative quantity becomes associated with the package.

[1]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L1016-L1035 
[2]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move.py#L1956 [3]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L662-L666 
[4]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L678-L687 
[5]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_quant.py#L1130-L1143
## Solution:
Remove the source `package_id` when creating revert moves for inventory adjustment locations.

When an inventory adjustment sets a product's quantity to 0, the adjustment is completed without a destination package, meaning the product is effectively removed from the package. Therefore, the corresponding revert move should not retain the package as its source. Keeping the package as the source is inconsistent because package information should not exist on a virtual inventory adjustment location, and the original inventory adjustment removes the product from the package (there is no destination package).

By removing the source `package_id` from the revert move, the system avoids creating negative quants associated with the package during quant synchronization. This also ensures that, after the inventory adjustment is reverted, the quantities of products inside the package are restored correctly and match their state prior to the adjustment.

opw-6285739

Forward-Port-Of: odoo/odoo#274663
Forward-Port-Of: odoo/odoo#271440

Steps to reproduce:
- Add an `s_add_to_cart` snippet inside a mega menu
- Open a product detail page for a storable product
- Change the product variant several times
- Stock availability messages keep appending under `availability_messages` instead of replacing the previous one

`_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with
`this.el.querySelector('div.availability_messages').append(...)`.

`document.querySelector('.oe_website_sale')` only returns the first `.oe_website_sale` element in the document. When a mega menu contains an `s_add_to_cart` snippet, that element appears before the product page container, so the removal step runs on the wrong subtree and never clears the messages on the product page.

Fix by scoping the removal to `this.el`, the current `WebsiteSale` interaction root, so both removal and insertion target the same product page container.

Forward-Port-Of: odoo/odoo#276007
Forward-Port-Of: odoo/odoo#274928

Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).

The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.

```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
    setStart@[native code]
    createEditorSelection@.../web.assets_web.min.js:12239:15
    getSelectionData@.../web.assets_web.min.js:12242:145
    updateActiveSelection@.../web.assets_web.min.js:12230:92
    @.../web.assets_web.min.js:12218:873
    handler@.../web.assets_web.min.js:14366:121
```

Steps to reproduce:

1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
   Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
   so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.

Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.

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

Forward-Port-Of: odoo/odoo#275587
Forward-Port-Of: odoo/odoo#270910

**Steps to reproduce:**
- Create a fiscal position T1, with detect automatically
- Create another one T2, without the detect automatically
- When looking at the fiscal positions list, make sure T1 is on top, followed by T2
- Go to the PoS settings, check flexible taxes
- Put T2 as default and in allowed, don't put T1 in allowed
- Go to the PoS, chose a customer
- The fiscal position is T1 even though it's not allowed

**Why the fix:**

Currently, the fiscal position is chosen like this in order:
- A FP specified on the customer's profile
- A FP detected with the detect automatically setting
- The default FP from the PoS settings

When we have a tie, it's the first one in the fiscal positions list that is chosen.

Before this commit, we did not check that the fiscal position was allowed to be used in the PoS, so we just fetched whatever fiscal position fit the best for a given customer and didn't check if we could actually use it.

We now make sure that the fiscal position we try to use is allowed in the current PoS, and if it's not we fall back to the default one.

opw-6032031

Forward-Port-Of: odoo/odoo#271343

### Steps to reproduce:
- Download 'Sales' application
- From 'Configuration' > 'Settings', enable 'Promotions, Loyalty & Gift Card'
- From 'Products' > 'Gift cards & eWallet', Configure an eWallet program with a top-up product
- Have a customer with an existing eWallet balance
- Create a new sale order for that customer and add the eWallet top-up product
- Pay the order using the customer's eWallet
> The order gets discounted by the eWallet, effectively allowing the user to top up their balance
using the balance itself (infinite money glitch).

### Cause of Issue:
When computing the discountable amount for payment programs (like eWallets and gift cards), `_discountable_order` includes the total order amount. However, it did not exclude the program's own top-up products (`trigger_product_ids`) from the discountable lines.

### Fix:
If an order consists solely of top-up products, attempting to apply the eWallet now correctly raises a `UserError` ("There is nothing to discount").

opw-6341410

Forward-Port-Of: odoo/odoo#273419

Step to reproduce:
- install pos_discount and l10n_es_edi_tbai_pos with demo data
- start pos, add a product and a discount of 10%
- fulfill the order
- go to backend and open that order
- from "TicketBai" page, open the "TicketBAI Post File" xml file

Observation:
- `ImporteUnitario` and `ImporteTotal` were exported as positive values for discount lines.

cause:
- Commit [1] assumed tax details are always positive.
- This is not generally true, in case we have price_unit < 0
- The logic relied on `is_refund`, which depends on `qty * price`.
- `_l10n_es_tbai_get_values` then multiplied values by `-1` again for refunds.
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L177-L181
- For discount lines, `is_refund = True` and `price = -10`, resulting in `-10 * -1 = 10`.

Fix:
-  Ensure tax detail values are always returned as positive values, matching the assumption introduced in commit [1]

[1] https://github.com/odoo/odoo/commit/03d55104e49aa65aa4c6475e199747fe9132e754

opw-6226003

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

Forward-Port-Of: odoo/odoo#275451
Forward-Port-Of: odoo/odoo#265777

Commit [1] introduces the concept of "global" cache for optimization. However
when loading a bundle inside a secondary document such as an iframe, containing
source files that are already loaded in the main document, those source files
are not properly added in the secondary document.

Example: load `web.assets_web` inside an iframe (this use case can happen in
`mass_mailing` where we have to wrap some component inside a sandboxed iframe in
order to display unsafe content (poorly sanitized), such as emails).

The issue is caused by an inconsistent usage of the `globalCache`: `getBundle`
adds `bundleName` key to JS and CSS libs, but `computeAssetCaches` adds `url`
keys to link or script elements.

After this commit:
- `globalCache` is only used in `getBundle` to map bundleNames to their libs
- `loadCSS` and `loadJS` only use the documents caches to map urls to their
  element in the respective document.

[1]: https://github.com/odoo/odoo/commit/5b1dc282b0f09c0fe6dcf9910a3a29cfd01d66a3

Steps to produce:
---
- Install the `sales` module.
- Create a product and `enable track inventory.`
- Log in as user with only view access rights in products and also have the sales access rights.
- Create a sale order containing product and confirm it.

Issue:
---
-  An access error is raised during order confirmation.

Root cause:
---
- In [commit], to handle inventory tracking, the `qty_available` field
was moved to `product.product`. Unlike before, this value is increased
or decreased depending on the operation performed.

- As a consequence, creating or updating a sale order triggers a write
to this `qty_available` field on the related product. This
write happens under the current user's permissions, so users who
only have read access to products (but can create/edit sale orders)
hit an `AccessError`, since they lack write access on
`product.product`.


Solution:
---
- Use `sudo()` when accessing the required product quantity information
  to ensure the operation can be completed without requiring additional product
  access rights.

The same issue also occurs when confirming a purchase order.

[commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b

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

Step to reproduce:
- install pos_discount and l10n_es_edi_tbai_pos with demo data
- start pos, add a product and a discount of 10%
- fulfill the order
- go to backend and open that order
- from "TicketBai" page, open the "TicketBAI Post File" xml file

Observation:
- `ImporteUnitario` and `ImporteTotal` were exported as positive values for discount lines.

cause:
- Commit [1] assumed tax details are always positive.
- This is not generally true, in case we have price_unit < 0
- The logic relied on `is_refund`, which depends on `qty * price`.
- `_l10n_es_tbai_get_values` then multiplied values by `-1` again for refunds.
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L177-L181
- For discount lines, `is_refund = True` and `price = -10`, resulting in `-10 * -1 = 10`.

Fix:
-  Ensure tax detail values are always returned as positive values, matching the assumption introduced in commit [1]

[1] https://github.com/odoo/odoo/commit/03d55104e49aa65aa4c6475e199747fe9132e754

opw-6226003

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

Forward-Port-Of: odoo/odoo#275451
Forward-Port-Of: odoo/odoo#265777

Steps to reproduce:
1. Create a new version on an employee with a future start date
2. Ensure the new version has a different working schedule
3. After the new version becomes active, observe that the working schedule on the employees record is different from the one on the employee's resource record

Every employee has an associated resource record associated with them. Normally, the employee's working schedule (`hr_employee.resource_calendar_id`) should always be in sync with their associated resource record (`hr_employee.resource_id.calendar_id`). When we update the employee's working schedule through the UI on a currently active version, it will also update their associated resource record with the same working schedule. However, if we change the working schedule for a future version, when `_cron_update_current_version_id()` runs and changes the active version, there is no mechanism to update the associated resource with the new working schedule. This change will ensure we keep the working schedules in sync, as if they are not, strange behaviors can occur.

One side effect of this problem: When a new version becomes active, and working schedules become de-synced, this can cause the Attendance gannt view to display incorrect unavailable intervals for an employee (this appears as a grayed-out time slot). This is because `_attendance_intervals_batch()` pulls from the working schedule of an employee's associated resource record, rather than the employee record itself. This is what occurred on the linked ticket.

[opw-6352770](https://www.odoo.com/odoo/my-tasks/6352770?debug=assets)

Forward-Port-Of: odoo/odoo#275430

# How to reproduce
- In Settings, enable Variants & Product Reference Price
- Create a published Product with a Sales Price
- Add 2 variants to the Product
- In the product's variant list, select the first one & set Base Unit Count to 0,
- Set the second variant's Base Unit Count to a value > 0
- Go to the Product's page
- Select the second variant

# The issue
The Reference Price is not displayed for the second variant, even though it should since it has a Base Unit Count > 0. Refreshing the page while being on the second variant will prevent the bug from happening.

# Cause
When loading the product's info, we call `_onChangeCombination`. This method is responsible for, among other things, updating the reference price and hiding it if Base Unit Count  = 0 :
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/website_sale/static/src/js/variant_mixin.js#L277-L289

To do that, it will search for an html element with the `.o_base_unit_price` css class. If it does not find it, the reference price will not be updated. The issue is that this element is behind a condition in the template :
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/website_sale/views/templates.xml#L2083

When the first time the template is loaded, if
`combination_info.get('base_unit_price')` is False, then the Reference Price will never be added to the view and will never be found by `_onChangeCombination`.

Since our first variant has Base Unit Count = 0, then `base_unit_price` will equal 0, so `combination_info.get('base_unit_price')` will be evaluated to false.

opw-6367289

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

Forward-Port-Of: odoo/odoo#274722

**Steps to reproduce:**

- Create a product A, tracked by lots
- Create a kit product, include a component A
- Change the UoM to 0.5
- Go to the PoS, order this kit product
- Also order the component A, with a quantity of 2
- Pay for it, ask for an invoice
- Go to the created picking
- The Demand column is correctly computed and is 0.5
- The Quantity column is wrong and is 2

**Why the fix:**

When getting the data from https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L283 
we always get the component's line, as the move's product is the component, even if it used to be the kit product's move. This is because when exploding a kit's moves, it gets the kit's component as a product instead of keeping the kit product.

This was introducing a weird behavior because we took the quantity from the component line, and not from the kit line, meaning the kit would always have the same quantity as the component.

We now check if the move is actually a kit product's move, and if it is we adapt the qty to correct one by fetching the correct line's qty, and adapting it with the correct UoM.

Changing the line in itself would not work, as the kit itself is not tracked by lots, so we would not enter https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L284 
and the move line would not be correctly created.

opw-6153000

Forward-Port-Of: odoo/odoo#275115
Forward-Port-Of: odoo/odoo#262551

### Steps to reproduce:
- Download 'Sales' application
- From 'Configuration' > 'Settings', enable 'Promotions, Loyalty & Gift Card'
- From 'Products' > 'Gift cards & eWallet', Configure an eWallet program with a top-up product
- Have a customer with an existing eWallet balance
- Create a new sale order for that customer and add the eWallet top-up product
- Pay the order using the customer's eWallet
> The order gets discounted by the eWallet, effectively allowing the user to top up their balance
using the balance itself (infinite money glitch).

### Cause of Issue:
When computing the discountable amount for payment programs (like eWallets and gift cards), `_discountable_order` includes the total order amount. However, it did not exclude the program's own top-up products (`trigger_product_ids`) from the discountable lines.

### Fix:
If an order consists solely of top-up products, attempting to apply the eWallet now correctly raises a `UserError` ("There is nothing to discount").

opw-6341410

Forward-Port-Of: odoo/odoo#273419

**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab

**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.

Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).

This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```

**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.

(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)

[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6

opw-6247412

Forward-Port-Of: odoo/odoo#275528

**PROBLEM**
`_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic.

**STEP TO REPRODUCE**
1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration.
2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
  - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id),
  - has res_field = NULL (record attachment, not a field binary),
  - is posted to the chatter → it has a row in message_attachment_rel.
3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size.
4. Run the cron _cron_migrate_local_to_cloud_storage.
5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping).

**FIX**
Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()`

opw-6347198

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#271829

CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate"

Odoo pins requests 2.31.0 (max depending on Python version), but online databases can use the version shipped by the OS (2.32.x on recent Ubuntu 26).

Set the certificate up when the adapter is created instead of on that connection call. That step runs the same on every requests version, so the fix works both before and after 2.32.

Steps to reproduce:
  - Spanish company with Veri*Factu and a certificate, on a server
  running requests >= 2.32 (saas-19.3 database for exemple on ubuntu 26)
  - Post a customer invoice and send it to Veri*Factu.
  => TypeError

Reference: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/HISTORY.md?plain=1#L146

Ticket [link](https://www.odoo.com/odoo/project.task/6366028)
opw-6366028

### Description of the issue/feature this PR addresses:
This PR fixes an issue in the `resource` module where flexible working hours cause unpredictable and shifting non-working (greyed-out) days on the Timesheets and Calendar views. It restores the weekly Monday anchor for flexible hour calculations while safely preserving a prior fix for partial-day work entries on public holidays.

### Current behavior before PR:
In `_attendance_intervals_batch`, the calculation for flexible schedules sets `current_start_day = start_date`. Because `start_date` is often passed as the first day of the month or a requested period (which can fall on any day of the week), the 7-day calculation cycle becomes unanchored. Odoo blindly allocates 8 hours to the first 5 days of this arbitrary period and leaves the 6th and 7th days empty. This results in the visual "weekend" shifting randomly month-to-month (e.g., greying out Wednesdays and Thursdays instead of Saturdays and Sundays).

### Desired behavior after PR is merged:
The `current_start_day` is correctly anchored back to Monday using `start_date - timedelta(days=start_date.weekday())`. This ensures the 5-day allocation always consistently spans Monday through Friday, keeping Saturday and Sunday as the standard non-working days on the UI grids. Furthermore, because the `min()` clamp on `remaining_hours` is retained, partial-day Work Entry generation (like a 2-hour gap on a Wednesday public holiday) continues to calculate correctly without attempting to over-allocate the remaining weekly hours.

opw-6370301

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

# How to reproduce
- Set an employee's work schedule to flexible 40hrs/week with 8hrs of work per day
- Create a new attendance for that employee that :
	- Is the very first attendance of that employee
	- Is not on a monday (e.g. a Friday)
- Create a second attendance for that employee that :
	- Is atleast one week after the first attendance
	- Is one of the two days of the week before the day of the week of the first attendance (e.g. a Wednesday or a Thursday)
- Go to the settings, update the value for "Tolerance Time In Favor Of Company" and save
- Come back to the second attendance

# The problem
The Extra Hours have changed and are equal to the worked time

# Cause
When we update the tolerance time, we recompute the overtime of every attendance of every employee.
In this recomputation, we compute the `expected_attendance` of every employee and transforms
them into a dict of the expected working time for each day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L349-L356

Later, if an attendace of the employee was not in their expected working days, then we consider that all hours worked were overtime :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L381-L384

This makes sense but our issue is that days in the middle of the week are considered "time-off" when they
should not. That's because for flexible working schedules, we emulate the expected working hours based on
the total hours per week and the maximum hours per day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/resource/models/resource_calendar.py#L384-L386

For every "week", we start from the first day and continue forward by greedily using all hours for that
day until there is no more hours for the week. The problem is that since this PR, we don't start "weeks" on
mondays, but on the `start_datime` :
https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

And in our case, `start_datetime` is the very first attendance day of the employee :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L344

So our expected working days are desynched with the days of the week

# Proposed solution
We partly revert https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

opw-6289079

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902