**Problem:**
On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist).

**Steps to reproduce:**
1. Create a subscription product with a recurring plan.
2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price).
3. Open the product page on the website.

**Current behavior:**
The page fails with a 500: Internal Server Error during price computation.

**Expected behavior:**
The page loads and shows the discounted recurring price.

**Cause of the issue:**
For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion.

**Fix:**
Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record.

opw-6306105

Forward-Port-Of: odoo/enterprise#121466

Before this commit, columns with figure_type 'date'/'datetime', General Ledger's Date column, but also Partner Ledger, Aged Partner Balance, Bank Reconciliation and Customer Statement. were exported to XLSX as plain text strings instead of real Excel date values.

_get_cell_type_value, which decides whether a cell must be written as a date or as text, only recognized a cell as a date when its 'class' contained 'date'. _build_column_dict, used by every report to build its column cells, never set that key, so
the check always failed and cells fell back to text, even though figure_type was correctly set to 'date' on them.

_build_column_dict now also sets 'class': 'date' on date datetime columns, the same convention already used by hand-built cells
 in account_followup

This in turn revealed a second, so-far dormant issue: once real datetime values started reaching the XLSX writer, _set_xlsx_cell_sizes crashed while estimating the column width, as it unconditionally tried float(value) to shorten long numbers and only guarded against value errors and overflow errors, not the TypeError raised by float() on a datetime object. It now skips that numeric-shortening step for date/datetime values, like it already did for None.

opw-6276398

Forward-Port-Of: odoo/enterprise#121668

On the website booking page, moving to a later month can show no available times even though the weekly schedule clearly has some.

### Steps to reproduce

- Install Appointments.
- Create a recurring appointment type available on a single weekday (say Monday), with a user or resource assigned and a date range spanning a few months.
- Set `Allow bookings at least` (the minimum booking delay) so that the current time plus the delay falls after this month's last Monday. Close to the end of a month, a day or two of delay is enough.
- Open the booking page: the first month shown is next month, because the delay skipped this month's last slot.
- Click the arrow to move forward one more month.

=> the reached month shows no slots, even though it has Monday availability.

### Cause

The calendar computes availability one month at a time. It builds a list of months, and the browser refers to each month by its position in that list (0, 1, 2, ...). Clicking the next arrow sends that position back to the server.

The server turns the position into a real month by adding it to a start month, which it computes as `now` plus the minimum booking delay. But the list shown to the visitor does not start there: it starts at the month of the first slot that can actually be booked.

These two are usually the same, so the position lines up. They stop matching when the delay moves the earliest bookable time past the last availability day of the current month. In the steps above, `now` plus the delay lands after the month's last Monday, so the first bookable slot is a Monday in the next month. The visitor's list then starts one month later than the server assumes, every position points one month too early, and the server computes availability for a month the visitor is not looking at. The reached month comes back empty.

### Fix

Count the visitor's month position from the same first bookable slot the list starts from, instead of from `now` plus the delay. The navigation offset is passed to the slot computation and resolved against that slot, so the filled month always matches the month the visitor sees.

opw-6353569

Forward-Port-Of: odoo/enterprise#123994
Forward-Port-Of: odoo/enterprise#122494

***Issue:***
Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in the documents list and kanban views, so every change of the selection count destroys and recreates everything inside it. Ticking a document checkbox updates both the selection and the focused record, and with these two updates the recreation goes wrong: the new ActionMenus component ends up destroyed while its button is still in the page. The dropdown click listeners are removed with the component, so clicking Actions does nothing until the selection changes again.

That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one.

***Fix:***
Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents.

***Steps to reproduce:***
1. Open the Documents app
2. Switch to the list view
3. Tick the checkboxes of two documents
4. Click the Actions button next to the "2 selected" box

=> the Actions dropdown does not open

Ticket [link](https://www.odoo.com/odoo/project.task/6365618)

opw-6365618

Forward-Port-Of: odoo/enterprise#123986
Forward-Port-Of: odoo/enterprise#123575

## Issue
When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong.

## Steps to reproduce
1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`)
2. Using a Luxembourgish company, create a new contract for an employee
    - *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025)
3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__

## Cause
The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are:
- `968.04` from 2025-05-01 (Mai 1st 2025)
- `992.24` from 2026-06-01 (June 1st 2026)

These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1).

## Tests modification
Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`).

https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74

Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023).

opw-6330790

Forward-Port-Of: odoo/enterprise#122147

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

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

[*]=website

1. Sync background shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    3. Drop any snippet.
    4. Add a background shape.
    5. Set the background shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
  
    Issue:
    The background shape color is not updated when the theme color changes.
    
    Reason:
    The background shape color is embedded in the URL of the "**background-image**" style attribute. When the theme color value changes, this URL is not updated. Additionally, the URL uses color variables rather than resolved hexadecimal color values as parameters. As a result, even when an updation occurs, the URL itself remains unchanged, preventing the background shape color from being updated.
    
2. Sync image shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    2. Drop any snippet.
    4. Click on the image and add a shape.
    5. Set the image shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
    
    Issue:
    The image shape color is not updated when the theme color changes.
    
    Reason:
    When the theme color value changes, the SVGs are not re-fetched. Additionally, the image "**shapeColors**" dataset stores the hexadecimal value of the theme color instead of the corresponding CSS variable. As a result, there is no way to determine which theme color was selected (for example, whether `o-color-1` or `o-color-2`), since only the hex value is available.


task-5438314

Forward-Port-Of: odoo/odoo#272952
Forward-Port-Of: odoo/odoo#241968

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#274167
Forward-Port-Of: odoo/odoo#271440

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

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