Steps to reproduce:

- Start the project tour
- Follow the steps till the tour step comes to selecting Assignee's(user_ids)
- Now click on the drop-down and select an user.

Issue:

- The step is not completed even though we have selected an user.
- Now type something the Assignee's the step is completed

Fix:

- Incorrect trigger causes to generate incorrect consumeEvent (i.e., an input consume type) which is not satisfied by click event we initiate

Solution:

- Change the trigger and rewrite the run function.

____

[FIX] web: increasing z-index of overlay-item

Currently in the code base there is a recurrent problem of different components 
using z-index as ``` z-index: $zindex-modal + 1(a constant) ``` just so that 
their components have no obstructions. Due to this there is a problem for 
overlay service as each overlay-item uses z-index same as zindex-modal. Thus 
this causes problem in some areas (especially tours). Thus increasing z-index 
of overlay-item would be good.

task-3906723

Forward-Port-Of: odoo/odoo#170247

Currently, when a loyalty program has a reward of type product and uses `reward_product_tag_id` (set up for at least 2 products), the addition of rewards to the pos order will have mismatched reward lines when adding the second free product (the first product needed to be added first).

Steps to reproduce:
-------------------
* Go to **Point of Sale** App
* Go to **Products** and add a tag (the same) for two products
* Under **Products** select `Discount & Loyalty`
* Create a new program of type **Buy X Get Y**
* Rule:
  * Min qty: 2 products $0.00
  * Among Products: Put all chairs products for example
* Reward:
  * Type: Free Product
  * Product: None
  * Product tag: The tag put on the products previously
* Open shop session
* Add 2 chairs
* Select reward, add the first one
> Everything ok until now
* Add 2 chairs
* Select reward, add the second one
> Observation: Reward computation is wrong we have the following lines:
  ```
  4 Chairs,
  Reward 1,
  Reward 2,
  Free product reward 1
  ```
  > We are missing the free product line related to the second product added and the button to select reward is still highlighted.

Why the fix:
------------
To explain this fix I will use the example given above.

Here are the steps that have been executed already
* Add 2 chairs
* Add the first reward product
* Add 2 chairs

We are currently in the middle of the step "Add second reward product". During that process, we end up in the function `_computeUnclaimedFreeProductQty` while computing values for the reward line. At this very moment in time, the order has the following lines:
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2 

Where Product 1 and Product 2 are the reward products, having the same tag.

Let's focus on this piece of code, with the current example: https://github.com/odoo/odoo/blob/76023820c4d725c81677d2bf3e010c8cee1edd19/addons/pos_loyalty/static/src/js/Loyalty.js#L1464-L1475

Where `product` in this case is `Product 2`. What is happening here at the end is that we have `available = 1` because of line 4 and `claimed = 1` because of line 3. The program considers that we have already claimed the quantity and is the reason why it is not adding the reward line.

The first idea to fix this issue was to write the condition:
```js
if (reward.reward_product_ids.includes(product.id) && reward.reward_product_ids.includes(line.product.id)) {
```

instead of this one
```js
if (line.get_product().id === product.id) {
```

Now both line 2 and 4 are counted toward the `available` quantity. This way the code knows that we have two availaible free product but only 1 was claimed.

While this fixed the original issue, a new issue was created. Now, when we add the second product, the two reward lines were grouped together, using the price of the first free product added. Why was this happening?

Well, once the fist call to the function `_computeUnclaimedFreeProductQty` was done and the reward line was added we had the following order (temporarily)
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
* Free product (related to Product 2)

Which is what we expect but we face an issue when the loyalty programs are updated. When the programs update, we go through the function `_updateRewardLines`. In this function we discard the reward lines from the order and then for each claimed reward (Product 1 and Product 2) we re-apply the reward.

While applying the reward for Product 1, we again go through the function `_computeUnclaimedFreeProductQty`. In this case, the order looks like this:
* 4 Chairs
* Product 1
* Product 2

and the function will say that there are 2 available free product and 0 claimed. Were it is technically true, in this case we want to have the available quantity to 1. We want the initial condition:
```js
if (line.get_product().id === product.id) {
```

In the second passage, for product 2, we have `available = 2` and `claimed = 2`.

opw-3587020

Forward-Port-Of: odoo/odoo#175592
Forward-Port-Of: odoo/odoo#173529

**Description**

- From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per [this](https://github.com/odoo/odoo/pull/171275) file in V16, module [l10n_fr_invoice_addr] has been optimized to adapt the documents as per new French law. Although, the traceback is showing due to the fact that while performing the "l10n_fr_invoice_addr" module's view, the "shipping_field" has set the groups to null in this [account_move.py](https://github.com/odoo/odoo/pull/171275/files#diff-5125aad1cd2220c7e0c4cfe80ec0541acf5e9f4dbce46fb370e94cd281012b36R17) file which should not be the case. Due to this, as per this [condition](https://github.com/odoo/odoo/blob/16.0/odoo/models.py#L1464), it is trying to find groups in V16.0, which will lead to traceback as the groups are set null here. Whereas in stable version 15.0, it was working due to the fact that previously the groups were set to null through the [account_move.xml](https://github.com/odoo/odoo/blob/15.0/addons/l10n_fr_invoice_addr/views/account_move_views.xml#L9) file.

- As a result, to resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. 

**Steps to Reproduce (V16.0)**

- Change the language to French. 
- Install "l10n_fr" module
- Get an FR company.
- Create an invoice, it's partner(customer) should be of FR , then confirm the invoice.
- Open the invoice and then click on the web studio button.

**Solution**

- To resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. 

**Current behavior before PR:**

![V16_behavior](https://github.com/user-attachments/assets/de318ec6-664c-427e-a497-3322b6ee445c)

---
opw-[4044861](https://www.odoo.com/odoo/project.task/4044861?cids=2)

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

Forward-Port-Of: odoo/odoo#173162

Steps to reproduce:
- Manufacturing > Products > Bills of Material > New
- Add any item as component then the same item as by-product
- Confirm
- Operations > Manufacturing Order > New
- Pick the product associated to your newly created BoM
- Confirm > Overview

What happens and why:
Odoo raises an RPC error due to an inifinite recursion between _get_components_data and _get_replenishment_lines. Both calls are made before the manufacturing order line is flagged as processed so the functions are mutually dependant on the other finishing first. The looping call is conitionally called when document_in and document_out are the same, which seems to be why the stock moves 'move_in' (component) and 'move_out' (by-product) need to be configured this way on the BoM.

Why is this an error:
This prevents the user from accessing the overview of a valid MO.

What this fix does:
Moves the flag to before the looping call can be made, so the recursive call does not propagate infiniely.

opw-4013371

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

Forward-Port-Of: odoo/odoo#172567

**Steps to reproduce:**
- Install l10n_ar and website_sale
- Switch to an Argentinian company
- Create a product with a customer tax (e.g. IVA 21%)

With a public user or a user without "AFIP Responsibility":
- Go to eShop and add the created product to the cart
- Go to the cart

**Issue:**
No tax is applied.

**Cause:**
There are some fiscal positions from Argentinian localization that map IVA 21% to IVA Exento (i.e. 0%).
These fiscal positions are linked to specific "AFIP Responsibility" types and should only be applied for users having these "AFIP Responsibility" types configured on their contact form.
However, when this field is not set, it is ignored in the domain computing the fiscal position and one of these Argentinian fiscal positions satisfies the resulting domain.

**Solution:**
Filter on "AFIP Responsibility" in the domain computing the fiscal position if "l10n_ar_afip_responsibility_type_id" key is present in the context, no matter what its value.

opw-3943108




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

Forward-Port-Of: odoo/odoo#171923

Steps to reproduce the bug:

- In Website edit mode.
- Drag and drop enough snippets to have a vertical scrollbar.
- Scroll the page to the top.
- Drag and drop a dynamic snippet (e.g. Products) at the bottom of the viewport.
- Bug: The page doesn't scroll to the dynanmic snippet.

The bug was due to the fact that we needed to know the top position of the snippet to set the scroll value. However, it wasn't possible to get the offset of the element because the dynamic snippets were set to "display: none" when this calculation was made.

It's a bug we had before and fixed with this commit [1]. It worked. But since this other commit [2] where dynamic snippets are no longer hidden with the Bootstrap class "d-none" but with the class "o_dynamic_empty", the fix no longer works.

[1]: https://github.com/odoo/odoo/commit/963f0ed02eba929fcbc65fe51bef95c2a1dcf2ea
[2]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878

task-4072655

Forward-Port-Of: odoo/odoo#175207

Steps to reproduce:

1.  Drop a pop-up snippet
2. Change the Shown on: This Page to All Pages
3. Save and Edit again
4. Changing Shown on: All Pages to This Page won't work and Snippet Duplicate and Remove options are not visible.

Issue reason:
Commit [1] relocates the `#o_search_modal` element to `#o_shared_blocks`. Once the Shown on option of popup is changed to All Pages and Saved then again when you Go to Edit mode it adds `o_editable`and `o_dirty` class to popup even when no changes are made. So after changing the option, the observer checks for `o_dirty` and changes get rollbacked.

Solution:
Instead of adding `#o_search_modal` element to `#o_shared_blocks` it is relocated to the new element `#o_search_block` inside the `main` element.

This commit ensures that the popup/newsletter popup Shown on option and Snippet Duplicate and Remove options are visible and working.

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

task-4011237

Forward-Port-Of: odoo/odoo#175440
Forward-Port-Of: odoo/odoo#173473

Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And other times it's a non-descript error that we replace with a more user-friendly error to guide users towards the most common fix.

Before this fix a traceback appeared when a human-readable error string was returned without 'unhandled error occured':

```
File ".../l10n_br_avatax/models/res_config_settings.py", line 85, in create_account
result = json.loads(result['message'])
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```

This makes the error handling more robust by first attempting to decode the string as JSON. If that fails we fall back on the other two scenarios.

A new test class is included that provides examples of each type of response.

opw-4067842

Forward-Port-Of: odoo/enterprise#67477

Steps to reproduce:
- Manufacturing > Products > BoM
- Create BoM with at least 1 operation
- New MO with Quantity to produce >= 1000
- Shop Floor > Remove filters

What happens:
Work order card truncates number of units to produce by 3 digits, i.e. a quantity of 2500 displays as 2, 34000 as 34, etc... This is caused by the successive conversions in formatFloat, they go:
Number (quantityToProduce) > String (formatFloat) > Number (ParseFloat) > String (String())
Which looks to be a dirty solution to forcefully display the float as an integer value.

What this fix does:
Getting rid of the superfluous conversions fixes the truncating issue.
The decimal precision was set to default to integer values if the precision props is not defined to conserve the original behavior since manufacturing fractions of a product seems nonsensical, but it seems a precision was passed all along and simply failed to display because of the aforementioned issue. So now 2500 displays as 2500.00 not sure if that was intended or just ignored because of the previous display weirdness.

opw-4040457

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

Forward-Port-Of: odoo/enterprise#66570