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#178048
Forward-Port-Of: odoo/odoo#175963

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

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

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

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

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

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

The route `/website_mail/follow` can create new contacts, for that reason, it should be protected with recaptcha similar to `/website/form/<string:model_name>` and `/website_mass_mailing/subscribe` This PR adds the Recaptcha check on the endpoint: `/website_mail/follow` Before this PR it was possible to create as much dummy contact as you wanted as an attacker with a simple script opw-4023724 Forward-Port-Of: odoo/odoo#178259 Forward-Port-Of: odoo/odoo#175083

The route `/website_mail/follow` can create new contacts, for that reason, it should be protected with recaptcha similar to `/website/form/<string:model_name>` and `/website_mass_mailing/subscribe`

This PR adds the Recaptcha check on the endpoint: `/website_mail/follow`

Before this PR it was possible to create as much dummy contact as you wanted as an attacker with a simple script

opw-4023724

Forward-Port-Of: odoo/odoo#178259
Forward-Port-Of: odoo/odoo#175083

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

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

Suppose the following structure: ---------------------------------------------- BoM of Main kit: - BoM Type: Kit - Quantity: 4 - Components: * 1 x Sub kit A * 1 x Sub kit B BoM of Subkit A: - BoM Type: Kit - Quantity: 1 - Components: * 2 x Component A (Cost: $10, Storable) BoM of Subkit B: - BoM Type: Kit - Quantity: 1 - Components: * 2 x Component B (Cost: $6, Storable) When creating a sale order for 1 Main Kit, delivering the components

Suppose the following structure:
----------------------------------------------
BoM of Main kit:
  - BoM Type: Kit
  - Quantity: 4
  - Components:
    * 1 x Sub kit A
    * 1 x Sub kit B

BoM of Subkit A:
  - BoM Type: Kit
  - Quantity: 1
  - Components:
    * 2 x Component A (Cost: $10, Storable)

BoM of Subkit B:
  - BoM Type: Kit
  - Quantity: 1
  - Components:
    * 2 x Component B (Cost: $6, Storable)

When creating a sale order for 1 Main Kit, delivering the components and posting the invoice, the Cost Of Goods Sold computed by the _stock_account_get_anglo_saxon_price_unit method was ignoring the COGS for the Subkit B.
This is due to the commit https://github.com/odoo/odoo/commit/31e1352df686d8a23628ade83d321929c49d6f4e which fetches the BOMs from the stock moves linked to the Sale Order. As no component is present directly in the bom lines of the Main Kit BOM, the bom was omitted.

Now, if the product's bom is not present in the stock move's bom, we'll fetch one the old way.

opw-4033293

Forward-Port-Of: odoo/odoo#177248
Forward-Port-Of: odoo/odoo#174853

This commit fixes an issue that allowed users to paste text containing line breaks inside of a no line break input (like text fields with line_break = False option). This is resolved by replacing line breaks by white spaces on input when the event originates from a paste action. Task 4130435 Forward-Port-Of: odoo/odoo#178044

This commit fixes an issue that allowed users to paste text containing line breaks inside of a no line break input (like text fields with line_break = False option). This is resolved by replacing line breaks by white spaces on input when the event originates from a paste action.

Task 4130435

Forward-Port-Of: odoo/odoo#178044

Before this commit we had (rare) situation where events would have matching dates, and then Postgres wouldn't guarantee their order, causing issue with pagination. [Reproduce] - have events with the same dates - query the events with and without limit opw-4061191 Forward-Port-Of: odoo/odoo#177553

Before this commit we had (rare) situation where events would have
matching dates, and then Postgres wouldn't guarantee their order,
causing issue with pagination.

[Reproduce]
- have events with the same dates
- query the events with and without limit

opw-4061191

Forward-Port-Of: odoo/odoo#177553

[FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the Sender part, which was skipping whatsapp

[FIX] mail: include whatsapp in webpush notifications

There are couple of components in the notification
architecture. For the sake of illustration
let's simplify it with the following: Sender -> Queuer -> Receiver
Queuer is an FMC backend, so we should only be concerned about the
other two. Receiver which is just a frontend service worker that will
generate notifications as soon as he receives an event. The issue
(before this commit) was in the Sender part, which was skipping
whatsapp type message generation.

[Reproduce]
- Configure Whatsapp account, include user A in "Notify users"
- Allow notifications in your browser (chat icon/ OdooBot suggestion)
- Send a whatsapp message to the configured whatsapp number
- BUG: Push notification is not showing up

opw-3720699

Forward-Port-Of: odoo/odoo#175638

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

SYSCOHADA should stay SYSCOHADA when translated task-4118393 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#177886

SYSCOHADA should stay SYSCOHADA when translated

task-4118393

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

In some cases, like when another tests activates a language, the log output can include an extra line. See an example here: https://runbot.odoo.com/runbot/build/66699073 After this commit, we only check for the logs we care about. See also: https://github.com/odoo/odoo/pull/175344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177209

In some cases, like when another tests activates a language, the log output can include an extra line.
See an example here: https://runbot.odoo.com/runbot/build/66699073 After this commit, we only check for the logs we care about.

See also: https://github.com/odoo/odoo/pull/175344


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

Forward-Port-Of: odoo/odoo#177209

## Issue: - When creating a kit BoM with two components that the total of their cost share is 100, we get this UserError when saving: 'The total cost share for a BoM's components has to be 100%.'" ## Steps To Reproduce: - Create a BoM of type Kit. - Add 2 components. - Set their cost shares to 99.99 and 0.01. - Save and Notice the error: "The total cost share for a BoM's component have to be 100" ## Solution: - After saving, the [`float_round`](https://github.com/odoo/odoo/blob/048

## Issue:
- When creating a kit BoM with two components that the total  of their cost share is 100, we get this UserError when saving:  'The total cost share for a BoM's components has to be 100%.'"

## Steps To Reproduce:
- Create a BoM of type Kit.
- Add 2 components.
- Set their cost shares to 99.99 and 0.01.
- Save and Notice the error: "The total cost share for a BoM's component have to be 100"

## Solution:
- After saving, the [`float_round`](https://github.com/odoo/odoo/blob/048ed950ad32187a8e7ae7811a5afc87d9ce8ac8/odoo/tools/float_utils.py#L35) method is eventually called. When it reaches the line [`result = rounded_value * rounding_factor`](https://github.com/odoo/odoo/blob/048ed950ad32187a8e7ae7811a5afc87d9ce8ac8/odoo/tools/float_utils.py#L113) with `rounded_value = 9999.0` and `rounding_factor = 0.01`,  it returns `99.99000001`.
- A possible fix is to modify the `float_round` method to include a condition before returning the result:
    ``` python
    if precision_digits or precision_rounding:
           decimal_places = precision_digits or len(str(precision_rounding).split('.')[1])
           return round(result, decimal_places)```
- However, I believe it might be too low-level, so I kept it simple by rounding the `bom.lines` before summing them and returning the UserError`.

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

Forward-Port-Of: odoo/odoo#177915
Forward-Port-Of: odoo/odoo#177015

Steps to reproduce: - Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos` - Enable "Use QR Code on ticket" - Make an order and validate it inside the POS - Open in an incognito window the link given by the QR Code Issues: Internal error, the cause is the multiple else that are added to the `get_info_div` block. This problem is blocking #175591 and #175593 related enterprise PR: https://github.com/odoo/enterprise/pull/68432 Forward-Port-Of: odoo/odoo#176746

Steps to reproduce:
- Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos`
- Enable "Use QR Code on ticket"
- Make an order and validate it inside the POS
- Open in an incognito window the link given by the QR Code

Issues:
Internal error, the cause is the multiple else that are added to the `get_info_div` block.

This problem is blocking #175591 and #175593

related enterprise PR: https://github.com/odoo/enterprise/pull/68432

Forward-Port-Of: odoo/odoo#176746

**Description of the issue/feature this PR addresses:** There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method. **Steps to reproduce:** 1) With a database in v16 onwards, install the account_check_printing module. 2) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal bank with more than one outgoing payment with "Checks" Payment Method. 3

**Description of the issue/feature this PR addresses:**
There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Steps to reproduce:**

1) With a database in v16 onwards, install the account_check_printing module.

2) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal bank with more than one outgoing payment with "Checks" Payment Method.

3) Go to "Accounting / Vendor / Payments" and create a new payment with journal created on step 1 and "Checks" payment method and confirm.

4) Go to "Accounting" and on "Accounting dashboard" click on "Check to print" on Journal created on step 1 and then a bug with traceback is raised.

**Current behavior before PR:**
There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Desired behavior after PR is merged:**
There is not a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Video/Screenshot link:**
https://drive.google.com/file/d/1r6A3uMkFv2nIDZ1HYJLgj6e18pNH1P67/view

Ticket Adhoc side: 75606
Task latam: 1217

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

Forward-Port-Of: odoo/odoo#168383

To reproduce the bug, follow these steps: 1. Create a new time off type. 2. Create a new accrual plan. 3. Set the "Accrued Gain Time" field to “At the start of the accrual period.” 4. Create a new milestone with a cap. 5. Create a new allocation set its type to accrual then link it to our accrual plan. 6. Set the start date in the past so that the accrued days reach the cap. 7. Create a new leave in the past related to the allocation. 8. Check your balance for a future date in the Time

To reproduce the bug, follow these steps:

1. Create a new time off type.
2. Create a new accrual plan.
3. Set the "Accrued Gain Time" field to “At the start of the accrual period.”
4. Create a new milestone with a cap.
5. Create a new allocation set its type to accrual then link it to our accrual plan.
6. Set the start date in the past so that the accrued days reach the cap.
7. Create a new leave in the past related to the allocation.
8. Check your balance for a future date in the Time Off app.

Normally, with accrual allocation, we should see the allocation increase. The problem here is that in the future, the
allocation decreases.

This issue arises due to the way the `leaves_taken` field is computed.

https://github.com/odoo/odoo/blob/08a4b9d78addeefde24b189f0066540e0dcee4c4/addons/hr_holidays/models/hr_leave_allocation.py#L215-L220

The value is retrieved from a default dictionary, which is processed based on existing records in the database. When we
attempt to fetch the value using a new instance that only exists in memory, the key returns the default value of 0.

Additionally, if we modify step 7 to set the leave in the future, the accrual value caps out at a level below the
intended maximum. In some cases, if the data-fetching function is called with the same parameters consecutively, we
receive different outputs.

These issues arise because the new record persists as a cache. When we retrieve a new record with the same origin as a
previous call, we receive the previously processed data. This also leads to a problem with recursion in the function
`_get_future_leaves_on`. This commit addresses and resolves these issues.

opw-4040882

Forward-Port-Of: odoo/odoo#174354

Since the refactor https://github.com/odoo/odoo/pull/110188, the welcome page had several bugs: 1) The `fa-microphone-slash` icon was displayed when the microphone was on instead of when the microphone was mute. 2) The localStorage keys `discuss_call_preview_join_mute` and `discuss_call_preview_join_video` were set with booleans, while the localStorage stores as strings, which made them always truthy as soon as they were set. 3) The microphone preview was not working as the `srcObject`

Since the refactor https://github.com/odoo/odoo/pull/110188, the welcome page had several bugs:

1) The `fa-microphone-slash` icon was displayed when the microphone was on instead of when the microphone was mute.

2) The localStorage keys `discuss_call_preview_join_mute` and `discuss_call_preview_join_video` were set with booleans, while the localStorage stores as strings, which made them always truthy as soon as they were set.

3) The microphone preview was not working as the `srcObject` of the audio element was `undefined` because we were using `this.audioStream` instead of `this.state.audioStream`.

4) Before the refactor, the preview was automatically started when opening the welcome page, this commit restores this behavior: https://github.com/odoo/odoo/blob/16.0/addons/mail/static/src/models/discuss_public_view.js#L46-L49

5) Streams (tracks) were not closed after leaving the welcome view, nor was it checked whether they were still needed after the `getUserMedia` promise.

Forward-Port-Of: odoo/odoo#177525

**Current behavior before PR:** - When a table was created within an empty list item `(li)`, it was inserted directly inside the `ul` and as a sibling of the list item `(li)`. Furthermore, an additional `li` element was generated after the table. **Desired behavior after PR is merged:** - Now, when a table created inside empty `li` elements, it will be correctly inserted within the list item itself instead of the `ul`. Additionally, no extra `li` element will be generated after the tabl

**Current behavior before PR:**

- When a table was created within an empty list item `(li)`, it was inserted directly inside the `ul` and as a sibling of the list item `(li)`. Furthermore, an additional `li` element was generated after the table.

**Desired behavior after PR is merged:**

- Now, when a table created inside empty `li` elements, it will be correctly inserted within the list item itself instead of the `ul`. Additionally, no extra `li` element will be generated after the table.

task-3550599

Forward-Port-Of: odoo/odoo#164304

Purpose ======= Fix the traceback appearing when flagging a question or answer without being a moderator. Specification ============= The .forum_answer class has been removed from the element when doing the website_forum redesign (ref: https://github.com/odoo/odoo/commit/4b1cf2e06643171e5ae10ea44648c4db66d09319 ) The element is thus not found and a traceback occurs when trying to perform the animation. Now using the 'o_wforum_answer' element and making sure it exists before callin

Purpose
=======
Fix the traceback appearing when flagging a question or answer
without being a moderator.

Specification
=============
The .forum_answer class has been removed from the element when doing the
website_forum redesign (ref: https://github.com/odoo/odoo/commit/4b1cf2e06643171e5ae10ea44648c4db66d09319 )
The element is thus not found and a traceback occurs when trying to perform
the animation.

Now using the 'o_wforum_answer' element and making sure it exists before
calling the animation.

Task-4058832

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

Forward-Port-Of: odoo/odoo#173614

When the l10n_es_pos module is installed, the post_init_hook attempts to create an account journal for each Spanish company using a chart template. However, the method does not verify whether the journal already exists for the company, leading to potential duplication errors. Steps to Reproduce: - Create a journal for a Spanish company with the code 'SINV'. - Install the Point of Sale module and the l10n_es_pos module. - An error is raised because the journal 'SINV' already exists. Solu

When the l10n_es_pos module is installed, the post_init_hook attempts to create an account journal for each Spanish company using a chart template. However, the method does not verify whether the journal already exists for the company, leading to potential duplication errors.

Steps to Reproduce:
- Create a journal for a Spanish company with the code 'SINV'.
- Install the Point of Sale module and the l10n_es_pos module.
- An error is raised because the journal 'SINV' already exists.

Solution:
This fix adds a check to ensure the journal does not already exist before attempting to create it.

opw-4108466

Forward-Port-Of: odoo/odoo#176953

The tax_discount field was removed in 512574861691. We take the opportunity to also mention our new EDI module. task-4145576 Forward-Port-Of: odoo/odoo#178291

The tax_discount field was removed in 512574861691. We take the opportunity to also mention our new EDI module.

task-4145576

Forward-Port-Of: odoo/odoo#178291

Steps to reproduce: - Log in as admin - Project > Configuration > Projects > Field service - In the Settings tab set Visibility to 'Invited Internal Users' - Create a task with Marc Demo as assignee - Check that Marc Demo is a follower of the task and not of the project - Settings > Users & Companies > Users > Marc Demo - Set Marc Demo's access rights for Project and Field Service to 'User' - Log in as Marc Demo > Field Service - No tasks are displayed As per the specifications of t

Steps to reproduce:
- Log in as admin
- Project > Configuration > Projects > Field service
- In the Settings tab set Visibility to 'Invited Internal Users'
- Create a task with Marc Demo as assignee
- Check that Marc Demo is a follower of the task and not of the project
- Settings > Users & Companies > Users > Marc Demo
- Set Marc Demo's  access rights for Project and Field Service to 'User'
- Log in as Marc Demo > Field Service
- No tasks are displayed

As per the specifications of the 'Invited Internal Users' mode of project privacy, a user should be able to see tasks they are a follower of even if they do not have access to the project they are from. This is correctly reflected in Projects > Tasks > My Tasks where the followed task is visible.

This does not happen because of a lack of access rights on the task as we can copy the url of the task in Field Service as admin and access the page when pasting it as demo.

The issue here is twofold:
- is_fsm is currently a field defined with both 'related' and 'search' arguments. Prior to 17.2, search is ignored in favor of search_related so the domain once again tries and fails to access the information on the related project. The search function defined here (which was previously unused) bypasses the issue by getting is_fsm through an SQL query.

- Since is_fsm is not storable on task, the search function is used to translate domains of type ('is_fsm', '=', ...). However the _search_is_fsm function did not take into account the value passed as argument (only the operator), resulting in domains like ('is_fsm', '=', 'False') not being inverted as they should.

opw-4003133

Forward-Port-Of: odoo/enterprise#69071

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

The s/h in column B of the export of the csv for DateV should be in uppercase. task-4131986 Forward-Port-Of: odoo/enterprise#68868 Forward-Port-Of: odoo/enterprise#68795

The s/h in column B of the export of the csv for DateV should be in uppercase.

task-4131986

Forward-Port-Of: odoo/enterprise#68868
Forward-Port-Of: odoo/enterprise#68795

In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#68875 Forward-Port-Of: odoo/enterprise#53722

In the payment report, a space was missing between the VAT label and
the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1
class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.".

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

Forward-Port-Of: odoo/enterprise#68875
Forward-Port-Of: odoo/enterprise#53722

Performs test of a related commit in communiy: [FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the

Performs test of a related commit in communiy:

[FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration
let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the Sender part, which was skipping whatsapp type message generation.

[Reproduce]
- Configure Whatsapp account, include user A in "Notify users"
- Allow notifications in your browser (chat icon/ OdooBot suggestion)
- Send a whatsapp message to the configured whatsapp number
- BUG: Push notification not showing up

opw-3720699

Forward-Port-Of: odoo/enterprise#68453

This commit make sure the values are get in the same order every time to avoid falsy error runbot 76085 Forward-Port-Of: odoo/enterprise#68963

This commit make sure the values are get in the same order every time to avoid falsy error

runbot 76085

Forward-Port-Of: odoo/enterprise#68963

[IMP] l10n_in_asset: add unit tests to indian asset depreciation This is about adding test to the new indian asset depreciation feature https://github.com/odoo/enterprise/pull/67225/commits/23591bb39500018afb3c4dab1c33c665c5f3a064 task-id#3909619 original-pr: https://github.com/odoo/enterprise/pull/67225 Forward-Port-Of: odoo/enterprise#68460

[IMP] l10n_in_asset: add unit tests to indian asset depreciation

This is about adding test to the new indian asset depreciation feature https://github.com/odoo/enterprise/pull/67225/commits/23591bb39500018afb3c4dab1c33c665c5f3a064

task-id#3909619

original-pr: https://github.com/odoo/enterprise/pull/67225

Forward-Port-Of: odoo/enterprise#68460

Currently, a traceback occurs when the user creates a PO with a product from a company other than 'KE'. To reproduce this issue: 1) Install `l10n_ke_edi_oscu_stock` 2) Switch to a company other than `KE` 3) Create a PO with a product > `Confirm Order` 4) Click on `Receive Products` > `Validate` and get back to PO through breadcrumb 5) Click on the `Create Bill` Error:- ``` ValueError: Compute method failed to assign purchase.order.line(19, ).display_name ``` The above error o

Currently, a traceback occurs when the user creates a PO with a product from a company other than 'KE'.

To reproduce this issue:

1) Install `l10n_ke_edi_oscu_stock`
2) Switch to a company other than `KE`
3) Create a PO with a product > `Confirm Order`
4) Click on `Receive Products` > `Validate` and get back to PO through breadcrumb 
5) Click on the `Create Bill`

Error:-
```
ValueError: Compute method failed to assign purchase.order.line(19, ).display_name
```

The above error occurs because of a computing method in which a filter is used to access the `KE` company record.

But when the user is not in `KE` company it returns None. 
Here, the `display_name` is a readonly and non-stored field.

Which leads to the above traceback.

https://github.com/odoo/enterprise/blob/7a9157e059fd70831eb3174863a797abdb99ad53/l10n_ke_edi_oscu_stock/models/purchase.py#L71-L73

After applying this commit, We can resolve the above issue by giving 
the POl name when it is not `KE` company.

sentry-5726618591

Forward-Port-Of: odoo/enterprise#68693

Steps to reproduce: - Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos` - Enable "Use QR Code on ticket" - Make an order and validate it inside the POS - Open in an incognito window the link given by the QR Code Issues: Internal error, the cause is the multiple else that are added to the `get_info_div` block. This problem is blocking #175591 and #175593 related community PR: https://github.com/odoo/odoo/pull/176746 Forward-Port-Of: odoo/enterprise#68432

Steps to reproduce:
- Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos`
- Enable "Use QR Code on ticket"
- Make an order and validate it inside the POS
- Open in an incognito window the link given by the QR Code

Issues:
Internal error, the cause is the multiple else that are added to the `get_info_div` block.

This problem is blocking #175591 and #175593

related community PR: https://github.com/odoo/odoo/pull/176746

Forward-Port-Of: odoo/enterprise#68432

Version: 17.0+ Current Behavior: Peppol fields are automatically populated based on the `vat` field of the res.partner record. With l10n_mx localization installed the `vat` field is based on the first two letters of the first name and the first letter of the last name. However, the peppol fields with be automatically computed if the first two letters are similar to country codes. Purpose of this PR: This PR overrides the peppol computation so that the peppol fields are emptied when l10n_

Version: 17.0+

Current Behavior:
Peppol fields are automatically populated based on the `vat` field of the res.partner record. With l10n_mx localization installed the `vat` field is based on the first two letters of the first name and the first letter of the last name. However, the peppol fields with be automatically computed if the first two letters are similar to country codes.

Purpose of this PR:
This PR overrides the peppol computation so that the peppol fields are emptied when l10n_mx_edi is installed. These fields are unused in l10n_mx localization so they can be omitted.

Steps to Reproduce on Runbot:
1) Install accounting and contacts
2) Create a contact with l10n_mx vat format (i.e. ESPN0101011E2) 
3) Navigate to the Accounting Tab of the partner record and find that the peppol fields are filled.

Notes:
In the current behavior, the user will have to manually empty the peppol fields to avoid receiving the error of incorrect peppol format.

opw-4074094

Forward-Port-Of: odoo/enterprise#67737

Added PLE 12.1 and PLE 13.1 records for detailed inventory tracking. PLE 12.1 tracks inventory in physical units, while PLE 13.1 includes both physical and monetary values. Both records are updated semi-annually and reported monthly, with submission deadlines of October 1st and April 1st, per Superintendent Resolution 169-2015. Forward-Port-Of: odoo/enterprise#62696

Added PLE 12.1 and PLE 13.1 records for detailed inventory tracking. PLE
12.1 tracks inventory in physical units, while PLE 13.1 includes both
physical and monetary values. Both records are updated semi-annually
and reported monthly, with submission deadlines of October 1st and
April 1st, per Superintendent Resolution 169-2015.

Forward-Port-Of: odoo/enterprise#62696

Issue ----- Error when multiple input lines on a payslip are of the same type. Steps ----- [hr_payroll] 1. Create a salary attachment for an employee, type "Attachment of salary", with a monthly amount and total amount A. 2. Create another salary attachment for the same employee, same type and monthly amount and total amount B different from A. 3. Create a payslip for the employee, create a contract with a start date matching the salary attachment date. On "Other Inputs", remove the "A

Issue
-----
Error when multiple input lines on a payslip are of the same type.

Steps
-----
[hr_payroll]
1. Create a salary attachment for an employee, type "Attachment of salary", with a monthly amount and total amount A.
2. Create another salary attachment for the same employee, same type and monthly amount and total amount B different from A.
3. Create a payslip for the employee, create a contract with a start date matching the salary attachment date. On "Other Inputs", remove the "Attachment of salary" line. Create two input lines of type "Attachment of salary", one with amount A and another with amount B.
4. Compute sheet > Confirm > Mark as paid > ** Error **

Cause
-----
Generally, input lines of the same type on a payslip will be merged in one input line, but it is not the case if there are multiple salary attachments of the same type matching these input lines.

opw-4066851

Forward-Port-Of: odoo/enterprise#68682
Forward-Port-Of: odoo/enterprise#68441

…g from it How to reproduce: - Install documents_hr - Open Employee -> "Abigail Peterson" -> stats button Documents - Upload a file The document is not linked to the employee record "Abigail Peterson". With this fix, it is and you can see it in the inspector of that document: "Employee Abigail Peterson" Task-4122377 Forward-Port-Of: odoo/enterprise#68561 Forward-Port-Of: odoo/enterprise#68541

…g from it

How to reproduce:
- Install documents_hr
- Open Employee -> "Abigail Peterson" -> stats button Documents
- Upload a file

The document is not linked to the employee record "Abigail Peterson". With this fix, it is and you can see it in the inspector of that document: "Employee Abigail Peterson"

Task-4122377

Forward-Port-Of: odoo/enterprise#68561
Forward-Port-Of: odoo/enterprise#68541