****Behavior:****
**Current:**
When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you reload the list.

This is occurring since list can be presented in multiple pages, the length of which is defined by the variable limit and the current page is represented by offset (multiple of limit) and when the last element of a page is deleted, we load the previous page (deduce limit from offset), the issue is that there isnt any checks that we are not currently on the first page of the list, and thus we change offset to a negative number (0-limit) which results in an empty list when trying to load the ids of the records (which happens when we reorder the list, and not when adding new elements which explains why they only disappear at that moment)

**Steps to reproduce:**
(example with sale orders but works with any manually sortable list)
- Create a Sale Order
- Add any product
- Delete it
- Add any two combination of product or sections
- Swap the order of both
- You'll see the elements disappear, when reloading the page they should come back.

opw-5191103

Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard.

**Steps to replicate:**
* Install `l10n_ec_edi` and change company to `EC company`
* Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm
* Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post
* Set system time to future date > Run `Base: Auto-vacuum internal data`.

Refer video [1] for replication steps.

**Error:**
`psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line'
`
**Root cause:**
* The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours.
* However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error.

**Solution:**
* Unlink the lines first and then unlink the wizard.

[1]:
https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing 
[2]:
https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 
[3]:
https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 
[4]:
https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427

sentry-6253783256

Forward-Port-Of: odoo/enterprise#99653

Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory

records
```
sagu_3267671=> select count(id) from account_move;
  count
---------
 1034179
(1 row)
```

```
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible
move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed')
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```

upg-3267671
opw-5246681


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

Forward-Port-Of: odoo/odoo#235919

Steps To Reproduce
------------------
1- Create an MTO product.
2- Create an SO for 10 units and confirm.
3- Deliver 5 on the first picking, validate, and create the backorder. 
4- Print the delivery slip of the first (done) picking.

Issue
-----
1- MTO: Ordered = 5, Delivered = 5, Remaining = 5.
2- Normal product: Ordered = 10, Delivered = 5, Remaining = 5.
The ordered quantity for MTO products is wrong, it shows the delivered amount instead of the original order total.

Cause
-----
The delivery report calculates the "Ordered" quantity by adding what we just delivered to what is left in the backorders. I found that the code was looking for move lines in the backorders to count what is left. When I checked a backorder that is waiting for stock (like MTO), there is no reserved stock yet, so no move lines exist. Because of this, the report thought the backorder was empty and ignored the remaining quantity.

Fix
---
I changed the code to look at the `move_ids` instead of the `move_line_ids`. While debugging I found out that the `move_ids` record always holds the correct demand regardless of the product.

opw-5112467

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

__Before this commit:__
1. Add a 2nd language to your site
2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page)
3. Press Alt+A (the shortcut to open the builder) => The builder opens, but it is unusable. The builder options are the translation options, but the iframe is not in a translatable state.

__Cause:__
Pressing Alt+A outside the admin backend just [adds `enable_editor=1` in the URL][1]. When the page is displayed in the 2nd language `data-translatable` is included in the metadata so the translation mode opens. However the iframe relies on the `edit_translations` search param being set to include the translation branding (i.e. `data-oe-translation-source-sha`) which is not the case after pressing Alt+A.

__The fix:__
Add `edit_translations` when pressing Alt+A in any case. If the page is translatable, the translation mode will correclty open, otherwise it will be ignored and the edit mode will open instead.

NB: By doing this, we bypass the checks in [`attemptStartTranslate`][2] therefore a user who doesn't have the proper access rights will still be able to open the translation mode but they will not be able to do anything. Using those checks would add too much complexity to the code in regards to how niche the feature is anyway.

[1]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/js/content/redirect.js#L33
[2]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/client_actions/website_preview/edit_website_systray_item.js#L54

task-5125700

Forward-Port-Of: odoo/odoo#236039

### [FIX] mail: clean the "beforeunload" listener in tests

Some tests trigger a call to the function `Rtc.joinCall` which adds a
listener on `beforeunload` event that cancels the event. Some of these
tests do not trigger a later call to `Rpc.clear`, thus the listener
stays registered. This could mess with other unrelated tests that check
their own handlers of `beforeunload` are correct.

This commit adds a cleanup on the helper used by the problematic tests.

task-5138313

### [FIX] website, html_builder: run after-save handlers if aborted

Usually, running the after save handlers is not needed after the save
because we are about to close or reload the builder. Thus they are not
run as an optimization. But there are a few cases where they are needed:
- The saving of the page failed. This case was correctly handled only
  when clicking on the save button or adding a module
- When adding a language, but cancelling the dialog to choose the
  language

This commit changes the save function of the save plugin, to take a
async callback to determine whether the after-save handlers should run.
The callback is async to be able to wait for the language choice dialog.
If the callback returns `true`, then the after-save handlers are run.

Steps to reproduce:
- Open website builder
- Open "Theme" tab
- Click "Add Language"
- Confirm the first dialog (about save)
- Cancel the second dialog (language choice)
- Bug: the save button stays disabled with the spinning wheel next to it

task-5138313

Forward-Port-Of: odoo/odoo#229843

### Steps to reproduce:

- Create a storable product
- Create a receipt for 100 units of that product
- Mark as to do, set the quantity to 50 and validate without backorder
- Go to your product form > Forecast
#### > The forecast displays a quantity of -50 for every date in the past

### Cause of the issue:

The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant.

#### Note:

The same issue happen if you receive more than the demand. That is:
- Mark as to do, set the quantity to 150 and validate without backorder
- Go to your product form > Forecast
#### > The forecast displays a quantity of 50 for every date in the past

The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would:
- in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand.
- in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move.

This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact.

opw-5152570

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

Forward-Port-Of: odoo/odoo#234576

Issue
-----
In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity.

Steps to reproduce
-----
- Enable warehouses and multi-step routes
- Set warehouse manufacturing to 3 step
- Edit the 3 step production route
	- Change the pre-prod -> prod rule to mts else mto
- Create a product "Comp"
	- Set a quantity of 5 in location pre-prod
- Create a product "Prod"
	- Add a BoM with "Comp" as component
- Create a MO for 10 of Prod
- Confirm MO
> There is a transfer stock -> pre-prod for 5 of Comp
- Open the production quantity wizard, update value to 12 and confirm
> The transfer still shows 5 of Comp instead of the needed 7

Cause
-----
Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement`

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485

Before actually running any procurement we do

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492

Since the procurement group's method is `mts_else_mto`, when we go through

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332

we go into the `else` part and set the move's `procure_method` to mts.

This means that, in the `run_procurement` method

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504

is not true, so we don't add any procurement to run.

Solution
-----
In `_adjust_procure_method` we update the move's rule to the MTSO one we found

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328

This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO.

-----
Ticket:
opw-5008871

Forward-Port-Of: odoo/odoo#235125

Steps to reproduce
------------------
1. Create a product with a UoM that is non groupable in PoS
2. Make a sale order with that product having a UoM that is based on the
   UoM of the first steps. If the UoM in the first step was Kg for
   intsance, use Gram (g) here.
3. Confirm the order, and settle it in PoS.

Notice that the price of that order in PoS is not correct.

Why it's happening
------------------
When settling the PoS order, we first convert the sale_order's line UoM
(g) to the original product UoM (kg), and we update the quantity
accordingly (in this example by dividing by 1000).
https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96
So this step updates both the qty and the unit_price.
https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161

However, when the UoM is not groupable, we split the lines by taking
into consideration the updated qty, but we still use the old price_unit,
which creates an inconsitency and wrong calculations.

The fix
-------
When splitting the lines, we're just supposed to change the qty per line
to max 1, but we're not supposed to change the price per unit for this
qty. We now use the updated `price_unit` to have a correct math.

opw-5232571

Forward-Port-Of: odoo/odoo#237246
Forward-Port-Of: odoo/odoo#236008

## Issue 1:
In this issue, active/inactive filter is not working correctly.

#### To reproduce:
1- Install `Sale`
2- Active `Promotions, Loyalty & Gift Card`
3- In `Discount & Loyalty` create a loyalty program
4- Create a `Loyalty Card` for the program
5- Archive the card
6- In search, click on `inactive` filter

As you see, you can't find the archived card.

### Cause:
This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`.

## Issue 2:
In this bug, earned points on archived loyalty can be used to claim rewards.

#### To reproduce:
1- Install `Sale` and `Ecommerce`
2- Active `Promotions, Loyalty & Gift Card`
3- In `Discount & Loyalty` create a loyalty program
4- Add a rule to grant 10 points per order
5- Apply a reward in exchange of 10 points
6- Create a `Loyalty Card` for the admin with 0 points.
7- In Ecommerce, add a product to your cart
8- Remove the product from the cart
9- Archive the loyalty card created for the admin
10- In Ecommerce, add another product to cart
11- As you see, you still can use the loyalty card

### Cause:
When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards.
To prevent this, we can unlink points from draft sale order when the card is archived.

opw-5166696

Forward-Port-Of: odoo/odoo#233645

[FIX] account_reports: returns: recomputed date_deadline when is_completed is set to False

To align it with the current deadline delay configured on the return type, and keep data consistent.

Also, databases migrated before https://github.com/odoo/upgrade/pull/8841 could contain returns marked as completed with no value set for the deadline. With this, we ensure unmarking them as completed will grant them one.

opw-5259168

====================================================================

[FIX] account_reports: returns: avoid error when computing days_to_deadline for migrated dbs

Databases migrated before https://github.com/odoo/upgrade/pull/8841 could contain returns marked as completed, but without any date_deadline. On such a db, if you open the list of returns, then remove the "to do" filter, you get an error, because _compute_days_to_deadline tries to substract today from None.

This commit just makes the computation more resilient, and arbitrarily chooses that a return without deadline is due today.

opw-5259168