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

Since commit ae16d9d, the Adam driver priority has been incorrectly set higher than it should be. The issue was a side-effect of removing the meta-class, since it no longer registered the `Driver` base class as a driver.

The fix was just to simplify the priority system to not be affected by inheritance. Then we manually set the Adam priority to -1, and the Blackbox priority to 1. Everything else will have priority 0.


For a detailed breakdown of the old behaviour and the cause of the bug, keep reading:

The priority system was influenced by inheritance - the more levels of inheritance, the higher the priority. For example, in saas-18.1, you get these priorities:
- `SerialBaseDriver`: 1
- `BlackBoxDriver`: 2
- `ScaleDriver`: 2
- `Toledo8217Driver`: 3

The Adam driver sets its priority to zero, but it still gets +1 from the meta class. So the final priorities are as follows in saas-18.1:
- `SerialBaseDriver`: 1
- `AdamEquipmentDriver`: 1
- `BlackBoxDriver`: 2
- `ScaleDriver`: 2
- `Toledo8217Driver`: 3

This results in the Adam driver runs last.

In saas-18.2, the priorities are shifted by 1 due to the `Driver` base class not being registered, but the Adam driver still ends up with the same value. So the priorities now look like this:
- `SerialBaseDriver`: 0
- `AdamEquipmentDriver`: 1
- `BlackBoxDriver`: 1
- `ScaleDriver`: 1
- `Toledo8217Driver`: 2

The Adam driver and blackbox driver have the same priority, so the Adam driver could end up running first and breaking the blackbox.

task-4750364

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

SQL traceback occurs when user creates their own automation rule involving python code.

**Steps to reproduce:**
Install base_automation,discuss if not already installed
* `Setting> Technical>Automation rules`
* name it as `Whatsapp add admin`
* model as `discuss channel` and trigger `after creation` any amount of time
* `Add an action>Execute code`
* Add the following code:  

```python
try: 
 env['discuss.channel.member'].create({ 'partner_id': 1,  # Likely invalid 'channel_id': 1, }) 
except Exception: 
 pass

env['res.partner'].search([], limit=1)
```

* Go to `techinical>automation>scheduled actions>Automation rules:check and execute` run it manually.

`ValueError:InFailedSqlTransaction('current transaction is aborted, commands ignored until end of transaction block\n') while evaluating
'model._cron_process_time_based_actions()'`

**Solution:**
* Place try and except inside the loop to handle errors per record and allow the loop to continue and handle the transaction error better.
* This will only one occurence of the error instead of repeating occurrence each time the cron runs.

**Sentry-6562754804**

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

## Version:
18.0+

## Issue:
PDF quotes on multiple pages having only the total table on the last page encounter a display issue. The total table is cut and partially displayed at the bottom of the penultimate page.

## Steps to reproduce:
- Install Sales app;
- Navigate to the Settings app:
    - Under the `Companies` section, configure the document layout: - Ensure the `Bubble` (or `Boxed`) layout is selected;
- Navigate to the Sales app:
    - Create a new quote with 8x `Chair floor protection`;
    - Via the `Actions` gear button, print the `PDF Quote`.

## Cause:
Complete code refactoring for documents layouts styles introduced by https://github.com/odoo/odoo/pull/169512 has probably not been tested on that use case.

## Fix:
<img width="1105" alt="Capture d’écran 2025-04-03 à 10 25 58" src="https://github.com/user-attachments/assets/67bce15e-c5e9-40f8-9fbf-7721afc98ae5" />

opw-4624623
opw-4627809

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

Forward-Port-Of: odoo/odoo#204575

Currently, since we read most data from cache, if an employee right was changed, it is not reflected in the pos.

Steps to reproduce:
-------------------
* Enable "Log in with employees" and set some records for each field.
* Open session, make a sale, close register
* Edit employees configuration, delete one, change rights advanced -> minimal
* Reopen the session
> Observation: The employee deleted is still visible in the list of cashiers
and the employee that has now minimal rights is still having advanced rights.

Why the fix:
------------
When removing rights from an employee it is important to have it reflected as soon as possible.

A possible solution would have been to recompute `last_data_change` when making any modification on the employee rights but this would recompute everything and we lose the performance added by the caching feature.

Instead, by adding the model to `uniqueModels` we ensure that anytime we reload the pos, all `hr.employee` records will be dropped from the indexedDB, which ends up using the data loaded.

https://github.com/odoo/odoo/blob/5d52373b4c9d64968316c4e883d6b49c7cd1d048/addons/point_of_sale/static/src/app/services/data_service.js#L246-L251

Fix during forward:
-------------------
The data related to hr employees is not sent to the frontend.

After this commit https://github.com/odoo/odoo/commit/96ee0b6288e4cc16aaf45162c5341fd2b9c7e60f
there is a difference in the data loaded regarding hr_employees.

With this change:
https://github.com/odoo/odoo/commit/96ee0b6288e4cc16aaf45162c5341fd2b9c7e60f#diff-86db45bc09231ecbc49a64405de92e0a022a6833980f46a9111501f8c8832760L172-R175
We see that we first load data with `_load_pos_data` then that data is post processed with `_post_read_pos_data`

`_load_pos_data` does not return any product. Previous to the commit, `_post_read_pos_data` was called `_load_pos_data` and the domain to read hr employees was:

`self._load_pos_data_domain(data)`

but now the domain is computed withinh `pos_load_mixin.py` with

`self._server_date_to_domain(self._load_pos_data_domain(data))`

So now the only hr employees that are going to be loaded to the frontend are the employees which have been modified after `_last_data_change`.

Since hr employees are needed to know which rights they have we want to load those related to the config everytime.

opw-4699241

Forward-Port-Of: odoo/odoo#206099

Steps to reproduce:
Using POS configs in french company with l10n_fr_post_cert module installed.
- Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment.
- Cash desk 2: Prepare an order
- Cash-desk 1: Start order payment.
- Cash-desk 2: Start order payment while cash-desk 1 is still paying.

Issue:
When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs on cash desk 2 during payment: could not obtain lock on row in relation “ir_sequence”. The odoo.service.model retries to create the order and since the ir_sequence of pos_config used in the pos_order name is not set to "no_gap", the pos_order names have a gap equal to the number of retries.

Task-4708543

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#207555
Forward-Port-Of: odoo/odoo#205935

XLS(X) allows to store in cells date/datetimes values as date/datetime objects. Meaning, instead of having a string with the date in some format, the cell value can hold an actual date/datetime object, which are automatically converted into the `datetime.date`/`datetime.datetime` when the xls(x) file is parsed in python.

When an xls(X) file contains at the same time date values under date/datetime objects and under strings with the user format `%d/%m/%Y` (rather than the server format `%Y-%m-%d`),
the import was failing with the error
`time data '06/30/2025' does not match format '%Y-%m-%d'`

This error normally happens when the user tries to do an import with different kind of date formats under strings in the same file e.g. `06/30/2025` and `2025-07-01`
and this is understandable that Odoo doesn't know what to do in such a case.
But, if you stick to the same format, either only `%d/%m/%Y` either only '%Y-%m-%d'`, Odoo supports it.

However the case here is trickier: it's when the file contains at the same time dates under a string format, e.g. `06/30/2025` and under date objects, e.g. `datetime.date(2025, 6, 30)`. Which can happen quite easily, as Google Spreadsheet for instance tends to automatically convert the cells holding a date value into date object. And it's then easy to have a file containing both date objects and strings for date, which looks visually the same in the Google Spreadsheet interface.

In addition Google Spreadsheet tends to convert automatically only dates below the 12 of the month because of the american format. e.g.
if you set `01/06/2025`, it gets converted into a datetime object if you set `13/06/2025`, it doesn't get converted into a datetime object, the value stays as a string.

The goal of this revision is to support to have the possibility of having date values under date objects and string in a user format

The problem lied in the fact, during the xls parsing, date objects were converted into strings using the server date format. And then you could finish with data containing both the user format and the server format.

The idea is to no longer automatically convert date objects and to support having date objects in the import parsing. And when trying to guess the date/datetime format of the file, date objects are simply ignored, as they do not need to be parsed.

Forward-Port-Of: odoo/odoo#206876

Versions
--------
- saas-17.4+

Steps
-----
1. Create a SO for non-user client;
2. add a product that isn't published on the website;
3. confirm SO;
4. create downpayment;
5. copy share SO link;
6. open link in private window.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> ValueError: Expected singleton: product.product()

Cause
-----
Commit 9aa52dd6418e removed the creation of a "Down payment" product. Before it, order lines were either of type `display_section` or they had a `product_id` value. After the commit, a third option is for `is_downpayment` to be true.

This regressed the fix to this issue added by 34d4ffa01d57d, as instead of ensuring lines have a `product_id` value before checking if reorder is allowed, it decided to check whether they're not of `display_type`.

Solution
--------
Ensure there's a `product_id` in `sale.order.line` instead of only relying on the caller to filter those out beforehand.

opw-4711297

Forward-Port-Of: odoo/odoo#207772
Forward-Port-Of: odoo/odoo#206435

The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time.

## How to reproduce
- Create product P, storable, tracked in Kg
- Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg
-> Stock Valuation is updated by 0.02Kg

OPW-4734980

---

Test result without fix:
```
2025-04-22 13:40:45,088 38626 ERROR oes_test_16 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_valuation_rounding_method
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 4397, in test_valuation_rounding_method
    self.assertEqual(receipt.move_ids.stock_valuation_layer_ids.quantity, 0.01)
AssertionError: 0.02 != 0.01
 ```

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

Forward-Port-Of: odoo/odoo#207401
Forward-Port-Of: odoo/odoo#206884

Currently an exception was generated when the user tries to save the new employee record after clicking on call icon.

Steps to reproduce:
1) Install HR module
2) Create a new employee record by giving employee name 
3) Click on the call icon of work phone
4) Now tries to save the new employee record

Error: `KeyError:  name`

This issue occurs because, while clicking the call widget, it creates the record but does not update it in the browser.

As a result, when the user tries to save manually, It again  creates the record with an empty vals_list.

So it will leads to the above traceback from the below lines

https://github.com/odoo/odoo/blob/2d64d94487d24278dc3c6615343a793e1ec94daf/addons/hr/models/hr_employee.py#L386

This fix resolves the issue by ensuring that clicking the call icon before saving retains the user input. Additionally, I have added a test to verify this behavior.

sentry-6234873849

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

Forward-Port-Of: odoo/odoo#206710
Forward-Port-Of: odoo/odoo#195278

**Steps to Reproduce:**
- Go to Sales
- Make a user-defined filter and make it the default filter
- Try to access the JSON link (/json/sales)
- You will see an error

**Issue:**
- When users apply default filters like 'My Quotations' or 'My Documents', Odoo saves 'uid' in the filter's domain to represent the logged-in user.
- However, when the system tries to process this filter, it fails because 'uid' is just a placeholder and not a valid value. This results in an **internal server error**, preventing users from applying these filters correctly.

**Cause:**
This issue is caused after this commit: https://github.com/odoo/odoo/pull/182196
- The domain string stored in 'ir.filters' includes 'uid' instead of the actual user ID.
- When Odoo('ast.literal_eval()') tries to evaluate the filter, it doesn’t know what 'uid' means, causing an error.

**Fix:**
- Replace 'uid' with `str(model.env.uid)` before evaluating the domain.
- This ensures 'ast.literal_eval()' processes a valid domain.

**Affected version:** 18.0~master
**opw**-4645608

Forward-Port-Of: odoo/odoo#202890

*: l10n_br_edi_pos, l10n_ke_edi_oscu_pos

The aim of this commit is to make test writing easier, by choosing
easy-to-calculate prices with their corresponding taxes.

The products created have prices of 10 or 20 with taxes of 5, 10 or 15
percent.

A global class will be created and inherited by all Point of Sale tests,
with the aim of always using products already available. If a different
product is required in a specific test, existing products can be
modified.

---

Test in file: `point_of_sale/tests/test_point_of_sale_flow.py`:

- Test `test_order_refund_lots` is removed and adapted in the frontend
tour `test_lot`

- Test `test_order_to_invoice` is removed because frontend is already
testing this behavior, related tests:
    - Test `test_02_pos_with_invoiced`
    - Test `test_order_and_invoice_amounts`
    - And more in submodules...

- Test `test_order_with_deleted_tax` is removed because it is using
`sync_from_ui` method which should not be used in the backend.
Frontend tours are already testing its behavior

- Test `test_order_refund_picking` is merged with `test_order_to_picking`

- Test `test_order_with_different_payments_and_refund` is removed
because its description don't correspond to the actual behavior of the
test. The goal of the test isn't clear.

- Test `test_product_combo_creation` is removed because its already
tested in owner module.

- Test `test_order_refund_with_owner` was merged with the frontend
test `test_lot`

- Test `test_change_is_deducted_from_cash` was merged with the frontend
test `test_tracking_number_closing_session`

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves.

The assumption is that records are created in the same order of the values list. This allows for breaking the for-loop because consecutive for-loops can simply inherit the order from the lists created in the loop just before. Another leverage point is that simply adding move_id to account.move.line(s) before creation is equivalent to `move.write({'line_ids': \[...\]})`. Based on the 2 assumptions, we could decouple the creation of moves and their lines into separate loops to aggregate their values.

After this PR creations, unlinks and posting operations are all batched to leverage the power of ORM optimization.


Benchmarks:
|Num deferred expenses | Time before | Time After | Num queries before | Num queries After |
|--------------------- | ----------- | ---------- | ------------------ | ----------------- |
| 100 		| 23.9s 	| 13.1s 	| 3768 		| 2918 			   |
| 1,000 	|181.4s      	| 66.5s       	| 17885         | 9530              	   |
| 10,000	|TIMEOUT(>1200s)| 616,7s    	| 1379          | 1010              	   |

opw-4480919
opw-4403217

Forward-Port-Of: odoo/enterprise#81440
Forward-Port-Of: odoo/enterprise#79255

### Step to reproduce:

- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
    - 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units

### Cause of the issue:

When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case  there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.

opw-4562965

Forward-Port-Of: odoo/enterprise#83555
Forward-Port-Of: odoo/enterprise#81818

### Issue:

Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP.

### Steps to reproduce:

- Install UK accounting and select UK's company: the currency will be GBP
- Install and set up Fedex Integration
- Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type
- Create a sale order, add shipping and get the shipping rate for your set up fedex UK.
#### > Fedex request error: `CURRENCY.TYPE.INVALID`

### Cause of the issue:

The currency used in the fedex request is the currency of the order: https://github.com/odoo/enterprise/blob/07845988daad911b10de3b7199b81cc4ed3cfba9/delivery_fedex_rest/models/delivery_fedex.py#L133-L141 that is GBP, however since 44e32359bb79eed08a41861e155c98f664c6d09a we do not automatically convert the GBP currency in UKL. Since Fedex API does not seem to support the GBP we raise the error.

### Fix:

We should use the currency conversion available between GBP and UKL.

opw-4712354

Forward-Port-Of: odoo/enterprise#83388

Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Duplicate the delivery
* Validate both deliveries delivery
> Observation: I have 4 jobs send for printing instead of 2

Why the fix:
------------
Actually the issue has the same explanation as this commit https://github.com/odoo/enterprise/commit/34267c4fa8c9aaa7c0216de13111a81fb53a67f1

as the IoT overrides `message_post` to send printing jobs each time a message is posted in the chatter.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L30-L46

opw-4526013

Forward-Port-Of: odoo/enterprise#82091

### Steps to reproduce:
- Accounting dashboard
- Click on the three dots of the "Bank" card
- Click "import file"
- Try importing a CAMT file with the namespace "camt"
- Traceback

Other issue:
- Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1")
- Traceback

### Cause:
Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace key because if the key was different from 'ns' the `findall` didn't work.

Second issue: Some banks use their own codes in the CAMT files. The specification has numerous codes which Odoo added in a dictionary, and it reads from this dictionary to get a description. When there is a custom code, Odoo tries to read a key which doesn't exist explaining the traceback.

### Solution:
- Change the way namespace is computed using the tag.

- If the code is not in the dictionary, we take the custom code.

opw-4553152

Forward-Port-Of: odoo/enterprise#82888

When the user tries to reply a whatsapp message,
a traceback will appear.

Steps to reproduce the Error:
- Install ``whatsapp`` and ``contacts`` module
- Go to WhatsApp > Configuration > WhatsApp Business Account >
  create a new account > Default Users: Mitchell Admin > Save
- Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp >
  Send a message with any template
- Contact will receive the message > Reply to that whatsapp message

Traceback:
```
UniqueViolation
duplicate key value violates unique constraint "discuss_channel_member_partner_unique"
DETAIL:  Key (channel_id, partner_id)=(84, 175) already exists.
```

https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L250 At lines [1] and [2], the same partner(s) (e.g., Mitchell Admin) are added to
``partners_to_notify`` multiple times.
Channel members should be unique.
So, when it tries to create ``channel_member_ids`` with same partners,
It will lead to the above traceback.

1- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L219

2- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L249

sentry-6252537579

Forward-Port-Of: odoo/enterprise#83908

## Description

This PR fixes several issues related to comments in spreadsheet cells:

- **Dark Mode Styling**  
  The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue.

- **Focus Issue When Using Keyboard**  
  When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now doesn’t take focus, so keyboard navigation keeps working smoothly.

- **Upload Button & Error Fixes**  
  - The upload button was showing for spreadsheet cell comments but didn’t work. It’s now hidden.  
  - There was also an error when editing a comment because `this.thread` wasn’t always available. Now it falls back to `this.message?.thread` when editing the message.

- **Popover Visibility Fix**  
  When posting the first comment and hovering over it, the action buttons (edit, favorite, delete) were partly cut off. This is now fixed by adding some padding to the thread style.
![image](https://github.com/user-attachments/assets/da774829-9fac-4ae0-a91a-6381c2404471)




**Task**: [4708400](https://www.odoo.com/odoo/project/2328/tasks/4708400)

Forward-Port-Of: odoo/enterprise#83410

Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Duplicate the delivery
* Validate both deliveries delivery
> Observation: I have 4 jobs send for printing instead of 2

Why the fix:
------------
Actually the issue has the same explanation as this commit https://github.com/odoo/enterprise/commit/34267c4fa8c9aaa7c0216de13111a81fb53a67f1

as the IoT overrides `message_post` to send printing jobs each time a message is posted in the chatter.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L30-L46

opw-4526013

Forward-Port-Of: odoo/enterprise#82091

When the user tries to reply a whatsapp message,
a traceback will appear.

Steps to reproduce the Error:
- Install ``whatsapp`` and ``contacts`` module
- Go to WhatsApp > Configuration > WhatsApp Business Account >
  create a new account > Default Users: Mitchell Admin > Save
- Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp >
  Send a message with any template
- Contact will receive the message > Reply to that whatsapp message

Traceback:
```
UniqueViolation
duplicate key value violates unique constraint "discuss_channel_member_partner_unique"
DETAIL:  Key (channel_id, partner_id)=(84, 175) already exists.
```

https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L250 At lines [1] and [2], the same partner(s) (e.g., Mitchell Admin) are added to
``partners_to_notify`` multiple times.
Channel members should be unique.
So, when it tries to create ``channel_member_ids`` with same partners,
It will lead to the above traceback.

1- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L219

2- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L249

sentry-6252537579

Forward-Port-Of: odoo/enterprise#83908