With the BS5 upgrade script of 16.0, countdowns' data-display may have
been converted to data-bs-display by mistake. This will fix the DOM at
page load for good measures, maybe even allowing to remove this code in
a few years as hopefully all current countdowns will have been removed
or edited (or when a proper upgrade script in a future version of Odoo
will be made, if necessary).
opw-3240041
opw-3240532
opw-3258751
opw-3272731
closesodoo/odoo#119767
X-original-commit: ce506f32e3471eea1785312d4140417eba0ce355
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit gives a small refresh to the web_editor UI. To do so we
remove the borders from the buttons and inputs. We also increase the
border radius to 4px instead of 2px. The nested menus such as in Themes
tab now have the same background color than the rest of the UI.
The box shadows on the `we-title`, `we-customize-block-options` and the
checkbox switch have been removed.
All the buttons and select components are now taking the full available
width. The inputs fields remain unchanged except their font which is now
set to sans-serif.
Finally a `<div>` have been added to the replace media snippet to make
it consistent with the other buttons having an icon. Maybe in the future
we'll need a better way to define those.
task-3265187
closesodoo/odoo#119697
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the issue:
- Open a website page in edit mode.
- Drag and drop several snippets onto the page.
- Add a 'Fade In Right' animation to an element on the page.
- Exit edit mode.
- Change the website language to Arabic to display the scrollbar on the
left.
- Test the animation.
- Bug: the scrolling (using the mouse wheel) becomes stuck or very slow
during the animation.
The issue only occurs with Chrome or Edge browsers and seems to be a
browser display issue. It happens only when animated elements overflow
to the left.
This commit fixes the problem by adding an 'overflow: hidden' to the
main element during RTL page animations. This is not the best solution
because the animated elements become non-visible outside the main
element, creating a difference, for example, with the 'Framed' page
layout.
opw-3260399
closesodoo/odoo#119766
X-original-commit: 69184ea84c78de33d47f1e952530cceb568c937b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There was an issue before this commit where some flags (basically all
the ones which are not tribands) would appear "broken".
This is the case for the China one where the symbol on the flag would be
squashed.
Using `object-fit` css property will keep the original flag ratio.
task-2929438
closesodoo/odoo#119683
X-original-commit: 5d6559218926a4c2f055bd55f113c7bfc83cd5b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since we've changed Bootstrap version from 4 to 5 the way to create a
popover has changed.
So we adapt it to the new way to declare popovers in the website form
closesodoo/odoo#119680
X-original-commit: 0cff1dc2967cafeb8964ed0802c309d3bb7f7525
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit removes the module "web.dom_ready" and
adapts the modules that imported it.
This module was used to wait for the content to be
loaded to manipulate the dom after that.
The goal is to remove async modules and simplify the
module loader in the future.
task id: 3265979
closesodoo/odoo#119158
Related: odoo/enterprise#40051
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce the bug:
- Open an empty page (e.g. the home page) in Website edit mode.
- The "DRAG BUILDING BLOCKS HERE" message is missing in the '#wrap'.
Since the commit [1], we have made modifications to the
'%o-editor-messages' mixin, which is used on the '#wrap' element, to
hide the editor message if the element is not the only child. However,
another commit [2] was added afterwards, which introduced a new div
called '#o_shared_blocks' next to the '#wrap' element. As a result, the
'#wrap' element is no longer the only child, and the message is never
displayed again.
To fix this, we took the rule out of the mixin to only use it where we
need to (for '.oe_drop_zone').
[1]: https://github.com/odoo/odoo/commit/6ee778fdbcd92dbefd08c8551ea654d352ad0dc0
[2]: https://github.com/odoo/odoo/commit/6007264afb83dcfed1693d72179cb156ff2254b6
task-3270409
closesodoo/odoo#119621
X-original-commit: d4b7a9e877804cd6bbdc0d15b1ab1c03561a4a86
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The goal of this commit is to fix the race condition introduced by
[this commit]. Here were the problematic steps:
- Open the mega menu.
- When then mega menu is opened, scroll up.
- Open the mega menu after scroll.
Before this commit, what could happened was that the mega menu did not
have enough time to be closed after the scroll. Clicking on it would
then actually close it rather than open it as wanted. This commit adds
a step to ensure that the mega menu is closed before open it.
[this commit]: https://github.com/odoo/odoo/commit/9b1de9e28697edbb6e1fa88665294f983f60e37f
runbot-20660
closesodoo/odoo#119438
X-original-commit: abd0038de73a057eb9c34dc8d316b67d96fac409
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This module allows to add secret key to add the turnstile captcha on
each snippet website_form.
Cloudflare Turnstile
--------------------
A friendly, free CAPTCHA replacement
Turnstile delivers frustration-free, CAPTCHA-free web experiences to
website visitors.
Turnstile stops abuse and confirms visitors are real without the data
privacy concerns or awful UX that CAPTCHAs thrust on users.
closesodoo/odoo#119246
X-original-commit: 4aca39a533e9d41f5f452f36a1ffc001f586b4f4
Signed-off-by: Jérémy Kersten <jke@odoo.com>
In the table of content snippet, both its generated entries and its
content wrapper can be dropped outside of it.
This cannot be allowed because the entries are generated from the
wrapped content that belongs to the same table of content snippet.
If any of them is missing, the feature is broken.
This commit prevents this by hiding the drag handle from the generated
table of content and from the content wrapper.
Note that they can still be moved using the arrows.
task-2752391
closesodoo/odoo#107510
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before this commit the "This page" menu sub-section of the website's
menu is displayed as a clickable entry when it is empty.
After this commit any website custom menu sub-section title entry is
hidden if none of its children is displayed.
Steps to reproduce:
- Install website only
- Log in as a restricted editor
- Go to website
- Open the "Site" menu
=> "This page" appears as a clickable entry instead of being hidden.
task-3149639
closesodoo/odoo#119125
X-original-commit: 4625f717bdccd8eea851f74a87a102436627106b
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Since the upgrade to Bootstrap 5 and especially since this [BS5 commit],
there is a gap between the mega menu and the navbar when the user opens
a mega menu. This commit removes that gap.
Steps to reproduce the bug fixed by this commit:
- Have a mega menu on your website.
- Drop a block of a dark color at the top of the page (it helps to see
the problem).
=> When you open the mega menu, you can see a small piece of the block
of dark color between the navbar and the mega menu.
Technical explanation:
This [BS5 commit] introduces a new css rule that adds a
`margin-top: 0.125rem;` on the `.dropdown-menu[data-bs-popper]`. However
when [mega menus were introduced], another css rule prevents having a
gap between the nav and the mega menu (`margin-top: 0;` on
`.o_mega_menu`). This commit makes sure that it will be a `margin-top`
of 0 by making the property more important.
[BS5 commit]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[mega menus were introduced]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
task-3133137
opw-3226013
X-original-commit: b41c76bd7583756ad059f77f0d3c1151720b0b0b
Part-of: odoo/odoo#118842
This commit allows to reopen submenus and mega menus if one of them was
opened when scrolling on a page of a website.
Steps to reproduce the bug fixed by this commit.
- Have a submenu or a mega menu in the navbar
- Open a dropdown of the navbar
- Scroll down
=> It is no longer possible to open the dropdown.
This commit fixes this issue and adds a test for this flow.
task-3133137
opw-3226013
X-original-commit: 9b1de9e28697edbb6e1fa88665294f983f60e37f
Part-of: odoo/odoo#118842
When a mega menu "Sub Menus" are configured as "On Hover", it becomes
very difficult to edit its content.
This commit changes the behavior of the "On Hover" while the page is
being edited:
- it disables the hide on exit (`mouseleave`)
- it prevents the show on hover if another dropdown is already opened
- it hides the menu when the page is clicked outside of the opened menu
This commit also disables the preview of the "Show Sign In" option
which is not previewed anyway, so that it does not deselect the mega
menu when hovering the options.
task-2825376
closesodoo/odoo#119002
X-original-commit: ccb78f7af2a4413836a969ff8009dc3df6c2df33
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Replaced _.each() functions (average 235 occurences)
Description of the refactoring this PR addresses:
Current behavior before PR:
There are underscore.js function enumerated above used in odoo.
Desired behavior after PR is merged:
These functions has been replaced by native javascript
prototypes/methods/functions.
TaskId : 3246238
closesodoo/odoo#118565
Signed-off-by: Georis François (fge) <fge@odoo.com>
On Chrome, and while adding a new image to Images Wall snippet (on
"masonry" layout), The layout adaptation method will remove the snippet
content to reinsert new images.
Sometimes, the appended images are invisible and not correctly loaded
(only when Chrome cache is enabled).
In this commit, we append a "clone" of each image to the snippet
container to prevent this behaviour.
opw-3240231
closesodoo/odoo#118658
X-original-commit: https://github.com/odoo/odoo/commit/0d43aec24baad6420e0fe150a9c19d33c0b74198
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce (the issue occurs only on Chrome):
- Go to website > Add an "Images Wall" block > Add images and save.
- Then try to add more images > new images are removed immediately.
Right after adding a new image to the snippet, the whole content will
be removed (see `registry.gallery` > `mode()`) and replaced with new
images in the current layout.
This adaptation will trigger a `historyStep()` on the editor side while
the "unbreakable protection mechanism" is detecting node changes inside
unbreakable ancestor and setting `_toRollback` to a truthy value,
leading to undo the last updates...
The goal of this commit is to fix this behaviour by preventing the
unbreakable protection code to be applied on image wall layout
adaptation.
opw-3240231
X-original-commit: https://github.com/odoo/odoo/commit/93b1751ff10374e21750da71ad84b7607f30371f
Part-of: odoo/odoo#118658
When clicking on a button from the link popover, the popover gets
hidden, which pauses the editor's mutation observer until the popover is
fully faded out. This is problematic when the button in question calls
an editor command which we need to be able to undo, since the mutation
observer will still be paused during the command execution. This lets
the buttons' listeners handle the hiding of the popover themselves to
prevent this race condition.
closesodoo/odoo#118248
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, some behaviors of the forms after being submitted
were problematic:
- with the `On Success` option set on `Redirect`, when going back to a
form after submitting it (with the browser arrows), the fields were
still filled.
- with the `Show Message` option selected, when going in edit mode when
the message was displayed, the submit button was still "loading", even
after saving.
This commit solves this issues by properly resetting the form at each
start and restoring the submit button loading effect when the message is
displayed.
task-2798576
closesodoo/odoo#118645
X-original-commit: ecb3bda77fab512a9790daf58447058f250f49e6
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
This commit patches the font awesome library to add an icon for the
TikTok social network. Users are now able to add these icons with the
media dialog. Now, the TikTok icon works like all other font awesome
icons, with the new class introduced by this commit: `fa-tiktok`.
Moreover, the social media block in the website application can detect a
tiktok link and automatically integrate its icon with its color.
Technical note:
In order to add this new icon, a new font that contains only the TikTok
logo has been created.
task-3235451
closesodoo/odoo#118542
X-original-commit: dc926d56a286eebd3e7c10343824a6e2c1a76adc
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
When assigned the role of restricted editor, there are many ways to
break the web_editor when trying to do actions that should be
unavailable. There is a traceback for the following scenarios under
some circumstances (mainly because of pages without editable areas or
features without the proper access rights):
- Drag and dropping snippet when Restricted Editor.
- Clicking on product when Restricted Editor in /shop.
- Clicking on product image on specific product page.
- Clicking on user name (e.g. Marc Demo).
- Clicking on menu items or logo.
- Clicking on a blog's image in /blog.
- Clicking on a blog's image on specific blog page.
- Clicking on calendar's image in /calendar.
There is now no longer a traceback which makes the editor crash or
freeze. This mimics the behavior in other cases where the editor does
not show a traceback, but there is no message indicating that the action
is unauthorized.
When accessing a menu that cannot be edited, the "Edit the menu" button
is not shown to the restricted editor.
task-2747895
opw-3164176
closesodoo/odoo#118116
X-original-commit: 15c85e4f9f967ee04af3cdeb766d280a2c00731e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
the error will occur because when you first add the menu that's menu can not
store in the database without clicking on the save button and that id is
temporary store in string format now you delete that menu and click on save they
try to browse that menu but it is not available in the database and also it has
a string.
steps to produce this error:
1) go to the website and click on 'menu editor'
2) click on 'Add Menu Item' button
3) Add name and URL and click on the ok button.
4) now delete the newly added menu and save it.
So here we can check the id type.
sentry-3931666290
closesodoo/odoo#117937
X-original-commit: 334e13a21dee6cba44aaa4ee79827278a89ab275
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Following the refactor done in [1], it is no longer possible to use the
`value` prop. Instead, the field should explicitly use
`props.record.data[props.name]`.
However, while [1] tried to adapt all the existing fields,
`website_publish_button` was forgotten.
This commit adapts website_publish_button.
Steps to reproduce:
- Install website_sale
- Go to the website app
- In the configuration menu select Shipping Methods
- Chose one of the shipping method
- Try to toggle the "Unpublished/Published" button
=> The value does not update properly
[1]: https://github.com/odoo/odoo/commit/688986f888f2fe2371d58b74ded81315ba6bb353
task-3223146
closesodoo/odoo#117833
X-original-commit: ddadbeed4700e537f7758746298fec43de997b21
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Steps to reproduce the bug:
- Go to the website edit mode.
- Choose the 'vertical' template header.
- Select 'off-canvas' in the 'mobile menu' option of the navbar.
- Bug: On mobile view, the menu links are not clickable.
This is caused by the addition of the "order-first" class to the navbar
by commit [1], which causes the menu to be placed behind the backdrop in
mobile view when off-canvas is activated. This only happens with
Firefox, and there is likely a difference in how Chrome and Firefox
handle the "order" property based on the positioning of elements.
[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2
opw-3009202
closesodoo/odoo#117683
X-original-commit: 7baa2d3e4949cf3c6e1b1130f03cc2b051dbff0f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, if a user searches for an event based on a location name, the
location name is not displayed.
This commit shows the event location name when users search for the event.
Also add the "_getFieldsNames" method to easily override this method to
add a field name from another model.
task-2791031
Part-of: odoo/odoo#89796
There is a very nice and clear system that helps the user to figure
what are the available area to drop content inside, and what will they
do: are they shared between products, or product specific etc.
The issue is that once you have dropped a snippet inside, that helper
message is not shown anymore, but it's still not obvious which area is
used for what, actually you have no clue which one is which, especially
if you come back on the page later: at best remember there were 2
separate zones but you don't especially remember which one is which.
Keeping the message helps in that regard without any negative impact.
Note that making the message appear when there are already a snippet
will work out of the box in the sense that the message will be
duplicated and shown twice: one at the very bottom of the area and one
at the very top.
Note that there is 5 cases to consider here:
- Empty website.page in edit mode (no drag & drop)
- Empty website.page with drag & drop
- Non empty website.page with drag & drop
- Empty product description with drag & drop
- Non empty product description with drag & drop
This commit also takes care of fixing the text color issue where the
"editor message" could not be read because of text color too close to
bg color.
task-3160416
closesodoo/odoo#117705
X-original-commit: 9236628b0d037a0a9444d13a30d813f4a8413377
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit addresses the issue where the livechat button was hiding the
buttons of the cookies bar. With this commit, when a cookies bar is
open, the bottom fixed elements (such as the livechat button) will be
hidden.
Most issues caused by bottom fixed elements hiding buttons on a page had
already been addressed in this [commit]. However, the case of a modal
without a backdrop (like the cookies bar) had not yet been addressed.
Steps to reproduce the bug:
- Activate the livechat on a website.
- Activate the cookies bar on the website.
- When both are open, the livechat button hides the buttons of the
cookies bar (only if the page has a scrollbar and the page is not
scrolled to the bottom).
[commit]: https://github.com/odoo/odoo/commit/1cdd1f2f9a7d90fbf8e0da61116abfcbe6db5ae1
opw-3213808
closesodoo/odoo#117506
X-original-commit: 2e4b9cd6dbcea5844afd4b16a98d9f16abee1556
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
Issue:
- Go to website > edit mode > add a form
- On one of the form fields, add a default value > save
- Change language > translate > the input has html code shown as value.
On translation editor, the default html values we get from translation
mapping (see 'ir.translation' > _get_terms_mapping()) are used on the
editor's JS code (beforeEditorActive()) to set the right translatable
attributes values on DOM elements, and since the use of jQuery "attr()"
will not update the "value" property on inputs, we force it to replace
the default translation html.
Remark: the same issue will prevent updating the "value" property on
the input when "AttributeTranslateDialog" is used for translation.
task-3042522
closesodoo/odoo#117472
X-original-commit: 9dbc25aab92ee31281d2bbc8c2ab6d743d5e43af
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Issue:
- Go to website > edit mode > add a form
- On one of the form fields, add a placeholder > save
- Change language > translate > impossible to translate the placeholder.
The fix on [1] was added to prevent interacting with inputs in editable
zones. This prevents translating attributes on those inputs too (using
the AttributeTranslateDialog) so the goal of this commit is to add
an exception to the restriction in [1], when input attributes are
translated.
Remark: On translation editor, elements with translatable default values
will get a `<span/>` as translation value which stays visible until the
content is updated on the editor. This issue can be fixed on CSS for
`placeholder` and input `value` attributes (since we can select elements
with attribute translation on CSS). In this commit, we need to hide the
text on JS until the editor's code sets the right values on inputs and
textareas.
[1]: 3e598a8
task-3042522
X-original-commit: 52aa67f74b89ad95d773bf1af836a136d0445b3a
Part-of: odoo/odoo#117472
*: website_blog, website
Before this commit, when clicking on a column in the "Blog Posts"
snippet (only with the "Big picture layout" template), the options for
that column were displayed in the editor panel, even if options should
never be displayed for the columns of dynamic snippets.
We had already prevented the appearance of options for elements in a
dynamic snippet in this commit [1] and also in this one [2], using a
'pointer-events: none' to prevent clicking on the elements. However, as
this also removed the mouse hover effect, the 'pointer-events: none' was
changed to 'pointer-events: auto', in this other commit [3], for the
"Big picture layout" template of the "Blog Posts" snippet, so that the
user could see the hover effects in edit mode. And by doing so, we
inadvertently allowed the options to appear again.
In the end, this 'pointer-events: none' was not the right solution, as
for example, for the dynamic "Products" snippet, it may be useful in
edit mode to be able to switch between slides by clicking on arrow
buttons, or to see the mouse hover effects on images (slight zoom).
In this commit, we proceeded differently by hiding the options for
elements that are inside an 'o_not_editable' element (unless they have
the attribute and value 'contenteditable="true"'), excluding them when
generating options so that they don't have associated options.
Steps to reproduce the bug:
- In edit mode, drop a "Blog Posts" snippet in the page.
- Click on the first blog image ("Sierra Tarahumara").
- Bug => Resize options are visible when they shouldn't. The options in
the "column" part of the right panel should also not be visible.
[1]: https://github.com/odoo/odoo/commit/64b663fb42ddca67a06cb067c897abb5a3c4dd70
[2]: https://github.com/odoo/odoo/commit/1345e879d809f811641ea3ad388b5d2c0b16f005
[3]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
task-3054763
closesodoo/odoo#117407
X-original-commit: 80f841e5e33f4694361730d3e015a6a813261685
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes several bugs with the navbar and the header templates:
- The "right" alignment options didn't work with most headers. This was
due to a missing CSS rule.
- The "right/left" alignment option was reversed with the "vertical"
header template.
- The navbar collapse style was broken with the "Hamburger Full" header
template.
- This commit hides the alignment options in cases where they have no
effect ("Hamburger Full" or "Magazine" header template + not
"off-canvas"). It also changes the options label to "Mobile Alignment"
when the alignment only impacts the mobile view (since this commit =>
[1], the "alignment" option no longer only impacts the mobile view,
depending on the templates, it can also impact the "desktop" view).
- The text section of the "Magazine" header template had no background
color (It was transparent after scrolling the page).
- The "off-canvas" navbar was not positioned correctly with several
header templates (e.g. "Boxed" header template).
[1]: https://github.com/odoo/odoo/commit/2a1aa808e939eeaa3caec6a1a82e19f023f1d010
opw-2951315
closesodoo/odoo#117237
X-original-commit: ca621a292c659f60dd8fdf19a7e77a52f05742c0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog,website_event,website_forum,website_hr_recruitment,
website_livechat,website_sale,website_slides
Prior to this commit, elements inside the New+ modal had a `isDisplayed`
property that was meant to be changed by the patches done by each
module. Unfortunately, this was forgotten in the refactor done in [1]
and more precisely when the component was introduced in [2].
This commit fixes that by checking the access rights of the user on each
individual model used on the create form.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/ca2e143d54622d598201826a2cd669bad64b205d
opw-3198700
closesodoo/odoo#117206
X-original-commit: 58704cb7615addd7d40291431e05a894776320d8
Related: odoo/enterprise#39066
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] fixed the editor not being able to start when clicking on a
link that triggers a download. This was caused by the
websiteRootInstance being undefined when a page is about to be
unloaded (beforeunload). Unfortunately, this event can be canceled.
This means that the websiteRootInstance had to be undefined when we are
certain that a navigation is going to happen within the iframe. However,
the condition introduced by [1] does not take into account multiple
factors, which lead to the websiteRootInstance being undefined during
edition.
This commit fixes that and introduces a test to make sure this behaviour
is not easily broken again.
Steps to reproduce:
- In edit mode, on the Home page, go in the footer and click on any link
(except "Contact Us") under "Useful Links" or on the house icon in the
Social Media snippet.
- Change the footer height with the Height option.
=> The option is applied correctly (because the link stays on the same
page).
- Click on "Contact Us" or another Social Media icon.
- Try to change the footer height again.
=> The preview works but when we leave it, we see that the option was
not applied.
- Drop a snippet and click on it.
=> Infinite loading.
[1]: https://github.com/odoo/odoo/commit/e47a9900e4a7842774d33a332b325e1f08c3ca45
opw-3196324
task-3212501
closesodoo/odoo#114366
X-original-commit: 15a17656b42442b40f4476efe8c985a9ba28ff93
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Co-authored-by: Soukéina Bojabza <sobo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The Bootstrap/Popper code which is in
charge of positioning the sub-menu could not work because the dropdowns
were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented
Bootstrap/Popper from aligning the sub-menu items correctly.
Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.
=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.
task-2904507
closesodoo/odoo#116535
X-original-commit: https://github.com/odoo/odoo/commit/03c82f6b0094c9d038b1699376d49f2846298bcd
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
*: web_editor
The table of contents menu entries are generated automatically which
poses a problem in translation mode. The menu translation entries
are not be editable separately, but the users might be trying to.
This commit shows a notification when the user clicks on the menu
entries while in translation mode, explaining that they are generated
from the title entries.
It was initially intended to use a tooltip - but the amount of code
needed to display a tooltip without marking the DOM as modified is
needlessly complex.
To avoid that styles applied on a plain text during translation were
also appearing in the navigation menu, an attempt at adding a span
around them to make sure that their translation was distinct from the
one inside the main content. But this led to the risk of losing
existing translations.
Because of this, and because that situation seems unlikely, any
remaining style in the navigation menu is instead stripped when the
table of content is started to maintain consistency with what is shown
during translation.
An `o_translation_without_style` class has been introduced to indicate
to the synchronization mechanism that only the text must be replicated
for those elements.
For labels that have a different `data-oe-translation-initial-sha` than
their related header, that value is temporarily kept in another
variable, the value is replaced by the one from the header, which make
the synchronization mechanism properly associate them, then on save
the initial value is restored so that the translation is saved for the
right slot.
task-2752391
closesodoo/odoo#116270
X-original-commit: 5776a358e1b42186d2c26c9bc25010a12811f416
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before [this other commit], it was possible to add a wrong video on a
page of its website. If the user did this and saved the page, it was no
longer possible for him to enter edit mode. To solve this, two
improvements have been made:
1. We now prevent the user from putting a wrong video on his page when
he goes through the media dialog (see [this other commit]).
2. Since there are probably websites that have a bad video (it was
possible before [this other commit]), this commit allows users to edit
the pages that have these wrong videos.
Steps to reproduce before [this other commit]:
- Edit a page.
- Via the media dialog add a video with the following URL: 'google.com'.
- Save the page.
=> It is no longer possible to enter edit mode.
Note that part 1 was merged from 14.0 but part 2 was merged from 16.0
because the media dialog adds `iframe` without `src` attribute since
[the refactor of the media dialog] and we cannot edit a page containing
this code `<div class="media_iframe_video"><iframe/></div>` since the
merge of the frontend into the backend.
[this other commit]: https://github.com/odoo/odoo/commit/fbab1bffa033638553750d49fcde89a9a2fc5e6c
[the refactor of the media dialog]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
opw-3167707
closesodoo/odoo#116128
X-original-commit: 242d6f2e1dc35c3d22314a4c92c2420f69eb9970
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
==== Purpose ====
There is an issue with the `/@/` symbol website is using to display a
page in the backend: if someone copy paste a link with `/@/` in it and
send it in an email, some mail client will block those mails.
It was reported by our internal team, after feedback from some sales
persons.
Office 365 was incriminated (not the outlook.com web platform). While we
couldn't reproduce the issue, it was decided by the hierarchy to get rid
of it as it was judged impossible to educate our sales to not send such
links.
It's probably a good decision as:
- `@` in URL are usually used for HTTP Authorization:
`http://username:password@example.com`
Link [1] seems to mention that some mail client will not implement
correctly the URL check to see if the `@` is problematic and will
simply block mails having links containing `@`.
- The tradeoff of removing it is impacting dev/tech people, not the end
user (except for F5, see below).
==== Technical ====
Before this commit and since commit [2] the following behaviors were
introduced:
1. a `/@/` prefix was added visually in the URL bar of the browser when
accessing the website app (previewing your website in the backend) to
differentiate it from the regular website/frontend URL
2. the possibility to type yourself `/@/` in the URL to access a website
page in the backend app
It was improving the following pain point:
A. On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
B. When the user edited the URL (Like removing `/shop` and typing
`/jobs` instead, he would land on the frontend version too.
C. Impossible to directly go to the backend version of the website.
This commit is now reverting point 1. while keeping the possibility of
point 2.
It means that while you can still reach directly your page in the
backend, the backend URL part `/@/` won't be kept.
About the mentioned point above:
A. This pain point will be back
B. This one too but workaround possible: need to edit the URL but also
need to now add the `/@/`
C. This one will still be "fixed" as `/@/` still reachable.
While it seems to be decreasing the UX, it actually is an acceptable
tradeoff as:
- It mostly impacts dev/tech people, lambda end user don't play with
URLs (low risk)
- It will prevent their mail to be blocked (high value)
--------------
Finally, note that in the meantime commit [3] was introduced which
relied on this `/@/` presence. This had to be adapted.
[1]: https://www.malwarebytes.com/blog/news/2022/05/long-lost-symbol-gets-new-life-obscuring-malicious-urls
[2]: https://github.com/odoo/odoo/commit/030d3cb10ee79aa1f010134578f4bcf65a1cfcde
[3]: https://github.com/odoo/odoo/commit/a0b3499d348d252c3abd48154e1fd8dd545c7504closesodoo/odoo#116100
X-original-commit: b01337710b5fde995a184e442f48b687cd17967a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to a website page (edit mode) > Duplicate the footer (or any
snippet with a Social Media block).
- Save > Traceback.
Starting from [1], a `dbSocialValues` variable was used to update the
"Social Media" DB links for the current website (on save).
These URL values are fetched from database (see: `_fetchSocialMedia()`)
to "compute the widget state" and when the snippet is dropped
(`onBuilt()`).
The specific case of "snippet clone" will lead to a situation where the
editor is created with an `dbSocialValues === undefined`, leading to
trigger the website `write` method with an empty update value...
Remark: The "save" works correctly after calling `_computeWidgetState()`
The goal of this commit is to simply prevent triggering the `write`
update on `clanForSave()` when `dbSocialValues` is `undefined`.
[1]: https://github.com/odoo/odoo/commit/f243bcbafb9291d94840795951c8fd51cab0cae1
opw-3204862
closesodoo/odoo#115912
X-original-commit: d3edef46426d1fefb31dae482f4c05dade4865a6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
New text_cover snippet added for the editor. Editors are now able to use
a cover composed of an image and some text on the side.
task-2691555
closesodoo/odoo#105650
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this first commit], the elements that make up the submenu of the
navbar of a website can no longer overflow the page. Depending on
whether the content is too long, the elements are aligned to the left or
to the right. Unfortunately, since [the merge of the frontend into the
backend], the dynamic alignment no longer works in edit mode. This commit
restores the dynamic alignment of the submenu items so that they no
longer overflow the page in edit mode.
Steps to reproduce the bug:
- Have a submenu with a long element in it
- In edit mode align the navbar elements to the right
=> When opening the submenu in edit mode, the long element goes over the
page instead of being aligned with the right side of the menu.
Technical explanation:
In edit mode, the dropdown opening in the navbar is done by
`WebsiteWysiwyg` which is instantiated in the backend while the function
that allows to align the submenu elements correctly is declared in
`menuDirection` in the iframe. So the dropdown must be opened with the
Bootsrap instance of the iframe in order for the iframe to detect that
the dropdown has been opened.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this first commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
task-2904507
closesodoo/odoo#115607
X-original-commit: 11f817e8d0b0764427f0db7d62fb0cdd403e3012
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Since [this first commit], the elements that make up the submenu of the
navbar of a website can no longer overflow the page. Depending on
whether the content is too long, the elements are aligned to the left or
to the right. This was done with the public `menuDirection` widget which
looked at the available space on the left and right and depending on the
size of the submenu elements, aligned the submenu in an optimal way. It
has now been decided to get rid of all this widget because Bootstrap
(with Popper) knows how to position dropdowns dynamically. Unfortunately
Bootstrap has limited this dynamic positioning by disabling it on
dropdowns that are in a navbar. So this commit removes the public widget
and replaces it with a bootstrap patch so that dropdowns are dynamically
aligned in navbars too.
Note that if we had not made this patch in master, we would have had to
adapt the public widget to the migration to Bootstrap 5 (see original
commit).
[this first commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
task-2904507
X-original-commit: b6963dc21bad4b012aace16b9ea9264c33a0d618
Part-of: odoo/odoo#115607
qsm-odoo