If you made a sale with multiple lines having the same product, the qty_delivered was not correctly computed on the different lines.

Steps to reproduce:
-------------------
* Activate the ship later option in the PoS settings
* Open PoS
* Add any product with a quantity of 5
* Apply a discount of 20% to the line
* Click on the same product so that they are added as a second line
* Change the quantity of the second line to 3
* Validate the order and use the ship later option
* Validate the picking
* Go to the sale report and check the qty_delivered for the product
> Observation: The qty_delivered is doubled, 16 instead of 8.

Why the fix:
------------
The qty_delivered was computed by summing the quantities of all moves for the product, but it did not take into account that the same product could be present in multiple lines of the same order. We now make sure to dispatch the delivered quantity correctly across the different lines of the order, ensuring that the qty_delivered is accurate.

opw-4826487

Forward-Port-Of: odoo/odoo#221373

Reproduction Steps:
---------------------------------------------------
To reproduce the issue first we need to create cowed view, follow the steps below:

- Ensure that the website and website_sale_mass_mailing modules are installed. 
- Navigate to Website > Shop.
- Select any product and add it to the cart.
- click on Proceed to checkout then checkout.
- On the checkout page, you will see the address form.
- Click on "Add a new address".
- Now "Edit" the website page (e.g., make the City label bold).

This will create a cowed view for the address page.
Now, follow the final steps to reproduce the actual issue:

- Enable the "Newsletter" option from Website Settings.
- Log out of the database.
- Go to the website shop, add a product to the cart, and proceed to checkout.
- On the address page, the subscription checkbox is not visible for a "Guest"  user.

Root Cause:
--------------------------------------------
The subscription checkbox does not appear because the cowed view of the newsletter is not activated.

Solution:
---------------------------------------
As of SaaS 17.3, a new module `website_sale_mass_mailing` was introduced, which adds the "Newsletter" option in Website Settings. When this option is enabled, the newsletter view is automatically activated. However, the corresponding cowed views are not automatically activated, causing the subscription checkbox to be missing during guest checkout.
To fix this, we ensure that the corresponding cowed view is also activated when the "Newsletter" option is enabled.

Related Link:
https://github.com/odoo/odoo/pull/154604/files

OPW-4860002
UPG-2978748



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

Forward-Port-Of: odoo/odoo#223255
Forward-Port-Of: odoo/odoo#214989

**Steps to reproduce:**
- For simplicity, create a new account.
- Create a new journal entry, with one line on the newly created account.
- Set the date to today or older.
- Set auto-post to "At date".
- Make sure the journal has autocheck_on_post set to True.
- Keep the journal entry in draft, and duplicate it until you have 100 copies. (Make sure auto-post is set to "At date" on all of the copies aswell)
- Set the newly created account to 'Deprecated'.
- Manually execute the scheduled action "Account: Post draft entries with auto_post enabled and accounting date up to today"

**Issue:**
The scheduled action fails and then falls into an infinte loop, and logs an error on the chatter every minute, which could lead to thousands of mail_message records beign created.

**Cause:**
If the autopost scheduled action fails on a certain move, it marks it as 'move.checked = False'. So that when it is calls itself again (if the number of moves to post is greater than or equal to 100), it won't fetch the same move and fail again.
But having 'journal_id.autocheck_on_post = True' in the search domain allows autopost to fetch the same move it marked before (if the journal allows it), which leads to an infinite loop.

**Solution:**
If autopost fails on a move, set 'auto_post' to 'no' so it won't be fetched again.

opw-4815790

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

Forward-Port-Of: odoo/odoo#214946
Forward-Port-Of: odoo/odoo#213642

Problem:
When a purchase order for a subcontracted product tracked by lots/serials is confirmed, the "Procurement: run scheduler" action creates a stock reservation in the subcontracting location. This reservation is created without a lot or serial number.

When the finished product is later received with its lot/serial, the system tries to use the untracked reservation to define a source for the move, but will still create a new quant line because of the destination. This results in two quants, leading to incorrect inventory levels:
- A positive quant for the product with the correct lot/serial.
- A negative quant for the same product without a lot/serial, with a hanging reservation.

Solution:
The reservation mechanism in _clean_reservations() is now bypassed for stock moves that should have a lot or serial number, but do not. This ensures that when the tracked product is received, no redundant quants are created.

Steps to reproduce on Runbot (tested on 18.3 and 18.0):

1. Create a new product and track by lots
2. Add a BOM for this product, setting type to Subcontracting
3. Create a PO for the product and confirm it
4. With debug enabled, go to Inventory > Operations > Procurement: run scheduler To see the issue:
5. Go to Inventory > Reporting > Locations
6. Search for the product, note the quant line at the subcontractor location with no lot number
7. Return to the PO and recieve, specifying lot number
8. Go to Inventory > Reporting > Locations
9. Search for the product again, note that there are now 2 quant lines at the subcontractor location when the quantity on hand should have zeroed out

opw-4935822

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

Currently, when users import a CSV or XLSX file into the Fleet app containing the `model_year` field as an integer, an error is raised.

**Steps to Reproduce:**
1) Install **Fleet** app(with Demo Data).
2) Open Fleet App and Import [this file](https://docs.google.com/spreadsheets/d/1KJgVTM7KeAVcHR-TQg86gO4in53G7NyR/edit?usp=sharing&ouid=101212513075316114369&rtpof=true&sd=true). 
3) Click on Test or Import.

**Error:**
`UndefinedFunction: operator does not exist: text = integer`

**Root Cause:**
Since PR https://github.com/odoo/odoo/pull/197440, the `model_year` field was changed from a `char` to a `selection`. The selection values are generated by the `_get_year_selection` method at [1], which returns a list of integers.
However, when these integer value is compared at [2], a type mismatch occurs because the expected type is `text`, not `integer`.

**Solution:**
This fix ensures that `_get_year_selection` returns a list of **strings** instead of `integers`, so that the values match the expected type at [2]

[1]- https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/fleet/models/fleet_vehicle.py#L34-L36

[2]- https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/odoo/addons/base/models/ir_fields.py#L451

sentry-**6663249660**

### Steps to reproduce:
	- Install Attendance and Website modules
	- Have a company 'Company A'
	- Create a new company 'Company B'
	- Set the Attendance kiosk mode to 'Barcode / RFID' for both companies
	- Update all websites to be related to Company B
	- Go to the Kiosk mode for Company B
	- Notice it makes you choose between the 3 check in types while we only chose 'Barcode / RFID'

### Cause:
When openning the kiosk mode it will check if the database is a trial one or if the user doesn't have a password and if so we assume that the database is a trial one. If it is a trial database we set the kiosk mode as 'settings' which shows all check in types when openning the kiosk mode.

https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L101-L102

https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L185-L196

When creating a new company and set website for it we create a public user for this company and normally we don't set password for this user as no one is gonna login using it.

### Fix:
We check if the user doesn't have a password and if he is not a public user. As we assume that if he is a public user he won't have a password anyways.

opw-4916329

Forward-Port-Of: odoo/odoo#220355

`* = pos_online_payment_self_order`

**Installation:** `pos_online_payment_self_order` and `payment_demo`

**POS Shop Configuration:**
- **Restaurant** mode.
- Self-order mode: **"QR menu + Ordering"**.
- Enable **online payment** method for self-order.
- Activate **Automatic Receipt Printing**.

**Steps to Reproduce:**
- Open the register.
- Place an order and choose **Online Payment**, and validate it (**QR** code appears).
- **Deactivate** the register tab (e.g., by opening another browser tab).
- **Pay** the amount by scanning the code (can use phone).
- Wait for the payment to **succeed**.
- Switch to the original register tab.

**Error:**
Frontend: `TypeError: Cannot read properties of null (reading 'cloneNode')` 
Backend: `ValueError - This order has already been printed automatically.`

**Case 1: Register tab is active**
No crash occurs, the receipt printing pop-up is triggered twice:
1. When the order is auto-validated and printed [(Ref 1)](https://github.com/odoo/odoo/blob/52badedb4edb4018bbf400af4f48f81aa597654a/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L391-L401)
2. When the `ONLINE_PAYMENT_STATUS` notification with status success is received [(Ref 2)](https://github.com/odoo/odoo/blob/52badedb4edb4018bbf400af4f48f81aa597654a/addons/pos_online_payment_self_order/static/src/overrides/services/pos_store.js#L16-L17)

**Case 2: Register tab is inactive (hidden)**
- The auto-print logic fails due to the DOM element (`el`) being `null`, skipping the first print and leading to a `TypeError` at [1].
- When the tab becomes visible again (`visibilitychange` event), a backend call is triggered to `get_order_to_print` at [2], which fails with a `ValueError` because the order was already flagged as printed.

[1] - https://github.com/odoo/odoo/blob/52badedb4edb4018bbf400af4f48f81aa597654a/addons/point_of_sale/static/src/app/services/printer_service.js#L55-L57
[2] - https://github.com/odoo/odoo/blob/8fb3776b54a17307979733e7f155939d7d87d9d2/addons/pos_online_payment_self_order/models/pos_order.py#L19-L20

**Fix:**
This commit ensures each order is printed only once:
- If the tab is active and auto-print works, skip printing on visible status.
- If the tab is inactive and auto-print fails, fallback printing is allowed via the visibility change event.

Sentry - 6707550067

Problem:
The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate reporting.

Purpose:
To ensure that non-recurring products added through upsell Sales Orders are correctly included in the Sales Analysis Report (report_all_channels_sales_action). This fix updates the report's domain filter to include upsell orders when the product is not recurring, resolving the issue of missing sales data for such products.

Steps to reproduce the bug:

1. Create a Sales Order (SO):
  Add two products to the order:
    - One recurring product (e.g., a subscription-based product with a recurring billing policy).
    - One non-recurring (standard) product. 
2. Confirm the SO
3. Generate an Invoice for the confirmed SO.
4. Validate the Invoice and deliver the non-recurring product (process the delivery order fully). 
5. Create an Upsell Sales Order:
    - From the original SO, create a new upsell SO.
    - Add the same non-recurring product again. 
6. Navigate to the Non-Recurring Product Page:
    - Open the Product form for the non-recurring item.
    - Click on the "Sold" smart button (shows delivered/sold quantities in the past 365 days).
    - This opens the Sales Analysis Report (report_all_channels_sales_action) filtered by this product.

Issue:
The upsell Sales Order is not included in the Sales Analysis Report for the non-recurring product. As a result, the delivered quantity or revenue from upsell SOs is missing from the report for non-recurring products.

opw-4940977

Forward-Port-Of: odoo/enterprise#92559