Description of the issue/feature this PR addresses: Real information was used as a demo data partner, which caused complaints from the company which was the owner of this information Current behavior before PR: Data of the affected company available for demo databases Desired behavior after PR is merged: Data replaced for a fake demo company Task: [4071645](https://www.odoo.com/odoo/project/1625/tasks/4071645?cids=3) --- I confirm I have signed the CLA and read the PR guidelines a

Description of the issue/feature this PR addresses: Real information was used as a demo data partner, which caused complaints from the company which was the owner of this information

Current behavior before PR: Data of the affected company available for demo databases

Desired behavior after PR is merged: Data replaced for a fake demo company

Task: [4071645](https://www.odoo.com/odoo/project/1625/tasks/4071645?cids=3)


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

Forward-Port-Of: odoo/odoo#174301

To replicate the issue: 1. Go to Accounting app 2. Click on the Accounting menu => Journal Entries 3. Click the button Upload 4. After selecting a file, an error is raise, saying that "The journal in which to upload the invoice is not specified." Cause: In the view for Journal Entries, there isn't a particular journal associated with it, so there is no definition the journal in which the document should be uploaded. Before 17.0, the document was uploaded to a default journal. Without a d

To replicate the issue:
1. Go to Accounting app
2. Click on the Accounting menu => Journal Entries
3. Click the button Upload
4. After selecting a file, an error is raise, saying that "The journal in which to upload the invoice is not specified."

Cause:
In the view for Journal Entries, there isn't a particular journal associated with it, so there is no definition the journal in which the document should be uploaded. Before 17.0, the document was uploaded to a default journal. Without a default journal, the error is raised. This renders the button useless in this view, as it will always raise an error after the user has selected a file to upload.

Fix:
The button should not be shown in the Journal Entries view (through Accounting => Journal Entries). But if the user is in a specific journal (for example, navigating from Accounting Dashboard => Miscellaneous Operations), the button should be shown.

To do so, the account move list and kanban controllers in bills_upload check if the default move type is 'entry', and if so, whether there is an active id in the context. This allows differentiating between the specific journals or the general Journal Entries view.

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

Forward-Port-Of: odoo/odoo#174561

Description of the issue/feature this PR addresses: - Updated the condition of groups for shipping_field as suggested in the previous PR https://github.com/odoo/odoo/pull/173162#discussion_r1686292899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr opw - [4044861](https://www.odoo.com/odoo/project.task/4044861?cids=2) Forward-Port-Of: odoo/odoo#174072 Forward-Port-Of: odoo/odoo#174031

Description of the issue/feature this PR addresses:
- Updated the condition of groups for shipping_field as suggested in the previous PR https://github.com/odoo/odoo/pull/173162#discussion_r1686292899

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

opw - [4044861](https://www.odoo.com/odoo/project.task/4044861?cids=2)

Forward-Port-Of: odoo/odoo#174072
Forward-Port-Of: odoo/odoo#174031

Due to introduction of downpayment mechanism, if downpayment was made, Sale Order would no longer be in "has to be payed" state and it would prevent client from further payments. opw-3891128 Forward-Port-Of: odoo/odoo#163178

Due to introduction of downpayment mechanism, if downpayment was made,
Sale Order would no longer be in "has to be payed" state and it would
prevent client from further payments.

opw-3891128

Forward-Port-Of: odoo/odoo#163178

If a quotation template is set on an order, and that template has a "Confirmation mail", it'll be used to send quotes on confirmation, regardless of the flow (backend/frontend). For frontend flows (portal/ecommerce), a confirmation mail is sent after the order confirmation: * after SO signature on portal (if no payment is required) * on payment post processing (payment on portal or ecommerce) * on free order confirmation (ecommerce) Issue: If a template (with confirmation mail)

If a quotation template is set on an order, and that template
has a "Confirmation mail", it'll be used to send quotes on
confirmation, regardless of the flow (backend/frontend).

For frontend flows (portal/ecommerce), a confirmation mail
is sent after the order confirmation:

* after SO signature on portal (if no payment is required)
* on payment post processing (payment on portal or ecommerce)
* on free order confirmation (ecommerce)

Issue:

If a template (with confirmation mail) is used in on the quote
in one of those flows, two mails would be sent on confirmation:

* the template confirmation mail
* the default confirmation mail (could be the same mail)

Solution:

Harmonize and factorize a bit the behavior, to only send 1 mail maximum.

In backend, only send a confirmation mail if there is one configured on
the quotation template (as before).

In frontend, always send one unique mail, either the default one, or the
quotation template one if one is set.

opw-3997315

Forward-Port-Of: odoo/odoo#171059

…x tags wizard After updating taxes, we didn't update already existing journal entries tags to map correctly into new reports. We let the user change his data which can be very time consuming. To tackle that we introduce a new wizard accessible in accounting settings in which user can set a date from which we will update tags on his journal entries for him. task-3330327 Forward-Port-Of: odoo/odoo#174339 Forward-Port-Of: odoo/odoo#127077

…x tags wizard

After updating taxes, we didn't update already existing journal entries tags to map correctly into new reports.
We let the user change his data which can be very time consuming. To tackle that we introduce a new wizard accessible in accounting settings in which user can set a date from which we will update tags on his journal entries for him.

task-3330327

Forward-Port-Of: odoo/odoo#174339
Forward-Port-Of: odoo/odoo#127077

Was always failing because of an invalid signature Forward-Port-Of: odoo/odoo#174217

Was always failing because of an invalid signature

Forward-Port-Of: odoo/odoo#174217

accounts and group from syscebnl taxes adapted for these accounts for each country --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166211

accounts and group from syscebnl
taxes adapted for these accounts for each country




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

Forward-Port-Of: odoo/odoo#166211

Avoid extra redirect, use slug directly instead. Forward-Port-Of: odoo/odoo#174032

Avoid extra redirect, use slug directly instead.

Forward-Port-Of: odoo/odoo#174032

[FIX] web_editor: won't place font element between if else nodes Previously when we updated color on multiple selected nodes, </font> tag would get inserted between qweb if and else tags. This caused qweb processor to crash. After this change we don't insert font on the "t" elements. [Reproduce] - Install account - Open Email Template called "Invoice: Sending" - Change color of all of its content - Open preview opw-3912434 Forward-Port-Of: odoo/odoo#173703 Forward-Port-Of: odoo

[FIX] web_editor: won't place font element between if else nodes

Previously when we updated color on multiple selected nodes, </font> tag
would get inserted between qweb if and else tags. This caused qweb processor to crash.

After this change we don't insert font on the "t" elements.

[Reproduce]
- Install account
- Open Email Template called "Invoice: Sending"
- Change color of all of its content
- Open preview

opw-3912434

Forward-Port-Of: odoo/odoo#173703
Forward-Port-Of: odoo/odoo#169678

Steps to reproduce: - Edit any product's 'Description for delivery orders' (inventory tab) - Create a delivery for this product (or confirm sale order to create one automatically) - Print delivery slip (Correct formatting) - Validate delivery - Print delivery slip once more (Description loses linebreaks) This is only for looks, but it's a document the end user will see so there are concerns about it looking unprofessional. This formatting error is due to us not being able to use a fie

Steps to reproduce:
- Edit any product's 'Description for delivery orders' (inventory tab)
- Create a delivery for this product (or confirm sale order to create one automatically)
- Print delivery slip (Correct formatting)
- Validate delivery
- Print delivery slip once more (Description loses linebreaks)

This is only for looks, but it's a document the end user will see so there are concerns about it looking unprofessional.

This formatting error is due to us not being able to use a field element after remaking the order lines to group related products in python.

opw-4040127

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

Forward-Port-Of: odoo/odoo#174495

`stdnum` library incorrectly sets `zeep` `Transport` timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. The monkeypatch is a full copy of the original code except for adding `operational_timeout` to the `Transport` initialization. The monkeypatch can be removed when https://github.com/arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded. Related zeep github issue: https://github.com/mvantellingen/

`stdnum` library incorrectly sets `zeep` `Transport` timeout, resulting in
some requests hanging for 15 minutes. With this monkeypatch the timeout
will be set correctly. The monkeypatch is a full copy of the original
code except for adding `operational_timeout` to the `Transport` initialization.

The monkeypatch can be removed when https://github.com/arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded.

Related zeep github issue: https://github.com/mvantellingen/python-zeep/issues/140
This fix was already merged but reverted due to an unexpected side-effect:
Original commit: https://github.com/odoo-dev/odoo/commit/11062f6f77ed1292c6db9d64985dddeb46d354c8
Revert: https://github.com/odoo-dev/odoo/commit/de9df2ba5c15d399d6906ef54f3e4ac9f063a175

The issue originated from a dependency issue in the `zeep` library in [Ubuntu 22.04](https://packages.ubuntu.com/jammy/python3-zeep).
The `python3-platformdirs` dependency is missing in there, yet it is used in that version of `zeep`. This missing dependency used to be hidden by the [chains of `try ... except ImporError` of `stdnum`](https://github.com/arthurdejong/python-stdnum/blob/d5666b8bfe379688a38bb0fd6764a8c536dd3c75/stdnum/util.py#L254).
That means that it's another import from the chain that was used. So to reduce the possibility of introducing a similar bug and catch such errors, the original code from `get_soap_client` of `stdnum` has been fully copied.

opw-3980718

Forward-Port-Of: odoo/odoo#174199
Forward-Port-Of: odoo/odoo#173359

Previously, the amount sent to Mollie always had 2 decimal places. However, Mollie supports 0 decimal places for amounts in ISK and JPY so it failed for payments in those currencies. This fix adjusts the decimal places sent to Mollie according to the currency. opw-4011259 Forward-Port-Of: odoo/odoo#174278 Forward-Port-Of: odoo/odoo#173595

Previously, the amount sent to Mollie always had 2 decimal places. However, Mollie supports 0 decimal places for amounts in ISK and JPY so it failed for payments in those currencies.

This fix adjusts the decimal places sent to Mollie according to the currency.

opw-4011259

Forward-Port-Of: odoo/odoo#174278
Forward-Port-Of: odoo/odoo#173595

This is a complement to previous fix https://github.com/odoo/odoo/commit/649a7f185dca806af3b3d54a1e4390b9baff79c6 in which the use case where both companies have "Round Globally" set as "Rounding Method" was not handled. **Steps to reproduce:** - Install Sales & Accounting - Create a second company with a different currency (e.g. AED) than the first one (e.g. USD) - Configure the rounding factor of the currency of the second company to 1.000000 - Configure the default company of the curre

This is a complement to previous fix https://github.com/odoo/odoo/commit/649a7f185dca806af3b3d54a1e4390b9baff79c6 in which the use case where both companies have "Round Globally" set as "Rounding Method" was not handled.

**Steps to reproduce:**
- Install Sales & Accounting
- Create a second company with a different currency (e.g. AED) than the first one (e.g. USD)
- Configure the rounding factor of the currency of the second company to 1.000000
- Configure the default company of the current user to the second company
- Switch to the second company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Switch to the first company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Create a SO:
  * Customer: [any]
  * Order Lines: [any line with a tax]
- Save the SO
- Edit the SO by changing the price unit of the product !!! Make sure that the tax amount has a decimal part
- Save the SO

**Issue:**
In the chatter, the note about the new value of the tracked field Total is different from the Total value shown in the SO. Also, in Customer Preview, the total to pay shown on the upper-left of the page is different than the total shown in the SO details.

opw-3814058



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

Forward-Port-Of: odoo/odoo#174560

Steps to reproduce: - Create a product that is a kit in company A and not in company B - Try updating quantity on hand in company B Bug: since [1] it's not possible to update kit quantites directly but is_kits is not company dependant Fix: is_kits depends on the selected companies opw-3946361 [1]:https://github.com/odoo/odoo/pull/161124/files Forward-Port-Of: odoo/odoo#174233 Forward-Port-Of: odoo/odoo#169063

Steps to reproduce:
- Create a product that is a kit in company A and not in company B
- Try updating quantity on hand in company B

Bug:
since [1] it's not possible to update kit quantites directly but is_kits is not company dependant

Fix:
is_kits depends on the selected companies

opw-3946361
[1]:https://github.com/odoo/odoo/pull/161124/files

Forward-Port-Of: odoo/odoo#174233
Forward-Port-Of: odoo/odoo#169063

This is a backport of #150175 This commit will add the basic package for the Cyprus localization. - Default Settings - CAO - Taxes - Fiscal positions - Tax Report Task: 3640438 Related: odoo/enterprise#54620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161488

This is a backport of #150175 

This commit will add the basic package for the Cyprus localization.
- Default Settings
- CAO
- Taxes
- Fiscal positions
- Tax Report

Task: 3640438
Related: odoo/enterprise#54620

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

Forward-Port-Of: odoo/odoo#161488

- Create 4 invoices: A, B, C, D with a correct MX setup - Make sure C will fail by removing the SAT code on the product for example - Run the send and print wizard on all invoices and check 'Download' (to force a synchronous run). After each call to the web-service, the code does: ``` # Check for success. if invoice.l10n_mx_edi_cfdi_state == 'sent': continue ``` However, the `cr.commit` is at the end of the loop. So the transacti

- Create 4 invoices: A, B, C, D with a correct MX setup
- Make sure C will fail by removing the SAT code on the product for example
- Run the send and print wizard on all invoices and check 'Download' (to force a synchronous run).

After each call to the web-service, the code does:

```
                # Check for success.
                if invoice.l10n_mx_edi_cfdi_state == 'sent':
                    continue
```

However, the `cr.commit` is at the end of the loop. So the transaction is not committed except in case of error!
When running the send and print synchronously, the error is raised to the user that will rollback the whole
transaction.
In case of the setup above, A, B and C are well commit but D is sent and has been rollback.
Then, the user will sign again D making the invoice signed twice.

To solve the issue, let's commit right after each web-service call.
That way, whatever the way we use to call the web-services, the transaction is commit immediately.

opw-4003043
opw-3985376
opw-4059666
opw-3955553
...and many others!

Forward-Port-Of: odoo/enterprise#67365

Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them t

Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`.

This is because we format tokens and filter out special characters and then compare them to names.

With this commit, we'll compare names and tokens that are formatted the same way.

opw-3964898

Forward-Port-Of: odoo/enterprise#67176

When shifts are group by in the planning, the open shift and total rows are not disabled. In this commit, we have disabled the total row and all rows except those at group level 0. task-3981814 Forward-Port-Of: odoo/enterprise#66634

When shifts are group by in the planning, the open shift and total rows are not disabled.
In this commit, we have disabled the total row and all rows except those at group level 0.

task-3981814

Forward-Port-Of: odoo/enterprise#66634

Current behaviour: --- Connected as Marc Demo, cannot set the Unique Field of any marketing campaign Steps to reproduce: --- 1. Go to Settings > Users > Marc Demo 2. At Marketing Automation, set User 3. Connect as Marc Demo 4. Go to Marketing Automation 5. Open any campaign 6. Try to set the Unique Field 7. Access Error Cause of the issue: --- unique_field_id is comodel of ir.model.fields Fix: --- Give group_marketing_automation_user the right to read ir.model.fields op

Current behaviour:
---
Connected as Marc Demo, cannot set the Unique Field of any marketing campaign

Steps to reproduce:
---
1. Go to Settings > Users > Marc Demo
2. At Marketing Automation, set User
3. Connect as Marc Demo
4. Go to Marketing Automation
5. Open any campaign
6. Try to set the Unique Field
7. Access Error

Cause of the issue:
---
unique_field_id is comodel of ir.model.fields

Fix:
---
Give group_marketing_automation_user the right to read ir.model.fields

opw-4001919

Forward-Port-Of: odoo/enterprise#66690

Before, in a multi company and mutli website setup, booking an appointment used the companies on the organizer for the context. This was leading to issue for appointment type in Website 2 tied to Company 2. Indeed the mails for the booking were sent with the context of Company 1 (value based on the allowed_company_ids of the user). Now, when website_appointment is installed, if a website is linked to the actual request we use the company tied to it. This ensure that we always use the corre

Before, in a multi company and mutli website setup, booking an appointment used the companies on the
organizer for the context.
This was leading to issue for appointment type in
Website 2 tied to Company 2. Indeed the mails for the booking were sent with the context of Company 1 (value based on the allowed_company_ids of the user).

Now, when website_appointment is installed, if a website is linked to the actual request we use the company tied to it. This ensure that we always use the correct company of the website for the creation of the event.

We target 17.0 to avoid a behavior change in older stable as the multi website was officially supported for appointment type in that version. Could be backported if really necessary.

task-3977787

Forward-Port-Of: odoo/enterprise#64144

Steps to reproduce - Display the intrastat report with at least one line - Create a european company - Install intrastat - Create and post an invoice to partner from another european country - Open the intrastat report - Deactivate the "Grouped" filter in the Options - Activate the Comparison filter (with any other date) => Traceback stating that the query has syntax error Cause of the issue: Missing parentheses between the different sections of the UNION ALL statement. task-40

Steps to reproduce
  - Display the intrastat report with at least one line - Create a european company - Install intrastat - Create and post an invoice to partner from another european country - Open the intrastat report

  - Deactivate the "Grouped" filter in the Options
  - Activate the Comparison filter (with any other date) => Traceback stating that the query has syntax error

Cause of the issue:
Missing parentheses between the different sections of the UNION ALL statement.

task-4017165

Forward-Port-Of: odoo/enterprise#67148
Forward-Port-Of: odoo/enterprise#65720

How to reproduce: ================= - Enable "Storage Locations"; - Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1); - Create an internal transfer from WH/Stock to WH/Stock for this product for at least 2 qty; - Confirm the internal transfer and open it in the Barcode app; - You can see you have one line, from WH/Stock/Shelf 1 to WH/Stock (if we follow previous example); - Scan one time the product, then scan another location (eg.: shelf2),

How to reproduce:
=================
- Enable "Storage Locations";
- Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1);
- Create an internal transfer from WH/Stock to WH/Stock for this product for at least 2 qty;
- Confirm the internal transfer and open it in the Barcode app;
- You can see you have one line, from WH/Stock/Shelf 1 to WH/Stock (if we follow previous example);
- Scan one time the product, then scan another location (eg.: shelf2), the line will be split.
=> Issue here: the line for the remaining quantity has WH/Stock as source location instead of Shelf 1.

Expected behavior:
==================
The source location of the split line doesn't change.

Explanation:
============
When a line is split, a new line is created for the remaining quantity. But the issue is, when a new line is created, it uses the picking's source location (or the previous scanned source) as the default location.

OPW-4016136

Forward-Port-Of: odoo/enterprise#66360

eBay recently changed the URL they send in the viewitemURL. We found 3 different ways they send it, but there might be more. We shouldn't have relied on this URL to match products in the beginning, but we can't refactor this flow in stable, instead, we try a different way to match the url, and fallback on another eBay call to get the expected variant. opw-3934127 Forward-Port-Of: odoo/enterprise#66924

eBay recently changed the URL they send in the viewitemURL. We found 3 different ways they send it, but there might be more. We shouldn't have relied on this URL to match products in the beginning, but we can't refactor this flow in stable, instead, we try a different way to match the url, and fallback on another eBay call to get the expected variant.

opw-3934127

Forward-Port-Of: odoo/enterprise#66924

Description of the issue/feature this PR addresses: 1 - Create a quality.point and add a repair operation type in the 'picking_type_ids' field 2 - Create a repair picking Current behavior before PR: No QC is created. This is expected because of https://github.com/odoo/enterprise/pull/59509 - only available since 17.3 Desired behavior after PR is merged: Exclude “repair” operation types from the domain of the “picking_type_ids” field to avoid confusing the user. opw-4052819 Forw

Description of the issue/feature this PR addresses:

1 - Create a quality.point and add a repair operation type in
	the 'picking_type_ids' field
2 - Create a repair picking

Current behavior before PR:
No QC is created. This is expected because of https://github.com/odoo/enterprise/pull/59509 - only available since 17.3

Desired behavior after PR is merged:
Exclude “repair” operation types from the domain of the “picking_type_ids” field to avoid confusing the user.

opw-4052819

Forward-Port-Of: odoo/enterprise#67257

This commit aims to: - make more coherent information displayed in the list view and the kanban view of the bank reconciliation widget. To do so we now display `ref`, `bank_account` `foreign_currency` and `amount_currency` within the "Manual Operations" tab. - display information even after the statement line is reconciled. To do so we made the "Manual Operations" tab visible even after validation, with its information in readonly. - make the cog menu available even if the transaction if vali

This commit aims to:
- make more coherent information displayed in the list view and the kanban view of the bank reconciliation widget. To do so we now display `ref`, `bank_account` `foreign_currency` and `amount_currency` within the "Manual Operations" tab.
- display information even after the statement line is reconciled. To do so we made the "Manual Operations" tab visible even after validation, with its information in readonly.
- make the cog menu available even if the transaction if validated.

task-3996739

Forward-Port-Of: odoo/enterprise#65313

### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days.

### Steps to reproduce:
	- Install hr_holidays_contract_gantt module
	- Create two employees one with a contract and another without
	- Create a time off for each employee
	- Check Time Off -> Overview

### Current behavior before PR:
The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days.

### Desired behavior after PR is merged:
Both employees should show the grey cells in the gantt view whether they have contract or not because if so we fallback on the employee working hours and then company's working hours 'According to the PO'

opw-3961873

Forward-Port-Of: odoo/enterprise#65470

Adding another report for SYSCEBNL. We need to provide a way to add an availability for children of a COA, so the reports is only available for Associations (and not for Companies). Forward-Port-Of: odoo/enterprise#62883

Adding another report for SYSCEBNL.
We need to provide a way to add an availability for children of a COA, 
so the reports is only available for Associations (and not for Companies).

Forward-Port-Of: odoo/enterprise#62883

Steps to reproduce: ------------------- - Install `data_merge` and `CRM` module - Go to CRM and create 2 opportunities with same name - Activate debug mode and go to `Scheduled Actions` - Run `Data Merge: Find Duplicate Records` action - Go to Discuss and click on `History` channel Issue: ------ Error: `Record does not exist or has been deleted.`. Cause: ------ When uninstalling a module that have a model that is used as `res_model_id` in a `Deduplication Model`, we do not

Steps to reproduce:
-------------------

- Install `data_merge` and `CRM` module
- Go to CRM and create 2 opportunities with same name
- Activate debug mode and go to `Scheduled Actions`
- Run `Data Merge: Find Duplicate Records` action
- Go to Discuss and click on `History` channel

Issue:
------

Error: `Record does not exist or has been deleted.`.

Cause:
------

When uninstalling a module that have a model that is used as `res_model_id` in a `Deduplication Model`, we do not remove message the message linked to the record deleted.
Therefore, when opening history channel, we try to access messages linked to records that might have been deleted.

Solution:
---------

When removing `Deduplication Model`, also remove the messages linked to the record.

opw-3906945

Forward-Port-Of: odoo/enterprise#67094
Forward-Port-Of: odoo/enterprise#64906

Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible. Forward-Port-Of: odoo/enterprise#6690

Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country.

Exceptions to this are:
- the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem.
- the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible.

Forward-Port-Of: odoo/enterprise#66905

Instead of calling `env.cr.savepoint()` in a loop, which will create a savepoint at every iteration, we should create a single savepoint and rollback to it at the end of every subtest. In Postgres, the number of sub-transactions that may exist in active transactions has a hard limit of 64 before sub-transactions are stored on disk. It's therefore best practice to limit the number of savepoints we create. See also https://github.com/odoo/odoo/pull/167236 Forward-Port-Of: odoo/enterprise#66

Instead of calling `env.cr.savepoint()` in a loop, which will create a savepoint at every iteration, we should create a single savepoint and rollback to it at the end of every subtest.

In Postgres, the number of sub-transactions that may exist in active transactions has a hard limit of 64 before sub-transactions are stored on disk. It's therefore best practice to limit the number of savepoints we create.

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

Forward-Port-Of: odoo/enterprise#66665
Forward-Port-Of: odoo/enterprise#66322

### Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. This issue also occurs with the Button URL as well. ### After this PR The Sample Values for Free Text Fields and Button Dynamic URL will now update based on the selected WhatsApp Template. Task-3996935 Forward-Port-Of: odoo/enterprise#66892

### Before this PR

In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template.

This issue also occurs with the Button URL as well.

### After this PR

The Sample Values for Free Text Fields and Button Dynamic URL will now update based on the selected WhatsApp Template.

Task-3996935

Forward-Port-Of: odoo/enterprise#66892

This is a backport of #54620 and #59137 Forward-Port-Of: odoo/enterprise#60531

This is a backport of #54620 and #59137

Forward-Port-Of: odoo/enterprise#60531