In commit https://github.com/odoo/odoo/commit/513dde64c736f1ff9141825b06c93666b67131db, we changed the field from `product_qty` to `quantity`, however, the latter use the move's UoM instead of the product's UoM. With this commit, we convert the quantities to the product's UoM to ensure the correct quantity is used. Forward-Port-Of: odoo/odoo#178226

In commit https://github.com/odoo/odoo/commit/513dde64c736f1ff9141825b06c93666b67131db, we changed the field from `product_qty` to `quantity`, however, the latter use the move's UoM instead of the product's UoM.

With this commit, we convert the quantities to the product's UoM to ensure the correct quantity is used.

Forward-Port-Of: odoo/odoo#178226

There is an issue where the Mercado Pago terminal rejects a card payment, but Odoo accepts the payment. This is caused by a quirk in the Mercado Pago API, where the payment intent status is "FINISHED" despite the payment status being "rejected". This PR fixes the issue by checking the payment status explicitly by calling the API. task-4097968 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178386

There is an issue where the Mercado Pago terminal
rejects a card payment, but Odoo accepts the
payment. This is caused by a quirk in the Mercado
Pago API, where the payment intent status is
"FINISHED" despite the payment status being
"rejected".

This PR fixes the issue by checking the payment
status explicitly by calling the API.

task-4097968

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

Forward-Port-Of: odoo/odoo#178386

In the accounting reconciliation tool: - Click in one of the 2 search inputs - Start typing - Single click on the second search input - Start typing - Notice it still types in the first search input instead of the second. The search input you choose first doesn't matter. You can start with the upper one or the bottom one, the issue is the same, just reversed. Before:  After: ![after](https:

In the accounting reconciliation tool:
- Click in one of the 2 search inputs
- Start typing
- Single click on the second search input
- Start typing
- Notice it still types in the first search input instead of the second.

The search input you choose first doesn't matter.
You can start with the upper one or the bottom one, the issue is the same, just reversed.

Before:
![before](https://github.com/user-attachments/assets/3f43c437-9937-452b-b0ab-029cacafbd7e)

After:
![after](https://github.com/user-attachments/assets/b3a02df7-5773-4d55-be6f-d01711d6c7cc)

Forward-Port-Of: odoo/odoo#178238

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178221

Description of the issue/feature this PR addresses:


Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#178221

In commit [1], the carousel controls have been deactivated in edit mode, in order to control the carousel sliding manually so everything is done in the mutex. This was done to avoid asynchronous issues and to have a correct history when using the carousel options. However, these controls are also blocked in translate mode, because it is considered as if it was in edit mode, which should not be the case. This made it impossible to translate the other slides, since we cannot slide the carousel

In commit [1], the carousel controls have been deactivated in edit mode, in order to control the carousel sliding manually so everything is done in the mutex. This was done to avoid asynchronous issues and to have a correct history when using the carousel options.

However, these controls are also blocked in translate mode, because it is considered as if it was in edit mode, which should not be the case. This made it impossible to translate the other slides, since we cannot slide the carousel anymore.

This commit fixes this by not deactivating the carousel controls if we are in translate mode.

Steps to reproduce:
- Install an other language.
- In edit mode, drop the "Carousel" or the "Quotes" snippet and save.
- Change the language of the website and translate it.
- Try to slide the carousel. 
=> It is impossible.

[1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd

opw-4134824

Forward-Port-Of: odoo/odoo#178252

This test was underministically failing due to a combination of two factors: - The domain chosen for the test is selected by ```py domain = list(iap_tools._MAIL_DOMAIN_BLACKLIST)[0] ``` which was undeterministic since `iap_tools._MAIL_DOMAIN_BLACKLIST` is a set. - Since commit 02b5d47, a distinction was made between email providers `_MAIL_PROVIDERS` and the domain blacklist `_MAIL_DOMAIN_BLACKLIST`. The test used `_MAIL_DOMAIN_BLACKLIST` instead of `_MAIL_PROVIDERS`, it should have been

This test was underministically failing due to a combination of two factors:
- The domain chosen for the test is selected by
```py
domain = list(iap_tools._MAIL_DOMAIN_BLACKLIST)[0]
```
  which was undeterministic since `iap_tools._MAIL_DOMAIN_BLACKLIST` is a set.
- Since commit 02b5d47, a distinction was made between email providers `_MAIL_PROVIDERS` and the domain blacklist `_MAIL_DOMAIN_BLACKLIST`. The test used `_MAIL_DOMAIN_BLACKLIST` instead of `_MAIL_PROVIDERS`, it should have been adapted. The only difference between the two, at the moment, is the addition of "odoo.com" in the domain blacklist. When that domain is selected, the test crashes.
There is approximately a 1/124 chance of that happening.

Forward-Port-Of: odoo/odoo#177935

* When fwd https://github.com/odoo/odoo/pull/156349 , we forgot to adapt with change in >=17.0 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177702

* When fwd https://github.com/odoo/odoo/pull/156349 , we forgot to adapt with change in >=17.0

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#177702

Commit that introduced the issue: https://github.com/odoo/odoo/commit/2050328a37ed5dd7639273bcd60eb5006bd98cfb Issue: ====== We can't scroll to anchor link until the animation is over in rtl language. Steps to reproduce the issue: ============================= - Go to a blanck web page - Add a form on the top - Create a link for it using the sidebar (it will be #Form) - Add text block after it - Add heading block - Add any animation but make sure to add a delay (3s for example) an

Commit that introduced the issue: https://github.com/odoo/odoo/commit/2050328a37ed5dd7639273bcd60eb5006bd98cfb

Issue:
======
We can't scroll to anchor link until the animation is over in rtl language.

Steps to reproduce the issue:
=============================
- Go to a blanck web page
- Add a form on the top
- Create a link for it using the sidebar (it will be #Form)
- Add text block after it
- Add heading block
- Add any animation but make sure to add a delay (3s for example) and duration (2s for example)
- Add a text and a button after the heading
- Add the link `#Form` to the button
- Save
- Reload the page and choose arabic language for the website (not the user)
- The scroll down and click on the button, nothing happens until the animation is over and then when you click the page scrolls to the form.

Origin of the issue:
====================
By default the value `overflow-y=visible` so in `ltr` since we don't update the overlow it stays by defaylt and the JQuery doesn't detect it as scrollable.

Now in `rtl` we add `overflow-x:hidden` which update the value of `overflow-y` to `auto` which makes the JQuery detect it as scrollable which explains the difference of behavior between the two directions.

Since the closestScrollable of the element isn't the same in the two directions, then in `rtl` it will produce different offset in `scrollTo` of JQuery.

opw-4053513

Forward-Port-Of: odoo/odoo#177082

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176435

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

Forward-Port-Of: odoo/odoo#176435

The 1.25% WH tax was incorrectly configured, it's an ISR withholding tax, not IVA. task-4101407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177113

The 1.25% WH tax was incorrectly configured, it's an ISR withholding tax, not IVA.

task-4101407



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

Forward-Port-Of: odoo/odoo#177113

When uninstalling a module, a wizard displays the dependent modules that will also be uninstalled if the user confirms. By default, only the applications are displayed. This commit adds the imported modules to the default list to prevent unforeseen issues. Task-4144690 Forward-Port-Of: odoo/odoo#178251

When uninstalling a module, a wizard displays the dependent modules that will also be uninstalled if the user confirms. By default, only the applications are displayed. This commit adds the imported modules to the default list to prevent unforeseen issues.

Task-4144690

Forward-Port-Of: odoo/odoo#178251

Since [1], applying a font-size on some snippet default text was not working properly anymore. As soon as the actual text was changed, the features were working again. Steps to reproduce: - Enter website edit mode. - Add a "Title" snippet. - Triple-click on the default text. - Hit the font-size "Default" button. => Nothing happens, you cannot restore the default title size. Other steps to reproduce: - Enter website edit mode. - Add a "Title" snippet. - Triple-click on the default

Since [1], applying a font-size on some snippet default text was not working properly anymore. As soon as the actual text was changed, the features were working again.

Steps to reproduce:
- Enter website edit mode.
- Add a "Title" snippet.
- Triple-click on the default text.
- Hit the font-size "Default" button.
 => Nothing happens, you cannot restore the default title size.

Other steps to reproduce:
- Enter website edit mode.
- Add a "Title" snippet.
- Triple-click on the default text.
- Choose a font-size (like "8").
 => It is applied but inside the pre-existing 62px environment instead of replacing it, meaning the DOM looks like this:
   ```xml
    <font style="font-size: 62px;">
        <font style="font-size: 8px;">Title</font>
    </font>
    ```
    While it seems insignificant, this creates vertical misalignment.
    Depending on the use case, it might be problematic (e.g. a long
    paragraph instead of a title: it would have a big line spacing for
    no apparent reason). Note that this one is actually a more generic
    problem already but [1] worsened it. We might fully solve that issue
    in future versions.

To fix the issue, we now ensure that applying any editor command on some
default text makes it not-default text anymore.

opw-3957198

Forward-Port-Of: odoo/odoo#178286
Forward-Port-Of: odoo/odoo#178083

When `_search_on_comodel` is called with no `domain` and no `additional_domain`, it returns `False` (see added documentation for more explanation). However, when it is called with no `domain`, but an actual `additional_domain`, it returns something because both domains are merged before the `search`. Yet the `additional_domain` should filter the result even more, not expand it. Fix: First return `False` if there's no `filtered_domain`. Otherwise, and only then, merge both domains before the

When `_search_on_comodel` is called with no `domain` and no `additional_domain`, it returns `False` (see added documentation for more explanation). However, when it is called with no `domain`, but an actual `additional_domain`, it returns something because both domains are merged before the `search`. Yet the `additional_domain` should filter the result even more, not expand it.

Fix:
First return `False` if there's no `filtered_domain`. Otherwise, and only then, merge both domains before the `search`.

task-3251630


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

Forward-Port-Of: odoo/odoo#178119
Forward-Port-Of: odoo/odoo#172973

The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178219

The vies check service may limit ip addresses when:
- checking too many vat numbers per day
- checking the same vat number multiple times
- checking too many invalid number




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

Forward-Port-Of: odoo/odoo#178219

Some fixes already landed with 7cbf7f94263a31d316b9c5a0efad57ad357aa5a0, but if the address is incomplete, the user would still be redirected to a 403 page because he cannot update the warehouse address to fill the missing fields. This commit makes sure that for onsite flows, the warehouse address is considered complete. opw-4126140 opw-4114139 opw-4115510 opw-4117520 opw-4109625 opw-4115415 opw-4143237 opw-4123382 opw-4136888 opw-4125807 Forward-Port-Of: odoo/odoo#178521

Some fixes already landed with 7cbf7f94263a31d316b9c5a0efad57ad357aa5a0,
but if the address is incomplete, the user would still be redirected
to a 403 page because he cannot update the warehouse address to fill
the missing fields.

This commit makes sure that for onsite flows, the warehouse address
is considered complete.

opw-4126140
opw-4114139
opw-4115510
opw-4117520
opw-4109625
opw-4115415
opw-4143237
opw-4123382
opw-4136888
opw-4125807

Forward-Port-Of: odoo/odoo#178521

Description of the issue this commit addresses: A new tax has been added and will be used as from the first of september 2024. With this new tax, the tax report has been modified to include it by adding a new line but what's actually required as from the first september is to include the new tax to the existing 24% tax line in the report. --- Desired behavior after this commit is merged: The 25.5% tax line in the report includes both 24.0 and 25.5 rates and is named after the 25.5 on

Description of the issue this commit addresses:

A new tax has been added and will be used as from the first of september 2024. With this new tax, the tax report has been modified to include it by adding a new line but what's actually required as from the first september is to include the new tax to the existing 24% tax line in the report.

---

Desired behavior after this commit is merged:

The 25.5% tax line in the report includes both 24.0 and 25.5 rates and is named after the 25.5 one but still says that the 24.0 rate taxes are included in it. This will be changed to totally exclude the 24.0 rate once it will not be used anymore probably on the first of january 2025.

---

Documentation:
Change of default VAT rate: https://www.vero.fi/en/businesses-and-corporations/taxes-and-charges/vat/rates-of-vat/new-vat-rate-from-1-september-2024--instructions-for-vat-reporting/
Line about both taxes being in the same line of the report: https://www.vero.fi/en/businesses-and-corporations/taxes-and-charges/vat/rates-of-vat/new-vat-rate-from-1-september-2024--instructions-for-vat-reporting/#:~:text=All%20sales%20with%20both%20the%2024%25%20and%20the%2025.5%25%20rates%20must%20be%20entered%20into%20the%20same%20space%20on%20the%20form

---

task-4101930

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

Forward-Port-Of: odoo/odoo#178453
Forward-Port-Of: odoo/odoo#175963

Steps to reproduce: - Go to a product page - Enable "Discussions and rating" in the eCommerce - Add some comments and ratings on the product - Use the filtering tool on the left => It does not work anymore task-4149745 Forward-Port-Of: odoo/odoo#178661 Forward-Port-Of: odoo/odoo#178524

Steps to reproduce:
- Go to a product page
- Enable "Discussions and rating" in the eCommerce
- Add some comments and ratings on the product
- Use the filtering tool on the left => It does not work anymore

task-4149745

Forward-Port-Of: odoo/odoo#178661
Forward-Port-Of: odoo/odoo#178524

This change fixes 2 related issues: - If a user went to their cart after setting their order's delivery method to "pickup in store", they'd get an error if the store's partner was incomplete. Indeed, going to the cart would trigger the shipping partner's (i.e. the store partner's) validation. Since the shipping method is cleared anyway when going to the cart, we now now also clear the shipping address if the delivery method was "pickup in store". - When creating a new SO, we automatically set

This change fixes 2 related issues:
- If a user went to their cart after setting their order's delivery method to "pickup in store", they'd get an error if the store's partner was incomplete. Indeed, going to the cart would trigger the shipping partner's (i.e. the store partner's) validation. Since the shipping method is cleared anyway when going to the cart, we now now also clear the shipping address if the delivery method was "pickup in store".
- When creating a new SO, we automatically set its shipping/invoice partners to those from the last SO. If the last SO had a "pickup in store" delivery method, then the store's partner was used as the new SO's shipping partner. If the user tried to edit the address, they'd get an access error. Now, we don't use the last SO's shipping/invoice partner if they don't belong to the current partner (i.e. if they belong to the store).

opw-4126140
opw-4114139
opw-4115510
opw-4117520
opw-4109625
opw-4115415
opw-4143237
opw-4123382
opw-4136888
opw-4125807

Forward-Port-Of: odoo/odoo#178338

* STEP TO REPRODUCE: create an application then change to the stage which we will hire he/she -> Duplicate that application -> the new one already display ribbon 'Hired' * SOLUTION: make copy=False to date_close to avoid this Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177606 Forward-Port-

* STEP TO REPRODUCE: create an application then change to the stage which we will hire he/she -> Duplicate that application -> the new one already display ribbon 'Hired'
* SOLUTION: make copy=False to date_close to avoid this

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#177606
Forward-Port-Of: odoo/odoo#176879

Mouse hovering on channel member list item had no background color change. This happens because `bg-view` had more specificity than the SCSS rule. This commit fixes the issue by replacing `bg-view` by `bg-inherit`, which makes background unchanged (matches global channel member list background) but inherit is necessary for proper IM status background in all cases. `bg-inherit` also has less specificity because it hasn't the `!important` like `bg-view`. In dark theme, color is adjusted beca

Mouse hovering on channel member list item had no background color change. This happens because `bg-view` had more specificity than the SCSS rule.

This commit fixes the issue by replacing `bg-view` by `bg-inherit`, which makes background unchanged (matches global channel member list background) but inherit is necessary for proper IM status background in all cases. `bg-inherit` also has less specificity because it hasn't the `!important` like `bg-view`.

In dark theme, color is adjusted because `bg-view` and `gray-200` are the same.

Before (hover on Marc Demo)
<img width="405" alt="Screenshot 2024-08-29 at 15 23 54" src="https://github.com/user-attachments/assets/6ae8815e-9c0c-41d2-b369-9d9c78b920b1">


After
<img width="402" alt="Screenshot 2024-08-29 at 15 18 49" src="https://github.com/user-attachments/assets/2a0f04e6-4dd6-4c63-aa0e-882f7b54d8b7">

Forward-Port-Of: odoo/odoo#178460
Forward-Port-Of: odoo/odoo#178387

This commit adds a localization module for Jordan. It includes the following: 1. Chart of accounts. 2. Accounts groups. 3. Taxes. 4. Tax report. task-2732319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176683

This commit adds a localization module for Jordan. It includes the following:
1. Chart of accounts.
2. Accounts groups.
3. Taxes.
4. Tax report.

task-2732319




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

Forward-Port-Of: odoo/odoo#176683

Steps to reproduce: - Payroll > Contracts > Contracts - Pick a running contract - Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends -- Both it and the previous entry have a work entry type -- They both have different types - Work Entries > Work entries - Regenerate work entries for the employee whose contract you editted - It appears as a singular block of the first entry's type For example Monday afernoon has an entry from 13:00 to 17:

Steps to reproduce:
- Payroll > Contracts > Contracts
- Pick a running contract
- Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends
-- Both it and the previous entry have a work entry type -- They both have different types
- Work Entries > Work entries
- Regenerate work entries for the employee whose contract you editted
- It appears as a singular block of the first entry's type

For example Monday afernoon has an entry from 13:00 to 17:00, give it type attendance then create a new line from 17:00 to 18:00 with type ovetime hours. This is interpreted as a singular work entry of type attendance spanning from 13:00 to 18:00.

Work entries of different type should be kept separate or at least show all encompassed wok entry types. Preventing the merge is difficult as other modules likely want this behavior in resource.calendar hence the post processing method used here.

opw-4053366

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

Forward-Port-Of: odoo/odoo#177755