## [FIX] industry_fsm_sale: fix invoice status for zero price lines

### Issue:
Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines linked to an FSM task to 'no'

This includes pre-existing lines that were already present on the quotation before confirmation. If a zero price line is pre-existing, it should follow the standard flow and be marked as 'to invoice'
Only lines added as materials from the field service task at a zero price should be considered included in the price and marked as 'no'

### Cause:
In `SaleOrderLine._compute_invoice_status`, the system forced `invoice_status = 'no'` for all zero price lines when Anglo-Saxon accounting was disabled
It failed to check if the lines were actually materials added via the FSM task or original quotation lines

### Fix:
A new `material_sale_lines` compute field is added to `project.task` to distinctly isolate and track lines added specifically as materials during the task execution

In `SaleOrderLine._compute_invoice_status`, the logic is updated to ensure that only zero price lines identified as FSM materials are set to 'no' when Anglo-Saxon accounting is disabled
Other pre-existing zero price lines properly remain as 'to invoice'

### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
Before the fix, the pre-existing SO line with price 0 is 
incorrectly considered as not to invoice ('no')

opw-6169802

------------------------------

## [FIX] industry_fsm_sale: sync sale order invoice status

### Issue:
When a sale order contains FSM material lines with a price of zero and Anglo-Saxon accounting is disabled, the overall sale order invoice status remains stuck on 'to invoice' even after all other invoiceable lines are fully invoiced

### Cause:
The standard `SaleOrder._compute_invoice_status` does not handle FSM business rules regarding zero price material lines that are marked as `invoice_status = 'no'`
Because these lines are never technically invoiced, the global order status fails to transition to 'invoiced'

### Fix:
Override `SaleOrder._compute_invoice_status` to recompute the status of confirmed orders linked to FSM tasks

We use the task's `material_sale_lines` to filter out material components
If all lines on the order are either 'invoiced' or are zero price FSM material lines with Anglo-Saxon disabled, the global sale order status is forced to 'invoiced'

### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
- Add a Product from the Task (Use a price 0 product, or set the unit price to 0 on the SO)
- Create the invoice for the Sale Order
Before the fix, the Service and Pre-existing product are invoiced, but in the Other Info Tab of the SO, the status stays on 'To Invoice' instead of 'Fully Invoiced'

opw-6169802

Forward-Port-Of: odoo/enterprise#123151
Forward-Port-Of: odoo/enterprise#119238

When a user asks an AI agent to open a view, a GPT-powered model simply
replies that it cannot do that. A Gemini-powered model takes a lot of
time computing, but eventually succeeds. In both cases, the models
successfully load the "View Builder" topic.

This buggy behavior is isolated to version saas-19.3. On other versions,
after a topic is loaded, we send a list of all accessible views and menus
to the agent so it knows how to navigate. That context was missing here,
so this solution backports the fix from master.

This context is strictly necessary because the agents are not allowed to
query `ir.ui.menu` directly. Gemini was only getting around this by
repeatedly calling `Get Menu Details` until it finally guessed the right one.

Since this missing context affects multiple areas, this commit adds the
required accessible views and menus context to the View Builder, Update
Records, Create Records, and Information Retrieval topics.

Additionally, this commit updates the system prompt to prevent OpenAI
models from fixating exclusively on tools. Previously, if a model had
already loaded a topic but needed a tool from a different one, it would
incorrectly claim it lacked access to the necessary tool instead of
loading the appropriate topic. The prompt edits shift the models' focus
toward managing topics rather than just executing tools.

related-commit: https://github.com/odoo/enterprise/commit/a6d804fe328e27bfdb1c35dc777aa25e1fce99d8

task-6234300

### Steps to reproduce:

- In the settings enable: "Storage Locations" and "Consignment"
- Create a storable product and put 1 unit in stock with a set owner
- Go to the barcode app > Operations > Delivery Orders > New
- Scan your product and validate
#### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit.

### Cause of the issue:

The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407
However, the option also make sense for none tracked products.

### Note:

Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330
Setting the same owner on the new move line as on the quant we are going to reserve:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715

Additional subtelties appearing when prefilling for non tracked product:

1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually
relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants.

2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line:
https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387
> This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned.

opw-6050657

Forward-Port-Of: odoo/enterprise#124017
Forward-Port-Of: odoo/enterprise#115021

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

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

**Description of the issue/feature this PR addresses:**

When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to access the interface from within the POS app's sub-menu.

This occurs because the dashboard menu triggers a server action (`action_pos_preparation_display_kitchen_display`) to route the user. When a server action has no explicitly defined `group_ids`, Odoo's `_can_execute_action_on_records` method falls back to requiring `write` access on the underlying model (`pos.prep.display`) to execute the code. Since standard POS users do not have 'write' access to this model, the execution engine blocks the routing attempt.

This commit resolves the issue by explicitly appending the POS User group to the server action's `group_ids`.

opw-6305014

**Steps to reproduce:**

- As Mitchell Admin:
    - Settings > Users & Companies > Users > Marc Demo > Access Rights > Sales > set POS to User
- As Marc Demo:
    - Attempt to access Kitchen Display app > observe Access Error
    - POS > Orders > Preparation Display > observe no error


**Current behavior before PR:**

- POS Users receive an Access Error when attempting to access the Kitchen Display app from the main dashboard

**Desired behavior after PR is merged:**

- No Access Error when POS Users access the Kitchen Display app

Forward-Port-Of: odoo/enterprise#122531
Forward-Port-Of: odoo/enterprise#121419

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

# 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