Steps to reproduce: - Create a kit with components Uom set as Kg - Create an SO for the kit using packaging - Validate the delivery and try printing the delivery slip ERROR Bug: when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units) Fix: Ignore kit lines (will be removed any way in _get_aggregated_product_quantities) opw-3758203 Forward-Port-Of: odoo/o

Steps to reproduce:
- Create a kit with components Uom set as Kg
- Create an SO for the kit using packaging
- Validate the delivery and try printing the delivery slip ERROR

Bug:
when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units)

Fix:
Ignore kit lines (will be removed any way in _get_aggregated_product_quantities)

opw-3758203

Forward-Port-Of: odoo/odoo#161920

Prior to this commit, if a "Buy X get Y" promotion was in place, with a free product reward associated with a specific tag, the computation of the free product reward could be incorrect in the Point of Sale when combined with products carrying the tag. opw-3753994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158618 Forward-Port-Of: odoo/odoo#157133

Prior to this commit, if a "Buy X get Y" promotion was in place, with a free product reward associated with a specific tag, the computation of the free product reward could be incorrect in the Point of Sale when combined with products carrying the tag.

opw-3753994

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

Forward-Port-Of: odoo/odoo#158618
Forward-Port-Of: odoo/odoo#157133

Since [1] when the website menu was converted to backend, the value of the "Cover Photo" option of the `s_facebook_page` snippet is not computed properly. This happened because when converting `.data()` to `.dataset` in [2], the stored values became implicitly converted to strings. This commit fixes this by expecting both string and boolean values when computing the widget value. Steps to reproduce: - Edit a website page. - Drop a "Banner" block. - Drop a "Facebook" block inside the "B

Since [1] when the website menu was converted to backend, the value of the "Cover Photo" option of the `s_facebook_page` snippet is not computed properly.
This happened because when converting `.data()` to `.dataset` in [2], the stored values became implicitly converted to strings.

This commit fixes this by expecting both string and boolean values when computing the widget value.

Steps to reproduce:
- Edit a website page.
- Drop a "Banner" block.
- Drop a "Facebook" block inside the "Banner".
- Toggle "Cover Photo" on.
- Save.
- Edit.
- Select the "Facebook" block.

=> The option displays "Cover Photo" as toggled off.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af

opw-3894649

Forward-Port-Of: odoo/odoo#164561

[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure that the "Shared Customer Accounts" setting is disabled. The user is so forced to create an account per website. - As a visitor, create an account in each website using the same email address. -> No issue; it is possible to create two accounts with the same email address. Steps to repr

[FIX] portal, website: allow to grant portal access for certain users

Context:
- Have a db with two websites (website1 and website2) with two different
domains.
- For those two websites, make sure that the "Shared Customer Accounts"
setting is disabled. The user is so forced to create an account per
website.
- As a visitor, create an account in each website using the same email
address.

-> No issue; it is possible to create two accounts with the same email
address.

Steps to reproduce the issue:
- Create two contacts (e.g. partner or customer) with the same email
address. One is linked to website1, the other is linked to website2.
- Select them, click on "Action" and then on "Grant portal access".
- Click on "Grant Access" for the first contact; it works as expected.

-> It is not possible to grant access for the second contact.

The goal of this commit is to ensure that the two described behaviors
lead to the same results. More specifically, it should be possible to
grant portal access for two partners that have:
- The same email address but are linked to different websites that have
the "Shared Customer Accounts" setting disabled.
- The same email address. One user is linked to a website that has the
"Shared Customer Accounts" setting disabled and the other is not linked
to a website.

It should however not be possible to grant portal access for two
partners that have:
- The same email address and are linked to the same website that has the
"Shared Customer Accounts" setting disabled.
- The same email address and are not linked to a website.

It should also not be possible to grant portal access for a partner that
is not linked to a website if it exists a user with the same email
address that is linked to the current website. Indeed, in this
situation, the partner is redirected to the current website at the
creation of its account and an "Access Denied" message would then be
displayed.

To solve the problem, the method `_get_similar_user_domain()` has been
implemented in the "website" module. Its goal is to build the domain
needed to find the users that have the same email than partners
depending on their linked website characteristics. The
`_is_portal_similar_than_user()` method has also been introduced. Its
goal is to check if the credentials of a portal user and a user are the
same. If it is the case, `email_state` field of the portal user is set
to `exist`.

task-3640503

Forward-Port-Of: odoo/odoo#166730
Forward-Port-Of: odoo/odoo#148482

The ptt extension allows odoo to listen to push to talk events even when chrome is not focused. Until now, the extension did not support versioning which made it hard to improve and fix it. This PR introduces versioning for the ptt extension in order to solve this issue. task-3950630 Forward-Port-Of: odoo/odoo#166168

The ptt extension allows odoo to listen to push to talk events
even when chrome is not focused.

Until now, the extension did not support versioning which made it
hard to improve and fix it.

This PR introduces versioning for the ptt extension in order to
solve this issue.

task-3950630

Forward-Port-Of: odoo/odoo#166168

In order to work with the Balance Sheet, several accounts needed to be set up with correct account tags. Enterprise PR: https://github.com/odoo/enterprise/pull/59106 Taskid: 3060790 Forward-Port-Of: odoo/odoo#158542

In order to work with the Balance Sheet, several accounts needed to be set up with correct account tags.

Enterprise PR: https://github.com/odoo/enterprise/pull/59106

Taskid: 3060790

Forward-Port-Of: odoo/odoo#158542

Computation of sale.order.expected_date is done in sale module and overridden in sale_stock. Both function are doing mostly the same, except when it is selecting the min or max date from the sale order lines dates list based on the picking policy. Use a dedicated function to chose the final date out of the SOL dates, to simplify the override (and avoid calling the method `_expected_date` twice for each line. Also use `_expected_date` when preparing the procurement, to avoid duplicated cod

Computation of sale.order.expected_date is done in sale module and overridden in sale_stock.
Both function are doing mostly the same, except when it is selecting the min or max date from the sale order lines dates list based on the picking policy.

Use a dedicated function to chose the final date out of the SOL dates, to simplify the override (and avoid calling the method `_expected_date` twice for each line.

Also use `_expected_date` when preparing the procurement, to avoid duplicated code (and ease overrides).

Forward-Port-Of: odoo/odoo#165519

Before this commit: ========== - After scanning the product barcode, the notification of the added product was not showing in mobile mode. After this commit: ========== - After scanning the product barcode, the notification of the added product will work fine. task-3877329 Forward-Port-Of: odoo/odoo#164272

Before this commit:
==========
- After scanning the product barcode, the notification of the added product was not showing in mobile mode.

After this commit:
==========
- After scanning the product barcode, the notification of the added product will work fine.

task-3877329

Forward-Port-Of: odoo/odoo#164272

This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced. This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder. This link isn't replaced because the mail created in

This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced.
This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder.

This link isn't replaced because the mail created inside testing wizard did not give a res_id, linked to a `mailing.contact`, to the `mail.mail` created. This led the function `_prepare_outgoing_list` to be exited prematurely without replacing any placeholder.

This commit fixes the issue by adding a res_id linked to the current user to the mail.mail created in order for the method to finish its execution. But we don't want the unsubscribe links to be replaced, as the user could blacklist himself. Thus we added a context key `send_as_test` which blocks the replacement of the unsubscribe link.

task-3869575

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

Forward-Port-Of: odoo/odoo#165711

Steps to reproduce: - add a pivot in a spreadsheet - create a From/To global filter - match the filter with a datetime field of the pivot - set some values in the filter => the domain contains dates, but they should compare the values with datetimes, because a date in a given timezone might start the previous day in UTC time. opw-3805775 Task:3853821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166335

Steps to reproduce:
- add a pivot in a spreadsheet
- create a From/To global filter
- match the filter with a datetime field of the pivot
- set some values in the filter

=> the domain contains dates, but they should compare the values with datetimes, because a date in a given timezone might start the previous day in UTC time.

opw-3805775
Task:3853821


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

Forward-Port-Of: odoo/odoo#166335

Desired behavior after PR is merged: I. This PR implements a functionality where pressing the `Escape` key removes the transform widget from the image. II. Also it ensures that pressing any character key does not result in the removal of the image when the transform widget is active. task-3839151 Forward-Port-Of: odoo/odoo#160071

Desired behavior after PR is merged:

I. This PR implements a functionality where pressing the `Escape` key
removes the transform widget from the image.
II. Also it ensures that pressing any character key does not result in the
removal of the image when the transform widget is active.

task-3839151

Forward-Port-Of: odoo/odoo#160071

**Current behavior before PR:** Clicking the checkbox triggered the `mousedown` event, where the `preventDefault` function prevented the list from gaining focus. Consequently, without any focused element, clicking the breadcrumb (`o_back_button`) to navigate back failed to trigger the `blur` event, resulting in unsaved changes. **Desired behavior after PR is merged:** After removing `preventDefault` from the `mousedown` event, clicking the checkbox will now set focus on it. As a re

**Current behavior before PR:**

Clicking the checkbox triggered the `mousedown` event, where the `preventDefault`
function prevented the list from gaining focus. Consequently, without any focused 
element, clicking the breadcrumb (`o_back_button`) to navigate back failed to trigger
the `blur` event, resulting in unsaved changes.

**Desired behavior after PR is merged:**

After removing `preventDefault` from the `mousedown` event, clicking the checkbox will
now set focus on it. As a result, when the breadcrumb `o_back_button` is clicked, it 
will trigger the `blur` event, leading to the execution of `onWysiwygBlur` in `html_field`,
which will commit(save) our changes.

task-3346155

Forward-Port-Of: odoo/odoo#126007

Helper methods for building a partner/employee address in a SEPA payment report. opw-3716705 Forward-Port-Of: odoo/odoo#166205

Helper methods for building a partner/employee address in a SEPA payment report.

opw-3716705

Forward-Port-Of: odoo/odoo#166205

Purpose ------- If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back. Specification ------------- make the field required. Task: 3770194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166805

Purpose
-------

If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back.

Specification
-------------

make the field required.

Task: 3770194


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

Forward-Port-Of: odoo/odoo#166805

Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in multi-company setups, a user from a company won't be able to access `sales.orders` related to the same project but from another company. Steps ----- - Create a new project, say P, with the company field set to empty. - From company A, create a new service product, say R, that creates a tas

Issue
-----

When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in multi-company setups, a user from a company won't be able to access `sales.orders` related to the same project but from another company.

Steps
-----

 - Create a new project, say P, with the company field set to empty.
 - From company A, create a new service product, say R, that creates a task in the project P.
 - From company A, create a sales order with the product R.
 - From company B, create a new service product, say Q, that creates a task in the project P.
 - From company B, create a similar sales order with the product Q.
 - From company B's sales order, click on the project smart button.
 - An access issue occurs as company B's user isn't able to compute `sale_order_count`.

Cause
-----

Not using sudo when computing `sale_order_count` through aggregating on `_compute_sale_order_count`.

Solution
--------

Although the `compute_sudo` can be used on `sale_order_count` & `sale_order_line_count` field definitions, it is more clear and secure to use sudo specifically on the compute function.

opw-3850932

Forward-Port-Of: odoo/odoo#166769
Forward-Port-Of: odoo/odoo#163357

Forward-Port-Of: odoo/odoo#166818

Forward-Port-Of: odoo/odoo#166818

The issue: Inside the function _l10n_co_edi_generate_xml, the variable 'tax' at line 272 will be overridden by the 'account.tax' record which leads to a traceback in the second iteration, saying 'account.tax' object doesn't have a 'get' attribute Expected behavior: To not throw a traceback and generate the xml opw-3899575 Forward-Port-Of: odoo/enterprise#62290

The issue:
Inside the function _l10n_co_edi_generate_xml, the variable 'tax' at line 272 will be overridden by the 'account.tax' record which leads to a traceback in the second iteration, saying 'account.tax' object doesn't have a 'get' attribute

Expected behavior:
To not throw a traceback and generate the xml

opw-3899575

Forward-Port-Of: odoo/enterprise#62290

[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#62108

[REF] l10n_mx_edi: change fecha date to sent date

Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month.

Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it.

Task-3885769

Forward-Port-Of: odoo/enterprise#62108

Cohort views were patched to allow inserting them as an embed in a Knowledge article, but `web_cohort` was not a dependency of `knowledge`. It was an issue if the `web_cohort` (which is auto_install: True) module was manually uninstalled. Using an odoo runtime import, we can evaluate if the module was loaded and apply the patch at that point. If the module was not loaded, the patch is not applied. task-3918938 Forward-Port-Of: odoo/enterprise#63211 Forward-Port-Of: odoo/enterprise#6

Cohort views were patched to allow inserting them as an embed in a Knowledge
article, but `web_cohort` was not a dependency of `knowledge`.

It was an issue if the `web_cohort` (which is auto_install: True) module was
manually uninstalled.

Using an odoo runtime import, we can evaluate if the module was loaded and apply
the patch at that point. If the module was not loaded, the patch is not applied.

task-3918938

Forward-Port-Of: odoo/enterprise#63211
Forward-Port-Of: odoo/enterprise#62181

According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced. To fix this, - missing account tags have now been added (cf community PR); - the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward. - the Profit and Loss carried forward from previous years has been created as a new line in the P&L. This is all done in accordance with the official Balance Sheet and Profit & Loss found at https

According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced.

To fix this,
- missing account tags have now been added (cf community PR);
- the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward.
- the Profit and Loss carried forward from previous years has been created as a new line in the P&L.

This is all done in accordance with the official Balance Sheet and Profit & Loss found at
https://www.jusline.at/gesetz/ugb/paragraf/224
https://www.jusline.at/gesetz/ugb/paragraf/231

Community PR: https://github.com/odoo/odoo/pull/158542

Taskid: 3060790

Forward-Port-Of: odoo/enterprise#59106

Before this commit: The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app. opw-3891923 Forward-Port-Of: odoo/enterprise#62663

Before this commit:
The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app.

opw-3891923

Forward-Port-Of: odoo/enterprise#62663

This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification. Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`. The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered. ta

This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification.
Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`.

The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered.

task-3933062

Forward-Port-Of: odoo/enterprise#62649

**Current behavior:** If you create a SEPA report for an employee that has address information in their `hr.employee` record but not their `res.partner` record, the creditor address will not use the `hr.employee` information- the corresponding XML node will not be included. **Expected behavior:** The employee address should be in the report if they have one listed in their HR information. **Steps to reproduce:** 1. Install the `test_l10n_be_hr_payroll` module, switch to 'My B

**Current behavior:**
If you create a SEPA report for an employee that has address
information in their `hr.employee` record but not their
`res.partner` record, the creditor address will not use the
`hr.employee` information- the corresponding XML node will not
be included.

**Expected behavior:**
The employee address should be in the report if they have one
listed in their HR information.

**Steps to reproduce:**
1. Install the `test_l10n_be_hr_payroll` module, switch to
     'My Belgian Company'

2. In the Employee application, go to an employee (e.g., Bernice
     Jensen) and make sure their listed bank account is verified
     to be able to receive payments

3. In the Payroll application, create a new `To Pay` record for
     the employee from step 2, register it, then create the
     payment report

4. In the Exported File notebook tab, you can see that there is
     no Creditor Address listed in the XML Sepa Report

**Cause of the issue:**
The report builder constructs the creditor address only from
the `res.partner` record.

**Fix:**
Extend the postal address construction such that we get an
address from a partner's employee record (when applicable). The
information should not be mix-and-matched; we will use whichever
address has the most complete information.

opw-3716705

Forward-Port-Of: odoo/enterprise#58743

Steps to reproduce: ------------------- - Install `Documents` module - Go to Documents -> Configuration -> Workspaces - Create a workspace with a sub workspace - Go to list view Issue: ------ The display name of the sub workspace is not correct; It should also add the parent workspace name in the display name. Cause: ------ The following commit added a second `_compute_display_name` method that override the flow that add the parent workspace to the sub workspace name. https://

Steps to reproduce:
-------------------
- Install `Documents` module
- Go to Documents -> Configuration -> Workspaces
- Create a workspace with a sub workspace
- Go to list view

Issue:
------
The display name of the sub workspace is not correct;
It should also add the parent workspace name in the display name.

Cause:
------
The following commit added a second `_compute_display_name` method
that override the flow that add the parent workspace to the sub
workspace name.
https://github.com/odoo/enterprise/commit/ca7efce8f7bdb497f39a8438b5c266a7861d9a92

Solution:
---------
Merge the 2 `_compute_display_name`.

opw-3835887

Forward-Port-Of: odoo/enterprise#63082
Forward-Port-Of: odoo/enterprise#62759