If you made an order and tried to pay with a payment terminal (like Adyen) then canceled the payment on the terminal. Then leave the order and create a new order, add different products, and try to pay again, pay on the terminal, the payment will not be transmitted to the PoS and the order would still be waiting for payment.

Steps to reproduce:
------------------
* Create a pos payment method using adyen
* Open a PoS session
* Create an order with a product
* Pay with the adyen payment method
* Cancel the payment on the terminal
* Leave the order
* Create a new order with different products
* Try to pay with the adyen payment method
* Validate the payment on the terminal
> Observation: The payment will not be transmitted to the PoS and the
  order will still be waiting for payment.

Why the fix:
----------------
The issue occurs because the canceled payment line is still considered as a pending payment line. And when the payment will be receiven on the pos it would take the canceled payment line as the pending one.

opw-4805704

Forward-Port-Of: odoo/odoo#222325
Forward-Port-Of: odoo/odoo#219054

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

Steps to reproduce:
  1. Go to a WhatsApp template, for e.g. Sale Order.
  2. Update the sample value for the Portal Link variable to include an underscore.
  3. Click on Preview

Issue:
Due to the current regex, we will apply italic to any underscore we find which is not ideal, mostly when we work with URLs that can contain underscores like "acces_token" which we will try to apply italic to it too.

Solution:
Following the most common logic for italic formatting, we will only apply italic formatting when the underscore is surrounded by whitespace. This is the same way it already behaves in Whatsapp.

If we write it like_this_for example, it will not apply italic formatting, but if we write it like this _this_ it will apply italic formatting.

So this for example:
 **"If we write it like_this_for example"**
 Will be like - before the fix:
  **"If we write it like<i>this</i>for example"**
 Will be like - after the fix:
  **"If we write it like_this_for example"**

opw-4720017

Forward-Port-Of: odoo/enterprise#91217

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

Currently an error occurs when trying to run whatsapp marketing automation test more than once.

**Steps to replicate:**
* Install `marketing_automation_whatsapp`
* Setup whatsapp integration
* Marketing Automation > New > Start From Scratch > Add a new activity
* Select Activity Type as Whatsapp Message and a Whatsapp Template
* Launch a Test > Pick a contact > Launch > Run (Do this step twice)

**Error:**
`ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)`

**Cause:**
This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset.

Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed.

**Solution:**
* Handle trace records one by one using a loop.

[1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20

**Sentry-6772553612**

Forward-Port-Of: odoo/enterprise#91207

**NOTE:** This is extremely similar to the [request](https://github.com/odoo/enterprise/pull/90605) that was created for saas-18.2. However with the changes in [2] , from saas-18.3 and on, template strings can be directly extracted with ``_t`` , and so this PR is meant to provide a more forward-port friendly version for future roll outs.

Steps to Reproduce:

- Change the language to something other than English.

- Create a new menu in the Appointment module using Studio.

- Link that menu with the existing model (Resource Time of Detail).

- Save the changes and add the Gantt view

- Save the changes and close Studio.

- View this new menu in the Gantt view

Issue:

- When clicking onto the kanban popover card for any record, the labels will remain as "Name" , "Start" , and "Stop" in English, and it will not translate.

Reason:

- [1] changed the rendering of default kanban card templates from XML to JS. This changed the default template to be static.

Fix:

- Add a call to the translation core tool "_t" on the three labels upon their generation in _getKanbanViewParams(). This ensures that the arch template that is generated is translated correctly into the user's set language.

- Additionally, add these terms into the .pot file for web_gantt. This ensures that the proper translations are stored for transifex and the relevant translation team and that the call to _t will have a translation to reference in it's call.

[1] : https://github.com/odoo-dev/enterprise/commit/23e53dab70fe3f1d418a12f7ac040acacf9e1ead

[2] : https://github.com/odoo/odoo/commit/079c3b0f6078377335837defa08077b0d7d3489f

opw-4861899

### Steps to reproduce:
	- Activate a payment method
	- Create a subscription and preview it in portal view
	- Pay this order through the order's portal view
	- Navigate to the invoice got generated
	- Notice there is not 'Payments' smart button

### Cause:
Since https://github.com/odoo/enterprise/pull/77432/commits/02f72f94b7c996fa19c6bfc70a704d27aa677245 we stopped creating the invoice before the payment and the transaction in the controller and we let _post_process do this invoice creation. So the invoice actually gets created after the payment not before and when preparing the payment values the invoice_ids will be False

https://github.com/odoo/odoo/blob/6c88e6ffd2c906b72b31d3c34ad3d6da5efba204/addons/account_payment/models/payment_transaction.py#L155-L170

Then we create the invoice for the transaction and we don't propagate it to the payment.

https://github.com/odoo/enterprise/blob/20fd574367757c06f30c344056e8b8d91ba8244c/sale_subscription/models/payment_transaction.py#L72-L84

### Fix:
Link the payment to the invoice after creating the invoice and link it to the transaction.

opw-4867631

Forward-Port-Of: odoo/enterprise#91690

**Steps to reproduce:**
- Install accountant

- Go to "Accounting / Configuration / Invoicing / Payment Terms"
- Create a payment term having at least 2 installments (e.g. 20%-80%)

- Create a bill:
  * Vendor: [any]
  * Payment terms: [the created payment term]
  * Amount: 1000
- Confirm the bill

- Pay the first installment from the bill (i.e. 200)
- Go to "Accounting / Vendors / Payments"
- Select the payment and create a batch
- Validate the batch payment

- From Accounting dashboard, go to Bank journal
- Create a statement:
  * Partner: [None]
  * Amount: -200
- Reconcile the statement with the batch payment

- From the bill, pay the second installment (i.e. 800)
- Go to "Accounting / Vendors / Payments"
- Select the payment and create a batch
- Validate the batch payment

- From Accounting dashboard, go to Bank journal
- Create a statement:
  * Partner: [None]
  * Amount: -800
- Reconcile the statement with the batch payment

**Issue:**
The following UserError is raised:
"You are trying to reconcile some entries that are already reconciled."

**Cause:**
When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used.
However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled.
It should not be reused when reconciling the second batch payment.

**Solution:**
Exclude reconciled payment term lines when reconciling a batch payment.

opw-4830185

Forward-Port-Of: odoo/enterprise#91367