### Steps to reproduce:

- Enable multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Operations types
- Click on Manufacturing and put "Always" on create a backorder
- Create a product P (no need for a bom)
- Create and confirm a manufacturing order for 2 units of the product
- Go to the barcode module > operations > manufacturing > the MO
- Register only one unit of P and produce

#### > A backorder is automatically created but you are redirected to the backend.

Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module.

### Cause of the issue:

The `validate` method called by clicking will execute the action if the orm call returns one and adds an 'onClose' call to its options: https://github.com/odoo/enterprise/blob/661fd61c0f50d4bf80484227c92a3fd0b9a05c68/stock_barcode/static/src/models/barcode_model.js#L475-L482 https://github.com/odoo/enterprise/blob/661fd61c0f50d4bf80484227c92a3fd0b9a05c68/stock_barcode/static/src/models/barcode_model.js#L487-L492 If the action is a popup, the onClose method will be called once the pop up is resolved. However, if the action redirects you directly to the form view of the mrp.propduction the onClose method will not be triggered and you will not be redirected to the kanban view.

### Fix:

As pop ups are the only actions that we really want to trigger during the validate call we exclude actions from the base models (stock.picking and mrp.production) to avoid any redirection to the backend.

#### Follow up of commit 6915741

## opw-3890886

Forward-Port-Of: odoo/enterprise#64850

## Steps to reproduce:
- Install **Timesheets** and **payroll** apps.
- Create a copy of the (**Standard 40 hours/week**) working schedule but remove **Wednesday** working hours.
- Create a new **employee**, and set his Working Hours to the newly created working schedule.
- Create a new **_running_** **contract** for the newly created employee with the newly created working schedule.
- Go to **Timesheets** app, and search for the newly created employee.
- **Add a line** for a project and register 8 hours in each day from Monday to Saturday.
- Switch the view to Day, Notice how for both Wednesday and Saturday, no overtime is shown. +08:00 should be shown for each as both are non-working days per the newly created working schedule. **(Issue 2)**

## Investigation:
- The overtime text comes from https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.xml#L8 using `overtimeIndication()` getter https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.js#L34
- For the off days - (Wed, Sat, Sun) in our example -, the `allocated_hours` (`this.props.allocated_hours`) = ZERO
- And so `shouldShowHours()` returns `false` https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.js#L19-L21
- which makes `overtimeIndication()` returns null. That's why no overtime text is shown for off-days
- Note that `allocated_hours` is `undefined` for rows that represent employee hours of the current week

opw-3718279

Forward-Port-Of: odoo/enterprise#63526
Forward-Port-Of: odoo/enterprise#60048

When posting a big invoice (>800 lines) for products that are valuated in real_time, the `_post` override in
`purchase_stock` can become a bottleneck for anglo-saxon companies. This method calls `_stock_account_anglo_saxon_reconcile_valuation` which performs reconciliations for all the invoice_lines.

Thanks to odoo/odoo#113680 it's now possible to batch the reconciliation process via the backend method `_reconcile_plan`. This gives various speedups by batching create, reducing the number of flush, etc.

Moving the reconciliation process outside of the loops in `_stock_account_anglo_saxon_reconcile_valuation` and calling `_reconcile_plan` only at the end of the method gives a significant speedup for big invoices.

#### speedup

Customer database with mix of real_time and manual inventory valuation and anglo-saxon accounting.
purchase_stock is installed.
15 000 products, 80 000 stock.moves, 66 000 stock.move.lines,
100 000 account.moves, 289 000 account.move.line.

Time to post an invoice changing the number of lines.

| # Lines |     Before PR            | After PR |
|:-------:|:------------------------:|:--------:|
|    10   |       1.66s              |   1.11s  |
|    50   |       8.53s              |   2.95s  |
|    200  |       1min30s            |   11.51s |
|    889  |       +20min (killed)    |   58.84s |

opw-3901468

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

Forward-Port-Of: odoo/odoo#169825
Forward-Port-Of: odoo/odoo#166482

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