In order for some text in the JavaScript code to be translatable, it must be wrapped in a call to _t. The title of a popup in the "sales management screen" missed this call to _t, preventing it from being translated. This commit fixes the problem by adding the missing call to _t. opw-3908751 Forward-Port-Of: odoo/odoo#166719 Forward-Port-Of: odoo/odoo#165337

In order for some text in the JavaScript code to be translatable, it must be wrapped in a call to _t.

The title of a popup in the "sales management screen" missed this call to _t, preventing it from being translated.

This commit fixes the problem by adding the missing call to _t.

opw-3908751

Forward-Port-Of: odoo/odoo#166719
Forward-Port-Of: odoo/odoo#165337

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

Steps to reproduce: - Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])" eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)" - Enable Bpost and enter test credentials. - Create a Sales Order and add Bpost shipping. - Try to validate the transfer - Error about the "LocalityCode" being too long. Fix: same as for other fields impose max length limit opw-3895123 Forward-Port-Of: odoo/enter

Steps to reproduce:
- Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])"
eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)"
- Enable Bpost and enter test credentials.
- Create a Sales Order and add Bpost shipping.
- Try to validate the transfer
- Error about the "LocalityCode" being too long.

Fix:
same as for other fields impose max length limit

opw-3895123

Forward-Port-Of: odoo/enterprise#62710

[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

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

Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652

Before this commit:
Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`.

After this commit:
All the slashes are removed from reference_id.

opw-3853123

Forward-Port-Of: odoo/enterprise#60652

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

Create an asset for 2400$, acquisition date on 1/1/2023. Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount. => The entries on the parent asset finish way too early. You don't get 36 months of lifetime. We would expect the amount of each new depreciation to be 50, so the amount of the parent + the child equals 100 each month for 36 months The reason why it happened is that we tried to compute the expected amount after each depreciation. This took into accoun

Create an asset for 2400$, acquisition date on 1/1/2023. 
Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount.

=> The entries on the parent asset finish way too early. 
You don't get 36 months of lifetime.
We would expect the amount of each new depreciation to be 50, 
so the amount of the parent + the child equals 100 each month for 36 months

The reason why it happened is that we tried to compute the expected amount after each depreciation. 
This took into account changes of amount, but not changes of length.
We don't have a good way to incorporate changes of length in the old computation. 
To fix this, for linear, we consider the original amount from the beginning/the reevaluation to compute the amount for each period.

It does not hold for degressive_then_linear, so we separate the logic.

opw-3811165

Forward-Port-Of: odoo/enterprise#62377

opw-3921760 opw-3889677 Forward-Port-Of: odoo/enterprise#63104 Forward-Port-Of: odoo/enterprise#62859

opw-3921760
opw-3889677

Forward-Port-Of: odoo/enterprise#63104
Forward-Port-Of: odoo/enterprise#62859

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

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

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

**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message.

**Steps to reproduce:**

- Install `documents_project` module (for test purposes)
- Create a new activity type with:
  - `action`: `Upload Document`
  - `folder_id`: `Internal`
  - `model_id`: `Task`
- Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project)
- Go to any task and add a new activity with the new activity type
- Click on `Upload Document` and select a file

**Issue:**

  Access right error message.

**Cause:**

Simple explanation:
2 documents are created (one on the activity creation and one on the attachment upload) and the attachment is linked to the second document. When trying to fisrt unlink the second document and then link the attachment to the first document, the attachment is already unlinked.

Detailed explanation:
When creating the activity, if a folder_id is set on the activity, an empty document is first created with the request_activity_id. https://github.com/odoo/enterprise/blob/a23a18681bddc5995c5dac8cacfb074c06fc5ea8/documents/models/mail_activity.py#L46

When uploading the file, if the related record model is an inherit of `documents.mixin` model and the documents settings (in this case `Document Project Settings`) are activated, it will create the document with the attachment.
https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/ir_attachment.py#L63

Then, in the action done, we will unlink the last document record created and try to link it's attachment (already unlinked) to the first document record (with the `request_activity_id`). https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/mail_activity.py#L33

Since the following commit, when unlinking a document, it unlink also it's attachment: https://github.com/odoo/enterprise/commit/a999f2c32ab542ca7aa44cf34970dc7cca4fdaf8

**Solution:**

Override the upload route (`/mail/attachment/upload`) so that it skip the creation of the second document (by adding `no_document` to the context) if an activity ID is available and that a document with a `request_activity_id` with the same activity ID already exists.

COM PR: https://github.com/odoo/odoo/pull/159943

opw-3458850

Forward-Port-Of: odoo/enterprise#63116
Forward-Port-Of: odoo/enterprise#59796

__Current behavior before commit:__ When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty. In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`. __Description of the fix:__ Check if each track is not `null` before setting its `enabled` property. opw-3833811 Forward-Port-Of: odoo/enterprise#62980

__Current behavior before commit:__
When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty.

In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`.

__Description of the fix:__
Check if each track is not `null` before setting its `enabled` property.

opw-3833811

Forward-Port-Of: odoo/enterprise#62980

**Current behavior:** In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers. **Expected behavior:** The current status of a package should not affect the accessibility of a company's picking history. **Steps to reproduce:** 1. Setup 2 companies, for both: Enable packages Enable stock warehouse locations

**Current behavior:**
In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers.

**Expected behavior:**
The current status of a package should not affect the accessibility of a company's picking history.

**Steps to reproduce:**
1. Setup 2 companies, for both:
        Enable packages
        Enable stock warehouse locations
        Enable multi-step routes -> set their in/out routes to 3-step (pick, pack, ship)

2. Create a reusable box type package, don't assign it to either company

3. In CompanyA, create a delivery using the reusable package and complete it so the package is fully emptied and ready to be reused

4. Switch to CompanyB, create a picking (any kind) using the same reusable box -don't finish the transfer- then switch back to CompanyA

5. Try to view Inventory transfers -> AccessError

**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method which is called on-demand when we try to open the transfers tree view. We will eventually look at packages from the picking that used the reusable package (which now 'belongs' to another company) and raise the AccessError.

**Fix:**
Use sudo() to read package records in the iteration over picking records.

We are only reading from pickings which belong to the current company, which makes the access check for the package records redundant (and as we see here problematic).

opw-3813917

Forward-Port-Of: odoo/odoo#166689
Forward-Port-Of: odoo/odoo#164677

### Description of the issue/feature this PR addresses: We have demo data that is not a real case of use, and if we try to re-use the partner to invoice for the EDI module we will get an error. ### Current behavior before PR: We have a **Foreign Partner** from the United States have an identification type of Uruguay Resident (NIE). This is not a real case because if you are from outside of Uruguay you can not select the NIE document type or any document issued by the Uruguay government.

### Description of the issue/feature this PR addresses:

We have demo data that is not a real case of use, and if we try to re-use the partner to invoice for the EDI module we will get an error.

### Current behavior before PR:

We have a **Foreign Partner** from the United States have an identification type of Uruguay Resident (NIE). This is not a real case because if you are from outside of Uruguay you can not select the NIE document type or any document issued by the Uruguay government.

Also if we want to re-use the demo partner to create new invoices and test the Send and Print functionality we are not able to send emails because the partners do not have an email set.

### Desired behavior after PR is merged:

We fixed this in the demo so makes sense. Now we have two demo partners:

* Fix Foreign partner to a proper document type
* Add a new partner, Resident Alien, who is a foreign person living in Uruguay which is the proper case for the use of NIE document type.
* We add an email to the UY demo partner, this way we can use this partners to test send and print functionality.


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

Forward-Port-Of: odoo/odoo#166543

Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants. Steps to reproduce: ------------------- * Make a quotation with the product `Desk Organizer` and select `Plastic` as its variant -> Confirm * Go to **Products** * Select `Desk Organizer` * Go to `Attributes & Variants` * Remove the `Plastic` option > The variant is now inactive * Go to the **Point of Sale** App * Open a shop session * Select the `D

Currently, if you select a product that has variants, the popup window to choose the variants shows both active and inactive variants.

Steps to reproduce:
-------------------
* Make a quotation with the product `Desk Organizer` and select `Plastic` as its variant -> Confirm
* Go to **Products**
* Select `Desk Organizer`
* Go to `Attributes & Variants`
* Remove the `Plastic` option
  > The variant is now inactive
* Go to the **Point of Sale** App
* Open a shop session
* Select the `Desk Organizer` product
> Observation: the `Plastic` variant is shown

Why the fix:
------------
We compare the workflow with sales, when doing a new quotation with the `Desk Organizer` product, the inactive variant is not an option to select.

We now load the information about attribute values being active or not when loading the data to the POS Session. All attributes that are inactive will not be shown in the product configurator.

opw-3713374

Forward-Port-Of: odoo/odoo#166666
Forward-Port-Of: odoo/odoo#165110

Suppose a SO line of 1210 with: t1 fixed tax of 5, price include, affect base amount t2 21% price included tax Make a down payment of 200. The resulting created SO line is computed as (1210 + 5) * (200 / 1210) = 200.83 instead of 200.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#16679

Suppose a SO line of 1210 with:
t1 fixed tax of 5, price include, affect base amount t2 21% price included tax

Make a down payment of 200.
The resulting created SO line is computed as (1210 + 5) * (200 / 1210) = 200.83 instead of 200.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#166792
Forward-Port-Of: odoo/odoo#166787

Before this PR, using the blur feature during a call on the public page will display an error popup. The library used to do so is not loaded. This PR fixes the issue. task-3948111 Forward-Port-Of: odoo/odoo#166743 Forward-Port-Of: odoo/odoo#166707

Before this PR, using the blur feature during a call on the public page will display an error popup. The library used to do so is not loaded. This PR fixes the issue.

task-3948111

Forward-Port-Of: odoo/odoo#166743
Forward-Port-Of: odoo/odoo#166707

Forward-Port-Of: odoo/odoo#166350

Forward-Port-Of: odoo/odoo#166350

Forward-Port-Of: odoo/odoo#166818

Forward-Port-Of: odoo/odoo#166818

## Issue: - when you open a calendar event popover, you can't see its time and duration ## Steps To Reproduce: - In mobile view, go to calendar and create an event. - Click on the event and notice you can't see it's time and duration. ## Solution: - We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDate

## Issue:
- when you open a calendar event popover, you can't see its time and duration

## Steps To Reproduce:
- In mobile view, go to calendar and create an event.
- Click on the event and notice you can't see it's time and duration.

## Solution:
- We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDateTimeAndDuration` function of the calendar popover.

opw-3829004

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

Forward-Port-Of: odoo/odoo#166279
Forward-Port-Of: odoo/odoo#160907

When uploading a file, the activity ID is now sent to the server. This will help (for example) to avoid creating a second document if the file is uploaded in the context of an existing activity. ENT PR: https://github.com/odoo/enterprise/pull/59796 opw-3458850 Forward-Port-Of: odoo/odoo#166593 Forward-Port-Of: odoo/odoo#159943

When uploading a file, the activity ID is now sent to the server. This
will help (for example) to avoid creating a second document if the file
is uploaded in the context of an existing activity.

ENT PR: https://github.com/odoo/enterprise/pull/59796

opw-3458850

Forward-Port-Of: odoo/odoo#166593
Forward-Port-Of: odoo/odoo#159943

The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below). This happens because 'already_propagate_ids' is copied at the beginning of _set_date_deadline (set | set = new set). So, when a child move propagates to multiple other moves, it is not known by the parent move, which will redo the propagation. To prevent this, we always keep the same reference for 'already_propagate_ids' (context: 'date_deadline_propagate_ids'). Th

The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below). This happens because 'already_propagate_ids' is copied at the beginning of _set_date_deadline (set | set = new set). So, when a child move propagates to multiple other moves, it is not known by the parent move, which will redo the propagation.

To prevent this, we always keep the same reference for 'already_propagate_ids' (context: 'date_deadline_propagate_ids'). This means that a parent and child move share the exact same Set, and when the child move updates the Set, it also updates the parent Set. So when a child move propagates, the parent will know which moves have been done.
   MOVES LINKAGE
```
       Move B
      /   |   \
  Move A  |  Move D
      \   |   /
       Move C
```
PROPAGATION GRAPHS:
```
  BEFORE    |  AFTER
------------+--------
    A       |    A
  /   \     |    |
  C   B     |    B
 / \ / \    |    |
 B D C D    |    C
 | | | |    |    |
 D B D C    |    D
------------+--------
    11      |    4     NUMBER OF CALLS
```
OPW-3904178

![image](https://github.com/odoo/odoo/assets/29302288/8329d051-5927-4fec-b85d-3994f93d8cc0)


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

Forward-Port-Of: odoo/odoo#164734

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

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

### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a new MO for 2 units of a product and produce 1 unit #### > A wizzard appears to ask you if you want to create a backorder ### Cause of the issue: Clicking on the produce button will call the "button_mark_done" method. However, the parameters of backorder creations are not checked before the wizzard generation: https

### Steps to reproduce:

- Inventory > Configuration > Warehouse Management > Operations types
- Click on Manufacturing and put "Always" on create a backorder
- Create a new MO for 2 units of a product and produce 1 unit

#### > A wizzard appears to ask you if you want to create a backorder

### Cause of the issue:

Clicking on the produce button will call the "button_mark_done" method. However, the parameters of backorder creations are not checked before the wizzard generation:
https://github.com/odoo/odoo/blob/5c2f60ae2b8eb6699bd322bc4ea3d5054c7aea37/addons/mrp/models/mrp_production.py#L2118-L2120 will call the

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

Forward-Port-Of: odoo/odoo#164560

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: - Create a PO: - 1 x storable product 1 - 1 x storable product 2 - Confirm the PO - Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery accordingly) - Click on the customer to open the res.partner form - Click on the "On-Time Rate" smart button #### > Traceback: psycopg2.errors.DivisionByZero ### Cause of the issue: Clicking on that smart button will call the "_read_group" method and the following sql expressio

### Steps to reproduce:

- Create a PO:
  - 1 x storable product 1
  - 1 x storable product 2
- Confirm the PO
- Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery accordingly)
- Click on the customer to open the res.partner form
- Click on the "On-Time Rate" smart button

#### > Traceback: psycopg2.errors.DivisionByZero

### Cause of the issue:

Clicking on that smart button will call the "_read_group" method and the following sql expression will be added to the associated query: https://github.com/odoo/odoo/blob/b4620c123b753caf2b77472a8d6c42d767471c53/addons/purchase_stock/report/vendor_delay_report.py#L57-L60 The error is therefore rasied because the SUM(qty_total) associated to product 1 was reset to 0 because of our change on the PO line.

### Fix:

Since SUM(qty_total) of 0 signifies that no units of that product was not expected to be delivered for that customer. As such they should be removed from the products whose "On-Time Rate" is computed from the vendor.delay.report's.

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

Forward-Port-Of: odoo/odoo#166721
Forward-Port-Of: odoo/odoo#162632

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

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

Prior to this commit, if a product wasn't loaded into the PoS, it would result undefined in the model. For instance, if one of the products in a combo product wasn't loaded into the PoS, an error would be raised when clicking on its combo product. This commit resolves the issue by ensuring that missing products are loaded, thereby preventing such errors. In addition, this commit introduces a domain to restrict the category, if applicable. opw-3810994 --- I confirm I have signed the CLA an

Prior to this commit, if a product wasn't loaded into the PoS, it would result undefined in the model. For instance, if one of the products in a combo product wasn't loaded into the PoS, an error would be raised when clicking on its combo product. This commit resolves the issue by ensuring that missing products are loaded, thereby preventing such errors. In addition, this commit introduces a domain to restrict the category, if applicable.

opw-3810994

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

Forward-Port-Of: odoo/odoo#160340

Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion. opw-3851823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164596 Forward-Port-Of: odoo/odoo#160646

Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion.

opw-3851823

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

Forward-Port-Of: odoo/odoo#164596
Forward-Port-Of: odoo/odoo#160646

Prior to this commit, if a partner was not loaded into the PoS, their name would not be displayed in the sale order list. This commit resolves this issue by ensuring missing partners are loaded when retrieving sale orders. opw-3881799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164603

Prior to this commit, if a partner was not loaded into the PoS, their name would not be displayed in the sale order list. This commit resolves this issue by ensuring missing partners are loaded when retrieving sale orders.

opw-3881799

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

Forward-Port-Of: odoo/odoo#164603

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

[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

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

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#166933 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#166933
Forward-Port-Of: odoo/odoo#166168