When on the main menu, `/odoo?cids=1`, if you activate the debug assets,
the router will push a new key (debug) into the query string :
`/odoo?cids=1&debug=assets`. To fully activate the debug, a reload will
be done. After the reload, the action service will push the new loaded
state (the menu), taking into account the locked keys (in this case:
`cid` and `debug`), which will inverse the order of the query string :
`/odoo?debug=assets&cids=1`.

This occurs because, the order of the keys on the query string will
depend on: the push order; if the keys are locked keys or not; and of
the kind of push state (replacement or simple push state). The issue
with this almost "random" order of the keys, is that the router could
push the same URL (with keys in different order) multiple times into the
browser history.

Before this commit, to compare the actual URL with the new one, we just
compare the two strings, and if the order of the query strings are not
the same the URLs are considered as different.

This commit, will avoid this issue by deep comparing the query string as
objects, so when just a difference of order exists in the query string,
they will be considered as the same URL.

opw-3557575

Forward-Port-Of: odoo/odoo#175837

Purpose
=======
Fix the height of the mail templates in the mailing form.

Specification
=============
For small templates / theme selector, there is a blank space below the editor
because the iframe's height is matching the full height of the website snippets on the side.
For big templates, the website snippets doesn't follow the template scrolling which
makes it difficult to drag and drop the snippets.

This happens following the removal of the full width view and a related js file which
was previously resizing the editor height accordingly (ref commit: https://github.com/odoo/odoo/commit/cf6cd5ef46287f4e71fe96ad6b404ba9b08c1066 )

Reverting a part of the old "mailing_mailing_view_form_full_width" file into
the "mass_mailing_html_field" one so that the editor iframe is correctly resized
depending on its content and the editor sidebar is correctly resized to follow
the scrolling behavior.
Concretely, introducting back the resize observer and the "_updateIframe", "_isFullScreen",
"_resizeMailingEditorIframe" and "_repositionMailingEditorSidebar" methods.

Task-4086341

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

Forward-Port-Of: odoo/odoo#170901

### Steps to reproduce:

- Enable Multi-Step Routes and Batch Transfers in the settings
- Inventory > Configuration > Warehouse Management > Operation Types
- Click on internal transfer: Enable Auomatic batches group by dest
- Create a internal transfer with two moves: 1 x screw and 1 x bolt
- Mark the transfer as Todo, duplicate it and `mark as Todo`
> the two transfers should be added to a batch
- In the barcode app, batch transfers, go on your batch
- Add a single screw and validate
> A pop up appears to tell you that the rest will be backordered
- Validate

### Bug:

Instead of being redirected to the barcode app, you are left on the old version of the batch. If you go back the barcode app you will see that your old batch is actually empty (0 lines) and its state is "in progress" instead of being done. If you click on the the empty batch you get a traceback since its picking_type is nowhere to be found by owl

### Cause of the issue:

When you added your screw via the barcode app, you marked the move of the picking as picked. When you validated the batch, you are going to mark this move as done and to back order its picking since only part of it was completed. However, since one of its move is 'done' and the other one is 'assigned', its state will not be done and the picking to backorder will be removed from the original batch y these lines: https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 It would make sense if the the other pickings were to stay in the batch, which is what the "any" part of the if condition is trying to check. However the other picking of the batch is going to be removed later by these lines (since none of its move are picked so that it is considered to be empty):
https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking_batch.py#L233-L234 https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L120-L121 This is the cause of all the issues since the old batch is now emptied from all of its picking so that its state will stay in progress and its picking_type_id can't be found from its pickings.

### Expected behavior:

The part of the picking that was marked as done should have stayed in the old batch.

### Fix:

The any part of this if condition should take into account the pickings that are going to be detached from the batch.
https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144

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

Forward-Port-Of: odoo/odoo#176384
Forward-Port-Of: odoo/odoo#176121

Issue 1:
---

### Steps to reproduce:

- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
  COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
    - 1 x COMP 1 consumed in op 1
    - 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.
**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**

As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P

### Cause of the issue:

When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").

Issue 2
---
### Steps to reproduce:

- Enable Multi-Step routes in the settings
- Go Inventory >  Configuration > Warehouse Management > Warehouses
- Enable 2-step manufacturing on your Warehouse
- Create 2 storable products:
    - product P: tracked by SN
    - product COMP: tracked by lot
- Update the "on hand qty" of COMP by creating a lot with 10 units
- Create and confirm a manufacturing order for 1 unit of P
- Assign a serial number to the final product
- Validate the transfer of components from stock to preproduction (The lot is automatically used on this transfer as it is available)

### Expected behavior:

Since the lot of COMP was used in the transfer from stock to preproduction it should be displayed on the raw move of the MO.

### Current behavior:

The raw move is not updated.

Note: if the transfer is validated before we assign a serial number to the final product, the lot of the component is correctly updated.

### Cause of the issue:

When the 'action_generate_serial' is triggered in order to assign a SN to the final product P, the '_set_qty_producing' is called in order adapt the quantities of the MO (produce only one unit and consume accordingly):
https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1397-L1398
https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1215-L1231
Now, changing the quantity of the stock move of the component to a positive quantity will trigger the inverse method '_set_quantity' of that field to adapt reservation by creating a stock.move.line. Therefore, validating the transfer of components from stock to pre-production will not update the lot of components on the raw move because the computed need will be at 0 here:
https://github.com/odoo/odoo/blob/3097ea49705a1b6319be9677152d65ebe3ce515b/addons/stock/models/stock_move.py#L1689-L1697
and the '_update_reserved_quantity' call will therefore be empty.

Issue 1: opw-3887580 and opw-3863572

Issue 2: opw-3925894

Enterprise: https://github.com/odoo/enterprise/pull/63912
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#175050
Forward-Port-Of: odoo/odoo#168205

## 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#68250
Forward-Port-Of: odoo/enterprise#65435

Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same link to this folder but from the Company B rights point of view, and since this folder is not accesible from this company it will throw a traceback and break the page until refresh to another url.

Steps to reproduce:

1. Install Documents.
2. Have atleast 2 companies.
3. Create a new folder that belongs to the current company.
4. While having this folder selected, change to the 2nd company.

Solution:

The issue is triggered within the load funcion for the DocumentsSearchModel, since we get the folderId that's in the url, and we also get the list of the folder we have access to, we could filter out if the current folder we are trying to access is within this list before calling toggleCategoryValue, and If it's not we could just call it on `folderId = false;` as default (which is the "All" section of folders). This way we avoid calling `category.values.get(...)` later on for undefined (we don't have access to this folder).

opw-3971935

Forward-Port-Of: odoo/enterprise#68377
Forward-Port-Of: odoo/enterprise#64513

#### [FIX] stock_barcode: restrict product scan pckging
> #### How to reproduce:
> - Create a product with a product packaging and set a barcode for this packaging;
> - In the Receipts operation type config, check the product mandatory scan;
> - Create and confirm a receipt for the created product;
> - Open the receipt in the Barcode app;
> - Scan the product's packaging => A notification asks you to scan the product first.
> 
> This behavior is not right, a packaging should be a valid scan too for product's mandatory scan.
> 
> [OPW-4062460](https://www.odoo.com/odoo/project/49/tasks/4062460?cids=1)

### [FIX] stock_barcode: GS1 packaging with lot
> #### Steps to reproduce:
> - In Inventory settings, choose GS1 as barcode nomenclature and activate packages;
> - Create a storable product tracked by lot;
> - Create a lot for this product (e.g.: 12345);
> - Create a second storable product tracked by lot;
> - Create a new lot with the same name (12345) and a packaging on the product page with the barcode number 10000000240489;
> - Go back to the barcode app and create a new delivery;
> - San the barcode 01100000002404891012345
>   => The line is added for the right product but the lot is missing.
> 
> #### What happens:
> When the GS1 barcode is parsed, we got a lot name and a packaging barcode, thus, we will search a lot for the scanned lot name.
> To avoid fetching the wrong lot in case multiple lots have the same name (but different product), we give a filter when the lot is scanned alongside a product.
> The issue here is we didn't scan a product but a packaging and we forgot to give the same filter in this case.
> 
> [OPW-3894500](https://www.odoo.com/odoo/project/49/tasks/3894500?cids=1)


### [FIX] stock_barcode_picking_batch: reserved lot
> Bug introduced by: https://github.com/odoo/enterprise/pull/63908
> 
> #### How to reproduce:
> - Create a product tracked by lot;
> - For this product, add some quantity in stock for at least two different lots;
> - Create a delivery for this product, with enough quantity to reserve at least two different lots;
> - Confirm it and add it into a batch;
> - Open this batch in the Barcode app;
> - You should have a button to display reserved lots on the product line, click on it, it will display the reserved lot AND select the first one;
> - Scan a reserved lot other than the first one => The first one will be replaced by the scannned lot even if there is already another line with this lot.
> 
> [OPW-4017945](https://www.odoo.com/odoo/project/49/tasks/4017945?cids=1)

Forward-Port-Of: odoo/enterprise#68313
Forward-Port-Of: odoo/enterprise#67267

### Steps to reproduce:

- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
  COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
    - 1 x COMP 1 consumed in op 1
    - 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.

**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**

As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P

### Cause of the issue:

When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").

Community: https://github.com/odoo/odoo/pull/168205

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

Forward-Port-Of: odoo/enterprise#68011
Forward-Port-Of: odoo/enterprise#63912