Commit 1:

    [FIX] website: use em unit for vertical padding of highlighted text
    
    The padding was defined in pixels, thus adding a small padding on
    highlighted titles (wanted design) but an apparently big one on
    highlighted paragraphs (unwanted design). Using em unit makes more
    sense: this commit chooses the values so that the padding of highlighted
    h2 titles in the default Odoo theme is unchanged. You will thus get a
    slightly bigger one for highlighted h1 titles and a slightly smaller one
    for highlighted smaller titles.
    This would lead to no padding for highlighted paragraphs though. While
    this might be what is wanted (most document editing software do not add
    any padding) it was decided to keep a minimal value as a compromise.
    
    Related to opw-3877772

Commit 2:

    [FIX] website: remove highlighted text horizontal padding
    
    Not adding any horizontal padding is important as it ensures that
    several features work (the first one is the very problematic one
    reported in the customer ticket):
    
    - Coloring a word inside a highlighted sentence -> in this case, the DOM
      is a succession of 3 <font> elements, the word one with both the
      background-color and the color.
    
    - Highlighting part of a word -> you don't want the word to be split
    
    - Even in the good cases, you might just not want the padding, to align
      the highlighted element with the general layout.
    
    => The user can still add surrounding spaces if needed anyway which is
       actually both technically and functionally intuitive.
    
opw-3877772

| Before | After |
| -------- | -------- |
| ![image](https://github.com/odoo/odoo/assets/10338094/96357e49-d3a2-40a3-98bd-a09a8f2c5311)  | ![image](https://github.com/odoo/odoo/assets/10338094/bcc536ee-8559-4502-99bf-b49e12bd08a1)  |
| Padding impossible to change + problems (the opw one is illustrated by the highlighted "what they want and give")  | Relative vertical padding + No horizontal one (you can add real spaces instead)                                                     |

Forward-Port-Of: odoo/odoo#164919

To reproduce the problem:
- Enable pricelist feature
- Create a new Contact > no pricelist shown (all versions affected)
- Save > still no pricelist shown (>= 17.0 versions affected)
- Exit and go back to the Contact: the pricelist is set

The _compute_product_pricelist() doesn't work properly for new record, then we create a new contact, pricelist is empty (until the save for version < 17.0, until save/exit/return on the record for version >= 17.0).

In 17.0, we introduced web_save, which makes create() and read() in the same request. This is why the version >= 17.0 is more problematic and more confusing for the user. Prior to 17.0, it was not great either, but was never considered a bug (some effort has been made in https://github.com/odoo/odoo/pull/153326/files). So this fix targets versions >= 17.0.

Fix the issue by taking care of new ids in the _get_partner_pricelist_multi() method. Also, add a Form test case for every possible case.

opw-3872299

Forward-Port-Of: odoo/odoo#163768

Commit [1] added the support to also consider invisible dropped snippets when checking if the snippets in the right panel are droppable. In order for this status to be properly updated when showing and hiding invisible elements, the `reload_snippet_dropzones` event is now triggered in each call to `toggleTargetVisibility`.

However, this function is called a lot of times when doing different operations (e.g. drag and dropping (in `buildSnippet` and `cleanForSave` functions), removing a snippet, showing/hiding an invisible element), which means that `_disableUndroppableSnippets` is also called each time.

This slowed down the editor a lot:
- Drop a "Text-Image" snippet and click on it to activate it. 
=> It takes a bit long for the "Undo" arrow and the overlay to appear.
- Drag and drop one of the snippet columns.
=> It takes a while for it to be dropped and for the dropzones to disappear, while it should be instant.

It also made some tours having steps that drop snippets fail when launched in the browser console (e.g. `carousel_content_removal`). This happens because the "drop" step takes too long to complete, making the next one fail.

Also, this made the call to `_disableUndroppableSnippets` redundant in certain cases. For example, when removing a snippet: in `removeSnippet` there is a call to `toggleTargetVisibility` which will therefore call this function. At the end, it triggers the `snippet_removed` event which will call `_onSnippetRemoved` which also calls this function.

This commit therefore fixes these issues by removing the trigger from `toggleTargetVisibility` and by calling `_disableUndroppableSnippets` directly when showing/hiding invisible elements, so only when necessary.

[1]: https://github.com/odoo/odoo/commit/922b4ba13d679a237bcc43d7296ff402beacb022

task-3902277

Forward-Port-Of: odoo/odoo#164826
Forward-Port-Of: odoo/odoo#164159

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

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

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


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

Forward-Port-Of: odoo/odoo#164734

Before this commit, it was impossible to force the use of 'vanilla' ISO 20022 over SEPA in every case. The 'Generic' selection value existed in the PAIN version field, but its actual meaning was to use the regular SEPA, not what the inner code of the module calls "generic SEPA", which actually corresponds to ISO 20022 without the SEPA-specific restrictions.

ISO 20022 is currently automatically used a a fallback by our SEPA implementation when trying to generate a file which values would violate the SEPA restrictions (such as a non-IBAN account or non-EUR amount). This works fine when your wish is to do SEPA and you need something more generic "by accident", and maybe your bank accepts it.

In that context, we got a report from a customer with his journal configured to "Generic", who actually wished to use ISO 20022 instead of SEPA:
- When making a batch payment containing a non-EUR amount or non-IBAN account, this worked fine
- When making a batch payment violating none of the SEPA restrictions, SEPA was used instead of ISO 20022

When SEPA was chosen, SvcLvl node was set to "SEPA" in the file, as it is the only accepted value. This got rejected by the customer's bank, which expected only ISO 20022, in which "SEPA" is not a legit SvcLvl value. With our commit, this node will now receive "NURG" as its value.

This commit is intended as a small patch to unlock customers facing this exact issue. More proper and sandboxed support for ISO 20022 will follow in master.

opw-3848174

Forward-Port-Of: odoo/enterprise#62240
Forward-Port-Of: odoo/enterprise#62054

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered.

Steps to reproduce:
-------------------
* Go to the **Field Service** App
* Switch to the calendar view
* Select "Tomorrow" (x+1)
* For the new task, set the `Planned Date` as follows:
  * Start date : The day after tomorrow at 3PM (x+2 3PM)
  * End date: Three days after the start at 4PM (x+5 4PM)
* Fill anything for the other required fields > **Save & Close**
* Switch to the kanban view and select the task created
> Observation: the start date of `Planned Date` is set at Tomorrow 7AM instead of the day after at 3PM

Why the fix:
------------
This behavior was introduced after this commit: https://github.com/odoo/enterprise/commit/39b9362d0469d71b59d47e9d66d5e73b9a46520b.

This commit added an inverse method to the field `planned_date_start` to enable drag and droping tasks in the calendar view. And `planned_date_start` is a field that exists purely for calendar displaying of tasks.

https://github.com/odoo/enterprise/blob/c8c4a52b508621b45239332273832de26a085931/project_enterprise/models/project_task.py#L299-L305

When creating a task in the calendar view, the context contains `default_planned_date_start` and its value depends on the first day you selected in the calendar. At task creation, `default_planned_date_start` triggers a write in `planned_date_start` which triggers its inverse method.

This removes the `default_planned_date_start` from the context which won't trigger the inverse method. We don't have to worry about the line `default_planned_date_begin: default_planned_date_start,` as if we have selected a start date in the form, it will be present inside `vals_list` in the create function and will use that value instead of the one in the context.

opw-3850455

Forward-Port-Of: odoo/enterprise#61351