Steps to reproduce:
- Install the helpdesk_sale_timesheet module.
- Create two helpdesk teams (e.g. VIP Support and Customer Care).
- Enable time billing and timesheets for the VIP Support team only.
- In the portal view of tickets observe that the "Time Spent" label is missing

Issue:
- In the portal view you will see the 'Time Spent' label missing.

Cause:
- In the portal view of tickets the 'Time Spent' label is missing because when data is grouped (e.g. by stage, assignee, 
  or team) it will check for the first group of tickets. It evaluates group in ascending order and if `use_helpdesk_sale_timesheet` is set to false for the first group the 'Time Spent' label will disappears even if it's enabled for other group.

Fix:
- In this commit we will check the `use_helpdesk_sale_timesheet` field for every ticket in the list. If it is set to true for any ticket the "Time Spent" label will be displayed; otherwise it will remain hidden.

limitation :
- In this case we need to add the list because removing `any` from the condition would violating our stability policy.

task-4058210

Forward-Port-Of: odoo/enterprise#69331

Steps to reproduce:
- Download 'Project' and 'Subscription'
- Create a product with: -- Product type: 'Service'
-- Create on order: 'Task'
-- Project: Pick any
-- Recurring checkbox must not be ticked
- Subscription > New > Add any recurring product > Confirm
- Create invoice > Confirm invoice > Back to subscription
- Upsell > Add your task creation product > Confirm
- The project is linked but no task is created

The ability to create tasks from upsell orders was disabled in cbbc70f73e6fe9e29e27dea4415e20a262bbdf82.
According to the commit message, this was done because upsell orders prorate the price of subscriptions accoding to the time until next invoice relative to the subscription's recurrence (i.e. if the upsell is created halfway through the recurrence it is discounted by 50% etc...). Since we do not have a way to prorate tasks it is marked as a technical limitation.

This however does not need to extend to non-recurring products on subscription sale orders as they are not prorated.

opw-4114049

Forward-Port-Of: odoo/enterprise#69794

Coupled with [53d6c3492ec977e4588ee734f3c3a7f06534687a](https://github.com/odoo/odoo/pull/179266/commits/53d6c3492ec977e4588ee734f3c3a7f06534687a)

Steps to reproduce:
- Helpdesk > Configuration > SLA policies
- Create one if necessary or use existing
- Helpdesk > Tickets > Create
- Configure it so that it corresponds to SLA requirements
- Duplicate the ticket and merge them both (data_merge module required)

Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen:

1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set.

2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well.

3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities.

opw-4037262

Forward-Port-Of: odoo/enterprise#69352

# Context:
A pesky bug has been flying under the radar since at least Odoo 15.0. When passing `email_from=False` to the _find_mail_server, we will always have an early return at: 
https://github.com/odoo/odoo/blob/f05626e14264cf3bb477c86ad82439726d778c8f/odoo/addons/base/models/ir_mail_server.py#L668C1-L676C1


This comes from the fact that we can generate False == False => True comparisons while filtering the `ir.mail.server` records, by :
* `email_from_normalize` is False (since `email_from` was also False) and mail server has no from_filter = > email_normalize(m.from_filter) == email_from_normalized => False == False
* `email_from_domain` is False (since `email_from` was also False)  and mail server has a full email address in the from_filter field => email_domain_normalize(m.from_filter) == email_from_domain => False == False

Both edge-cases leads to the first email server config to always be selected for the SMTP connection, even if a valid mail server exist matching for example the default notification email (i.e. notifications@custom.domain).

This can lead to notification emails failing on DB having multiple outgoing email servers setup, where the SMTP server does sender verification (Outlook, Gmail – you can only send as a specific sender email).
Should impact Odoo versions 15 and later.

# Proposed fix:
We wrap the first checkpoint in an if block with email_from. Logically if email_from is already False, we should skip to the second checkpoint (matching notifications default email) and only later try to fall back to the first `ir.mail.server`  record (while also triggering the warning log).

# How to reproduce:
Any workflow triggering an automatic notification email as Odoobot, while having the `email` field set to `False`.

1) Setup DB with website_sale installed
2) Set `email` field of Odoobot `res.partner` (by default id = 2) to False 
3) Setup at least two outgoing email servers (`ir.mail.server`) with the first having no `from_filter` and the second one matching the default notifications email address (default = notifications@mycompany.example.com) 
4) So to the Ecommerce shop and buy any random product and finalizing the transaction. → Triggered notification email will always be sent by mail server id = 1, even if it should match id = 2 in this case

OPW-4140192


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

Forward-Port-Of: odoo/odoo#181872
Forward-Port-Of: odoo/odoo#178340

# Context:

The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of it's kind to be created.

But in it's current form it fails to accound for grandfathered databases (pre 17.0) or miss confgurations by a user, where we have archived companies attached to `mail.alias` where the `alias_domain_id` field is False.

In such a edge case, it is impossible to create a alias domain record, because during the save (create), the user is faced with a Validation Error produce by the checks in the `_check_alias_domain_id_mc` in the `mail.alias` model.

Example error message:
```
"We could not create alias archived-company-alias@example.com because
domain example.com belongs to company ActiveCompany while the owner
document belongs to company ArchivedCompany."
```

It follow that the user is blocked from setting up an alias domain unless they temporarily unarchive a company.

# Proposed solution:

Assuming that the objective is to initialize all current mail aliases in the DB with the "first" alias domain record to be created, we should force the `company_ids` field in the just created `mail_alias_domain` record to contain ALL companies (active or not).

# Reproduction steps:

One way to reproduce the issue on a fresh DB is:
- install mail
- define a domain alias in the general settings
- create a second company
- install Accounting
- make sure a localization pack is loaded for each company (the idea is to create default sale and purchase accounting journals with their email alias)
- archive second company
- in Technical > Aliases menu, clear alias domain from aliases (set `alias_domain_id` = False)
- delete alias domain
- create a new alias domain

--> Validation Error

OPW-3955936

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

Forward-Port-Of: odoo/odoo#169613

Currently when invoicing through pos, multiple values related to price discounts are incorrect.

Steps to reproduce:
-------------------
* Go to the **Point of sale** app
* Under **Configuration**, select **Settings**
* Enable **Flexible Pricelists**
* Select **Advanced price rules**
* Create a pricelist, 10% discount on all products, visible on the invoice
* Go to the **Products list**
* Select any product and apply a tax (price excl)
* Open shop session
* Select the product with the tax
* Pay and invoice it
> Observation: In some cases the line "Price discounted from" does not appear on the invoice. And when it appears, values are not correct. If you also plied a discount on the product line in addition to the pricelist, values are completely mixed.

Why the fix:
------------
We see that we are curently comparing `line.price_subtotal_incl` with `line.product_id.lst_price * line.qty`.
https://github.com/odoo/odoo/blob/b49159db74cf4c8212a7bd3dfe551eb852df99f3/addons/point_of_sale/models/pos_order.py#L213-L219

To simplify, we consider a quantity of 1.
* `line.price_subtotal_incl` includes discounts (order line discounts and pricelist) and always represent a price with taxes included.
* `line.product_id.lst_price` reprensents the price set on the prodcut form. It does not account for any sort of discount. If the tax applied on the product is tax excl(resp. incl) it will be a price tex excl(resp. incl).

In the case where the pricelist discount is smaller than the tax amount, for products with tax excl, the `line.price_subtotal_incl` will still be greater than `line.product_id.lst_price` and that's why the invoice does not have the line "Price discounted from".

I asked MOBT the behavior expected. For the line "Price discounted from", this should only reflect discounts related to pricelist, and should represent the price tax excl/incl depending on the tax set up on the product page. Line discounts are already reflected on the invoice with `Disc.%`.

We choose to compare two values that reflect the same price tax configuration. We compare `line.product_id.lst_price` with `line.price_unit` as both will be tax excl(resp. incl) if the tax applied on the product is tax excl(resp. incl). We also remove the `line.qty` as both represent a price per qty.

opw-4170357

Forward-Port-Of: odoo/odoo#181674
Forward-Port-Of: odoo/odoo#181007

**Current behavior:**
With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate fashion.

**Expected behavior:**
The price_unit should be accurate.

**Steps to reproduce:**
1. Enable another currency, set an exchange rate on it that is very small (like < 0.01)

2. Enable automatic valuation, create a product with both average costing method and real time valuation on its category, give it some initial cost e.g., 500

3. Create a new purchase order, add a line like: - product_id: from step 2 - quantity: 13 - discount: 1%

4. Set the currency on the purchase order to be the one from step 1, so it is different from the active company's

5. Confirm the purchase order and validate the receipt, look at the SVL generated and note its remaining value

6. Create a bill for the purchase order, post the invoice, then look at the SVL's remaining value again -> it changed

**Cause of the issue:**
The price unit being converted between currencies and rounded causes some discrepancy with the final value, also the calculation for gross price unit on AML model is somewhat primitive.

**Fix:**
Stop rounding base and update the formula used when calculating gross price unit.

opw-4103167

Forward-Port-Of: odoo/odoo#181527

Steps:
---------
- Install the Point of Sale module with demo data.
- Set up online payment provider (e.g. Razorpay) for the Indian company.
- Enable online payment method in Point of sale app configuration
- Add the payment method in Point of sale shop configuration.
- Make a successful online payment in the Point of sale app.

Issue:
---------
- Error occurs after successful payment, preventing the payment from being
  processed and confirmed in POS module and the payment entry from being posted.

Cause:
---------
- Payment transactions status were failing due to company mismatch between the
  partner(admin)'s company and the pos order's company.

FIX:
---------
- If customer is not selected in pos order, we consider the order and payment
  from public user not from the admin user.

Improvement:
---------
- env is not accessible with self in controller for self.env.ref('base.public_user')
  fixed with request.env.ref('base.public_user')
- Unused code removed from `_get_partner_sudo` method

task-3989409

Forward-Port-Of: odoo/odoo#173268