Have a partner in need of action with the followup level configured to Send an Email, with 'Automatic' enabled Case 1: - Send the followup manually - Reply to the follouwp mail - Message will be posted as log note but the system link the message with the previous one[1], where user is the author and will be automatically notified Case 2: - Wait for the cron to send followup automatically - Reply to the followup mail - Message will be posted as log note but since OdooBot is the author

Have a partner in need of action with the followup level configured to Send an Email, with 'Automatic' enabled

Case 1:
- Send the followup manually
- Reply to the follouwp mail
- Message will be posted as log note but the system link the message with the previous one[1], where user is the author and will be automatically notified

Case 2:
- Wait for the cron to send followup automatically
- Reply to the followup mail
- Message will be posted as log note but since OdooBot is the author of the previous message no user will receive any notification

With this commit we make use of the followup responsible when sending followup email automatically before defaulting to OdooBot

[1] https://github.com/odoo/odoo/blob/fe4b2a6d08a450b281e7ac0676afd51a88dd6008/addons/mail/models/mail_thread.py#L1182

opw-4000835

Forward-Port-Of: odoo/enterprise#67391

Create group of tax 5% + 5% and create invoice with two lines with same tax and one line with analytic and another line without analytic then tax_details is wrong because tax.analytic is NULL 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#178390

Create group of tax 5% + 5% and create invoice with two lines with same tax and one line with analytic and another line without analytic

then tax_details is wrong because tax.analytic is NULL

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#178390

On linux and Windows, CTRL + left clic on links, e.g. a customer on an invoice opens a new tab. This browser behavior is similar with regular links using Command + Left clic on MacOS. It wasn't working for many2one links in Odoo because the clic was captured and prevented the browser default behavior. It was not captured only for the `ctrlKey` currently. This revision adds the `metaKey` in addition to the `ctrlKey` to the non-capture condition. There are similar conditions a bit ev

On linux and Windows, CTRL + left clic on links,
e.g. a customer on an invoice
opens a new tab.

This browser behavior is similar with regular links using Command + Left clic on MacOS.

It wasn't working for many2one links in Odoo because the clic was captured and prevented the browser default behavior. It was not captured only for the `ctrlKey` currently.

This revision adds the `metaKey` in addition to the `ctrlKey` to the non-capture condition.

There are similar conditions a bit everywhere in the code:
- https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/barcodes/static/src/js/barcode_events.js#L170-L171
- https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/mail/static/src/models/user_setting/user_setting.js#L163
- https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/web/static/src/core/hotkeys/hotkey_service.js#L250
- https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js#L1705-L1710
- https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/website_slides/static/src/js/slides_embed.js#L178
- https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/documents/static/src/js/documents_controller_mixin.js#L975
- https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/documents_spreadsheet/static/src/js/o_spreadsheet/o_spreadsheet.js#L31440
- https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/timesheet_grid/static/src/js/timesheet_grid/timesheet_timer_grid_renderer.js#L301
- https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/web_enterprise/static/src/webclient/home_menu/home_menu.js#L434
- https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/web_gantt/static/src/js/gantt_renderer.js#L163
- https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/web_gantt/static/src/js/gantt_row.js#L159

Unfortunately, given the nature of this behavior (requires a Command keystroke + check that a new tab is opened), it cannot really be tested in a unit test, not even a web tour.

Forward-Port-Of: odoo/odoo#178314
Forward-Port-Of: odoo/odoo#178268

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

When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets. No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues. [1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a Found while working on task-3930204 Forward-Port-Of: odoo/odoo#178618

When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets.

No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues.

[1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a

Found while working on task-3930204

Forward-Port-Of: odoo/odoo#178618

If nobody gave a global discount (fixed amount/on SO) in a given company before, the first user to give a global discount through the dedicated wizard would create the dedicated Discount product for that company. Nevertheless, it was not done in sudo, so the user would get a traceback if he didn't have admin rights (for company update) or manager rights (for the product creation). opw-4048403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-

If nobody gave a global discount (fixed amount/on SO) in a given company before, the first user to give a global discount through the dedicated wizard would create the dedicated Discount product for that company.

Nevertheless, it was not done in sudo, so the user would get a traceback if he didn't have admin rights (for company update) or manager rights (for the product creation).

opw-4048403





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

Forward-Port-Of: odoo/odoo#178361

This commit reverts dd331e7bb27c533808a01b53f80e0ee7f1dfed7f This change has caused a lot of issues recently, and despite some other fixes, we believe it's safer to revert it for now. opw-4126140 opw-4114139 opw-4115510 opw-4117520 opw-4109625 opw-4115415 opw-4143237 opw-4123382 opw-4136888 opw-4125807 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

This commit reverts dd331e7bb27c533808a01b53f80e0ee7f1dfed7f

This change has caused a lot of issues recently, and despite some other fixes, we believe it's safer to revert it for now.

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

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#178622
Forward-Port-Of: odoo/odoo#178587

With negative unit price it was possible to have a zero division error when ventilating the analytic distributions. Example: Create a new sale order, set the business partner and other header data. Add a line, with a VAT of 15% for example. With a product, It doesn't matter which one. a price. To this line, add 2 analytics distributions. Add a second line whit an other product, a price and an other VAT 7% for example. Add the same analytic distribution. Add a third line, a discount one, same pr

With negative unit price it was possible to have a zero division error when ventilating the analytic distributions. Example:
Create a new sale order, set the business partner and other header data. Add a line, with a VAT of 15% for example. With a product, It doesn't matter which one. a price. To this line, add 2 analytics distributions. Add a second line whit an other product, a price and an other VAT 7% for example. Add the same analytic distribution. Add a third line, a discount one, same price * -1 then then second. same VAT then the second. Add analytic distribution. Make a down payment

This fix also remove the 0 amount down payment line this would create.

opw-4140669

Forward-Port-Of: odoo/odoo#178668
Forward-Port-Of: odoo/odoo#178043

In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal instead of the backend. This happens because of the override of _notify_get_groups in the account module adds an extra recipient group 'additional_intended_recipient' in the first position of the groups list. This group is based on 'portal_customer' but its validation function will evaluate to Tr

In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal instead of the backend.

This happens because of the override of _notify_get_groups in the account module adds an extra recipient group 'additional_intended_recipient' in the first position of the groups list. This group is based on 'portal_customer' but its validation function will evaluate to True for internal users.

In any case, the recipient group for user must be considered first as only internal user will be validated through its function. The recipient group portal_customer can then be added in the second position, ie after user but before portal, and the eventual additional_intended_recipient can be set before portal_customer as it is the case now.

Description of the issue/feature this PR addresses:

Steps to reproduce:
1. Have a internal user that manages notifications by email
2. On a customer invoice log a note and ping this user using '@'

Current behavior before PR:

The email contains a link to the portal

Desired behavior after PR is merged:

The email contains a link to the backend


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

Forward-Port-Of: odoo/odoo#178105
Forward-Port-Of: odoo/odoo#176818