When unselecting an export template, the list was empty
instead of just keeping the current list. I also added
some tests for this component introduced in Owl recently.
Some scss changes have been done to remove unnecessary
lines from the file and fix the style in a small window.
With a small window, items from the export list are not
draggable and the list must be placed at the bottom
part of the dialog
closesodoo/odoo#95226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For modules that fully implement Stripe Connect, i.e. that sign requests
with their own API keys, there was no way to pass contextual data to the
proxy when making those requests.
This commit addresses the issue by populating the `proxy_data` param
present in all proxy's routes' signatures with an extendable `dict`.
task-2917229
closesodoo/odoo#96279
X-original-commit: 5df308c58e02c9ca3287c124c0df4e359817ce16
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
After the following steps, snippets overlays are not properly removed
from the DOM:
- In edit mode, drop 2-3 snippets in the page.
- Click on these snippets to activate their overlays.
- Drag and drop a popup in the page.
- Drag and drop a snippet in the popup.
- Move this snippet inside the popup thanks to the move handle button.
- Click on the "eye" button to hide the popup.
- Click on snippets of the page, the overlays are no longer removed when
they should.
It was because since commit [1], it is allowed to define an element
in which '_destroyEditors' destroys the editors but we forgot not to
completely empty the array that contains them.
But anyway, the editors list does not need to be updated in
'_destroyEditors' since commit [2] as it is already done in the
'destroy' method of 'SnippetEditor'.
[1]: https://github.com/odoo/odoo/commit/b7d522e9e7e31ac6bf926aae65e58d9f6cfa8903
[2]: https://github.com/odoo/odoo/commit/2a19a83762c1bc74dd7336378d254ab6da8e3a22
task-2799602
closesodoo/odoo#96267
X-original-commit: 0e97847cf42db935522f5f834f6fcb86de02eae3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.
This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.
Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.
task-2885882
closesodoo/odoo#96248
X-original-commit: 317eea48186c948009399daedf70dd407f6a9ca8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Small oversight of: 4c6a010730
This commit simply hides the stat-buttons when the mail.activity is opened in
the popup form.
When in that popup form, you don't want to switch your context, especially
considering the only button currently available allows you to open the related
document (from which you just opened the activity popup form, creating a loop).
Task-2920490
closesodoo/odoo#96238
X-original-commit: 7b6e700d7e7c54cac0200e98b4eb04af9f115608
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, in large database the time to unlink is very long.
Before 500 ms after a few ms
closesodoo/odoo#96236
X-original-commit: c17e0a6702e58ba784c70bdb04f6a455e6d5b727
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Reproduction:
1. Install Attendance app
2. Create a new internal user “kiosk”, with only access right “Kiosk
Attendance” for app “Employee”, other places as blank
3. Make sure the Settings for Attendance app, Employee PIN is unchecked
4. In an incognito tab, log in as kiosk, go to Attendance, click “kiosk
mode”, then “identify manually”
5. Choose an employee, with a warning message “Wrong pin”
Reason: A recent update refined the user group check for the
attendance_manual function. Checking if the user is an officer in the
Attendance app can be over strict. However, after discussing with yti,
we decided to pop up a warning message for security reasons when the
user would like to use Kiosk mode without pin code.
Fix: Add a warning message for higher access right requirement
opw-2898452
Related fix in V15: https://github.com/odoo-dev/odoo/commit/2975c0539d8c2781ff56a9f8be8e302d45b7d80bclosesodoo/odoo#96230
X-original-commit: 82f2966ed5b3afd30ac5b18c32af7993746fc681
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Install Time off and timesheet modules
- Create a public holiday with no "working hours"
- Then edit it and add it with working hours used by some employees
Expected behavior:
Adding the working hours makes that the global time off meets the
requirements to create timesheets. Then the employee related to the
new "working hours" is going to have timesheets created for this
holiday.
Current behavior:
No timesheet is created.
Explanation:
The write function of the global time off only updated timesheets
when the dates where modified. We add the update in the calendar_id
modification case and with it the new conditions to create the
timesheets. (working hours = calendar_id)
opw-2879882
closesodoo/odoo#96226
X-original-commit: a255a743b5296570aab166a5e275a323a1792b60
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When a timezone before UTC is selected (e.g.: US/Pacific), the highlighted days
of some events are not rendered on the correct day (offseted one day before).
More technically, events wrongly displayed will be the ones where:
event.start_date.hour < (UTC - current_tz)
Step to reproduce the issue:
1. Change the Odoo user and your computer timezone to any timezone matching the
condition above (e.g.: US/Pacific)
2. Create an event matching the condition above (e.g.: a full day event is
the easiest)
You will see that the day that is highlited is the day before the real date
of the event (e.g.: 14th July is highlited while the event is a whole day
event the 15th of July)
Solution: The issue is that the cursor (highlight of the day), doesn't take
into account the timezone of the calendar (which is the timezone of the
computer). Consequently, the highlight is sometimes done on the wrong day.
As stated in commit [1], the `FullCalendar` library contains a `start` and
`end` property that takes into account the timezone of the calendar (as
described in [2]).
[1]: https://github.com/odoo/odoo/commit/94018575c6ac21fc94591c3265e017c769d87c0c
[2]: https://fullcalendar.io/docs/event-object
opw-2830697
closesodoo/odoo#96224
X-original-commit: 8764fdccb395875de5682f9019e0e99fde59f286
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Before this commit, if you are on the time off dashboard calendar of a company
that is not set as your user's default company, no time off is displayed.
Also, if you try to consult your time offs on the dashboard tree view and if
you have one leave with a leave_type without company on a company that is not
the one you're logged in, you'll get a access error.
This commit fixes both issues.
taskID 2893659
closesodoo/odoo#96199
X-original-commit: 6e604bd8bb1d6011482a9ce1778a71a108d0c610
Signed-off-by: Kevin Baptiste <kba@odoo.com>
With Calendar and CRM installed:
- Create a lead and a meeting related to that lead.
- Delete the lead.
- Go to the meeting form view from the calendar App.
- Click the Document action button and nothing will take place.
After this commit if you delete the lead, you will no longer be able to the
see the button as document information is correctly reset.
Task-2917174
Closesodoo/odoo#42450Closesodoo/odoo#47497closesodoo/odoo#96190
X-original-commit: 71ccb7dae43a13521f2a290ce76cafd8fb5b963f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The error message should not be copied for obvious reasons. A new request
should not begin in error state.
CLosesodoo/odoo#43603
X-original-commit: 613dba74b66c51d358e7a6590b6cbfdef81a62b8
Part-of: odoo/odoo#96190
The fake demo email used in our crm_lead demo data is an actual customer's email.
Steps:
* Install Demo Data
* Navigate to CRM and activate Leads.
* See Lead for "DeltaPC: 10 Computer Desks"
* Issue: Email being used is an active real company's email.
Updating to a more distinctive fake email so actual customers are not
accidentally used in our demo data.
opw-2746911
Task-2917174
Closesodoo/odoo#84225
X-original-commit: 3e11482db41d7633a1606d6a98537e23f369d1e4
Part-of: odoo/odoo#96190
Probability is not always given to write, hence date_closed is currently not
always reset. Indeed as it is a computed field it can be updated after stage
update, without being explicitly in values.
In this fix we consider that going out of won stage without any other hints
on probability is like being not won anymore, therefore resetting date closed.
Task-2917116
Closesodoo/odoo#93704Closesodoo/odoo#93704
X-original-commit: 1cf1b572b10bfbd02581c12f89824a028c4f23e6
Part-of: odoo/odoo#96190
Followup of odoo/odoo@6e46d4cd07 and odoo/odoo@1f81d60de6
Also fix a test failing with python 3.8. Message-ID is formatted using chevrons.
Task-2917174
X-original-commit: 26c88387f24b8515dc74c24594f203e3953b8a39
Part-of: odoo/odoo#96190
Onchange could also populate the lang field of the lead when updating the
customer.
Partial backport of odoo/odoo@65bb3a5710
Task-2917174
Closesodoo/odoo#78715
X-original-commit: e0e1e402a6c40ed89bc5a11671e364a67e93a176
Part-of: odoo/odoo#96190
Revert
"[FIX] sale_timesheet_margin: prevent cost override on product service"
This reverts commit e260a97392e698c88741be713a6b8cc2dc3c74a1.
After discussing with thcl-odoo, it was determined that it is better to
revert this commit as it is affecting all service products.
Also the desired behavior is that users should change the cost on
the product form not on Sales Orders
OPW-2857506
closesodoo/odoo#96189
X-original-commit: 143f1d4766fb7d718c5262cfcb062e2039549dd3
Related: odoo/enterprise#29577
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When editing database fields via the web editor, their value are not checked.
Thus, stack traces can come up to the front-end user.
Step to reproduce the issue:
1) Install the E-Learning module and connect to the website
2) On the main website (not the backend), go to Courses > Edit
3) Edit the Next Rank treshold with any non integer string (e.g.: coucou)
A stracktrace will be shown upon save.
Solution: The issue is that there are no validation on the submitted fields,
this can cause stacktraces. A try-catch was used around the parsing of the
input value to catch and properly raise these exceptions to show clean errors.
On top of this, integers were not properly parsed, they were not taking into
account the `thousands_sep` of the user lang (e.g.: 35,000 for 35000).
NB: Generic fix of the following PR [1].
[1]: https://github.com/odoo/odoo/pull/85535
opw-2819392
closesodoo/odoo#96187
X-original-commit: edf76dbb0880c9b08354563a3c77e7c06a604802
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
_split_productions wrongly compute duration expected for backorders.
Setting quantity on production adapt many things including workorders,
so adapt original production after copy_data for backorders.
closesodoo/odoo#96179
Task: 2884562
X-original-commit: 71b8531881ff6924762ec34db3f2ddf858383218
Signed-off-by: Tiffany Chang <tic@odoo.com>
*: calendar, survey.
In order to ease the PR introducing websockets in Odoo, introduce
the multi service. Indeed, the cross tab bus won't be necessary
anymore but there will still be a need to elect a main tab: some actions
should only be triggered once. To achieve this, the code electing the main
tab has been split with the one handling the longpolling. The crosstab
bus now relies on the multi tab service to known whether or not the
current tab is the main tab.
task-2053917
closesodoo/odoo#96174
Related: odoo/enterprise#29573
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This only happens after the introduction of PosPopupController.
ProductInfoPopup and ClosePosPopup manages their own error but it's
not compatible with the new controller. Basically after the error
in onWillStart, the renderer will attempt to render the component
but there will be error which results to *not* being able to call
onMounted hook which is responsible in calling error popup.
Furthermore, the PosPopupController is unable to cleanup the original
popup that failed. So the connection returns, all the unshown popups
will show up again.
In this change, we clear the problematic popup by immediately calling
`cancel` and showing the proper error in the onWillStart call stack,
no need for the onMounted hook.
IMPROVEMENT: Perhaps it's better to delegate the management of error
to the component that requests for showing the popup, such that the
popup popup is more or less dumb which only receives props, and not
make it's own rpc during mounting.
To reproduce: https://watch.screencastify.com/v/1LE31gapmkIjTfkB7dTYclosesodoo/odoo#96166
X-original-commit: f692b403213d593d7327a2cbc33bd00359fd079d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, the tours default_shape_gets_palette_colors and
edit_link_popover were not using the tour utils function
registerEditionTour, that starts a tour on the iframe, in edit mode,
with a timeout on the first step.
Because this timeout was not there, loading the iframe and the snippets
menu could take longer than the default timeout and the test would fail
inconsistently.
task-2687506
closesodoo/odoo#96164
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, we asserted that the view did not switch to form when clicking
on the the color picker. It was wrong because there is no action manager, hence no possibility
to effectively switch view.
After this commit, we assert that the list view's callback selectRecord is not called, which
is equivalent.
closesodoo/odoo#96159
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Add .col to the button to properly align it with the pos_config_id
field and label.
closesodoo/odoo#96113
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit fixes the product image grid not being updated after
changing a variant.
TaskId-2922057
closesodoo/odoo#96102
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*: calendar, note, test_mail.
In order to ease testing and to prepare for the ActivityMenu widget to be
converted into a component, let's add the sytray menu item into the registry
systematically when using the start helper.
closesodoo/odoo#96094
Related: odoo/enterprise#29529
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
on/off are deprecated in favor of addEventListener/removeEventListener.
Calls to the bus service have been updated to reflect those changes.
task-2053917
closesodoo/odoo#96017
Related: odoo/enterprise#29501
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, if installing a new module from the "new content"
modal would fail, the "Building your website" gif was not removed.
This commit removes it when the installation fails.
task-2687506
closesodoo/odoo#95955
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, uploading multiple files could lead to inconsistent
results: the files array was sorted from the lower to the higher size,
but this sorted array was not used after (the unsorted one was).
This commit fixes this issue by clearly defining a sorted array, and
uploading the files sequentially, as it was done before [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
Before this commit, the media dialog was not handling properly the
upload of svg files from the media library: a whole part of the original
ImageWidget was missing in the converted media dialog from [1], which
was converting the svg with the appropriate color codes from the color
palette, to allow for color customization.
See original file from 15.4: web_editor/static/src/js/widgets/media.js.
Also, it was not displaying those svg correctly with the appropriate
background.
This commit fixes those issues by adding back the code handling the
dynamic colors detection and the background css rule.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
Before this commit, following those steps:
- Go to /hello.css
- Create the page/file
- View in page manager
- Click on its row
-> You're redirected to the file, with infinite loading
This commit fixes this behaviour by unblocking the iframe:
- on the OdooFrameContentLoaded event for frontend pages
- on the load event for other pages
To do that, the BlockIframe component is changed to handle process ids.
Before this commit, the BlockIframe component would count the calls to
block or unblock the iframe (and store it in an iframeLocks variable),
so that multiple processes can block the iframe independently from each
other.
As an exemple, for two processes A and B, the iframe should remain
blocked during those two processes, and released at the end:
(A) blockIframe => (B) blockIframe => (B) unblockIframe => (A)
unblockIframe.
But that iframeLocks variable was fragile: a process that blocks the
iframe should unblock it once, otherwise it would mess up the locks
count. It was not appropriate for a process that could be ended with two
events, for example loading the iframe. The first of the 'load' or
'OdooFrameContentLoaded' events should unblock it.
To change that, a process can block the iframe with a processId. The
first unblock call with the same processId will unblock the iframe, the
other ones will be ignored.
task-2687506
Part-of: odoo/odoo#95955
Before this commit, when uploading multiple files and clicking on the
cross button, the toast was reappearing every time a new file was
succesfully uploaded.
This commit changes its state so that it is only visible when one or
multiple files are added to the uploading queue. The user can still hide
it with the cross.
task-2687506
Part-of: odoo/odoo#95955
Before this commit, clicking on a different variant of a product from
the WebsitePreview client action introduced in [1] would not update the
browser's url.
This commit adds an event listener to update the browser url on hash
changes, as load events are currently handled.
The product variant buttons are directly changing the hash instead of
replacing the state of the history.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
This commit aims at making the website dialog as well as the edit_menus
tour more stable.
Commit [1] introduced a new dialog API for website.
The component WebsiteDialog handles click asynchronously.
Prior to this commit, the tour could sometimes detect and click on modal
triggers before the actions that the previous trigger was triggering
could complete. This could lead to a modal closing too early either
because a click would done on the wrong modal or the input was completed
before the validation method was called (since the click handlers are
asynchronous).
Here are a few examples of possible failure in the tour :
- The tour clicks on "Add Menu Item", which should open a new modal
- The tour then clicks on OK to make sure the modal does not close.
- The click on OK is done before the New Menu Item modal is open and
therefore is triggered on the previous modal
- The modal is closed too early
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field.
- The validation method doesn't block the OK method which results in the
dialog being closed
- The tour expects the dialog to be open and crashes
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field
- The tour clicks on OK again
- 2 entries are created instead of one.
The last one doesn't crash the tour but is still incorrect.
This commit disables the buttons when they're clicked for the first time
until the handler is processed.
This commit also make the triggers in the tour more specific so that the
tour always clicks on the right modals.
[1]: https://github.com/odoo/odoo/commit/28a78fb4e4e4465aa99fb94f7cac3a21b2188502
runbot-4122
closesodoo/odoo#95839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
After this commit clients will be able to select whether to display the add to cart button when the computed price of a product is 0.
This option will be available in the settings.
task-2694860
closesodoo/odoo#87952
Related: odoo/enterprise#27594
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Purpose
=======
When a user receives an email to activate their account, allow them to
click on the "Activate Account" button after the account has already
been activated instead of showing a "Invalid signup token" error.
Specifications
=============
Add a parameter p_id to the sign up url to check if the partner has
already activated their account (if their user_ids state is not new) and
redirect them to login otherwise.
Task-2680414
closesodoo/odoo#79936
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Create a user with only "Inventory/Administrator" access right
- Connect with this user
- Go to Inventory/Configuration/UoM Categories
- Try to add/delete/change any unit of measure in any category
Problem:
an access error is triggered `You are not allowed to access 'Model Data'
(ir.model.data) records.`
opw-2905840
closesodoo/odoo#96137
X-original-commit: 8e58feb6e6151db8e47af4f296d5eb552532cb29
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When contacting attendees of an event, exclude cancelled attendees by default
as chances are they do not have any interest in what you are going to
communicate.
Task-2796152
closesodoo/odoo#86625
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Consider two models A and B, where
- model A has a many2one_reference field 'res_id' with model field 'res_model';
- model B has an auto-join one2many field 'stuff_ids' to A using field 'res_id';
- the field 'res_model' is not flushed on some record.
model | A | B
-----------+-------------------+-------------------
memory | res_model = B |
-----------+-------------------+-------------------
database | res_model = NULL | id = 42
| res_id = 42 |
| foo = 'bar' |
Now, perform a search on model B that should return record with id=42 by
matching some condition on the unflushed record in model A, like:
B.search([('stuff_ids.foo', '=', 'bar')])
Before this patch, the search method would not flush the field
'res_model', which causes the method to return incorrect results. This
patch fixes the issue by ensuring that searches on one2many fields flush
all the fields on which the one2many field depends.
The issue was discovered while working on task 2735672.
closesodoo/odoo#96115
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit improves the expendability of the attachment_viewer model
and component by making it less dependent on attachment_list.
This is required by the refactoring in wowl of the documents app(s).
TaskId-2898342
closesodoo/odoo#94930
Related: odoo/enterprise#28976
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The `sale.report` `paid` state is added in `pos_sale` and shouldn't be considered in the standard `sale` code.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#96125
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since [1] when Bootstrap 5 was introduced, the position of the
connectors between steps of the "Steps" block is wrongly computed.
The left offset of the connectors between steps is computed as 50% of
the column width + half the size of the content it connects to.
In Bootstrap 4 the columns are positioned as relative.
In Bootstrap 5 the columns are positioned as static.
Because of this "50% of the column width" became "50% of the row width"
in Bootstrap 5.
This commit makes the specific columns of this snippet positioned as
relative so that the offset calculation get back to its former result.
Steps to reproduce:
- Drop a "Steps" block.
=> Connectors are wrongly positioned, even spanning outside the page.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2729177
closesodoo/odoo#96071
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The HTML sanitization regroups similar elements into a single one.
For 'style-inline' HTML fields, the font awesome icons are converted
to images within spans.
Because of this, when sanitizing a "5 Stars" block in a 'style-inline'
HTML field, the spans are grouped and all the images end up inside a
single span, with:
- each image being `display: block;` and
- the global span having a fixed width equal to a single image's width.
This turns the horizontal succession of stars into a vertical one.
This commit adds the `oe_unbreakable` class to the image wrapping spans
to prevent sanitize from grouping them into a single one.
Note that this commit does not address the issue that upon a further
edit of the field, the Stars block is not recognized anymore. This
would require a `convert_from_inline` reverting operation which would
change many other behaviors.
Steps to reproduce:
- Go to user profile.
- Edit signature.
- Insert a "5 Stars" block (i.e. use the "/5" command).
- Save.
=> Stars became vertical.
task-2845963
X-original-commit: 9bf0b9872056e5f69a9c912825b863e0a353d5f5
Part-of: odoo/odoo#96071
Since [1] when the Stars blocks were introduced, they were corrupted
during the save operation of views because the views do re-render their
content with `pretty_print=True`.
This commit prevents this from happening by adding a zero-width space
to the Stars blocks.
Steps to reproduce:
- Drop a Text block in a page.
- Insert a "5 Stars" block after the text (type "/5" to find it in the
Power box).
- Save the page.
=> Spaces appear between the stars, and the block does not respond
anymore when clicking on stars if the page is edited again.
[1]: https://github.com/odoo/odoo/commit/8266b978e1bfa5bedfaf1c4fcceadd26400fc85c
task-2845963
X-original-commit: 832995cafcf6181ab3bd1b2d432fd34f6aeed7fe
Part-of: odoo/odoo#96071
Since [1] when the stars were made available in the power box, an
exception is raised when clicking on a technical SVG of the "Steps"
block.
This happens because SVGs have their `nodeType === Node.ELEMENT_NODE`,
they have `className` and `classList` properties, but their `className`
is not a string: it is an `SVGAnimatedString`. Because of this, the
`includes` method is not available on `className`.
This commit prevents the non-existing `includes` from being called.
Steps to reproduce:
- Drop a "Steps" block into the page.
- Click on the column before the first step, at the same height as the
steps icons. (There is an hidden SVG there containing the definition of
the arrows head.)
=> Did raise an exception.
[1]: https://github.com/odoo/odoo/commit/8266b978e1bfa5bedfaf1c4fcceadd26400fc85c
task-2845963
X-original-commit: dbfbf264750a0760d4f2d96a1b7a13ea27472316
Part-of: odoo/odoo#96071
luvi