auth_totp module added user_id in session_info, but it's not in the depends of project and web_editor module.
To avoid traceback after uninstalling auth_totp module:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading '0'),
we should use uid instead of user_id in js code.
closesodoo/odoo#96880
X-original-commit: 81b92a61907028f71b1337b11d0d60ee98bb5775
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
Onclicking quote icon of BlockQuote generates traceback
After this commit:
Now on clicking quote icon doesnot generate traceback
Task-2920794
closesodoo/odoo#96944
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- switch to any language other than English
- go to a page where you can use the text editor,
for instance you can try to edit a project's description.
- type `/` in the editor
You should see that some commands are not translated.
Some files modified in this commit are located in the
web_editor/static/lib/web-editor directory.
However, only the JS code located into /static/src/ is considered for
export of translations. This is done to avoid polluting translations for
code not managed by Odoo.
We have to update the .pot file manually. A good workaround is to copy
the web-editor folder inside to static/src, export the
translations and then delete the copy folder.
However, this means that those updates to the .pot file will be lost in
the next translation export.
opw-2918128
closesodoo/odoo#96939
X-original-commit: 0cc5505b27f29d44c25af83653b09b1b49cfec79
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Before this commit:
When we put the text direct in td and try to color it with design toolbar with
text color then text in normal should change the color.
After this commit:
When we enter the text direct and try to change the color with design toolbar
then it will change the text with defined color.
Task-2843065
closesodoo/odoo#96830
X-original-commit: 76fd633ab78d5cb47c990063040d6d1e9708df2d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: website, website_mass_mailing, website_payment
When an unsafe snippet is dropped into a sanitized HTML model field, its
unsafe content gets removed on save.
We need a way to mark snippets as being (in)compatible with
sanitization. It cannot be automatic, as, for example, the snippet
introduced at [1] contains an iframe but is compatible with
sanitization.
In 13.0, we will temporarily set up an automatic mechanism that marks
existing snippets containing forms as being incompatible with
sanitization.
In 14.0 a distinction between full sanitization and form-tolerant
sanitization introduced at [2] is added with this forward-ported commit.
This commit prevents unsafe snippets from being dropped into sanitized
HTML model fields.
The "Form Builder", "Product Search" and "Product Search Input" blocks
are now prevented from being dropped or moved into form-sanitized HTML
fields.
To do this, this commit introduces a new `t-forbid-sanitize` attribute
on the `t-snippet` tag. It can have the value `true` to prevent it from
being dropped into any sanitize fields, or `form` to specifically limit
to form-sanitized fields.
Steps to reproduce (in 13.0):
- Go to a product page
- Drop a "Product Search" snippet into the product-specific section of
the
product
- Save
=> The form was removed.
[1]: https://github.com/odoo/odoo/commit/c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
[2]: https://github.com/odoo/odoo/commit/388c222c6c4bb7e2fe3e67009b248359ae0fd3db
task-2829961
closesodoo/odoo#96812
X-original-commit: 9eaba23781766730b06e936dbd9c5d0c28c909c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Only youtube and dailymotion were able to add this property to their
video. Maybe it was not supported by vimeo back then, but it seems to be
supported now.
It improves the vimeo youtube in two ways:
1. For background video, the controls are now hidden. There were visible
for a few seconds before this PR which is not ideal
2. For non background video, there were no way to hide the controls
which might be problematic to some users as in mobile there is the
controls display but also an ugly "Tap to unmute" in the middle of
the video.
Step to reproduce (background video):
- Drag & drop a "Text - Image" snippet and add it the biggest possible
padding, also add padding to the image (so you see the full video and
not just part of it)
- Double click on the image, then on the video tab insert a vimeo url
- Save, you will see the controls for a few seconds (progress bar, video
title, link to vimeo, etc)
Step to reproduce (non background video):
- Drag & drop a "Text - Image" snippet and double click on the image
- On the video tab, insert a vimeo url
- Select "Auto Play"
- Save and go to mobile, you will see the controls and an ugly "Tap to
mute" in the middle of the video.
The "Tap to mute" is a browser feature, not a vimeo feature. Browsers
are muting video by default when auto play.
Still, some people want to have a nice auto play video shown to users
without sounds and don't want that overlay/controls.
opw-2901256
closesodoo/odoo#96804
X-original-commit: 7128e4080511b5f224da3dce6d88ba8bcf9a0d47
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
On pasting image to editor, the default width was set to auto.
After this commit:
Now on pasting image to editor, the default width is set to 100%.
Task-2862892
closesodoo/odoo#96779
X-original-commit: 2e4811b751960548dc66f6e4ff00495e5226fdbc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This nomenclature was taken straight from the old Summernote options
when the new editor was merged in 15.0.
While perfectly correct from a technical point of view, the use of the
word "Auto" in this context is confusing because the user might think
that the system is going to choose an optimal size for them while this
is not what this option does at all. What it does is simply removing any
width style property that might be set on the image, thus letting the
image be sized appropriately by the browser in accordance with active
CSS rules at that position in the page, hence its "Default" width.
closesodoo/odoo#96679
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: im_livechat, snailmail_account, survey, web_editor.
The callback registered by the bus service method onNotification was
not the same unregistered by offNotification. Since those method were
superfluous, they have been removed in favor of (add/remove)EventListener.
closesodoo/odoo#96684
Related: odoo/enterprise#29819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1] and even after [2] when replacing a media by a media of a
different type only classes were cleaned - but all inline styles were
copied.
This commit filters the inline styles when replacing a media by a media
of another type.
Steps to reproduce:
- Drop a "Text - Image".
- Replace the image by an icon.
- Apply solid colors for the foreground and the background.
- Replace the icon by an image.
=> The applied colors were kept in the inline style of the image.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/9ca349bbdb75505e8dbd31898f05ba8d694e7953
task-2687506
closesodoo/odoo#95853
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when replacing a media by a media of the same type or that has
some extra classes in common, those classes were removed instead of
being kept.
This commit makes sure only the classes that do not exist in the newly
selected media type are removed.
Steps to reproduce:
- Drop a "Text - Image".
- Replace the image by an icon.
- Apply a circle effect and colors on the icon.
- Replace the icon by another icon.
=> The applied effect and colors were lost.
[1]: https://github.com/odoo/odoo/commit/9ca349bbdb75505e8dbd31898f05ba8d694e7953
task-2687506
Part-of: odoo/odoo#95853
Commit [1] moved the editor in the backend introducing changes to the
way some options interact with the website. This unfortunately broke
the header position option, the header background option and the footer
visibility option.
The header position option would loop indefinitely, the header
background color option would not display the correct preview colors and
the footer position would trigger a traceback.
This commit fix those bugs:
- The header position option had a callback that was never called, it is
now called.
- The copy of styles introduced by [2] is now less implicit. Only styles
that are defined in web_editor/common/utils:
[EDITOR_COLOR_CSS_VARIABLES] are copied on the snippet menu, and only
those variables will be used as background colors for the preview
elements. (Allowing for every other colors like black and white to be
used with classes).
- The footer visibility option had a broken line of code that was copied
from past code. It is now fixed and working.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
task-2687506
closesodoo/odoo#94949
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Windows uses /r/n as newlines and the split parameter was not taking
that into account, thus inserting the /r character.
task-2742071
closesodoo/odoo#96422
X-original-commit: 90e565f811523968c297f0254f4aa7046c4e710e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Before this commit, the styles for the qweb elements
(t, t-if, t-out, ...) were not applied.
This commit apply them except when converting html to inline
styling.
task-2892193
closesodoo/odoo#96433
X-original-commit: 4cc40661ed3287e15ea21cedf8e2a582e32be5c8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The codeview of mass_mailing had the wrong height in non full-width
contexts.
task-2894177
closesodoo/odoo#96342
X-original-commit: ee001e843a0a02f04030f0959c7db58beaaa3a3b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Margin top of `we-selection-items` was removed during the migration of
BS5 to avoid warning on runbot, but we have to restore it for non BS
`dropdown-menu`.
Ref:
odoo/odoo@e1ea58c941closesodoo/odoo#96186
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
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, 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, 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
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
Since [1] when the media dialog was re-written in owl, the problem is
solved, this forward-port only keeps the added test scenarios.
See the description of the initial problem below:
Similarly to the comment introduced in [2], classes identifying a video
are only available before media.js begins to save.
This led to wronly inserting the pictogram in an incorrect location when
replacing a video by a pictogram.
This commit keeps track of the fact that a media node was a video before
being replaced instead of trying to find out after the classes have been
removed.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Replace the image by a video.
- Replace the video by a pictogram.
=> Was adding the pictogram in the first column's button instead.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/d4d25c8b497e465753cef030292faa4824145cb1
task-2729177
closesodoo/odoo#95963
X-original-commit: b50a8015da7bba3b156fa8941b6c2b17533159c7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website
Since [1] when the media dialog was re-written in owl, the problem is
solved, this forward-port only keeps the added test scenarios and some
of the code cleanup & comments.
See the description of the initial problem below:
Since [2] replacing an image by an icon then selecting the icon opens an
error popup.
After this commit there is no error when selecting the icon that
replaces an image because the editor of the replaced media is destroyed.
Steps to reproduce:
- drop a Text-Image snippet
- select the image
- replace the image by a pictogram
- click on a different snippet
- click on the pictogram
=> an error popup is displayed
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
task-2729177
X-original-commit: e1c4b62601e5a76a36406d790c9ad2da91c54951
Part-of: odoo/odoo#95963
Co-authored-by: qsm-odoo <qsm@odoo.com>
Since [1] the file size is displayed only for images that support
processing (filter effect, crop, resize...) but when switching to an
image that does not support it, the old size remains displayed.
After this commit when an image for which the file size is not computed
is selected, the previous file size is hidden.
Steps to reproduce:
- drop a Text-Image snippet
- select the image => the size is displayed in the options block title
- replace the image with an animated gif
=> previous size did remain displayed (now size is not shown anymore)
[1]: https://github.com/odoo/odoo/commit/089ae3d28b5d2d7bdbaad133174ae54240113181
task-2729177
X-original-commit: 378f67749a51d8c0b9fb65767faceaa0844916e5
Part-of: odoo/odoo#95963
Add some classes to improve the alignment.
Quite difficult to deal with as we have a lot of inputs on the same line.
Follow of odoo/odoo#95725closesodoo/odoo#95815
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
During Editor initialisation, detect if the editable element contain orphan inline nodes.
If so we transform the base element HTML to put those orphans inside `<p>` containers.
This is used to ensure the HTML generated by Etherpad is compatible with this editor,
allowing the user to use all the features without loosing the Etherpad look.
task-2877273
closesodoo/odoo#93207closesodoo/odoo#95347
Related: odoo/enterprise#28965
Related: odoo/enterprise#29130
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
# Conflicts:
# addons/web_editor/static/lib/odoo-editor/src/OdooEditor.js
closesodoo/odoo#95445
Related: odoo/enterprise#29185
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
During paste HTML, an inline element or a textNode should never be
inserted outside of the targeted initial container.
Those kind of orphans elements should never be present in an HTML paste data,
but better safe than sorry.
Part-of: odoo/odoo#95347
# Conflicts:
# addons/web_editor/static/lib/odoo-editor/src/OdooEditor.js
Part-of: odoo/odoo#95445
* Adapt Unit tests to always have a container block element
* Add some tests to ensure the editable root direct child nodes are all blocks
* Fix paste HTML unit tests to properly check that we never paste inline
elements or text nodes outside the target container
Part-of: odoo/odoo#95347
# Conflicts:
# addons/web_editor/static/lib/odoo-editor/test/spec/collab.test.js
# addons/web_editor/static/lib/odoo-editor/test/spec/copyPaste.test.js
# addons/web_editor/static/lib/odoo-editor/test/spec/editor.test.js
Part-of: odoo/odoo#95445
Following [1], it was discovered that, before this commit, the
img-thumbnail class was properly removed when turning an image into an
icon, document or video but not when turning an icon into an image,
document or video. The working image case actually worked by chance as
we remove all classes starting by img-. The "thumbnail" class was
actually removed instead of the "img-thumbnail" one.
In master, this fixes the issue by adding "img-thumbnail" instead of
"thumbnail" to the list of classes to remove. We also do not need to
consider all classes starting by "img-" anymore.
[1]: https://github.com/odoo/odoo/pull/95287#pullrequestreview-1031639109closesodoo/odoo#95616
X-original-commit: 55ba93da587773fedae64b2911ddc8d04482d94b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website_forum
Portal users cannot insert images in the WYSIWYG, eg in a forum post.
Steps to reproduce:
- Install website_forum
- Connect as portal
- Go to the forum and create a new post
- Type '/image' and try to insert an image
- An Access Error is raised preventing the portal user from inserting an
image
History:
- It was possible in version earlier than 15.0 before the new editor, as
it was using a base64 inplace image upload to bypass the access rights
and avoid creating an attachment.
- It was broken in 15.0 with the new editor which doesn't have such a
mechanism. The image upload was then disabled for those users in 15.0
with [1] to avoid that bad UX with those errors/tracebacks.
- It was decided to implement a clean solution in master and see from
there was will be done with 15.0 (as being able to upload an image on
a forum seems quite critical).
Solution here in master to be able to use the media dialog:
- First issue, about opening the media dialog:
It fetches attachments, which is raising some access errors. We now
catch the error silently and return an empty list.
- Second issue, about upload an image (and thus creating an attachment):
We now create attachments with sudo to allow access to portal users,
but only if he has write access on the model.
[1]: https://github.com/odoo/odoo/commit/e453d4c119a69f285d9a014babe485492bbe9c40
opw-2648770
task-2811325
closesodoo/odoo#82612
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Merlin (megu) <megu@odoo.com>
Before this commit:
Changing header style with triple click selection bring changes to the next
line, which it should not.
After this commit:
Now even after triple click selection the change stays with the selected part.
Task-2810134
closesodoo/odoo#95613
X-original-commit: dd64fc7730ef34d715cfb2146a7ef8a7ba98f34e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When replacing an image by a pictogram, the classes of the previous
media are copied to the new icon's `<span>`. This potentially includes
the `w-100` class which prevents the alignment from behaving correctly.
This commit removes the `w-100` class if it exists.
Steps to reproduce:
- Drop a "Media List" block
- Replace first image by pictogram.
- Align icon to the right.
=> Icon was displayed aligned to the left.
task-2829971 (was task-2729177)
closesodoo/odoo#95287
X-original-commit: https://github.com/odoo/odoo/commit/8f71a3c55dcaae738fbb673266aa400b4c4a1fa4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the media dialog was refactored to owl, some of the
classes clean up when switching across media types were lost.
This commit restores the clean up for each media type - as they were
before [1].
Steps to reproduce:
(Just one example - there are many scenarios)
- Drop a "Text - Image" block.
- Apply a rounded circle on the image.
- Replace the image by a video.
=> The rounded circle effect remains but cannot be removed.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
task-2829971
Part-of: odoo/odoo#95287
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
Due to the removal of btn-block we need to change the display to grid
> Dropped .btn-block for utilities. Instead of using .btn-block on the
> .btn, wrap your buttons with .d-grid and a .gap-* utility to space
> them as needed
https://getbootstrap.com/docs/5.1/migration/#buttons
Task ID: 2766483
Part-of: odoo/odoo#95450
The conversion of html to inline-styled html compatible with e-mail
clients failed to take into account styles that included `var()` and/or
`calc()`. Those didn't occur with Bootstrap 4 but are very common with
Bootstrap 5.
This allow that conversion by using `getComputedStyle` in those cases.
Task ID: 2766483
Part-of: odoo/odoo#95450
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
In BS5 there is a check to avoid having multiple handler for one
element and we can't add two components' instance on an element.
So, before disposing a tooltip we check if there is an instance of a
tooltip and we avoid instantiation of tooltip if not already done.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.collapse.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.carousel.
> Bootstrap doesn't allow more than one instance per element.
> Bound instance: bs.tooltip.
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 JS use the `data-bs-toggle="dropdown"` attribute to
automatically enable the BS Component.
But in this case as the `.dropdown-menu` is only rendered when the
`.dropdown-toggle` is clicked we can't initialize the Dropdown at the
first render. So we do it manually.
- change .dropdown-menu by .o-dropdown-menu (owl)
-> to handle keyboard navigation we can't use BS dropdowns
- use currentTarget of event
As the event can bubble we use currentTarget to be sure to be at the
higher level in the DOM.
> All the events for the dropdown are now triggered on the dropdown
> toggle button and then bubbled up to the parent element.
- BS5 don't add .show on parent group anymore
-> dropdown show class not on the same node on BS5
- avoid dropdown warning using margin in CSS
BS5 show a warning if we use margin statically in CSS for a dropdown.
> Popper: CSS "margin" styles cannot be used to apply padding between
> the popper and its reference element or boundary. To replicate margin,
> use the `offset` modifier, as well as the `padding` option in the
> `preventOverflow` and `flip` modifiers.
- adapt the systray activity dropdown for mobile
On desktop positions are now dynamic and on mobile it's static
- In BS5 the CSS `bottom: 100%;` is not more applied to the
`.dropup .dropdown-menu` selector.
- Change right -> end and add data-bs-popper="none" to avoid
Popper interaction
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 uses native inputs instead of pseudo-element for some
input like checkbox, radio, ...
in BS5 input checkbox don't have "virtual visual" checkbox anymore
(::before), so we remove the relative's rules
- removed `.custom-control` class
- `form-switch` use a new layout system in BS5 we adapt the code to
match the Bootstrap approach (inline SVG).
- In tests, we don't check the exact value of the background as it
change in community/enterprise, and it's difficult to check the value
of an SVG.
- Overflow in progressbar is now hidden.
-> we had to restore it.
- In BS5 margins in forms/inputs has been changed
-> we had to restore it (e.g. 'mb-3')
- .form-group, .form-row, .form-inline
> Dropped form-specific layout classes for our grid system.
> Use our grid and utilities instead of .form-group, .form-row,
> or .form-inline.
- .input-group-append and .input-group-prepend
> Dropped .input-group-append and .input-group-prepend.
> You can now just add buttons and .input-group-text as direct
> children of the input groups.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#forms
Task ID: 2766483
Part-of: odoo/odoo#95450
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
jlzhou