## Issue:
- A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period, receiving the error: 'Timesheets before [PERIOD] are validated and cannot be modified.'

## Steps To Reproduce:
- Edit `Create on Order` of the `Service on Timesheets` product to be `Project & Task`.
- in settings:
        - enable the `Lock Timesheets` option.
        - set the invoicing policy for Timesheets to `validated timesheets only` .
        - set the invoicing policy for Sales to 'invoice what is delivered'.
- ​Update the timesheet access for `Marc Demo` and set it as 'User: all timesheets'.
- Create a SO with `Service on Timesheets` as a product.
- On the related Task create a timesheet for period 01 May to 31 May and validate it.
- With Marc Demo click on Create an Invoice on the SO, for the same period notice The Access Error.

## Solution:
- in `check_if_allowed` I modified the condition to check if the current user is not a superuser.

opw-3965532

Forward-Port-Of: odoo/enterprise#66607
Forward-Port-Of: odoo/enterprise#65435

Using distinct websockets (ws) per company cause a lot of diffent issues, for example:

## Issue this PR solve:
### Multi-company:
Assume we have an IoT with no company set. In this case, it should be able to print from any company.
In practice, it is not the case as the IoT will listen to the channel of the first company, so it will always fail if the user company is not the first one.

Same goes if we have child companies, if C2 is a child company of C1, then C2 should be able to print too. With current code it is not the case as C1 and C2 will have distincts channels

### Change of IoT company:
When the IoT start, it makes a call to know its channel (see iot/setup route).
However, if we change the company set on the IoT, it should change its channel to match the one of newly set company. In practice it is not the case and will only happen on the next iot/setup call (which happen each 3 seconds call in theory IF new devices are detected)

### Simplicity
Help simplifying the code as it was sometime complicated to be get the right websocket.

For example, when the IoT reply back that the operation completed, see `/iot/printer/status` route. Relying on the IoT device company might be wrong as if no company is set, we don't know the company that the user who did the request is, so we might send on the bus on the wrong channel.
In this case, the document did print but the pop-up will still pop

### Visibility
The iot.channel had no practical way to be browsed as there is no view defined for this model. The only feasible way to get its data for a functional would be to run a server action or create a view.

Using a system parameter is more practical and only accessible for admin users


## Downside of this PR:
- system parameter could be modified manually
- websocket send/receive more messages
- stability: to ease the transition, I tried to get the existing ws channel using basic heuristics, but it might be wrong (if a company other than the first is set on the IoT).
In the worst case, they will have to restart their IoT to get the new channel

opw-4038176

Forward-Port-Of: odoo/enterprise#66573

### Steps to reproduce:

- Create 2 storable product
- Update the on hand quantity to 100 only for the first one
- Create an confirm an SO 75 units of each
- Set the done qty to 50 on both moves and create a backorder
- Print delivery slip for the original picking
#### > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75).

### Cause of the issue:

If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_ordered` will not be updated by these lines:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L785-L791 Furthermore, since they are not cancelled, they are filtered out here and hence do not update the `qty_ordered` by these lines either: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L813-L816 https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831

### Fix:

We modify the filter meant for empty move lines so that moves that are not confirmed and are not associated to any `move_line` contribute to the `qty_ordered` via these:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 However, since we do not want a move that is fully backordered to appear on the delivery slip we need to filter out all the line keys that will be created, because they pass our new filtering condition (but didn't pass the old one), here:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L819-L821

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

Forward-Port-Of: odoo/odoo#176196
Forward-Port-Of: odoo/odoo#175113

### Issue:

Changing the reservation method of a picking type on a large DB might result in a memory error invalidating the requested change.

### Cause of the issue:

The dependency `picking_type_id.reservation_method` was introduced on the `_compute_reservation_date` method of stock moves by commit c4023d7. This dependency was introduced to remove the reservation date on all moves whose picking type reservation method is no more "date". Because of this new dependency, if one change the `reservation_method` of a picking type say manufacturing, it will fetch and "recompute" the `reservation_date` of all stock.moves whose picking type is manufacting. The ORM will handle these records 1000 by 1000 but if you happen to have a million records of that picking type (which is the case of the customer) all of these records will be added to the cache during the `_fetch_query`. This will lead to a Memory error since the cache is not cleared after a certain amount of computed records during the `_compute_reservation_date`.

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

Forward-Port-Of: odoo/odoo#175873

### Steps to reproduce:
	- Install eCommerce module
	- Go to Website > Cart
	- Click on Edit > Customize > Extra Info
	- Go to Website settings and Check 'Extra Step During Checkout'

### Current behavior before PR:
The 'Extra Step During checkout' setting is not synchronized when turning on and off from website editor or from website settings. This actually leads sometimes that you might turn it on from website settings and it won't be visible in the checkout process. This is happening because in the 'res.config.settings' we are dealing with 'ir.ui.view' that is not linked to any website but in the website editor we are dealing with 'ir.ui.view' that is linked to the website you are editing.
https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/res_config_settings.py#L68 https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/website.py#L588

### Desired behavior after PR is merged:
When turning on/off the setting from the website settings now we are dealing with the 'ir.ui.view' that is linked to a website. So the setting is now website dependant.

opw-3992571

Forward-Port-Of: odoo/odoo#175929
Forward-Port-Of: odoo/odoo#170639

When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up with negative untaxed amount on the invoice.

Steps to reproduce:
-------------------
* Create 2 taxes, A and B with 5% and 10%
* Create 2 products, A and B. Assign the 2 taxes to the products
* Create a sale order with the 2 products
* Open the sale order in PoS and make a downpayment for it
> Observation: There is only one downpayment line when it should have 2.

Why the fix:
------------
If you do the same flow in the sales app, you get 2 downpayment lines. We do this to allign the behavior in sales and PoS. For each unique tax combination we compute what part of the total downpayment should be assigned to it. Then we make sure that the taxes are assigned to the line and that the line has the right value.

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

Forward-Port-Of: odoo/odoo#174358
Forward-Port-Of: odoo/odoo#174076

Current behaviour:
---
When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback.

Steps to reproduce:
---
1. Install CRM
2. Go to the Pipeline
3. Open any lead
4. Click on Actions > Add properties
5. Input anything as value, then save
6. Make a xmlrpc call to retrieve leads (see below)
7. Traceback

`models.execute_kw(db, uid, password, 'crm.lead', 'search_read', [])`

Cause of the issue:
---
Feature introduction: https://github.com/odoo/odoo/commit/87307a9010c6c872fe6c746d5ece378ad90d038f 
Change from `None` to `False`: https://github.com/odoo/odoo/commit/608bffff59c9444f59a282dbdc43c207704223cc 
Issue caused by: https://github.com/odoo/odoo/commit/da48700b59da49cdc810eac31a8617fcaa0dc2a8 
(Due to the modification of `convert_to_read_multi`)

When adding `PropertiesDefinition` to an existing record, it doesn't go through 
`_add_default_values` again, thus making `None` not being replaced by `False`.
https://github.com/odoo/odoo/blob/cd9c69bd7d9b21e6220a49f88f22160de33c5e06/odoo/fields.py#L3616

opw-3940841

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

Forward-Port-Of: odoo/odoo#172689

When scrapping a kit, it leads to incorrect behaviours

**Case 01:**
1. Create a storable kit with one storable component
2. Validate a scrap order with that kit
3. Open the product moves

Error: we moved the kit instead of its component

We first create a draft SM with its SML:
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L145
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L112

During the SML creation, we check if we should recompute the state
of the SM:
https://github.com/odoo/odoo/blob/dc0917d2a55a12e5c30d413a46e2c16190fd8a08/addons/stock/models/stock_move_line.py#L344-L355
`reservation` is `True`, the SML has a quantity -> we recompute the
state of the SM -> it is now assigned
Back to the scrap, we now `_action_done` the kit SM
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L147
which leads to
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1827-L1830
Here is the problem: the SM has a demand, its state is not draft
-> we don't confirm it
-> we don't explode it
Hence the error. This is the reason why the commit stops providing
the scrap SM with an initial demand. That way, we will explode the
SM and everything will work as expected

**Case 02:**
1. Create a consumable kit with one storable component
2. Validate a scrap order with that kit

Error: a server error is raised "Missing record [...]"

This time, `reservation` is `False` (the diff comes from the kit
type, consu vs stor, c.f. `_should_bypass_reservation`). Therefore,
we explode it. Since we are in scrap mode, we generate SM with a
zero demand:
https://github.com/odoo/odoo/blob/68f981d2a690addf0b70ddab498b556986752e49/addons/mrp/models/stock_move.py#L464-L466
https://github.com/odoo/odoo/blob/68f981d2a690addf0b70ddab498b556986752e49/addons/mrp/models/stock_move.py#L527
Back to `_action_done`, we create the extra moves if needed:
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1847-L1853
Here, our component SM has a done qty greater than its demand
(reminder: it demand is zero), so we will create the extra move,
confirm it and merge it with the initial one:
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1799-L1802
Buuuuut... Step 2 in the use case, we validate the scrap order.
Since we don't have such product on hand, we trigger a wizard with
some default values:
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L204-L219
And... Now you see where I'm going: when we create the extra move,
we still have these default values in the context -> the extra move
has a demand and(!) a done qty to 1. We merge it with the initial
move: we are now scrapping a component with a demand equal to one
and a done qty equal to 2. It will later lead to other
inconsistencies (among them, the server error raised)

opw-4090951

Forward-Port-Of: odoo/odoo#176186