Issue: ====== Adding a new block in mailing in email marketing raises an error. Steps to reproduce the issue: ============================= - Go to email marketing - Create a new mailing - Create one from scratch - Drop any block - `TypeError : Cannor read properties of null (reading 'parentElement')` Origin of the issue: ==================== When we drop the block in the iframe's document we trigger the `click` event but we don't have any selection yet in the document so `anchor

Issue:
======
Adding a new block in mailing in email marketing raises an error.

Steps to reproduce the issue:
=============================
- Go to email marketing
- Create a new mailing
- Create one from scratch
- Drop any block
- `TypeError : Cannor read properties of null (reading 'parentElement')`

Origin of the issue:
====================
When we drop the block in the iframe's document we trigger the `click` event but we don't have any selection yet in the document so `anchorNode`will be `null` thus the error.

task-3724551

Forward-Port-Of: odoo/odoo#152814

Currently, the user does not get any feedback if the printer couldn't print. This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx: https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55 After this commit, a pop-up error is displayed in the PoS as well as an error message in the IoT box logs so the user is informed that the printing failed. Also, the '`-`

Currently, the user does not get any feedback if the printer couldn't print.
This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx:
https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55

After this commit, a pop-up error is displayed in the PoS as well as an error message in the IoT box logs so the user is informed that the printing failed.
Also, the '`-`' character has been added to the RegEx as it is a commonly used character in printer's identifier as CUPS doesn't allow spaces and nothing seems to justify filtering it.

opw-3458347

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

Forward-Port-Of: odoo/odoo#144325

This patch provides the possibility to implement a custom security layer on top of Odoo's imbus notification system and ir_cron live triggering system. The key addition is the `ODOO_NOTIFY_FUNCTION` environment variable (opt-in), which can now define a custom postgresql function to be called instead of the default `pg_notify` function. This allows for greater flexibility and control over the notification and triggering mechanisms within Odoo. This PR is a simplified version of the followin

This patch provides the possibility to implement a custom security layer on top of Odoo's imbus notification system and ir_cron live triggering system.

The key addition is the `ODOO_NOTIFY_FUNCTION` environment variable (opt-in), which can now define a custom postgresql function to be called instead of the default `pg_notify` function. This allows for greater flexibility and control over the notification and triggering mechanisms within Odoo.

This PR is a simplified version of the following one (already merged in previous versions):
https://github.com/odoo/odoo/pull/130370

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

Forward-Port-Of: odoo/odoo#140089

If translation of '__export__' module record's source and translated value in 'en_US' language is different. In that case, record's value of 'en_US' lang is translated value. Also in most of the case export module records are set as noupdate false due to this while upgrading the database to version 16 from lower version, the record's value is changed to their source value for 'en_US' lang. To avoid this problem of updating a record's value, this PR will not considering '__export__' module rec

If translation of '__export__' module record's source and translated value in 'en_US' language is different. In that case, record's value of 'en_US' lang is translated value. Also in most of the case export module records are set as noupdate false due to this while upgrading the database to version 16 from lower version, the record's value is changed to their source value for 'en_US' lang.

To avoid this problem of updating a record's value, this PR will not considering '__export__' module records for translation updates. Hence,'__export__' module's records translation remain same  as per original database.

Task : 3626386

Description of the issue/feature this PR addresses:
```
15_test_copy=> select id,name,res_id,noupdate,module from ir_model_data where module='__export__' and res_id=323;
  id   |             name              | res_id | noupdate |   module   
-------+-------------------------------+--------+----------+------------
 18613 | product_template_145_b960fe0c |    323 | f        | __export__

15_test_copy=> select * from ir_translation where name='product.template,name' and res_id=323;
  id   |         name          | res_id |  lang  | type  |    src    |       value        |   module   |   state    | comments 
-------+-----------------------+--------+--------+-------+-----------+--------------------+------------+------------+----------
 39689 | product.template,name |    323 | ar_001 | model | moob test | moob test (ARABIC) | __export__ | translated | 
 39987 | product.template,name |    323 | hi_IN  | model | moob test | moob test (HINDI)  | __export__ | translated | 
 39690 | product.template,name |    323 | en_US  | model | moob test | moob test (ENG)    | __export__ | translated | 
```

Current behavior before PR:
```
15_test_copy_16.0=> select id,name from product_template where id=323;
 id  |                                         name                                         
-----+--------------------------------------------------------------------------------------
 323 | {"en_US": "moob test", "hi_IN": "moob test (HINDI)", "ar_001": "moob test (ARABIC)"}
```
Desired behavior after PR is merged:
```
15_test_copy_16.0=> select id,name from product_template where id=323;
 id  |                                            name                                            
-----+--------------------------------------------------------------------------------------------
 323 | {"en_US": "moob test (ENG)", "hi_IN": "moob test (HINDI)", "ar_001": "moob test (ARABIC)"}
```




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

Forward-Port-Of: odoo/odoo#147682

This commit fixes the problem of selection change on colorpicker fast hover. Before this commit, hovering too fast on the colors of the colorpicker unselected text that would be on the edge of the selection and uncolored. This is fixed by deep ranging the selection at the moment we limit it to fonts. This improves the accuracy of the history as, in case the font tag has been removed, it saves the text node as the current selection. And since hovering updates rely on it, it prevents losing the

This commit fixes the problem of selection change on colorpicker fast hover.

Before this commit, hovering too fast on the colors of the colorpicker unselected text that would be on the edge of the selection and uncolored. This is fixed by deep ranging the selection at the moment we limit it to fonts. This improves the accuracy of the history as, in case the font tag has been removed, it saves the text node as the current selection. And since hovering updates rely on it, it prevents losing the selection when unhovering fast (which is the cause of the bug).

We noticed two behavior when dealing with this bug. When hoving on a color cell and exiting out of the colorpicker altogether, no bug appears. But when switching between two cells, multiple selection issue happen. After analysis of the performance graph, we believe that this is due to the fact in the first case, onSelectionChange events are fired
and the handler is called, whereas in the other case it doesn't happen. That handler particularly reacalulates the latest selection. And this doesn't happen in our pathological case. After testing this theory, we view that the problem is solved.

task-3295858

Co-authored-by: Hamza Maimoune <hmai@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>

Forward-Port-Of: odoo/odoo#152937
Forward-Port-Of: odoo/odoo#130191

I. When inserting a list to a mega menu, the closest `LI` is a nav-item within the navbar. We aim to prevent the toggling of this list. This commit ensures that lists with class nav-item in the navbar are not toggled. II. Commit [1] implemented an approach to preserve all the attributes when converting to a list. This is beneficial for `p` elements since they will no longer be in the DOM. However, elements other than `p` will always remain, requiring only dir attribute and not other attr

I. When inserting a list to a mega menu, the closest `LI` is a nav-item within the
navbar. We aim to prevent the toggling of this list. This commit ensures that
lists with class nav-item in the navbar are not toggled.

II. Commit [1] implemented an approach to preserve all the attributes when
converting to a list. This is beneficial for `p` elements since they will no
longer be in the DOM. However, elements other than `p` will always remain,
requiring only dir attribute and not other attributes like href, data-name,
describedby, etc.. to transfer to the list.

III. The mega menu templates on the website, like `s_mega_menu_multi_menus` and
`s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`.
This div has multiple block type anchor nodes. When a list is added to the mega
menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then
adds the `oe_edited_link` class, resulting in the centering of the A tag due to
the `inline-block` display of the `oe_edited_link` class. This PR fixes the
issue by adding display `inline-block` when not with nav-link.

[1]: https://github.com/odoo-dev/odoo/commit/c422db596d909efc5ae0ba049f8f9f5b80a90883

task-3609500

Forward-Port-Of: odoo/odoo#152902
Forward-Port-Of: odoo/odoo#144341

__Current behavior before commit:__ The `find` jQuery method calls at some point `apply` on the results. Sometimes however the number of results can exceed the maximum number of arguments given to a function. In such case `RangeError: Maximum call stack size exceeded` is thrown. __Description of the fix:__ Instead of selecting all children with `find('*')` and filter them afterwards with the selector, we can simply use `querySelectorAll`. This will lead to the same result. In order to

__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results. Sometimes however the number of results can exceed the maximum number of arguments given to a function.

In such case `RangeError: Maximum call stack size exceeded` is thrown.

__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them afterwards with the selector, we can simply use `querySelectorAll`. This will lead to the same result.

In order to respect the specification that `$from` can contain multiple elements we need to execute `querySelectorAll` on each of them. In practice however `cssFind` is always used on a single element therefore it basically serves the same purpose as `querySelectorAll`. Thus, it is marked as deprecated and should be removed in master.

opw-3703963

Forward-Port-Of: odoo/odoo#152729

After the commit added by odoo/odoo#152513, it was not possible anymore to create a new time off from the management view in situation where the default leave type wouldn't be defined. This commit adds a falsy value so that the variable exists even if no default leave type is set. Forward-Port-Of: odoo/odoo#153066

After the commit added by odoo/odoo#152513, it was not possible anymore to create a new time off from the management view in situation where the default leave type wouldn't be defined.

This commit adds a falsy value so that the variable exists even if no default leave type is set.

Forward-Port-Of: odoo/odoo#153066

ba1a550 The above commit added some constraints on what can be used on the context of views. The key word 'force-email' is no longer relevant and will be removed from the context before reaching the next view/python code. This commit's purpose is to remove the force_email that were forgotten. In order to still open the simplified partner form view, the ref of the view is given in the context instead. While at it, we also fix the create option given on the partner_ids field that was inconsist

ba1a550
The above commit added some constraints on what can be used on the context of views. The key word 'force-email' is no longer relevant and will be removed from the context before reaching the next view/python code.

This commit's purpose is to remove the force_email that were forgotten. In order to still open the simplified partner form view, the ref of the view is given in the context instead. While at it, we also fix the create option given on the partner_ids field that was inconsistent.

affected version 17.0 - master
task - 3538000
https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form

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

As `this._rpc()` can not be used since [1], this commit removes the mention to this method in the documentation of the `_shouldIgnoreRpcResult` method. [1]: https://github.com/odoo/odoo/commit/7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 Related to runbot-28700 Forward-Port-Of: odoo/odoo#152885

As `this._rpc()` can not be used since [1], this commit removes the
mention to this method in the documentation of the
`_shouldIgnoreRpcResult` method.

[1]: https://github.com/odoo/odoo/commit/7422eb643c5922bde8c70edfbe7b6f8dad53c1d9

Related to runbot-28700

Forward-Port-Of: odoo/odoo#152885

Final goal of this PR is to add in a first pass full auto-translation of Odoo into Russian. Steps taken to do so: 1. Re-export all pot files to ensure correct terms to translate + clean them up in general due to human error 2. Add missing pot files for modules that were added after the last cleaning/freeze and therefore were also missing from the .tx config file (later PR to follow to add in modules missing from config file, but already have a pot file) 3. 1 large master po file of all the

Final goal of this PR is to add in a first pass full auto-translation of Odoo into Russian. Steps taken to do so:

1. Re-export all pot files to ensure correct terms to translate + clean them up in general due to human error
2. Add missing pot files for modules that were added after the last cleaning/freeze and therefore were also missing from the .tx config file (later PR to follow to add in modules missing from config file, but already have a pot file)
3. 1 large master po file of all the modules exported in steps 1 + 2 were feed into an auto-translator
4. Master po file was split back into respective module's ru.po files (missing ones due to module not being in config file were auto-generated, these modules will be added into the config in a later PR). Note that because msgmerge would not auto-update the existing po files with the new translations for some reason, the metadata of the previous translators was discarded for the sake of automating the splitting of the master po translation file into the individual module ones in a simple way
5. Manual fixes of incorrect translating (i.e. of code terms) were done where noticed, additional bugs may pop up in the future as users use db in Russian more

Same process was done for Enterprise.

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



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

Forward-Port-Of: odoo/odoo#152285

Current behavior before PR: On inserting icon in note, it replaces another icon.It occurs because `isEmpty(block)` returns true, when block element was font-awesome, which causes the code in `insert` method to remove current node, resulting in removal of previous icon. Desired behavior after PR is merged: Now icon is added without replacing the another icon. task-3482264 Forward-Port-Of: odoo/odoo#134121

Current behavior before PR:

On inserting icon in note, it replaces another icon.It occurs because
`isEmpty(block)` returns true, when block element was font-awesome, which
causes the code in `insert` method to remove current node, resulting in removal
of previous icon.

Desired behavior after PR is merged:

Now icon is added without replacing the another icon.

task-3482264

Forward-Port-Of: odoo/odoo#134121

Versions -------- - 15.0+ Steps ----- 1. Go to product variants; 2. select a product; 3. add a new Vendor line in the Purchase tab; 4. save; 5. add another Vendor line; 6. save. Issue ----- Previous line disappears from view. Cause ----- In 93bc96047ff684cb66b69186822493815cf37982 I added logic which sets the `product_tmpl_id` in `product.supplierinfo` if a `product_id` gets written without accompanying `product_tmpl_id`. Adding lines from the Product Variant views add `{'

Versions
--------
- 15.0+

Steps
-----
1. Go to product variants;
2. select a product;
3. add a new Vendor line in the Purchase tab;
4. save;
5. add another Vendor line;
6. save.

Issue
-----
Previous line disappears from view.

Cause
-----
In 93bc96047ff684cb66b69186822493815cf37982 I added logic which sets the `product_tmpl_id` in `product.supplierinfo` if a `product_id` gets written without accompanying `product_tmpl_id`. Adding lines from the Product Variant views add  `{'product_id': False}` to the values for every vendor in the list without a Product Variant, so their `product_tmpl_id` gets overwritten with the `product_tmpl_id` of an empty product.

Solution
--------
Only overwrite `product_tmpl_id` iff `product_id` gets written to a non-falsy value by changing `if 'product_id' in vals` to `if vals.get('product_id')`.

Related
-------
https://github.com/odoo/odoo/pull/149618

opw-3664524

Forward-Port-Of: odoo/odoo#153115
Forward-Port-Of: odoo/odoo#152881

Steps to reproduce and current behavior: --- Go to Manufacturing > Operations > Manufacturing Orders Create a Manufacturing order with at least one line Actions (gear icon) > print > Production Order The column : "To Consume" is not aligned with the values. Cause of the issue: --- There is an html anchor with a t-else close that should not be there. Fix: --- This anchor is removed. opw-3692098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/

Steps to reproduce and current behavior:
---
Go to Manufacturing > Operations > Manufacturing Orders
Create a Manufacturing order with at least one line
Actions (gear icon) > print > Production Order

The column : "To Consume" is not aligned with the values.

Cause of the issue:
---
There is an html anchor with a t-else close that should not be there.

Fix:
---
This anchor is removed.

opw-3692098

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

Forward-Port-Of: odoo/odoo#150891

When using Peppol Bis 3 with a partner without VAT, use the `peppol_endpoint` to fill the `PartyTaxScheme/CompanyID` and `PartyLegalEntity/CompanyID` to avoid errors like: "[BR-E-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Standard rated" shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63)." "[BR-CO-26]-In order for th

When using Peppol Bis 3 with a partner without VAT, use the
`peppol_endpoint` to fill the `PartyTaxScheme/CompanyID` and
`PartyLegalEntity/CompanyID` to avoid errors like:

"[BR-E-02]-An Invoice that contains an Invoice line (BG-25) where the
Invoiced item VAT category code (BT-151) is "Standard rated" shall
contain the Seller VAT Identifier (BT-31), the Seller tax registration
identifier (BT-32) and/or the Seller tax representative VAT identifier
(BT-63)."

"[BR-CO-26]-In order for the buyer to automatically identify a supplier,
the Seller identifier (BT-29), the Seller legal registration identifier
(BT-30) and/or the Seller VAT identifier (BT-31) shall be present."

Also adapt the tests, as the rules for the supplier's identifier are
stricter than for customers.

Forward-Port-Of: odoo/odoo#152898
Forward-Port-Of: odoo/odoo#152663

Steps: - Install project module - Activate customer rating from settings - Create new project without company - Add stages, then in final stage set in rating email template to 'Project: Task Rating Request' - Create a task and add the customer, move the task to that final stage then - Check the emails in settings, the subject line is look like ': Satisfaction Survey'. Issue: - When there is no company set on the project, on that time company name is missing in subject line. Cause:

Steps:
- Install project module
- Activate customer rating from settings
- Create new project without company
- Add stages, then in final stage set in rating  email template to 'Project: Task Rating Request'
- Create a task and add the customer, move the task to that final stage then
- Check the emails in settings, the subject line is look like ': Satisfaction Survey'.

Issue:
- When there is no company set on the project, on that time  company name is missing in subject line.

Cause:
- In task satisfaction survey email template only set the company name based on the project only.

Fix:
- By adding the current user's company name to the template subject line, the problem will be solved.

task-3626702

Forward-Port-Of: odoo/odoo#146260

Avoid affect document type assignation for no Peruvian countries Forward-Port-Of: odoo/enterprise#56100

Avoid affect document type assignation for no Peruvian countries

Forward-Port-Of: odoo/enterprise#56100

Extra Translations for ecuadorian ride and change position of date field in v17.0 Forward-Port-Of: odoo/enterprise#54068

Extra Translations for ecuadorian ride and change position of date field in v17.0

Forward-Port-Of: odoo/enterprise#54068

Summary: When we unfold an account and show journal entries in the general ledger (with the "Hierarchy and Subtotals" option checked), the journal entries do not appear on the XLSX report. Steps to reproduce: 1. Enable debug mode 2. Create a new account group (Accounting > Configuration > Accounting > Account Groups) with a code prefix from 1 to 9 3. Open the general ledger (Accounting > Reporting > Audit Reports > General Ledger) and check the option "Hierarchy and Subtotals" 4. Unf

Summary:
When we unfold an account and show journal entries in the general ledger (with the "Hierarchy and Subtotals" option checked), the journal entries do not appear on the XLSX report.

Steps to reproduce:
	1. Enable debug mode
	2. Create a new account group (Accounting > Configuration > Accounting > Account Groups) with a code prefix from 1 to 9
	3. Open the general ledger (Accounting > Reporting > Audit Reports > General Ledger) and check the option "Hierarchy and Subtotals"
	4. Unfold a line until you can see journal entries (e.g., "101000 Current Assets" on runbot)
	5. Export the general ledger in XLSX, and open it: the journal entries do not appear

Cause:
In the local stack, there is a field "unfolded_lines" that is a list containing the unfolded lines in absolute format (e.g., if account A is in account group G, the line is noted as "G|A").
However, when checking if an account is unfolded, it checks if the name of the account is in this field (just the name and not the group/account), which is not the case if the account is in an account group. In this case, the children are not displayed because only the content of the unfolded lines is shown.

Fix:
Modify the check for whether an account is unfolded: check if the name in absolute format is in the unfolded_lines list.


opw-3649550

Forward-Port-Of: odoo/enterprise#55753
Forward-Port-Of: odoo/enterprise#54385

### [IMP] l10n_mx_edi: duplicate check using fiscal folio As every fiscal folio on a vendor bill in Mexico is unique, we can easily check that to find duplicates. This change extends the default duplicate vendor bill check to first see if it can find duplicates with the same folio fiscal. If it doesn't find any, it will apply the generic duplicate check. task-3590442 ### [IMP] l10n_mx_edi: import withholding taxes Currently when importing a Mexican vendor bill, we skip the withhol

### [IMP] l10n_mx_edi: duplicate check using fiscal folio

As every fiscal folio on a vendor bill in Mexico is unique, we can easily check that to find duplicates.

This change extends the default duplicate vendor bill check to first see if it can find duplicates with the same folio fiscal. If it doesn't find any, it will apply the generic duplicate check.

task-3590442

### [IMP] l10n_mx_edi: import withholding taxes

Currently when importing a Mexican vendor bill, we skip the withholding taxes defined on the lines.

In this change, we also allow importing the withholding taxes when we find at least one that matches in the database.

task-3590442

### [IMP] l10n_mx_edi: flag "to check" on issues with import

When we're importing a Mexican vendor bill and we're unsure about something, like a tax that couldn't be found or multiple possible taxes, a message is logged in the chatter of that invoice in Odoo. However, it is not easy to identify which imported bills have errors later on when we have a bunch of them.

In order to make that easier, we flag the vendor bill as "to check" whenever we encounter an uncertainty at import, so the user can easily filter on that to follow up on these invoices.

task-3590442

Forward-Port-Of: odoo/enterprise#53128

We revert the below commit in this commit due to some issues that arose, so we decided to remove the default Indian public holiday. commit-https://github.com/odoo/enterprise/commit/403c8faf24afe79a533bab19d6c994ed5b5edc3a task-3693329 Forward-Port-Of: odoo/enterprise#56119

We revert the below commit in this commit due to some issues
  that arose, so we decided to remove the default Indian public holiday.

 commit-https://github.com/odoo/enterprise/commit/403c8faf24afe79a533bab19d6c994ed5b5edc3a

task-3693329

Forward-Port-Of: odoo/enterprise#56119

Before this commit, the US localisation was adding charts of account to rules only for the demo US company. However, the base company is based in San Francisco and should also have its demo data updated. task-3713709 Forward-Port-Of: odoo/enterprise#55524

Before this commit, the US localisation was adding charts of account to rules only for the demo US company. However, the base company is based in San Francisco and should also have its demo data updated.

task-3713709

Forward-Port-Of: odoo/enterprise#55524

This commit is a follow up of its community part. see : https://github.com/odoo/odoo/pull/149806 affected version: 17.0 - master task - 3538000 https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#54549

This commit is a follow up of its community part.
see : https://github.com/odoo/odoo/pull/149806

affected version: 17.0 - master
task - 3538000
https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form

Forward-Port-Of: odoo/enterprise#54549

### Steps to reproduce: - Install **Subscriptions** app - Open **Subscriptions** app and go to **Configuration** > **Automation Rules** - Create a **New** Rule - Under **ACTION** section, choose: - **Action To Do:** Send an email to the customer - **Email Template:** Subscription: Rating Request -for example- - Click on save button - U can notice how the **Email Template** field is empty ### Investigation: - We'll examine the case for `Send an email to the customer action`

### Steps to reproduce:
- Install **Subscriptions** app
- Open **Subscriptions** app and go to **Configuration** > **Automation Rules**
- Create a **New** Rule
- Under **ACTION** section, choose: 
    - **Action To Do:** Send an email to the customer 
    - **Email Template:** Subscription: Rating Request -for example-
- Click on save button
- U can notice how the **Email Template** field is empty

### Investigation:
- We'll examine the case for `Send an email to the customer action` but it's the same for `Send an SMS Text Message to the customer` and `Create next activity`
- The **SaleOrderAlert** model has `action_id` https://github.com/odoo/enterprise/blob/b4568ac28aaeb330eb7d679eb9ccd5afd0d78e1a/sale_subscription/models/sale_order_alert.py#L32
- It also has a non-readonly related field `template_id` https://github.com/odoo/enterprise/blob/b4568ac28aaeb330eb7d679eb9ccd5afd0d78e1a/sale_subscription/models/sale_order_alert.py#L34
- On saving the rule, we create an action https://github.com/odoo/enterprise/blob/b4568ac28aaeb330eb7d679eb9ccd5afd0d78e1a/sale_subscription/models/sale_order_alert.py#L244
- on which we set the `action_id` https://github.com/odoo/enterprise/blob/b4568ac28aaeb330eb7d679eb9ccd5afd0d78e1a/sale_subscription/models/sale_order_alert.py#L193
- but this new action doesn't have the chosen `template_id` set, and so the **_related_** `template_id` being a related field is changed to an empty record.

### Discussion
This PR extends upon https://github.com/odoo/enterprise/pull/53442 where it addresses the `next_activity` case

opw-3667217

Forward-Port-Of: odoo/enterprise#53715

Replace `this.env._t()` (not supported in 17.0) by `_t()`. Forward-Port-Of: odoo/enterprise#55930

Replace `this.env._t()` (not supported in 17.0) by `_t()`.

Forward-Port-Of: odoo/enterprise#55930

Enterprise side of what was done in COM PR: https://github.com/odoo/odoo/pull/152285 Forward-Port-Of: odoo/enterprise#55637

Enterprise side of what was done in COM PR: https://github.com/odoo/odoo/pull/152285

Forward-Port-Of: odoo/enterprise#55637

Fix the issue when the number of contract displayed on the contract smart button is greater than 1. Forward-Port-Of: odoo/enterprise#56036

Fix the issue when the number of contract displayed on the contract smart button is greater than 1.

Forward-Port-Of: odoo/enterprise#56036

- master - 17.0 Steps to reproduce: - Open Field Service / HR Employee Application - Open any task / employee record - Click on call button in mobile or phone field Issue: - Throws out a validation error to the user saying the mobile number which is a required field is not set Cause: - The Phone Widget Activity Patch which supplies the value of phone number from the field in which the call button has been presses has an issue - It gathers the field name in which phone widge

- master
- 17.0

Steps to reproduce:

- Open Field Service / HR Employee Application
- Open any task / employee record
- Click on call button in mobile or phone field

Issue:

- Throws out a validation error to the user saying the mobile number which is a required field is not set

Cause:

- The Phone Widget Activity Patch which supplies the value of phone number from the field in which the call button has been presses has an issue
- It gathers the field name in which phone widget is present and matches it to mobile or phone and returns either of the values

Solution:

- The simple solution is to supply the mobile number based on the field it is clicked rather than a fixed setup of supplying only mobile or phone values.

task-3678808

Forward-Port-Of: odoo/enterprise#54484

This PR hides the 'time_resource' option for appointment schedule-based on staff users as it is the same as the 'resource_time' option. Task-3584478 Forward-Port-Of: odoo/enterprise#56058 Forward-Port-Of: odoo/enterprise#55314

This PR hides the 'time_resource' option for appointment schedule-based on staff users 
as it is the same as the 'resource_time' option.

Task-3584478

Forward-Port-Of: odoo/enterprise#56058
Forward-Port-Of: odoo/enterprise#55314

This pull request: 1. re-exports the source terms of Belgian payroll localization modules 2. adds the corresponding resources to the .tx/config so that's it available for translation on Transifex 3. forward-ports translations from Odoo 16 Forward-Port-Of: odoo/enterprise#55363

This pull request:
1. re-exports the source terms of Belgian payroll localization modules
2. adds the corresponding resources to the .tx/config so that's it available for translation on Transifex
3. forward-ports translations from Odoo 16

Forward-Port-Of: odoo/enterprise#55363

Issue: ------ When we uninstall the `hr_referral` module, an error occurs when we want to create a job application. This is because a domain which uses a field which only exists if the `hr_referral` module is installed is persistent on window actions. It is therefore necessary to remove these domains during uninstallation, as they are no longer present on the `hr.applicant` model. opw-3708569 Forward-Port-Of: odoo/enterprise#55935

Issue:
------
When we uninstall the `hr_referral` module, an error occurs when we want to create a job application.

This is because a domain which uses a field which only exists if the `hr_referral` module is installed is persistent on window actions.

It is therefore necessary to remove these domains during uninstallation, as they are no longer present on the `hr.applicant` model.

opw-3708569

Forward-Port-Of: odoo/enterprise#55935

Issue: Aba is meant for batch payments and raising `UserErrors` individually for each employee/vendor prevents User from knowing all the faulty accounts. At the same time, difficult to find bank accounts for partners with multiple accounts. Fix: Raise a `RedirectWarning` with tree view to show all faulty partners/vendors simultaneously. And makes it simpler to directly find the account without the need to discard/recreate the faulty payments. 3635231 Forward-Port-Of: odoo/enterprise#554

Issue:
Aba is meant for batch payments and raising `UserErrors` individually for each employee/vendor prevents User from knowing all the faulty accounts. At the same time, difficult to find bank accounts for partners with multiple accounts.

Fix:
Raise a `RedirectWarning` with tree view to show all faulty partners/vendors simultaneously. And makes it simpler to directly find the account without the need to discard/recreate the faulty payments.

3635231

Forward-Port-Of: odoo/enterprise#55403

Before this commit, the timesheet to validate could be not found when the filtered is made inside `action_validate_timesheet` method, it is for that reason the timesheet created inside the test is not validated as expected. This commit ensures the timesheet created is recorded yesterday to be sure the timesheet will be validated inside `action_validate_timesheet` method. runbot-56444 Forward-Port-Of: odoo/enterprise#55924

Before this commit, the timesheet to validate could be not found when the filtered is made inside `action_validate_timesheet` method, it is for that reason the timesheet created inside the test is not validated as expected.

This commit ensures the timesheet created is recorded yesterday to be sure the timesheet will be validated inside `action_validate_timesheet` method.

runbot-56444

Forward-Port-Of: odoo/enterprise#55924