Steps to reproduce the issue:
=============================
- Have 2 p elements where the last one have a link at the end of it
- Copy the 2 lines
- Paste them
- The box around the link is shown which indicates that the cursor is
  inside the link
- Try to add content
- The content is added oustide the link

Origin of the issue:
====================
When the selection have the p element and inside it there is an a
element , currentNode will be the p and not the a, but lastposition
will have the link node which is not padded with zws yet. So we put the
selection without the padding and then it's added which changes the
selection to have anchor node on the end of the ufeff charater inside
the link (`<a>&#xFEFFcontent&#xFEFF[]<a>`) which makes the selection
appears as inside the link but adding content will be after the link.

Solution:
=========
We need to pad the link with zws in case the selection we put is at the
edges of the link.

 ----------------------------------------------- 

Before:
=======
In rtl lang, the cursor gets stuck at the edge of the link using the
arrow keys.

After:
======
No the cursor moves correctly in rtl lang. We need to make `arrowLeft`
as go to next and `arrowRight` as going previous

task-4089193

Forward-Port-Of: odoo/odoo#185707

In a prior commit [1], a jQuery call was replaced with a vanilla JS implementation, inadvertently introducing an issue where unencoded URLs in background-image caused rendering or validation errors, such as "Invalid property value."

The `style.backgroundImage` property in vanilla JavaScript returns the raw value of the attribute, unlike jQuery's `.css('background-image')`, which automatically encodes URLs.

This fix ensures that URLs extracted are properly encoded using `getComputedStyle`.

Steps to reproduce:

- Install the Blog module.
- Configure your credentials in the Unsplash settings.
- Create a new post within a blog.
- Change the background of the post by searching for "electrical wire" on Unsplash. Select the first image in the results, noting that its filename contains a space.
- Click the "Add" button to set the background image.
- Save the changes.
- Observe that the background image is not applied. Inspect the style attribute of the div, and you will find: background-image: url(/unsplash/hokONTrHIAQ/electrical wire.jpg?unique=6015d8d5); This value is invalid for the background-image property due to the unencoded space in the URL.

[1]: https://github.com/odoo/odoo/commit/f9c9d6c4058086849b7e87174afd7f97d514baad

opw-4233483
opw-4271093

Forward-Port-Of: odoo/odoo#187932

Currently a parse error would arises if the user deletes the saleable product category and try to install POS

To reproduce this issue

1) Install Sale Management without a demo data
2) Delete the Saleable product category
3) Try to install POS

Error:-
```
ParseError: while parsing /home/odoo/src/odoo/18.0/addons/point_of_sale/data/point_of_sale_data.xml:21, somewhere inside
<record id="product_category_pos" model="product.category">
            <field name="parent_id" ref="product.product_category_1"/>
            <field name="name">PoS</field>
        </record>

```

This error is occurring because the user deleted the saleable product category, which leads to the above traceback as the saleable product category is referenced at multiple places to create master data.

https://github.com/odoo/odoo/blob/51296055790f8c6f01dfbbc82ca340756c54cdb3/addons/point_of_sale/data/point_of_sale_data.xml#L16

We can resolve this issue by preventing the user to delete the saleable product category.

sentry-6026143114

Forward-Port-Of: odoo/odoo#188788

Content of the IMP:
---

In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available quantity of quants present in the  DB are not updated. This commit ensures that the quants proposed for your  move line creation have an available quantity (even if currenlty dirty) and that the quantity used for the next move line creation is both related to the demand of the move, and the real availability of the quant used to create it.

[FIX] stock: avoid move line reset when opening detailled ops
---

This reverts [1] commit b45e249f8f5f36cffdb1ff615953eac7bb45b995.

### Steps to reproduce:

- Enable Multi-step routes
- Create a storable product: put 5 units on shelf 1 and 5 on shelf 2
- Create and "mark as todo" a delivery order for 3 units
- Click on the detailed operation and change the reservation from shelf 1 to shelf 2 > save (the subrecord not the record)
- Reopen the details operation
#### > The records get resets in front of you

### Cause of the issue:

One of the main problems of [1] is that it modifies dirrectly the data's of the props of the component used by the X2many dialog:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L48
As such, as soon as you mount that component, you will reset the data's used by that same component. Worse, the component is doing this to itself. Hence, if you did not perform a save before opening the details operation you will reset the values to match the DB's data. Furthermore this data change modifying the props of the component we are looking at will force to reload the component with the newly hardcoded data (which explains that you see your last change resetting in front of you).

In addition, the `quant_id` field of the stock.move.line model is a very particular field as it is neither stored or computed but is used by the create and the write for the stock.move.line data's to match some of the quant informations:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L85
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L310-L311
Therefore this field will never be set on a move. line that was not  modified in JS and is not saved yet. In order to take into account  the offset between the DB Data and the data's we are setting on the form of stock move it is therefore necessary to perform an rpc to **guess**  what quant was used to create a given line. HOWEVER, as teached by the JS framework formation:
```
The first rule of customizing Odoo in JS is: do it in python
```
So that you should not do that matching in JS but rather where it belongs.

Finally, modifying the props of a component during the `onMounted` is a super hacky way to use OWL as it is the first Hook for which OWL does not destroy the component because of props inconsistency...

opw-4294650

Original issue of the reverted "FIX":
---

### Steps to reproduce

- In the setting enable Multi Step Routes
- Create a storable prodcut and put 5 units on shelf 1
- Create and Mark as Todo a delivery order for 3 units of your product
- Set the quantity of the move to 0 and save the record
- Click on the "burger list icon" of the stock move to edit the
  detailed operations and make the reservations for your 3 units
- We want to make the reservation in 2 lines targetting the same quant
- Add a new line selecting your shelf 1 quant and set the qty to 1
- Try to add a second one the quant is not proposed

### Cause of the issue:

When a quant has been selected at least once and the record is not yet saved the js data of the record contains the info of the quant used to create/update the move line because of the non stored not computed dummy field `quant_id` of the stock move. As such the quant will be considered to already having been used in this transaction and hence not available:
https://github.com/odoo/odoo/blame/54e06a1b25ed9e317e368e89979c7c77ddbffc08/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L52-L54

### Note:
The IMP fixes the original issue + more.
This reverted commit already required an other fix: Commit ea4fca8faa4ee84693e645514085a65b92364842

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

Forward-Port-Of: odoo/odoo#186400

Current behaviour:
---
When you make content of type article in eLearning, then add an animation on scroll on an element,
when you put the article in fullscreen, the animations do not trigger.

Steps to reproduce:
---
1. Go to eLearning
2. Select a course with articles
3. Click on Go to website
4. Go on the article content
5. Open the editor
6. Drag and drop the columns block at the end
7. Select "feature one" and add an animation on scroll
8. After saving, scroll, the animation works
9. Click on "Fullscreen"
10. Scroll again, animation doesn't trigger

Cause of the issue:
---
In website_slide, fullscreen mode, the right scrollable element is not `#wrapwrap`, but `.o_wslide_fs_article_content`

Note:
---
If the animation is not complete, but the page is scrolled at maximum, 
animation intensity can be lowered in the editor panel, so that the animation can finish earlier.

opw-4151770

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

Forward-Port-Of: odoo/odoo#184717

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in delivery in 2 steps
- Create 4 storable products: Kit 1, Kit 2, content, foo
- Create 2 boms of type kit: one for Kit 1 and one for Kit 2, both with:
  - 1 x content
- Create and confirm a sale order with two lines:
  - 1 x Kit 1
  - 1 x Kit 2
> On the associated pick, you can see 2 distinct moves: one per kit
- On the SO add a line for 1 unit of foo and save the SO
#### > On the associated pick both kit moves were merged.

### Cause of the issue:

When you add 1 unit of foo, the `_action_launch_stock_rule` will be called in order to create and confirm the associated stock moves. During the `_action_confirm` of this move a `_merge_moves` will be called to determine if the move can be merged with any other already existing one. However, this merge operation will actually be performed on each of the move present in the "candidate_move_set" which includes all the moves of the already existing picking:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1015-L1027 https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1011-L1013 This is problematic since the `disting_fields` used as a merging criterion are based solely on the records present in self and not on the candidates on which the merging might be performed: https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1021 In our case, the reason why the two kit moves where not merged the first time that they were confirmed was because the `bom_line_id` was added to the distinct fields by:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/mrp/models/stock_move.py#L605-L609 But on the action confirm of the foo move and since this move is not assocaited with a `bom_line_id` of phantom type, it will not and the two kit moves will be considered as good condidates to merge into one an other.

### Fix:

The `distinct_fields` used as a merging criterion should be based on the set of all moves that are  considered to be merged rather than to the moves that we initially wanted to merge.

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

Forward-Port-Of: odoo/odoo#188101

Steps to reproduce the bug:
- Create a storable product “P1” and “P2”
- Create two route:
    - route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 1” to “customer -> Trigger another action

    - route 2:
        - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 2” -> Trigger another action
        - rule 2: Pull from “WH/Stock/Shelf 2” to “customer -> Trigger another action

- P1 -> route 1 + buy (add azure interior as vendor)
- P2 -> route 2 + buy (add azure interior as vendor)

- Create a SO: - vendor: Azure interior
    - One unit of P1 and P2

- Confirm the SO
- Go to the created PO
- Confirm the PO and go to the reception
- put in pack the products together
- Try to validate the picking

Probelm:
An User Error is triggered:
ValueError: Expected singleton: stock.location(3694, 3696)

Because we have two moves with different destination locations, and we are trying to set them in all the move lines.

opw-4291067

Forward-Port-Of: odoo/odoo#188074

This commit:
1. Removes useless btn-group around "New" button
2. Removes useless borders in the cog dropdown
3. Makes the edit modal buttons more consistent with the rest of the modals
4. Fixes an alignment problem when the loading indicator is displayed
5. Fixes an alignment problem between cog and count

| - | 2 | 3 | 4 | 5 |
|--------|--------|--------|--------|--------|
| before | ![image](https://github.com/odoo/enterprise/assets/8558351/fcd965f4-89c8-4031-a81f-6dcb1fbfb9b6) | ![image](https://github.com/odoo/enterprise/assets/8558351/0dbd0a57-62dc-4171-94af-8db6e8ac88b8) | ![Screenshot 2023-11-07 at 11 37 30](https://github.com/odoo/enterprise/assets/110090660/4c2a450c-313c-4d17-b318-dccca8926e83) | ![Screenshot 2023-11-07 at 11 39 49](https://github.com/odoo/enterprise/assets/110090660/8e0fe921-d75a-484f-bb1b-766090d56d88) |
| after | <img width="227" alt="Screenshot 2024-04-04 at 11 04 49" src="https://github.com/odoo/enterprise/assets/110090660/bc264ad0-28b7-44a4-b4ae-29cf03b3f33a"> | <img width="231" alt="Screenshot 2024-04-04 at 11 03 54" src="https://github.com/odoo/enterprise/assets/110090660/891554fa-7ac8-4f3b-9566-5340e98522ea"> | <img width="196" alt="Screenshot 2024-04-04 at 11 02 57" src="https://github.com/odoo/enterprise/assets/110090660/7479740b-80fd-47af-95e4-8b4fbc8228d9">| <img width="198" alt="Screenshot 2024-04-04 at 11 03 25" src="https://github.com/odoo/enterprise/assets/110090660/32229f8e-16d9-487b-845d-704f7a07e63e">|


task-3580143

The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow.

In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each row is way faster. We also discarded duplicated `text_tokens` to reduce the size of the `ARRAY`.

The reason why using a `LIKE(ANY(ARRAY[]))` is faster is because postgres inlines the CTE in the outer query. This means that it performs a Seq Scan on sale.order and injects the CTE definition of sub.name inside the `WHERE` conditions of the outer query, along with injecting the `WHERE` conditions of the CTE.

So, the regex functions are distributed among the `OR` conditions. I.e. every `OR` condition left operand will contain the regex functions. As those have to be executed for every `OR` condition, this quickly becomes slow.

We can explicitely materialize the CTE to avoid that. This makes postgres evaluate the regex functions only once. But it will still have lots of `OR` conditions to check along with running pattern matching for each one of them.

`LIKE(ANY(ARRAY[]))` avoids this issue. The CTE is still inlined but since we now only have a single condition, the regex functions are only evaluated once and pattern matched once against an array of options. This makes the whole query faster and scale better.

#### speedup

Customer database with 808341 sale.orders. Query timing when increasing the number of text tokens.

| Number of tokens | Before PR | After PR |
|:-------------------:|:----------:|:--------:|
|        2         |     7s    |    1.3s  |
|        5         |     10s   |    1.3s  |
|        10        |     18s   |    1.4s  |
|        20        |     33s   |    1.55s |

opw-4329067
opw-4316765

Forward-Port-Of: odoo/enterprise#74827
Forward-Port-Of: odoo/enterprise#73755

Steps to reproduce:
------------------
1. Create a fresh database of version 17.0 or earlier.
2. Install website_event and website_enterprise modules.
3. Migrate the database to version saas~17.4.
4. Open the website and click on the `Edit` button, Will encounter Traceback Error.

Cause:
------
In this [PR](https://github.com/odoo/enterprise/commit/eedf84b093f6c4803f53d7dc0021830c0c7b84cf) there have been changes made using an xpath where the node 'event_upcoming_snippet_hook' is being used. But there exists a view called 'website_event.snippets', where that particular node 'event_upcoming_snippet_hook' is being replaced with some other element/node.
>File(FYR): website_enterprise/views/snippets/snippets.xml

As the view 'website_event.snippets'  has same priority [i.e; 16 default] as the 'website_enterprise.external_snipppets'  view, the 'website_event.snippets' is being executed before than 'website_enterprise. external_snippets' which in result, the node 'event_upcoming_snippet_hook' will get replaced first and will not found for the view 'website_enterprise.external_snippets' when it tries to find that node for making changes and causes the error.

Note: The view 'website_event.snippets' will have smaller id than the view 'website_enterprise.external_snippets' cause it exists before than 'website_enterprise.external_snippets'.

Solution:
---------
Reset the priority of view 'website_enterprise.external_snippets' to 15 so that it will get executed first for finding the node and then gets replaced by the other view 'website_event.snippets'.

Forward-Port-Of: odoo/enterprise#69384

### Steps to reproduce the issue:

1. In a Colombian Company, create an Invoice with a Product with UNSPSC
2. Confirm then Send & Print (check DIAN option in wizard)
3. Access Error:

>     You are not allowed to access 'Colombian operation modes of DIAN used for different documents' (l10n_co_dian.operation_mode) records.
>
>     This operation is allowed for the following groups:
>     	- Administration/Settings

### Explanation:

Access Rights for `l10n_co_dian.operation_mode` are reserved to `base.group_system`.
During tests, discovered an Access Rights issue with `l10n_co_dian.certificate` as well when trying to "Reload DIAN configuration" of `account.journal`.

### Fix reasoning:

Log note from MASI on the ticket: add Read Access for Invoicing / Billing on `l10n_co_dian.operation_mode`
Since `l10n_co_dian.certificate` should not be openly accessible, we will use sudo to retrieve them while sending the request.
Testing access rights for invoicing, sudo addition and journal flow at the same time.

opw-4242695

Forward-Port-Of: odoo/enterprise#74617
Forward-Port-Of: odoo/enterprise#72623

## Issue: 
After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign.

## Steps to reproduce:
1. Get Sign module.
2. Upload any document to sign.
3. Add sign box and go to sign the document.
4. Now change from Auto to Draw.

## Solution: 
We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'.

The fix is part of > [#164410](https://github.com/odoo/odoo/pull/164410)

opw-3874034

Forward-Port-Of: odoo/enterprise#71474
Forward-Port-Of: odoo/enterprise#61981

# [FIX] mrp_workorder: always select first option
> Depending of the selected work centers in the Shop Floor view, different work center buttons will be visible ("All Mo", "My WO", "Assembly 1", ...) When no work center are selected by default, the first one should be the selected one, but for now, in this case it's always "All MO" who is selected.
This commit fixes that, the first button/WC will always the selected one if there is no WC id in the context.

# [FIX] mrp_workorder: don't set qty for component added from catalog in the Shop Floor.
> Description
> ===========
> 
> Before this commit, the quantity of a new move raw added through the catalog in Shop Floor was set directly in `_get_new_catalog_line_values`.
With this commit, it is not the case anymore, that way, if we should pick the component (production in 2 steps), the picking will be correctly created (before this fix, the picking was created only after an updated by `_get_new_catalog_line_values`.)
> 
> How to reproduce
> ================
> 
> - In Inventory settings, enable "Multi-Steps Routes";
> - In your warehouse configuration, select the 2 steps options for the manufacture;
> - Create a product with a BoM with at least a component;
> - Create a second product component (but not as a part of the BoM;)
> - Add quantity in stock for both components;
> - Create and confirm a MO for the product with the BoM;
> - Go in the MO's transfer and validate the "Pick Component" picking;
> - Go in Shop Floor, and for this MO, add the second component: click on the gear icon, "Add Component", search your component and click on it.
> 
> If you check your MO in the back end, you'll see no "Pick Component" transfer was created for the added component. That said, if you add more quantity for this component (still through the Shop Floor catalog), you'll see the transfer will be created but 1 qty will be missing.
> 
> Explanation
> ===========
> 
> When in 2 steps manufacture, if a component line is added and the demand is greater than the actual quantity, a Pick Component transfer will be created for this product.
In the catalog, when using it through the Shop Floor, the raw move is
created with an equal quantity and demand, which means no Pick Component
transfer is needed.
That said, when updating an existing raw move through the Shop Floor
catalog, the demand is updated BEFORE the actual quantity, resulting of
the creating/update of the Pick Component transfer.
> 
> To fix this issue, the quantity is not set directly during the move creation but will be updated just after (see related community fix.)

Community PR: odoo/odoo#183532

Forward-Port-Of: odoo/enterprise#71791

## Pull Request HOOT (PRHOOT) - part 27

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767
Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895
Part 21: https://github.com/odoo/odoo/pull/174337
Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721
Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728
Part 24: https://github.com/odoo/odoo/pull/181971
Part 25: https://github.com/odoo/odoo/pull/183358
Part 26: https://github.com/odoo/odoo/pull/186403 / https://github.com/odoo/enterprise/pull/73361

Enterprise: https://github.com/odoo/enterprise/pull/74093

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

## Pull Request HOOT (PRHOOT) - part 27

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767
Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895
Part 21: https://github.com/odoo/odoo/pull/174337
Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721
Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728
Part 24: https://github.com/odoo/odoo/pull/181971
Part 25: https://github.com/odoo/odoo/pull/183358
Part 26: https://github.com/odoo/odoo/pull/186403 / https://github.com/odoo/enterprise/pull/73361

Community: https://github.com/odoo/odoo/pull/187034

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in delivery in 2 steps
- Create 4 storable products: Kit 1, Kit 2, content, foo
- Create 2 boms of type kit: one for Kit 1 and one for Kit 2, both with:
  - 1 x content
- Create and confirm a sale order with two lines:
  - 1 x Kit 1
  - 1 x Kit 2
> On the associated pick, you can see 2 distinct moves: one per kit
- On the SO add a line for 1 unit of foo and save the SO
#### > On the associated pick both kit moves were merged.

### Cause of the issue:

When you add 1 unit of foo, the `_action_launch_stock_rule` will be called in order to create and confirm the associated stock moves. During the `_action_confirm` of this move a `_merge_moves` will be called to determine if the move can be merged with any other already existing one. However, this merge operation will actually be performed on each of the move present in the "candidate_move_set" which includes all the moves of the already existing picking:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1015-L1027 https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1011-L1013 This is problematic since the `disting_fields` used as a merging criterion are based solely on the records present in self and not on the candidates on which the merging might be performed: https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1021 In our case, the reason why the two kit moves where not merged the first time that they were confirmed was because the `bom_line_id` was added to the distinct fields by:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/mrp/models/stock_move.py#L605-L609 But on the action confirm of the foo move and since this move is not assocaited with a `bom_line_id` of phantom type, it will not and the two kit moves will be considered as good condidates to merge into one an other.

### Fix:

The `distinct_fields` used as a merging criterion should be based on the set of all moves that are  considered to be merged rather than to the moves that we initially wanted to merge.

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

Forward-Port-Of: odoo/odoo#188101

Before this commit, when the user wants to create a SO via the stat button displayed in the project form view when the project is billable without any SO created. The SO to create should have at least one service product to be able to timesheet on it inside the project. To make sure a service product will be in the lines of the newest SO, an user error should be displayed once no service product is inside lines of the SO created to avoid letting the user to create the SO until there is no service product.

This commit makes sure the context is correctly passed to the action to be able to trigger the warning once it is needed.

Steps to reproduce the issue:
============================

1. install `sale_project` module
2. create new billable project
3. go to the form view of that new project
4. set a customer to that project
5. click on `0 Sales Order\nMake Billable` stat button to create a new SO linked to that project
6. Create/Confirm the SO without any service products in its lines

Expected behavior
-----------------

The user error should be displayed since no service product is inside the lines of new SO.

Actual Behavior
---------------

The SO is created/confirmed without any errors.

task-4291437

Forward-Port-Of: odoo/odoo#185533

In a prior commit [1], a jQuery call was replaced with a vanilla JS implementation, inadvertently introducing an issue where unencoded URLs in background-image caused rendering or validation errors, such as "Invalid property value."

The `style.backgroundImage` property in vanilla JavaScript returns the raw value of the attribute, unlike jQuery's `.css('background-image')`, which automatically encodes URLs.

This fix ensures that URLs extracted are properly encoded using `getComputedStyle`.

Steps to reproduce:

- Install the Blog module.
- Configure your credentials in the Unsplash settings.
- Create a new post within a blog.
- Change the background of the post by searching for "electrical wire" on Unsplash. Select the first image in the results, noting that its filename contains a space.
- Click the "Add" button to set the background image.
- Save the changes.
- Observe that the background image is not applied. Inspect the style attribute of the div, and you will find: background-image: url(/unsplash/hokONTrHIAQ/electrical wire.jpg?unique=6015d8d5); This value is invalid for the background-image property due to the unencoded space in the URL.

[1]: https://github.com/odoo/odoo/commit/f9c9d6c4058086849b7e87174afd7f97d514baad

opw-4233483
opw-4271093

Forward-Port-Of: odoo/odoo#187932

### Steps to reproduce:
- In Accounting Dashboard, click on "import file" in the Bank kanban box
- Select a CSV file with two missing values on a line, for example:
```
Transaction Type,Bank Reference,Narrative,Debit Amount,Credit Amount
TRANSFER,bank_ref_1,bank_statement_line_1,,1000
TRANSFER,,bank_statement_line_2,,3500
```
(missing `bank_ref_2`)
- Complete the Odoo fields: Transaction Type, Reference, Label, Debit, Credit
- Import
- Go in Accounting Dashboard > Bank Reconciliation and select the list view
- `bank_statement_line_2` appears in Reference instead of Label

### Cause:
In `_parse_import_data` some line values are added and some are expected to be removed. The values expected to be removed are stored by index but they are removed by value. In this case the index supposed to be removed is 3 but its value is empty like index 1. On the line `line.remove(line[index])` the first occurrence is removed, so index 1 is removed instead of 3.

### Solution:
Use `del` to remove by index.

opw-4319464

Forward-Port-Of: odoo/enterprise#74512

Steps to reproduce:
------------------
1. Create a fresh database of version 17.0 or earlier.
2. Install website_event and website_enterprise modules.
3. Migrate the database to version saas~17.4.
4. Open the website and click on the `Edit` button, Will encounter Traceback Error.

Cause:
------
In this [PR](https://github.com/odoo/enterprise/commit/eedf84b093f6c4803f53d7dc0021830c0c7b84cf) there have been changes made using an xpath where the node 'event_upcoming_snippet_hook' is being used. But there exists a view called 'website_event.snippets', where that particular node 'event_upcoming_snippet_hook' is being replaced with some other element/node.
>File(FYR): website_enterprise/views/snippets/snippets.xml

As the view 'website_event.snippets'  has same priority [i.e; 16 default] as the 'website_enterprise.external_snipppets'  view, the 'website_event.snippets' is being executed before than 'website_enterprise. external_snippets' which in result, the node 'event_upcoming_snippet_hook' will get replaced first and will not found for the view 'website_enterprise.external_snippets' when it tries to find that node for making changes and causes the error.

Note: The view 'website_event.snippets' will have smaller id than the view 'website_enterprise.external_snippets' cause it exists before than 'website_enterprise.external_snippets'.

Solution:
---------
Reset the priority of view 'website_enterprise.external_snippets' to 15 so that it will get executed first for finding the node and then gets replaced by the other view 'website_event.snippets'.

Forward-Port-Of: odoo/enterprise#69384

Issue:
When printing PDF reports, long account names cause the report to overflow out of the page.

Steps to reproduce:
- Install the accounting app
- Enable "Analytic Accounting" in the settings
- Create one (or more) analytic account(s) with very long names
- Open either "Balance Sheet" or "Profit and Loss" reporting
- Do an "Analytic Group By" with the created account(s)
- Print the PDF

Cause:
The default style in the associated scss file does not use wrapping.
https://github.com/odoo/enterprise/blob/bf6c64b8fd5591f271e9b0f18f40d205a64cd5bd/account_reports/static/src/scss/account_pdf_export_template.scss#L41

Solution:
Override the default style by using the "o_overflow_name" class. This is the class already used for handling overflow in the tables' content lines. This gives a more readable result than just editing the "white-space" field (see below for comparison).


The proposed solution gives the following result:
![image](https://github.com/user-attachments/assets/265d96f4-fd8b-4152-a56a-07dcad662ef0)

As opposed to just editing to "white-space: wrap;"
![image](https://github.com/user-attachments/assets/b2a5a704-5ea2-4ef1-b2aa-48f778575b3a)

Ticket:
opw-4277596

Versions
--------
- 17.0+

Community: https://github.com/odoo/odoo/pull/188440

>[!important]
>All functional changes are made in `sale`, this PR simply adds a test.

Steps
-----
1. Have a confirmed subscription;
2. go to subscription management in portal;
3. set or change payment method.

Issue
-----
The following email is sent:
> A payment [...] amounting $ 0.00 for [...] has been confirmed.

Cause
-----
The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction.

It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1].

This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2].

Solution
--------
Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders.

opw-4169491

[^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003
[^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144