The COGS registered was wrong when invoicing a product that is a kit
with UOM A and component uses UOM B.

Steps to reproduce:
-------------------
* Create Comp A with UOM Dozens. It's cost should be 12000
* Create Product A with UOM Units.
* Make sure both use the same category, and the category should use
  automcatic inventory valuation.
* Create a kit bom for product A that contains 1 comp A.
* Sell this kit in the PoS and invoice it.
* Close the PoS and go to the order then on the invoice.
* Check the journal items

> Observation: the COGS is 12000 it's wrong. It should be
  1000

Why the fix:
------------
The `_get_pos_anglo_saxon_price_unit` is not taking the product uom into
account. So in this example the price unit will be for a dozen, but the
bom specifies that we are using a unit and not a dozen. So the quantity
needs to be modified from a dozen to unit. That's what the 
`_compute_price` method is doing.


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

Forward-Port-Of: odoo/odoo#170267
Forward-Port-Of: odoo/odoo#166382

Description of the Issue/Feature Addressed by This PR:

This pull request addresses translation issues related to a string defined in JavaScript code. Previously, the string was incorrectly formatted, making it unlocatable for the translation files. The proposed solution ensures that Odoo can now accurately translate the string.

Current Behavior Before PR:
In the point of sale, when attempting to close a session with a closing difference exceeding the maximum, a popup displays two sentences. Unfortunately, these sentences couldn’t be translated due to an improperly formatted string in the JavaScript. The translation files were unable to identify the string.

Desired Behavior After PR Is Merged: 
The corrected string enables Odoo to perform accurate translations. The change has been implemented following an example from another well-formed string in the code.
![image](https://github.com/odoo/odoo/assets/98310877/2964d042-f295-4ae7-a674-07bea860d81a)

Now the text displayed in the pop up will be translated without problems.
![Captura desde 2024-04-03 11-56-12](https://github.com/odoo/odoo/assets/98310877/4d22a04e-b34a-4278-863a-13f9e1a23e2e)


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

Forward-Port-Of: odoo/odoo#168952
Forward-Port-Of: odoo/odoo#160303

### Steps to reproduce:

- Enable Batch Transfers in the settings
- Go to Inventory > Config> Warehouse Management > Operation Types
- On  receipts, enable "Automatic Batches" group by contact
- Create and confirm a purchase order for any contact with:
  - 1 X storable product P1
- Create and confirm a purchase order for the same contact with:
  - 1 X storable product P1
  - 1 x storable product P2
- Go to the assocated stock picking > change the quantity of P1 to 0
- Validate and create a backorder

#### > invalid operation: The following transfers cannot be added to batch

### Cause of the issue:

When the backorder is processed, the stock picking that currently belongs to our batch is validated and a backorder is created: https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock/models/stock_move.py#L1891-L1892 The picking associated to this backorder is then added to our batch https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking.py#L160-L162 But for this action to be performed, we need to pass the sanity check verifying that the pickings associated to our batch are allowed: https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking_batch.py#L282-L286 And here comes the problem, the picking that created the backorder was not yet removed from our batch but is not allowed anymore since it is now in 'done' state:
https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking_batch.py#L76-L77

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

Forward-Port-Of: odoo/odoo#163935

### Steps to reproduce:

- Create a product SP tracked by lots
- Click on "on hand" and create a lot with 10 units on hand
- Create and validate picking for 1 x any other product
- Unlock the delivery
- Add a line (stock move) for 1 x SP
- Click on the list icon of the line and set your lot
- Save the picking
- Go to the on hand quantity of SP

#### > 1 unit was reserved even though the move is 'done'

### Cause of the issue:

Creating the stock move line associating the lot to the stock move will update the reserved quantity of stock quants independently of the state of the move created:
https://github.com/odoo/odoo/blob/347c7e21002313da155ebf872853078de23b38fe/addons/stock/models/stock_move_line.py#L337-L343 https://github.com/odoo/odoo/blob/347c7e21002313da155ebf872853078de23b38fe/addons/stock/models/stock_move.py#L1525-L1528

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

Forward-Port-Of: odoo/odoo#170304
Forward-Port-Of: odoo/odoo#166186

Currently when applying a coupon for 10% on the order on the current order, the points awarded are 100% of the points instead of 90%. The loyalty program rewarding x points per $ spent.

The same behavior is also observed in the sale worflow.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Open shop session
* Select a customer
* Add a product (ex. Office chair 70$)
* Select **Enter Code**
* Enter the code `10pc`
> Observation: The order will grant 700 points instead of 630. The amount paid is 63$ with the code for 10% on the order.

Settings of the **Discount & Loyalties**:
* **Code for 10% on orders**
  * Rule: 
    * `Among` -> no restriction set 
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0
  * Reward:
    * `Discount`: 10% `on` order
* **Loyalty Program**
  * `Use points on`: Current & Future orders
  * Rule:
    * `Among` -> no restriction set
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0 
    * `Grant` 10 loyalty poins per $ spent

Idea of the fix
---------------
As discussed with DALA, discount should count toward points awarded. Here is how it should apply:
* If program_rule has no domain, all lines should count (except ewallet & gift cards)
* If program_rule has a domain, we should use all the lines where the product matches the domain (except ewallet & gift cards)

This applies for the computation of points based on the money spent.

Why the fix:
------------
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L917

Sale-wise, we replace `rule_products` with `so_products_per_rule.get(rule, [])`. We also replace `order_lines` by `lines_per_rule`.
* `rule_products` don't include discounts as they are computed on `order_lines` (all lines that are not reward lines). https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L834-L841 https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L889
* `so_products_per_rule` will include the discounts if they match with the program's domain.
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L844
* We don't need to exclude the free product reward lines from `lines_for_points` as the price is 0 on the SO. Shipping lines and free shipping rewards are not counted.

In pos, the fix is a bit different.

https://github.com/odoo/odoo/blob/4b9dee8fbe9aefde798c8543fef89c661cc85c57/addons/pos_loyalty/static/src/js/Loyalty.js#L908-L914

We first notice that this piece of code is never triggered as the structure of `program.id` is a number and `reward.program_id` is the following thus the last if statement is never true. A `.id` is added.
```
Proxy(Object) {id: 1, name: 'Code for 10% on orders', trigger: 'with_code', applies_on: 'current', program_type: 'promo_code', …}
```

This now means that we only count reward lines if they are from the same program. 

With the following if statement, it means that only the lines that are not reward lines are counted (which excludes discounts).

https://github.com/odoo/odoo/blob/eadfa4ee290a8b62956097aa66989eacff230275/addons/pos_loyalty/static/src/js/Loyalty.js#L921-L924

We conclude that those two ifs must be changed as we want a similar behavior as the workflow in sales.

We remove `orderedProductPaid` out of the if statement since it can be impacted by reward lines. We change the first if to excludes the reward lines only from the current program or from ewallet and giftcards. With this, `orderedProductPaid` now counts the discount lines from other program. (Similar to sales, where `amount_paid` is computed with `lines_per_rule`)

`totalProductQty` still applies only on non reward lines. (Same as sales)

opw-3858286

Forward-Port-Of: odoo/odoo#170391
Forward-Port-Of: odoo/odoo#164723

**[IMP] website: match navbar toggler color to overlay header text color**

Before this commit, the navbar hamburger button didn't have the same
color as the text color defined for the "Over The Content" header, which
led to situations where it wasn't visible.

Steps to reproduce:

- Go to the website edit mode.
- Click on the header and choose "Over The Content" for the "Header
Position" option.
- Use the color picker to set the "Text Color" option to white.
- Drag and drop a "Text-Image" snippet onto the page.
- Apply a dark background color to the "Text-Image" snippet.
- Click on the "Mobile Preview" button.
=> The navbar hamburger button is not visible in the header.

After this commit, the navbar hamburger button in the "Over The Content"
header matches the color of the header's text.

task-3853573

---------------------------------
**[FIX] website: hide the overlay on the mobile menu navbar toggler**

Before this commit, after clicking on the mobile menu navbar toggler in
Website edit mode, the blue overlay was covering the button.

This commit fixes this. Indeed, this element is not editable, so there's
no need for an overlay on it.

task-3853573

Forward-Port-Of: odoo/odoo#163139