Tuesday, October 1, 2024
23 changes · saas-17.2
Miscellaneous changes
Steps : - Set the company of the first pricelist in list view to false - Create a product and set it's company and the go to extra price tab and group by product - Now when adding a new, opens form view, try saving the record Issue : Returns a warning message not allowing to save Cause : The company for pricelist that is default selected and the product have different companies Fix : Updated the action so that it does not open form view as the pricelist tree view is multi-edit
Original PR description
Steps : - Set the company of the first pricelist in list view to false - Create a product and set it's company and the go to extra price tab and group by product - Now when adding a new, opens form view, try saving the record Issue : Returns a warning message not allowing to save Cause : The company for pricelist that is default selected and the product have different companies Fix : Updated the action so that it does not open form view as the pricelist tree view is multi-edit opw-3943830 Forward-Port-Of: odoo/odoo#171032
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's)
Original PR description
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P…
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's) #### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be - validate one of the 7 MO #### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be ### Cause of the issue: By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice opw-4145680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181255
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on the last day of the month > Save - Management > Allocations > New - Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan - Set the start date to today - 0 days of allocation for 'Time off type' of your choice > Validate - My time > Dashboard > Use 'Balance at the mm/
Original PR description
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on…
Steps to reproduce:
- Time off > Configuration > Accrual Plan > New
- Set 'Accrued Gain Time' to 'At the start'
- New Milestone > Set 'Milestone reached' to 0 days after...
- Accrue 1 day Monthly on the last day of the month > Save
- Management > Allocations > New
- Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan
- Set the start date to today
- 0 days of allocation for 'Time off type' of your choice > Validate
- My time > Dashboard > Use 'Balance at the mm/dd/yyyy'
The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead.
The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid re-computations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves.
This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute.
Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway.
opw-4192703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#181115odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it. Task-4203142 Forward-Port-Of: odoo/odoo#181763
Original PR description
odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it. Task-4203142 Forward-Port-Of: odoo/odoo#181763
Issue: ====== We can't move elements in mass mailing. Steps to reproduce the issue: ============================= - Create a new mass mailing with a template that have some blocks - Try to drag one of the blocks to another position - When you click on the button to drag, the right sidebar refreches Origin of the issue: ==================== The issue was first introduced by [1]. The problem when we have the wysiwyg inside an iframe `document.activeElement` will be equal to the i
Original PR description
Issue: ====== We can't move elements in mass mailing. Steps to reproduce the issue: ============================= - Create a new mass mailing with a template that have some blocks - Try to drag one of the blocks to another position - When you click on the button to drag, the right sidebar refreches Origin of the issue: ==================== The issue was first introduced by [1]. The problem when we have the wysiwyg inside an iframe `document.activeElement` will be equal to the iframe element and the `ev.target` is the button of dragging. In reality the button is inside the iframe but the content of the iframe is like this `<iframe> document <iframe>` so contains returns false. Solution: ========= When the `activeElement` is an iframe we search inside its `contentDocument`. opw-4196067 [1]: https://github.com/odoo/odoo/commit/ef97eaf9876bcf1712d4a6bfb91307875b0034ac Forward-Port-Of: odoo/odoo#181143
To reporoduce: ============== 1. install "l10n_mx" 2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket) -> Odoo only retrieves the XML file and PDF is deleted Problem: ======== when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted. Solution: ========= process all files. opw-4054484 --- I confirm I hav
Original PR description
To reporoduce: ============== 1. install "l10n_mx" 2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket) -> Odoo only retrieves the XML file and PDF is deleted Problem: ======== when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted. Solution: ========= process all files. opw-4054484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180576
__Current behavior before commit:__ When making a search through `/website/search`, the `website_search_box` view is cached. This includes the search term and the search count. Therefore when a user makes a search, a previous search term might be displayed. It may even be a search that another user made. This bug appeared since the search bar has been added to header templates [`7559626`][1]. __Description of the fix:__ Add `t-nocache` to the whole searchbox so that the search term a
Original PR description
__Current behavior before commit:__ When making a search through `/website/search`, the `website_search_box` view is cached. This includes the search term and the search count. Therefore when a user makes a search, a previous search term might be displayed. It may even be a search that another user made. This bug appeared since the search bar has been added to header templates [`7559626`][1]. __Description of the fix:__ Add `t-nocache` to the whole searchbox so that the search term and the search count is updated with each search. __Steps to reproduce the issue in local:__ (For the issue to appear consistently everytime there should be only a single worker) 1. Click on the search button in the website header and make a search 2. Do the same thing again with another search 3. Click again on the search button The previous search term is shown inside the searchbar opw-4114511 [1]: https://github.com/odoo/odoo/commit/7559626 Forward-Port-Of: odoo/odoo#180548
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Ta
Original PR description
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Taxes need to be assigned on all invoice lines Why the fix: ------------ Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product. We can treat the parent combo line as the note or sections we would put on a quotation. opw-4090946 Enterprise PR: https://github.com/odoo/enterprise/pull/70505 Forward-Port-Of: odoo/odoo#181068
### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on the [+] button to generate one serial number of P > This steps updates the qty_producting to 1 and the set the consumed_qty of the raw move to 1. - Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN) > This generates 9 backorders each for 1 unit of P with a set SN ###
Original PR description
### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on…
### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on the [+] button to generate one serial number of P > This steps updates the qty_producting to 1 and the set the consumed_qty of the raw move to 1. - Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN) > This generates 9 backorders each for 1 unit of P with a set SN #### > However raw moves are **picked with a consumed_qty of 0** ### Cause of the issue: Since the stockpocalypse commit 7dda6bb the `_split_productions` did not consume quantities anymore. This behavior was fixed by commit 4be8cac for mass production notably by the addittion of these lines: https://github.com/odoo/odoo/blob/6995d65437ba6b2cd0df7503d589260bedcce67d/addons/mrp/models/mrp_production.py#L1879-L1887 However, in our flow, when we assigned the firt serial number by clicking on the [+] button we had set the quantity of the `initial_move` to 1 and associated a `move_line` with the corresponding quantity to it. As such, none of the move line of the raw moves of the back order is going to be created and the issue remains. opw-4119702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179062
Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an SO with that product (quantity 5) and confirm it - Go on the purchase order created Bug: The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well) Fix: In https://github.com/odoo/odoo/commit/a35be7b0dd52a5
Original PR description
Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an…
Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an SO with that product (quantity 5) and confirm it - Go on the purchase order created Bug: The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well) Fix: In https://github.com/odoo/odoo/commit/a35be7b0dd52a5a02b6811cb95ad3189483b7327, the partner passed to _select_seller will always have a value, but an incorrect one for dropshipping routes. The problem resides in https://github.com/odoo/odoo/blob/c04fe54bf45509660ea94a9d7d431c74f1c6023b/addons/product/models/product_product.py#L656. The partner_id is the SO buyer, and it's not possible to have the vendor == to the buyer. It thus default the vendor to the first known vendor which is incorrect. task-id: 4207060 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181542
When a user clicks in the catalog record input to change the quantity manually the input content isn't autoselect and the user has to delete the former one to enter the desired value. Autoselecting the value seems more conveniant in the majority of cases. Also, after one of these edits, if the user click right away in the Back to order button, the redirection to the order form will too fast and it will miss the last edition. Current behavior before PR:  Desired behavior after PR is merged:  @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180003
Some pot files were out of date/missing, some .po files were out of date/missing/missing translations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182056
Original PR description
Some pot files were out of date/missing, some .po files were out of date/missing/missing translations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182056
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#179676
Original PR description
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#179676
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Set "Quick encoding" to "Customer Invoices and Vendor Bills" - Create an invoice - Set "Total (Tax inc.)" to any value - Add a section and a note - Check Journal Items **Issue:** A tax is set on the section and the note lines. opw-4204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181519
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Set "Quick encoding" to "Customer Invoices and Vendor Bills" - Create an invoice - Set "Total (Tax inc.)" to any value - Add a section and a note - Check Journal Items **Issue:** A tax is set on the section and the note lines. opw-4204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181519
Steps: --- - Open POS Restaurant - Edit floor & click on a table - Rapidly click add table multiple times - Multiple tables with the same number are created - Duplicate tables also overlap the original table completely Issue: --- Duplicate tables should not be created. Cause: --- The "Add" button that creates the table calls an async function. Rapid clicks make new calls even before the promises are successful. FIX: --- Disable the button and creation until the previous tabl
Original PR description
Steps: --- - Open POS Restaurant - Edit floor & click on a table - Rapidly click add table multiple times - Multiple tables with the same number are created - Duplicate tables also overlap the original table completely Issue: --- Duplicate tables should not be created. Cause: --- The "Add" button that creates the table calls an async function. Rapid clicks make new calls even before the promises are successful. FIX: --- Disable the button and creation until the previous table is created so that rapid clicks are handled. task-3956310 Forward-Port-Of: odoo/odoo#169937
When computing the cheapest line of an order to apply a discount on it, combo line should be considered as one product as it is done in the sale app. Steps to reproduce: ------------------- * Setup a combo product * Setup a discount program that applies on the cheapest line * Open a PoS and add the combo product > Observation: The discount would be applied on the cheapest product of the combo instead of the whole combo Why the fix: ------------ When we look for the cheapest line an
Original PR description
When computing the cheapest line of an order to apply a discount on it, combo line should be considered as one product as it is done in the sale app. Steps to reproduce: ------------------- * Setup a combo product * Setup a discount program that applies on the cheapest line * Open a PoS and add the combo product > Observation: The discount would be applied on the cheapest product of the combo instead of the whole combo Why the fix: ------------ When we look for the cheapest line and we encounter a combo product we sum all the lines of the combo to compute it's total price opw-4033960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180482
When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701
Original PR description
When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#181129
Original PR description
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#181129
Steps to reproduce: 1. Install the `sale_project` module. 2. Create a product with the following properties: - Type: 'Service' - Create on Order: 'Project & Task' 4. Create a sale order and add the product to it. 5. Confirm the sale order. 6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.) The issue arises because the 'Project' smart button remains visible
Original PR description
Steps to reproduce:
1. Install the `sale_project` module.
2. Create a product with the following properties:
- Type: 'Service'
- Create on Order: 'Project & Task'
4. Create a sale order and add the product to it.
5. Confirm the sale order.
6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.)
The issue arises because the 'Project' smart button remains visible in the sale order tab until the page is reloaded, and there are no longer any order lines with a product of type 'Service', resulting in a StopIteration error.
Closes #180340
Forward-Port-Of: odoo/odoo#181946We did not compute fiscal position correctly regarding billing/delivery addresses combinations. Before this commit, we used the delivery to compute the fiscal position, except for invoices with no delivery or in the same country as the company, but it is not sufficient for several use cases. With this commit we check multiple combinations of EU/extra-EU partners with/without VAT. Change has been made regarding this spreadsheet: https://docs.google.com/spreadsheets/d/1PDlXpsgRiGvYvrUKgu
Original PR description
We did not compute fiscal position correctly regarding billing/delivery addresses combinations. Before this commit, we used the delivery to compute the fiscal position, except for invoices with no delivery or in the same country as the company, but it is not sufficient for several use cases. With this commit we check multiple combinations of EU/extra-EU partners with/without VAT. Change has been made regarding this spreadsheet: https://docs.google.com/spreadsheets/d/1PDlXpsgRiGvYvrUKguJqWPVl-g-7H6YqJiWoRNgWCYI/edit?gid=0#gid=0 opw-4072691 Forward-Port-Of: odoo/odoo#181648 Forward-Port-Of: odoo/odoo#178076
Manual back porting the part of 02f78498972a6fc7d560c0e6c0a5b3bf63eb58d3 that add common for account journal dashbaord tests. opw-4182523 Forward-Port-Of: odoo/odoo#182182
Original PR description
Manual back porting the part of 02f78498972a6fc7d560c0e6c0a5b3bf63eb58d3 that add common for account journal dashbaord tests. opw-4182523 Forward-Port-Of: odoo/odoo#182182
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing.
Original PR description
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in…
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing. This is even more obvious on a slow network. The difference between the first time and the others is that the form view used in the quick create must be loaded the first time, and is in cache afterwards. When we click on the "+" icon, the following happens: - we remove sample records from the groups and we enable the quick create in a column => triggers a rendering of the KanbanRenderer - in the same tick, we toggle the useSampleModel flag on the model => triggers a rendering of the Controller After its rendering, the Controller no longer has the classname `o_view_sample_data` which ensures that sample records are displayed as ghosts. After its rendering, the Renderer no longer contains sample records. The flickering occurs when the rendering of the Renderer is async (the one of the Controller being always sync, as it doesn't wait for his children to be re-rendered, as their props didn't change). Indeed, in that case, there's a small timeframe during which the controller no longer has the classname `o_view_sample_data` but the renderer still contains sample records. Normally, the rendering of the Renderer should always be sync. Indeed, we triggered the loadViews in its onWillStart but we didn't wait for the rpc to return (we have a `isLoaded` flag, and we have an empty rendering while `isLoaded` is false). However, when the loadViews is already in the cache, the promise is resolves in the next microTick, and we directly render the component with the state `isLoaded` true, i.e. with the KanbanQuickCreateController. But that component is always async, as it loads the form view data (onchange) in its onWillStart, and must wait for it. As a consequence, in that case, the whole rendering of the Renderer is delayed. To fix the issue, this commit simply ensures that the rendering of the KanbanRecordQuickCreate is **always** sync, by toggling the `isLoaded` flag in onMounted instead of onWillStart. That way, the Renderer is rendered without the sample records in the same animationFrame as the Controller, and only then we toggle the KanbanQuickCreateController. Closes #181743 Task~4196741 Forward-Port-Of: odoo/odoo#182300
Starting from `18.0`, text highlight effects are used for snippets customizations in themes, which means snippets can be provided with highlighted content (in a minimal format) that allows the JS code to rebuild the SVGs later when it's needed: ``` <span class="o_text_highlight o_text_highlight_[highlightId]" style="--text-highlight-width: ...; --text-highlight-color: ...;"> text content ... </span> ``` The highlights code provides some tools to adapt them when the content
Original PR description
Starting from `18.0`, text highlight effects are used for snippets
customizations in themes, which means snippets can be provided with
highlighted content (in a minimal format) that allows the JS code to
rebuild the SVGs later when it's needed:
```
<span class="o_text_highlight o_text_highlight_[highlightId]"
style="--text-highlight-width: ...; --text-highlight-color: ...;">
text content ...
</span>
```
The highlights code provides some tools to adapt them when the content
is changed: add & remove text, resize… But It doesn't handle the case
of a dropped snippet with highlights.
The goal of this commit is to be able to build the highlights of a
snippet once dropped.
Remark: The behavior fixed in this commit wasn't possible until `18.0`
(with themes snippets using highlights) but we target `17.0` to handle
every possible customization that uses the effects before themes
refactoring.
task-4215788
Forward-Port-Of: odoo/odoo#182208