We had a bug when selling event tickets in POS where tickets with seats_max set to 0 (which should mean unlimited) appeared as sold out when the event had seats_limited enabled.

Steps to reproduce:
-------------------
* Create an event with seats_limited=True and seats_max > 0
* Create a ticket for that event with seats_max=0 (unlimited)
* Open POS and view the event product

> Observation:
Ticket appears as "Sold out" instead of showing available seats

Why the fix:
------------
The frontend logic only treated tickets with seats_max=0 as unlimited when the event itself was not limited (!event.seats_limited). However, according to the backend logic, seats_max=0 means the ticket is unlimited regardless of the event's limitation status. When the event is limited, unlimited tickets should still respect the event's seats_available limit, not show as sold out.

We now check for seats_max=0 independently of event limitation. If the event is not limited, tickets with seats_max=0 are fully unlimited. If the event is limited, we use the event's seats_available value (since the ticket doesn't constrain availability but the event does), ensuring correct display of availability status.

opw-5475803

Forward-Port-Of: odoo/odoo#246102

**Issue**:
The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback

**Steps to reproduce**:
- Create a kit product with 2 components: 
    - Inventory tracking enabled 
    - Use a category configured with AVCO and Perpetual (at invoicing) valuation
- Create a SO for the kit product and confirm it
- Go to the associated delivery and validate it
- Create and post the invoice on the so -> A traceback occurs

**Cause**:
In `_get_cogs_price_unit`, the code accesses `self.product_id.cost_method` assuming a singleton: https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/stock_move.py#L245 but `self.product_id` can be a multi-recordset when the sale line corresponds to a kit with multiple components https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/account_move_line.py#L67-L68 https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/sale_stock/models/account_move.py#L155-L156

which causes the traceback.

**solution**
The solution has been inspired by this:
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228

opw-5880383

Forward-Port-Of: odoo/odoo#247775

[FIX] website: enable custom javascript on website
Steps to reproduce the problem:
- Go to the "HTML/ CSS Editor".
- Go to the JS tab.
- Uncomment the example and save.

-> Problem: the confirmation dialog does not appear.

The problem is that since [1], `/* @odoo-module */` has been removed
from the file as since [2], js files in `/static/src` and
`/static/tests` are considered as odoo module without the need of the
annotation `odoo-module`. In order to understand the problem, here is a
summary of what happens when a custom js code is saved;
- An attachment is created with the custom js code.
- An asset is created to replace the user custom rules of
`user_custom_javascript.js` by the one of the newly created attachment.

Because the url of the newly created attachment looks like
`/_custom/web.assets_frontend_lazy/website/static/src/js/user_custom_javascript.js`,
the transpiler does not recognize it as an odoo module.

task-5925607

[1]: https://github.com/odoo/odoo/commit/6d2fda172ec9cc7642abe9625ca486c7769e8297
[2]: https://github.com/odoo/odoo/commit/5f2c505836002ac7851c29c28d612f721d467bc4

Forward-Port-Of: odoo/odoo#247959

## Issue
When using the *Default GS1 Nomenclature*, it is possible to create multiple lots/serial numbers with a same name if that name matches a barcode rule pattern.

## Steps to reproduce
1. Install *Inventory* (`stock`)
2. In Settings, enable *Lots & Serial Numbers* and set *Barcode Nomenclature* to *"Default GS1 Nomenclature"*
3. Create a product tracked *By Unique Serial Number* or *By Lots*
4. In Inventory > Products > Lots / Serial Numbers, create a lot/serial number named *"101"* and set the product to the one created in the previous step
    - The name *"101"* matches the pattern of the rule *"Batch or lot number"* (`(10)([!"%-/0-9:-?A-Z_a-z]{0,20})`)
5. Create a second lot/serial number with the same name and the same product
6. **The second lot/serial number is succesfully created**

## Cause
When comparing a (new) `stock_lot.name` to existing `stock_lot`s, the potential rules at the start of the name are removed by the `gs1_decompose_extended` method [here](https://github.com/odoo-dev/odoo/blob/e06282df3a7482cc327d3124e6c2b1c8bc55c2f0/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L116-L125). This results in comparing **the end** of the new lot/serial number with **the entire** name of existings serials.

## Solution
Commit https://github.com/odoo/odoo/commit/3513b189a225ca52fc9fae94693f00f43ded71aa introduced the `skip_preprocess_gs1` context flag. This flag allows to skip the step that removes the start of the new lot/serial number before comparing it to existing serials.

## Test
The test for this commit is added in `stock_barcode` by [this PR](https://github.com/odoo/enterprise/pull/104720)

opw-5477003

Forward-Port-Of: odoo/odoo#244427

**Steps to reproduce:**
- Install Accounting
- Install a localization using PEPPOL (e.g. l10n_be)
- Switch to a Belgian company
- In Accounting settings, activate PEPPOL and Audit Trail

- Create an invoice:
  * Customer: [a Belgian customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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

Forward-Port-Of: odoo/odoo#248220
Forward-Port-Of: odoo/odoo#247949

Steps to reproduce:
1. Create a storable product with tracking set to 'By Quantity'.
2. Update the Quantity on Hand (e.g., 100 units).
3. Change the product tracking to 'By Serial Number'.
4. Create a Repair Order for this product.
5. Add a line, select a specific Serial Number, and click Save.
6. Observe that the serial number disappears.

Cause:
When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation.

Solution:
In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid.

opw-5156267

Forward-Port-Of: odoo/odoo#248094
Forward-Port-Of: odoo/odoo#247150

Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)

--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------

Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.

Cause:
- The QWeb template always prefixed “Order” regardless of order type.

Fix:
- Added a condition to skip the “Order” label for self-order references:

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

Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
   - Open that table. The "Send To Kitchen" button is still visible even
     though the order was already sent to the kitchen and printed.

Cause:
- In self-order mode  the order is not automatically synced after being sent to
  the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
  visible.

Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------

Task-5106704

Forward-Port-Of: odoo/odoo#246867
Forward-Port-Of: odoo/odoo#231005

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105930
Forward-Port-Of: odoo/enterprise#102714

Steps to Reproduce:
1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours.

Source:
When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28).
However, these four days are not enough to cover 40 hours.

The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December.

Solution:
Remove already-used intervals before recomputing the schedule.

opw-5364327

Forward-Port-Of: odoo/enterprise#107043
Forward-Port-Of: odoo/enterprise#101262

## Issue

When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern.

## Fix
The fix related to this commit is introduced by [this PR](https://github.com/odoo/odoo/pull/244427).

## Problematic flow
The problematic flow starts in the `StockLot._check_unique_lot` method when calling `self._read_group`. At that point, the domain is still correct: it contains the product_id and the (correct) name for the lot we try to create.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/stock/models/stock_lot.py#L104-L111

In the `BaseModel._read_group` method, the query is defined by the `self._search` method. At that point, the domain is the same as in the previous step, so it is still correct.

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/odoo/orm/models.py#L1902-L1904

Now the flow differs depending on whether the `stock_barcode` app is installed or not. If it is, the `stock_barcode/StockLot._search` method is called:

https://github.com/odoo/enterprise/blob/24fea3814b95144953fb809d10bf6a62906c06fd/stock_barcode/models/stock_lot.py#L11-L15

This is the method that calls the `BarcodeNomenclature._preprocess_gs1_search_args` which uses the `skip_preprocess_gs1` context flag:

https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L149-L151

**This flow makes the query returned by `self._search(domain)` erroneous, as the start of the name of the lot is removed further down the execution of the `preprocess_gs1_search_args` method.**

### If stock_barcode is not installed

The `self._search` method called in the BaseModel will not call `stock_barcode/StockLot._search`, but instead it calls `BaseModel._search`. This totally skips the problematic gs1 flow.

opw-5477003

Forward-Port-Of: odoo/enterprise#104720