## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
    - *Subscriptions* checked
    - *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
    - Any Customer
    - Any plan
    - Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**

## Causes

In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":

https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62

This is the case of upsells, as explained here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

---

Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.

https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78

In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.

| Upsell | Invoiced based on delivered quantities | last_invoiced_date      |
|--------|----------------------------------------|-------------------------|
| True   | True                                   | today + 1 month         |
| False  | True                                   | today                   |
| True   | False                                  | today + 1 month - 1 day |
| False  | False                                  | today + 1 month - 1 day |

An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.

---

opw-5500585

Forward-Port-Of: odoo/enterprise#108967
Forward-Port-Of: odoo/enterprise#107967

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix archive the revoked portal user (keeping its previous non-public groups), to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

*Reapply the reverted fix properly to avoid template issues and blocking flows (https://github.com/odoo/odoo/pull/239477 and https://github.com/odoo/odoo/pull/236462)*

opw-4760550

Forward-Port-Of: odoo/odoo#250505
Forward-Port-Of: odoo/odoo#243056

This commit improves the new field service integration and fixes some
mistakes made during the merge of Field Service app inside Planning app.

In this commit,
- the new format duration has been used for allocated hours and break time
  fields in planning,
- some planning.slot fields are hidden in the form view when field service
  integration is enabled to reduce the number of fields inside that view
  since those fields were more useful for a planning manager to prepare
  the intervention of his workers,
- some access right errors are fixed,
- the planning user can no longer edit access once field,
  service integration is disabled,
- field service geolocation service has been re-introduced since it was
  removed when the timer in timesheets has been reviewed,
- some terms are now correctly translated,
- `planning_field_service` module is flagged as an application,
- `Products` menu item has been added in planning field service,
- map and activity views has been been added in all planning menu items
  when field service is enabled.

task-5921961

Co-authored-by: Maxime de Neuville (mane) <mane@odoo.com>