*: 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>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@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>
before this commit, on contact us form, except
question input all the other required input
field has * (asterisk) after the field label.
after this commit, * will be added for the
question input label in the contact us form
closesodoo/odoo#115780
X-original-commit: 127f7f5cfbca103f6d50330aefe355fdaee808c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
after odoo #113888
when copy translations from one record to another, translations for
non-installed languages may raise error.
These translations may be
1. created before the langauge is deactivated
2. en_US which is always available for non falsy translated field value
this commit drops translations for uninstalled languages except 'en_US' when
copy and prevents raising error when users want to translate en_US when en_US is
not activated
closesodoo/odoo#115711
X-original-commit: 7bb1825ddbf2340882bef5ed1d9c877f78a2b815
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@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
Since [1] when the Dynamic Snippet was first introduced, it also
introduced a concept of "inherited" snippets. Specific snippets would
all `t-call` the same template for their rendering.
A mechanism was introduced to deduce the `data-snippet` from the caller
template, but it stored the obtained value in the `t-called` template
itself. Because of this if several "specific snippets" that used that
template had to be rendered, they would all have the `data-snippet`
value of the first one that got compiled.
We could compile the snippet template into something having a
dynamically obtained `data-snippet` value, but then that would be
equivalent to just using a `t-attf-data-snippet`.
All specific snippets already do set a `snippet_name` in the context
because it needs to be added in the classes.
This commit therefore adds a `t-att-data-snippet` attribute on the
base template, and populates with that same value in `onBuilt` for
stable versions.
During forward ports across stable versions, each new caller must be
patched as well - and all patches must be removed in master.
[1]: https://github.com/odoo/odoo/pull/53175
task-2922635
closesodoo/odoo#115566
X-original-commit: 73d2c9f87bf9a1a792f4318325c2e52fc81db5f2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
The following basic case has been broken in website forever since [1] in Odoo 8:
```html
<p><span>a</span><span>b</span></p>
```
Saving the above html results in:
```html
<p>
<span>a</span>
<span>b</span>
</p>
```
Which, when re-rendered back in the DOM renders equivalent to:
```html
<p><span>a</span> <span>b</span></p>
```
Note the space between "a" and "b". That is because etree will pretty print
nodes with indentations as long as they do not have text content, and that
indentation is collapsed into a single visible space by the browser when
inserted in the DOM. This is not limited to span nodes as the same applies to
any inline node. This is very easily reproduced in website on any version:
- Drop a Text snippet.
- Replace all the content of the snippet by "ab".
- Put "a" in bold and "b" in italic.
- Save.
- Notice that the saved version is now "a b" instead "ab".
The user has no way of removing this space easily because even if they manage to
do it by any mean, the server will pretty print the html again and the space
will reappear. The only way to circumvent this is to have some text content as
sibling of the inline nodes.
Consider this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span></p>'), pretty_print=True)
b'<p>\n <span>a</span>\n <span>b</span>\n</p>\n'
```
Which is incorrect, while this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span>c</p>'), pretty_print=True)
b'<p><span>a</span><span>b</span>c</p>\n'
```
Is correct.
We could fix it using a heavy hack that would leverage this behavior by
inserting one of the few unicode control characters that etree considers to be
actual content, and therefore preventing pretty printing for this node. The
server would then remove the control character to avoid polluting the actual
views. This would have the side-effect of forbidding this control character to
ever be used in a view however, and would obviously be an extremely ugly hack.
The alternative which was chosen in accordance with Antony (al) and Xavier (xmo)
is to disable pretty printing altogether, since the original commit [1] seem to
have introduced it as a fix for an old version of the editor rather than for the
intrinsic qualities of having pretty printed views.
If we ever want to re-enable pretty printing in the future, I suggest it be
implemented in JS because the browser is the only one able to assert whether a
node is going to be treated as a block or as an inline with respect to the
current CSS rules in application.
task-3142796
opw-3122373
opw-3186250
[1]: https://github.com/odoo/odoo/commit/6b857b6eeb59137a71385f98c82c440ac82cd45dclosesodoo/odoo#115159
X-original-commit: 3c6b9249482454a931f384ffc66ceec64dffbcfc
Signed-off-by: David Monjoie (dmo) <dmo@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#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit, the event handlers that prevents the default
behaviors of a click was bound onto the $editable after the wysiwyg
editor had started.
This meant that during a very short period, the element could have the
"editor_enable" class but would not prevent clicks on the document
from triggering a default behavior.
This issue is not as important in versions prior to 16.0, because most
of the clicks on link would trigger navigation within the page,
canceling edit mode. If a traceback had appeared, it would be removed
quickly after, as the page was unloaded.
However, in 16.0, if the iframe leaves its current page, it can crash
the editor which now resides outside the page we are currently
editing.
Furthermore, the test introduced in [1] highlights the problem, as it
clicks on a link directly after checking if "editor_enable" is added to
the body within the iframe. This created a race condition, which means
the test crashed often.
This commit fixes the issue by using the click handler of the
website_preview to prevent the default behavior while in edit mode.
[1]: https://github.com/odoo/odoo/commit/050378dd8599b907ad429d4d1812602b557d0f73
runbot-18660
closesodoo/odoo#115119
X-original-commit: f9e51a8ab1cc469bd3dd4dba21856597d5e0f902
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [the merge of the frontend into the backend] and more precisely
since [this commit], clicks on some elements makes the user switch from
the backend view to the frontend view.
Steps to reproduce (just an example):
- Go to /blog from the backend (/@/blog)
- Click on a tag (eg: adventure)
=> users are redirected to the frontend view, we do not want that. This
commit makes the user stay in the backend. For some scenarios (like the
one above), we create a fake form and submit it. The forms have a target
attribute that specifies where the form response should be displayed.
This commit set back the default value for the target attribute when a
user clicks on a blog tag, a course tag, the pager, ... so that the
response is displayed in the current context (the iframe when the user
is in the backend).
Note that [this commit] introduced the target attribute change to fix
two issues:
1. The opening of the payment gateways in the iframe.
2. The create page from a 404 page in the backend.
After [this other commit] has been merged, to prevent the first issue so
here we just remove the target attribute change except for the case of
the second issue.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this commit]: https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64
[this other commit]: https://github.com/odoo/odoo/commit/3a32b9e1efa6277b345dc9239334680651690df7
task-3054970
closesodoo/odoo#114056
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: web_tour, website_blog
Since [1] when the search box autocomplete was introduced, the URL
parameters are implicitly included into the RPC that fetches the
autocompletion results.
Those parameters were not correctly unescaped before being sent to the
RPC call.
Because of this, a timestamp such as "2023-01-01 23:00:00" was sent as
"2023-01-01+23%3A00%3A00" to the server. If that string reached the SQL
layer, the "+" was interpreted as defining a timezone.
This commit unescapes the URL parameters before using them in the RPC.
Note that javascript's `decodeURIComponent` does not handle the '+'
encoding of spaces inside URL parameters.
For testing purpose, the following updates were needed to make it
possible to select the `<option>` within the Archive month `<select>`:
- because the `option`s are in a tree, the tool was adapted to take all
`option`s into consideration instead of only the direct children of the
`select`.
- because the `option` text is dynamically created from the date of the
test execution, the tool was adapted to allow targeting an `option`
based on its index by specifying the tour step's `run` as
`'text index N'`, `N` being the index of the `option`.
Steps to reproduce:
- Enable the sidebar of the `/blog` page.
- Select a month in the sidebar.
- Type something in the search box.
=> Did show an error popup while obtaining the autocompletion records.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-3213916
closesodoo/odoo#114913
X-original-commit: 115fc399461c37b57127684cf5c28f05443fbb54
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This reviews [1] which solved the problem in most cases (hopefully) but
not in all cases. Animated elements which overflow the screen on the
right made an horizontal scrollbar appear on iPhone <= 8 using Safari,
even when they were not animating yet.
This was due to Safari ignoring the `transform: none` rule on inactive
elements, preferring to consider the animation transform. As a fix, we
forced no possible overflow of the page when we saw this safari bug on
the first animated element.
The problem here... is that this Safari bug does not occur in every
situation. For example, if the animated element is inside a column which
is marked as hidden in mobile, Safari actually understands the no
transform rule. So if the first animated element was in such a situation
but another element in the page had the safari bug... the problem was
there again.
As a fix, we now check all animated elements for the Safari bug, instead
of only the first one. That should do the trick.
This commit also reviews the comment: the problem is not confined to
old iPhones. This was reproduced on the latest iPhone with latest iOS
and up-to-date Safari.
opw-3204613
opw-3201937
Related to opw-3165651
[1]: https://github.com/odoo/odoo/commit/c1447835786e04f342342540c09e46d1226d5fc0closesodoo/odoo#114999
X-original-commit: 8fe2d91e05e85ae2e50f1066214d0af5796e5296
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When using the 'toggleDeviceVisibility' option, we can see that there is
a mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> at 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding/showing an
element in the mobile/desktop view (for example, if it does not look
good in one of them) has no effect until the screen reaches 768px.
This commit increases the screen breakpoint at which the 'toggleDevice-
Visibility' option is applied, that is, at 992px instead of 768px, in
order to be consistent with the display.
task-3110770
closesodoo/odoo#114977
X-original-commit: b062b280fdadcde857fff4f7a57876da50542cb3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Benoit Socias