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>
Many templates use the company logo that is set by default on
database creation. As that logo is clearly a placeholder and the user
isn't necesserely prompted to update it. It's possible for a user to
inadvertently start sending emails with "your logo" placeholders
plastered all over.
This removes the default logo of the company and removes it from
templates conditionally.
The logo isn't simply replaced with a transparent PNG as the templates
set a fixed height for the logo, which would look weird.
task-3067315
Part-of: odoo/odoo#106307
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 [this commit], a horizontal scrollbar appears on mega menus. This
is because Bootstrap position the dropdown automatically and the mega
menus are a bit shifted on the right (due to a `translate3d` added by
dynamic position of popper). This commit fixes the problem by removing
dynamic positioning for mega menus.
Steps to reproduce:
- Have a system setting that enlarges the texts size or zoom the page
- Have a mega menu
- Open the mega menu
=> There is a horizontal scrollbar.
[this commit]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
task-3133137
closesodoo/odoo#118842
Signed-off-by: loco-odoo <loco@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>
*: mass_mailing, website_blog, website_event, website_mail_group,
website_mass_mailing, website_payment, website_sale, website_twitter
The names of snippet blocks are not translatable because their name is
obtained from a their template name which is not a translatable item.
For markets that use a non-latin alphabet this is a no go.
This commit makes it possible to specify a `string` attribute in the
`t-snippet` blocks that makes their name inventoried by the translation
process.
closesodoo/odoo#118530
X-original-commit: a501d226d8674ed0c9b183c69a9e754c79682237
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@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>
Commit [1], [2] and [3] added `Properties` type fields on (respectively)
project.task, helpdesk.ticket and crm.lead. Unfortunately, those fields
are not currently supported by the Website Form snippet. Selecting the
"Properties" field while editing a form related to one of these model
will lead to a crash as no definition for how the field is supposed to
render is present in the current code base.
(Note that no logic for how options should behave if such field is
selected is present either.)
Therefore, this commit removes this specific type of field from being
present in the "Existing Fields" section of the Website Form Field
editor.
Steps to reproduce:
- Install website and project
- Go to Website and start edit mode
- Drop a form snippet
- Click on the form snippet and select "Create a task" as an Action
- Click on an existing field or add one
- Select "Properties" as the field type
=> Traceback (QWeb render error)
[1]: https://github.com/odoo/odoo/commit/2f244769cbb1512875ae197aa8adc3efd34fd54b
[2]: https://github.com/odoo/odoo/commit/8de9f4c4777481142063f75d4cd3cef47948714b
[3]: https://github.com/odoo/odoo/commit/4722cc4b1fb027b7b9d731c3b206656588071360
opw-3240395
closesodoo/odoo#118597
X-original-commit: 078f879444e5c2655f80ee572156ac663c0e4abb
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Steps to reproduce the bug:
- Add an Image Gallery snippet on a the page.
- Stay in edit mode and click on one of the arrows (left or right).
- Bug -> The arrow disappears.
This bug comes from the fact that the "oe_edited_link" class is added
to the anchor of the arrow when clicking on it. Because of the scss
related to this class, the position of the arrow is modified. This bug
is fixed by adding the "o_not_editable" class to the anchor of the
arrow. By doing so, the "oe_edited_link" is not added to the anchor of
an arrow when clicking on it.
task-3147271
closesodoo/odoo#118383
X-original-commit: 92f2a50bbabaa387f557ef8e728796c3b3e6410c
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Before this commit: if there wasn't any mail group, and you add a
"Discussion Group" component to the website it will raise an error. The
problem is that the `'website.prompt` wasn't loaded.
The solution is to add the `website.xml` file path to
`web.assets_backend` in the website manifest.
opw-3184203
closesodoo/odoo#117824
X-original-commit: feed4ba6f0e904911de419a94998e22a2033f9f7
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Since [1] when the translations were converted to jsonb, when
translations are saved, the actual `ir.ui.view` is saved (instead of a
translation record like before). Because of this, the copy-on-write
mechanism of `website` kicks in and unneeded website-specific views are
created.
This commit disables the copy-on-write mechanism during the update of
translations in views.
Steps to reproduce:
- Install `website_sale`.
- Install a second language (e.g. French).
- Go to a single product's website page in the second language.
- Translate the "ADD TO CART" button.
=> Many website-specific views were created.
[1]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224
task-3225622
closesodoo/odoo#117256
X-original-commit: 1bf7e2322d22aeef30097a1d19848ff351bc83f9
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>
With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
*: 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>
Since commit [1], which updates jQuery to version 3.6.3, when dropping a
dynamic snippet (Events, Blog Posts), it appears broken. This happens
because in jQuery 3.5.0, the `htmlPrefilter` function (which is called
when the dynamic snippet content is rendered) has been modified.
The dynamic snippets are broken because auto-closed tags are contained
in the data that are fetched from the server and without the jQuery
regex to fix them, they are never closed properly, which breaks the
rendering. Indeed, the `etree.tostring(...)` function auto-closes the
tags of elements having no content when no method is specified as a
parameter.
This commit prevents auto-closed tags to appear in the data sent by the
server when rendering the dynamic snippets, by enforcing the fact that
they will be used as HTML.
[1]: https://github.com/odoo/odoo/commit/ae1cd3d5bb99b9835501144522b71f152aaf8e34
task-3199318
closesodoo/odoo#116929
X-original-commit: f6cbec8d0116305041f018870ab63e26c8cbef41
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>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@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>
Jeremy Kersten