This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature.

Steps to reproduce:

- Install the ``pos_restaurant`` and ``point_of_sale`` modules
- Make sure there are no active orders in the restaurant
- Dashboard > Open Register > Open session > Close Register
- Dashboard > Restaurant > Dropdown Menu > Mobile View
- An Error will be generated in the terminal

Traceback : 
``ValueError: bus.Bus only string channels are allowed.``

This situation arises because we have two self-ordering modes: i) ``Mobile`` and ii) ``kiosk``. When the condition at [1] is evaluated, it will become false because the session has been closed, causing ``pos_config.has_active_session`` to be false. Additionally, since the mode is ``Mobile``, the condition in the ``elif`` statement at [1] also evaluates to false. As a result, we will get the value of ``config_access_token`` as a boolean value from line [2] because the value of ``config_access_token`` will not be set from both of the above conditions. Due to ``config_access_token`` being a boolean value, the value of ``channels`` ends up being a boolean value.

This commit will fix the above error by providing an empty string within ``config_access_token``, rather than boolean values. So, the value of ``channels`` will consistently be a string.

[1]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L35-L47
[2]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L16C8-L23C50

sentry-5136273134

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

Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New').
           However, the data type of the 'name' field is character and translate = False.
           Additionally, the default value for the 'name' field is set to 'New', causing
           this condition to evaluate to false and consequently terminating the execution
           of the if block.

    Solution: To address this, we propose changing the condition to vals['name'] == 'New'
              to ensure correct comparison. This modification is warranted due to the
              [configuration](https://github.com/odoo/odoo/blob/89fbb75659ba71b8c76dddd62ba331966161f59b/addons/repair/models/repair.py#L31)
              of the field:

              The field is not translatable.
              The field is required and set to readonly true, preventing customers from inputting values.
              The default value for the field is set to 'New'.

    Before:
           Unable to obtain the auto-generated sequence (receiving default value 'New').

    After:
          The sequence is generated automatically.

    OPW-3887638

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

Forward-Port-Of: odoo/odoo#165771

The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location.
But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue.

How to reproduce:
- Inventory -> Settings -> Enable "Multi-Step Routes";
- Go to your warehouse and choose 3 steps for incoming and/or outgoing shipments;
- Go to the Barcode App > Operations > Internal Transfers > New;
- In the newly created transfer, try to scan who is not a sublocation of WH/Stock (WH/input for example, barcode: WH-INPUT)
  - :arrow_right:  An error message is displayed because you are not allowed to scan this location.

The exact same issue happens for destination too since 61d378b0a49ba734cff84a39aa2693fe4226225d.

Also, fix a minor unrelated bug where locations on the barcode line are
not correctly written when there name include the picking's defaut
location's name (eg.: WH/Stock 2 when the default location is WH/Stock.)

[OPW-3843358](https://www.odoo.com/web#id=3843358&cids=1&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#63058
Forward-Port-Of: odoo/enterprise#62480

Steps to reproduce:
- Install `stock_barcode`
- Create two product "aaa" and "bbb" with both of them being tracked by
  lots with the same lot number "123"
- Open the Inventory app and go to Configuration > Operation Types >
  Delivery Orders
- Enable Product in the Barcode App
- Go to the barcode app > Operations > Delivery Orders and click on New
- Scan 123
- Scan aaa (or bbb it probably depends on order of creation of product)
- Scan 123

Issues:
bbb has been added even though we never scanned it.

The reason for this bug is that when we scan 123 we don't have it in the
cache as such we make an RPC and store 123 in `missCache`.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L184-L185

After this when we scan aaa we retrieve the record, and add the line as
intended. The problem arise when we scan 123, since it's already in our
cache.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L130

However that record is not right since this lot is linked to the wrong
product bbb.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L135-L138

We will try to retrieve again the right record, however we will once
again get a hit on the cache. As such no RPC call will be made to
retrieve the lot we're looking for.

We will go in the function once again, where we will have the same
problem this time in the `if (model)` condition.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L112-L115

Later in the execution we will get to this line where we call the
function without a filters which will allow the wrong record to be
added.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/models/barcode_model.js#L943

The root of this problem lies in the way we set the key to the cache,
since two product can share the same barcode we need a more precise
cache key to differentiate them.

The proposed solutions is to cache result based on the provided
arguments to the function. This means fewer hit if we retrieve the same
record with different filter for example, however it's safer as when we
hit we are sure to get the right record.

opw-3862263

Forward-Port-Of: odoo/enterprise#63094
Forward-Port-Of: odoo/enterprise#61844

Steps to reproduce the bug:

- In Website edit mode.
- Drop 2 "Columns" snippets.
- Hide one of the columns in the first snippet by clicking on the "Hide
on desktop" button of the "Column" options in the side panel.
- Start to drag another snippet.
- Bug: There is no dropzone between the 2 "Column" snippets.

The issue happens because when the column becomes invisible, after
clicking the button, the attribute `data-invisible="1"` is added to the
column in the DOM thanks the 'snippet_option_visibility_update' event.

However, this event then propagates to the column's parent elements
(`<section>` and `<main>`). So, the attribute `data-invisible="1"` is also
added to the `<section>`, causing the dropzone not to be inserted as
expected. We should investigate this further later because it doesn't
seem consistent. For now, we prefer not to make changes at this level to
avoid introducing other bugs.

In this commit, we change the selector that determines where not to
insert dropzones so that it no longer considers `data-invisible="1"`.
This was added by this commit [1], but it seems unnecessary, and
':not(:visible)' in the selector is sufficient to avoid placing
dropzones between two non-visible elements.

[1]: https://github.com/odoo/odoo/commit/f9bd3033b21dbd1e4487d6d6cd1d8d8fdfbfb2ac

Forward-Port-Of: odoo/odoo#165797

## Issue:

- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.

## Steps To Reproduce:

- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.

In an other scenario:

- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.

## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:

    `if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`

- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.

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

Forward-Port-Of: odoo/odoo#165832
Forward-Port-Of: odoo/odoo#161704

### Issue:

Trying to validate a wave transfer with an empty picking will raise and error.

### Expected behavior:

The empty picking  should be removed from the wave transfer and the rest of the operations should be validated.

### Steps to reproduce:

- In the settings: enable Batch Transfers > Wave Transfers
- Create 2 receipts: 
    1) 1 x product P1 
    2) 1 x product P2
- In the inventory overview, click on the dots of receipts > operations
- Select your receipts > Add to wave >  Create new wave transfer
- Go to inventory > Operations > Transfers > Wave transfers
- Open your wave transfer  and set the quantity of P1 to 0

### Cause of the issue:

Currently, only the empty pickings 'waiting for another operation' are removed from the batch when it is validated:
https://github.com/odoo/odoo/blob/3cfe548ee03f96713c7a6d462409be9c825d22e7/addons/stock_picking_batch/models/stock_picking_batch.py#L201-L204 
In particlar, other empty pickings will not pass the sanity check: https://github.com/odoo/odoo/blob/3cfe548ee03f96713c7a6d462409be9c825d22e7/addons/stock_picking_batch/models/stock_picking_batch.py#L217-L218 and an operation error will be raised for them.

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

Forward-Port-Of: odoo/odoo#163320

Steps to reproduce:
> The Company Currency is the Dollar
> Create a product > Set FIFO and Manual valuation
> Set BIlling policy as Ordered Quantities
> Create Purchase order in Euro
> Create Vendor bill in USD (10 $)
> Now Receive the quantities
> Check the valuation
> Wrong value (15.92 $)
the value should be 10$ (taken from the bill)

Bug:
In the case of BIlling policy on Ordered Quantities and PO in a foreign
currency we assume the bill will be in same currency as the PO

Fix:
currently unit price is first computed in PO currency and then converted
in the end to company currency added conversion from bill to PO
opw-[3805454](https://www.odoo.com/web#id=3805454&view_type=form&model=project.task)

also fixed a rounding issue opw-[3773413](https://www.odoo.com/web#id=3773413&view_type=form&model=project.task)

alternative fix:
compute everything in company currency (https://github.com/odoo/odoo/pull/155937)

Forward-Port-Of: odoo/odoo#166346
Forward-Port-Of: odoo/odoo#162827