Currently, a traceback is occurring when the user tries to create an 
exchange return without giving the origin value in picking.

To reproduce this issue:

1) Install `purchase_stock`
2) Create a stock picking with operation type as `receipts` and don't give the `origin` value 
3) Add a product in operation that contains vendor records in the  product
4) `Validate` the product and click the `return` button to open a wizard 
5) Update the qty to return and click the `Return for Exchange` button

Error:-
```
TypeError: sequence item 0: expected str instance, bool found
```

This traceback occurs from the line below because we are getting the origin value as False from the procurements.

https://github.com/odoo/odoo/blob/949ed6f30f539dd787594511751bda0e714a5409/addons/purchase_stock/models/stock_rule.py#L119

The origin value of this procurement is directly taken from the origin value of picking. 
The above traceback occurs because the user didn't provide the origin value in picking.

We can resolve this issue by providing a fallback value of an empty string if there is no origin in picking.

sentry-6316652948

Context: the MPS only creates records when numbers have been manually input.
If the number input is superior to the `max_to_replenish_qty`, the leftover
is reported to the next period via computation, meaning no record is created.
This means that every time the MPS is opened or refreshed, the computation
happens.

Issue: with the inclusion of the period switcher, some issues have been
revealed concerning quantity computation and period switching.

Solution: to be sure that numbers are accurate, the MPS will compute in
2 steps using 2 date ranges:
- the `shown_date_range`: it's the one the user sees,
the number of period shown is defined in the settings
- the `default_date_range`: it's the one selected in the settings
it uses the start and end of the `shown_date_range` to build itself

E.g. 1: if your `shown_date_range` is month with 6 periods to show and your
`default_date_range` is days, the MPS will calculate everything day per day
before doing sums for each month. Meaning it will do ~180 computations,
one for each day.
E.g. 2: if your `shown_date_range` is 12 weeks and your `default_date_range`
is in years, the MPS will calculate everything on 2 years (the current year
and the next) in case the `shown_date_range` is straddling 2 years. Once the
computation is done, it will insert the yearly `forecast_ids`
(date == 01/01/2025) and place it in week 1 of 2025 (30/12/2024 to 05/01/2025),
all other weeks should show zero.

Pros:
- it's precise

Cons:
- it's potentially very slow in extreme cases: if you want to show 4 years and
your default period is in days, this means the MPS will calculate quantities
for 1461 days before summing them in 4 years. This should be alleviated with
task 4370071 where the default period type is not a general setting anymore but
defined separately on each MPS product record.
- manual input, when not in the default period type, can be displaced to a previous
shown period or absorbed in the sum of the previous default period. This is most
often because weeks are one of the 2 period types and how they never fit neatly
because the Gregorian Calendar is the drunk way of keeping time with some month
having 30 days, some having 31 and then there's February who changes its mind
once every 4 years.

task 4381366

Versions
--------
- saas-17.4+

Steps
-----
1. Create a new product with a lot of variants;
2. publish it to the website;
3. edit the website home page to add a product carousel;
4. set it to display newest products & hide variants.

Issue
-----
Fewer than 16 products are displayed in the carousel.

Cause
-----
Unlike the other product filters handled in https://github.com/odoo/odoo/pull/189040, the "Newest Products" filter is defined in `data/data.xml`, and stored as a record.

This means it doesn't use the `_get_products` method to perform the search, instead using the `_prepare_values` method from the `website` module.

For obvious reasons, the method defined in `website` doesn't take the `hide_variants` parameter into account to get the correct amount of search results: https://github.com/odoo/odoo/blob/0f64298c871ffea088a4fe6255d19852c8348159/addons/website/models/website_snippet_filter.py#L102-L108
Instead it passes 16 `product.product` records to the `_filter_records_to_values` override in `website_sale`, where duplicate templates are filtered out, resulting in fewer than 16 product templates: https://github.com/odoo/odoo/blob/0f64298c871ffea088a4fe6255d19852c8348159/addons/website_sale/models/website_snippet_filter.py#L73-L76

Solution
--------
When calling `super()._prepare_values` for stored `product.product` filters, temporarily square the usual limit for the search, and filter reduce to size later.

This may still be inadequate when working with products with dozens of variants, but should cover most normal use cases without requiring drastic changes to filter templates or search domain in stable.

On master, we could add a new filter specifically for `product.template`.

opw-4302856

Forward-Port-Of: odoo/odoo#195857

Issue:
------
Case:  User Settings menu is basically used to handle created users but when clicking on the `New` button within the User Settings the form view corresponding to that model i.e; `res.users.settings` will be opened which is an inappropriate behavior.
Whenever a User is created that user will be reflected within that menu. There's no meaning of having `New` button when no user is created to handle.

Solution:
-----------
Some users do not have a user settings yet, so it is a perfectly valid use case to create one.
We should not artificially prevent acceptable behavior in technical/admin menus.

Steps to reproduce:
------------------------
1. Create a database in version 16.0.
2. Go to `User Settings`.
3. Click On `New` button. Try making changes and save.
4. An Invalid Field `User` error will Occur.

This is because there's a many2One field i.e; `user_id` within the tree and form views which is basically an existing user.
The `New` button will open a form view with no User which is a must. And will cause the Invalid field error when trying to save any change.

Ref:
https://github.com/odoo/odoo/blob/16.0/addons/mail/views/res_users_settings_views.xml#L24

Ref Screenshot:
![image](https://github.com/user-attachments/assets/24373b6e-2d67-42f7-9506-24faa3021e41)


Co-Authored By - @seb-odoo

Forward-Port-Of: odoo/odoo#196844
Forward-Port-Of: odoo/odoo#193400

### Issues:

Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.

### Cause of the issues:

The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147 
In which case, the quality check is not triggered (Issue 1). Furthermore, since  the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).

### Issue 1:

1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
    - Control per: "Operation"
    - Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt

#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.

### Cause of the Issue:

Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74 
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61 
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.

### Fix:

The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.

### Note:

The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.

### Issue 2:

Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check

#### > Two quality checks were created isntead of one for your receipt

### Cause of the issue:

At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state: https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157

However, during the `_action_done` of the moves if the quantity of the move exceeds its `product_uom_qty`, extra moves will be created, confirmed and merged back to the move in order to update its `product_uom_qty`:
https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1885-L1890 https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1823-L1832 However, the action confirm of this extra move will trigger the same override of the `_action_confirm` that creates a quality check and it will even be called on the original move that was already confirmed and already created its QC since the extra move was merged into it: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
As a result we end up with an extra quality check creation.

### Fix:

We avoid quality check creation during extra move confirmation.

Enterprise: https://github.com/odoo/enterprise/pull/76301

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

Forward-Port-Of: odoo/odoo#197122
Forward-Port-Of: odoo/odoo#192034

**To replicate:**
1. Install a localization reports module (e.g. l10n_lu_reports)
2. Create two branches for the company in the localization: one with a different VAT, and another without VAT (it takes the same VAT as the closest parent with VAT)
3. In Accounting > Reporting > Tax Report
4. Select only the company with a different VAT. The button to export an XML is not enabled.
5. Select the parent company and the company without VAT. The button to export an XML is not enabled.

**Issue:**
In some Tax Reports and EC Sales Reports with branch companies, the additional buttons are not enabled properly, even when all companies with the same VAT are selected.

**Expected behavior:**
If all branches with the same VAT are selected, export buttons should be available.

**Cause of the problem:**
In the tax report handler and EC sales report handler, `_custom_options_initializer()` calls the function `_enable_export_buttons_for_common_vat_groups_in_branches()`, which should enable the buttons if branches with the same VAT are selected.

When extending `_custom_options_initializer()`, the call to super happens before extra buttons are added. These additional buttons are not included in the call to
`_enable_export_buttons_for_common_vat_groups_in_branches()`.

**Fix:**
Instead of calling the function in _custom_options_initializer, add an option key to check and enable export buttons. This check is now done in `get_options()`, using the same logic previously applied in `_enable_export_buttons_for_common_vat_groups_in_branches`. As `get_options()` is called after the custom options initializer, all buttons are enabled if all branches with the same VAT are selected.

task-4061157

Forward-Port-Of: odoo/enterprise#79227

### Issues:

Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.

### Cause of the issues:

The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147 
In which case, the quality check is not triggered (Issue 1). Furthermore, since  the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).

### Issue 1:

1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
    - Control per: "Operation"
    - Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt

#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.

### Cause of the Issue:

Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74 
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61 
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.

### Fix:

The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.

### Note:

The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.

### Issue 2:

Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check

#### > Two quality checks were created isntead of one for your receipt

### Cause of the issue:

At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state: https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157

However, during the `_action_done` of the moves if the quantity of the move exceeds its `product_uom_qty`, extra moves will be created, confirmed and merged back to the move in order to update its `product_uom_qty`:
https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1885-L1890 https://github.com/odoo/odoo/blob/607d63fd4d9c07bac9cb68b2d31d86551e93d5b1/addons/stock/models/stock_move.py#L1823-L1832 However, the action confirm of this extra move will trigger the same override of the `_action_confirm` that creates a quality check and it will even be called on the original move that was already confirmed and already created its QC since the extra move was merged into it: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
As a result we end up with an extra quality check creation.

### Fix:

We avoid quality check creation during extra move confirmation.

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

opw-4266053
---

Forward-Port-Of: odoo/enterprise#78949
Forward-Port-Of: odoo/enterprise#76301

This traceback arises when the user tries to change the orders from one stage to another.
after deleting the last stage in another tab.

To reproduce this issue:-

1) Install `pos_restaurant`
2) Duplicate the tab and open the preparation display in one tab
3) In another tab delete the last stage(`complete`) for the above preparation display 
4) In the first tab click any product of an order from the `ready` stage 
5) Now click the `ready` icon of that order
5) At the terminal you will see a traceback

Error:- 

```
IndexError: list index out of range
  File "odoo/http.py", line 2252, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1828, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1848, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1826, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1833, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2058, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.1/pos_preparation_display/models/preparation_display_orderline.py", line 51, in send_stricked_line_to_next_stage
    next_stage_id = stage_ids.ids[current_stage_index + 1]
```

When the user clicks on the current stage icon it is supposed to go to the next stage with the help of the current stage index + 1.

But, because the user deleted the next stage it leads to an index error

After applying this will resolve the issue by preventing the user to modify stages
when there is an active session for that preparation display. Which making the code more robust

sentry-5056416790

Forward-Port-Of: odoo/enterprise#59415