Commit [1] added the support for images with a link set on them in grid
mode.
As a follow up, this commit does the following:
- Removes the `!important` from the grid image anchor CSS rules, as they
were not really needed.
- Checks if the image has a closest `o_grid_item_image` column instead
of checking the parent in the `GridImage` options. Indeed, this class
already guarantees that the image is well a grid image; we can therefore
simplify the code.
It also removes a comment that was forgotten in commit [2].
[1]: https://github.com/odoo/odoo/commit/085d70cea571ea80c141ac6005e8bd8333bd269f
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600
related to opw-3580128
closesodoo/odoo#149681
X-original-commit: 9244e85ebb9e1605292698fe31ad94da7709ab86
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
bug 1:
- Enter edit mode.
- Drag and drop an "Image Gallery" snippet onto the page.
- Double-click on an image within the snippet.
- In the media dialog, click the "Video" tab.
- Copy-paste a YouTube video URL into the URL input.
- Save the media dialog by clicking on the "Add" button.
- Bug: The video is very small.
bug 2:
- Drag and drop an "Images Wall" snippet onto the page.
- Double-click on an image within the snippet.
- In the media dialog, click the "Video" tab.
- Copy-paste a YouTube video URL into the URL input.
- Save the media dialog by clicking on the "Add" button.
- Bug: the spacing around the video is not correct and the "spacing"
option does not work for the video.
Note that the "image gallery" snippet (also the "image wall" snippet)
was not initially designed to handle anything other than images. When
you click on the "Add" button of the snippet, you can only add images.
However, by following the steps described above, it's possible to work
around this limitation and add a video to the snippet. Since this was
not part of the original plan, several options do not function correctly
with a video.
Instead of preventing the addition of videos, we have chosen to allow it
and focus on fixing the main issues (the small size of the video and the
"spacing" option which does not work with videos). So, if someone
specifically wants to add a video, it's currently possible, though some
features may not work as intended.
task-3597156
closesodoo/odoo#149679
X-original-commit: 73f60e97a1b534b5f8dd3759bd631f9aac095426
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Commit [1] changed the class from .ui-draggable to .o_draggable in the
`snippet_version` test, specifically in the run function that checks
if all snippets have their `[data-snippet]` properly set.
Indeed, `.o_draggable` is set on the parents of draggable elements and
not on the elements which are draggable themselves. This lead to a
`.every` on an empty array which returns `true`, and therefore avoids
the `console.error` but did not properly check the snippets.
This commit changes the selector to all snippets which do not have
a [data-module-id] which should be all snippets that are draggable.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to task-3079246
closesodoo/odoo#148824
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
*: website
This basically reverts the parts of [1] that are the known cause of race
conditions in runbot tests (in particular, the link tools one:
`test_15_website_link_tools`). But more importantly, this just did not
make sense to stop observing changes for async period of time, at least
unless there is no alternative given the state of the related code.
Commit [1] test-hack was actually adapted with [2] which probably made
it even more unreliable and hacky.
On top of that, this commit is of course trying to restore whatever
purpose this was made for ("dirty" flag addition, the history steps
recording, etc). Although fixing those the most robust way would
probably require a deeper refactoring in master and other stable fixes.
Note: in this forward-ported version, the test is still disabled on
runbot and broken for other reasons. Those will be fixed later.
[1]: https://github.com/odoo/odoo/commit/8cab404dce3a65c0bdd635a93682ee14282a3ebb
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35
runbot-18747
closesodoo/odoo#148728
X-original-commit: 003422a73f0b5fb5540fbf2bd95a26a6dd663530
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
The editor has a feature that allows to automatically select a whole
paragraph on click when that paragraph contains text by default. At the
origin, this happened at every click on the element, until its content
was replaced, by typing something while it is selected or the cursor is
inside. Placing the cursor inside was actually impossible by clicking on
the element, since this forced a selection on the whole text again.
Since [1], that behavior changed (for no apparent reason): only the
first click forces a selection on the element. This is done by removing
the marker class from the element ("o_default_snippet_text"). Also, the
code which removed that class while typing was left behind... even
though it did not work anymore due to a code typo.
This commit fixes that without changing the main behavior:
- On click, we do not remove the marker class anymore, but only force a
selection on the text if it was not already seen before. Small change
of behavior: not changing the text and coming back later in edit mode
will force a selection on the text again on click.
- While typing, the code removes the marker class and thus the text will
never have a forced selection again (fixed the code typo).
Note: we may reconsider restoring the behavior there was before [1], in
master. Automatically selecting default text that was never changed
could indeed be better, although it will require better code to allow
placing the cursor inside easily anyway.
The main purpose of this fix is to avoid a mutation of the DOM on click
(removing the marker class). Indeed, this wrongfully marked the page as
dirty.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the first paragraph of the snippet (=> it is auto-selected)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/912996fe902c41cafa12dcfe09713ce9857f95ab
Related to runbot-18747
X-original-commit: 3cc5bbcab641d7d436ebfbb0f160c9e0d77da142
Part-of: odoo/odoo#148728
*: web_editor
Commit [1] made the multiple drag and drop feature of the editor stop
using jQuery and used our own implementation. Unfortunately, the
initialization of that implementation in the case of the "drag column
on image move" feature marked the page as dirty by mistake.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the image of the snippet (and do not do anything else)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to runbot-18747
Part-of: odoo/odoo#148728
*: web_editor
Next commits will extend the main new test to make sure the flows they
are fixing are not wrongfully marking the pages as dirty. This commit
introduces it on its own as it deserved some more detailed explanations.
In 15.0, where this commit is being merged, the final version of the
test was failing for no apparent reason on staging only. This is because
the staging builds are made with more apps... which fill the website
menu with more items in such a way the "+" auto-fold menu feature comes
in play. That feature is marking the page as dirty by mistake in this
version, 3 different ways for 3 different configurations:
- the menu is not folded outside of edit mode and when entering edit
mode, the "+" appears and some menu are folded
- the menu is folded outside of edit mode and when entering edit mode
the resize actually makes it so a different set of menu is folded
- the menu is folded outside of edit mode and when entering edit mode
it stays the same (known to have been broken because edit mode
tweaks the dropdown behavior)
The first problem with this is actually the way we check the page is
dirty in case of discard: we check the whole DOM and compare it to the
way it was when entering edit mode... the whole DOM, including the non
editable parts. This is wrong by definition but it is also weird that it
does not match what is done when we *save*: where we only consider
sections that are explicitly marked as dirty (.o_dirty) and other
exceptions. This can't be changed in stable though, some save / discard
override may rely on this (not marking with the o_dirty class etc).
In 15.0, the original commit of this forward-ported version fixed the
3rd case described above, which was less risky than fixing the 2 others.
The cause for the DOM diff in that case was the `data-toggle="dropdown"`
which mysteriously reappeared between the moment we check the "initial
DOM" and the "DOM when we try to discard". This was because of [1],
which makes the dropdowns behave differently in edit mode, combined with
the fact that the "+" menu is re-rendered after each resize (and one is
triggered when entering edit mode since [2], originally for that
actually). That behavior is however apparently not needed for the "+"
dropdown, so we simply disable it. Some lower level fix is still needed
but will be done in master, as the real problem falls in the dirty page
detection system. A test was added for this specific third case.
In 16.0, this is different: all 3 cases seem fixed, probably indirectly
thanks to the website-in-iframe refactoring at [3] and the bootstrap 5
migration at [4]. Not sure. This forward-port commit thus only adds
tests and a bunch of comments. Note that what was said about the 15.0
version was actually not entirely true: "That behavior is however
apparently not needed for the "+" dropdown, so we simply disable it." is
actually wrong. Indeed, it changed the behavior when clicking *outside*
of the extra items menu (which is less important). A patch in 15.0 will
be backported anyway to explain that.
To make the final test pass, it ensures most menus are removed so that
the "+" feature is basically disabled always during the test. Behaviors
will of course be fixed in further versions.
Note that in this 16.0 forward-ported version, a test kinda already
existed for this... although it was badly written and the code that was
merged with it actually worsened the dirty check behavior. See [5].
This commit adds comments around some more problematic parts.
[1]: https://github.com/odoo/odoo/commit/fe67b34f1a03d838df82a1307cf6467f994a8f3b
[2]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[4]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[5]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
Related to runbot-18747
X-original-commit: a0b741a53fef6a2a15d9283397dd7ec22d624382
Part-of: odoo/odoo#148728
This probably does not change much but it short-circuit a bunch of code
when we click outside of an editable zone and something in the DOM
happens. Allows for easier debugging of mutations. It also avoids the
creation of a jQuery object when the mutation is about changing a
contenteditable attribute, I guess any small perf improvement should be
welcomed.
Related to runbot-18747
X-original-commit: f93a2da57e1424898fbf6e157945e2afa97be89e
Part-of: odoo/odoo#148728
The range widget doesn't work with Serbian language, because language
locale subtag contains `@`.
Steps to reproduce:
1. Activate Serbian Latin language (sr@latin) on your website
2. Go to /shop
3. Switch to Serbian lang
The price ranger slider (which can be disabled) will throw this TB:
"RangeError: Incorrect locale information provided".
The fix is to do as other places in the code: replace this specific
lang code with the expected one.
Ideally, a util method should be used at all those places.
closesodoo/odoo#148593
Forward-port-of: odoo/odoo#148279
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website
When the user uploads an image and remove the original image, some
image options continue to work thanks to a backend fallback on another
image. Unfortunately, this fallback is not available for images coming
from unsplash. This commit fixes this issue by preventing the UI to be
blocked when the original image is not found.
Steps to reproduce the bug:
- Activate the developer mode
- Configure Unsplash in the settings
- Add a Cover block on a page
- Replace the background image with an unsplash image
- Save
- Edit the page and via the media dialog, remove the original image
=> The options on the image cannot start anymore.
opw-3636499
opw-3474103
closesodoo/odoo#148197
X-original-commit: 3b0ac160a800f70ae965b60110e83e41655bca5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Originally, restricted editors don't have the rights to edit the SEO of
a record.
It was probably a bad idea as they can already edit the record itself
and can change the name / description of the record in the page.
Changing the SEO seems to be very similar.
Also, for our internal needs, we need our HR people (which are
restricted editor with rights on jobs position) to be able to edit the
SEO of their jobs. And we don't want to grant them the full editor
right.
Note:
- We already have a `data-can-optimize-seo` attribute set on the HTML
tag if one is logged in, but this is just about knowing if the record
has SEO-mixin capability, it does not check the rights for a given
record.
- In master, one day, we would like to have the "Edit" button shown only
when something can be edited for restricted editor (to not be able to
enter edit mode to then not be able to edit anything). The same would
be nice here: optimize seo menu could only be shown if you have the
right, but we don't want to do an extra RPC each time for now.
- We keep the info shown in readonly mode so the restricted user can see
it and ask for a change to someone else if needed
Related commits:
- https://github.com/odoo/odoo/commit/94e2eefca28196efc0ac38f155a3b85acbbdeaae
- https://github.com/odoo/odoo/commit/21464edf7ce858c065e113e32d857dfa4ace1788closesodoo/odoo#147981
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The "grid images" are grid items that only contain an image (i.e. the
image is alone in its column). This distinction with other images in
grid mode allows to set the `object-fit` CSS property to `cover` so they
take the whole space of the grid item (see commits [1] and [2]). In
commit [3], the "Position" option has been added, allowing to switch
between the `cover` and `contain` values for this property, to have the
possibility to still choose to display the entire image, so it can keep
its ratio.
However, only the images that are direct children of the column have
been considered when checking if it was a grid image and in the related
CSS rules. This means that an image with a link cannot be one, since
the image is the child of an anchor element `<a>` in that case. It can
therefore not be set as "cover" or have the "Position" option.
This commit adds the support for images with a link set on them, so they
can be considered as grid images too.
Steps to reproduce:
- Drop the "Masonry" snippet.
- Click on the image and set a link on it.
=> The image is now "contain" and the "Position" option disappeared from
the right panel so we cannot change it.
[1]: https://github.com/odoo/odoo/commit/e9c7e020daf88022d6e02de0a5620074e8417b5a
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600
[3]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
opw-3580128
closesodoo/odoo#148022
X-original-commit: 085d70cea571ea80c141ac6005e8bd8333bd269f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Since [this other commit], the recipient email option of the form on the
`/contactus` page is not filled correctly with the company email.
By chance, the form signature task fixed the bug but introduced another
one. The previous commit fixed the bug introduced by the form signature
task but reintroduced the inital bug. This commit fixes the initial bug
and adds a test.
By default, the form on the `/contactus` page sends emails to the email
address of the company. Unfortunately, before this commit, when a user
entered edit mode, the Recipient E-mail option always displayed
"info@yourcompany.example.com" even when the company's e-mail address
was different. This commit corrects this by displaying the dynamic value
of `company.email` in the Recipient E-mail option coming from the
data-for.
Steps to reproduce the issue fixed by this commit:
- Go to Settings > General Settings
- Update the company's email address
- Go to /contactus and edit
- Click on the form
=> The recipient email value is still "info@yourcompany.example.com"
instead of the company's email address.
This commit fixes the issue, adds a test to ensure the recipient email
option is correct and adds a utility to parse the data-for data.
Bonus: this commit also fixes the following issue catched by sentry:
- Go to /contactus
- Click on Edit
- In the Form option, remove the content of the 'Recipient Email' field.
- Save
- Fill and submit the form
=> An error is generated in the log.
[this other commit]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
task-3382195
sentry-4633940473
closesodoo/odoo#147933
X-original-commit: 56f6b8dccec5cebc9a93454538b39886d4d3f63c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The email_to field of the contactus form have to be dynamic except if
the user manually set it via the form options. Unfortunately, the
website signature task broke this feature. This commit fixes it and adds
a test to prevent this regression in the future.
Steps to reproduce the bug:
- Go to the contactus page
- Edit the page
- Add a field on the form
- Save the page
- Change the company email address via the settings
=> The contactus form still send the email to the old email address.
Related to task-3382195
X-original-commit: 10b4db60fbd077936b5c9586485fa40c3c890d3f
Part-of: odoo/odoo#147933
Steps to reproduce
==================
Go to Maintenance > Studio > Website > New Form
Click on the website editor
Click on the name field
UncaughtPromiseError > KeyNotFoundError
Cause of the issue
==================
Starting from 17, the FormEditorRegistry is not the legacy one.
If the key is not present in the registry, it will fail, unless we pass
a default value.
In this case, the key `website_form_key` is false.
Solution
========
Pass null as the default value.
opw-3652423
closesodoo/odoo#147840
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Add a "Form" snippet on the website.
- Select the first field.
- Try to toggle the "description" option of the field.
-> Problem: there is no description added on the field.
The problems appeared since [this PR] and comes more precisely from
[this commit]. The problem is that one condition required to fill the
`default_description` parameter is that `field.type === "description"`.
This should not be the case. Indeed, here was the flow before
[this commit]; When the user toggled the description option,
`toggleDescription` assigned `field.description` to `true`. The field
was then rendered trough `renderField()`. During this rendering, the
system called the `website.form_field_description` template through
`website.form_field` independently of the field type. Because
`field.description` was set to `true`, a `div` with the description
"Describe your field here." was added on the rendered field. To solve
the problem, the `field.type === "description"` condition has been
removed as a condition to set the `default_description` parameter. Now,
as it was the case before [this commit], this parameter is filled either
if `field.description` is set, either if the field name is `email_cc` or
`email_to`.
The error probably comes from the fact that the name of the template
used to render the field is `"website.form_field_" + field.type`. As the
name of the template in charge of rendering the description is
`website.form_field_description`, the author probably thought that this
template should only be called when `field.type === "description"`. This
is not the case; the template `website.form_field_description` is always
called when rendering a field (independently of the field type through
the template `website.form_field`) but is only relevant if
`default_description` is set.
Note that this fix fixes also another bug:
- Add a "Form" snippet on the website.
- Add a field which is of type "Cc".
-> Problem: there should be a description of type "Separate email
addresses with a comma." on the field.
This commit also adapts the `website_form_editor_tour` tour to verify
that the description option works as wanted.
[this PR]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/363251986dcd753796b4b037a2da2e118b3e8e35
opw-3630348
opw-3604548
closesodoo/odoo#146115
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`onDuplicate` was marked as optional while it never was. If you don't
specify it, the call to `this.props.onDuplicate();` will still be
executed and will crash:
`Uncaught Promise > this.props.onDuplicate is not a function`
Randomly spotted while reviewing PR about duplicate button in list view
related to opw-3640878. But it's not related to it.
closesodoo/odoo#147647
X-original-commit: 296feaa9aa16cdb1766ce8d2f5ae8126d74f881b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Each date in the timeline snippet was displayed with the time line going
through them. The line is supposed to be cut around the date. This
occurs since [1] which made it so `<span>` elements are automatically
removed by the editor if they do not have any attributes. Unfortunately,
this snippet relied on such a span, since [2]. This commit solves the
issue by making the snippet better (and the XML structure will further
be improved in the master forward-ported version). Unfortunately, this
is not entirely stable, even though it leads to the exact same result
provided no custom code tweaks the snippet. It will also solve existing
timeline snippets in current databases.
Note: [1] was obviously a mistake to merge in stable, although it might
be kept seeing the delay since it was merged and nothing critical seems
to have happened.
[1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c
[2]: https://github.com/odoo/odoo/commit/fbe38fb41dfdb76878748a1149f93700b566d228
task-3657771
closesodoo/odoo#147598
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A anchor menu in the mobile offcanvas related to an element in the
current page doesn't work in offcanvas:
- The offcanvas doesn't close
- The page doesn't scroll to the clicked location
This is because the menu anchor navigation is hooked to use our own
scrolling behavior instead of the browser one.
Doing so, we preventDefault, which prevent the offcanvas menu to close
itself when clicking on a anchor menu.
This commit simply manually closes the offcanvas and once the closing
animation is complete, starts our own smooth scrolling.
It also targets the desktop offcanvas menu (when hamburger layout is
selected) so it got a smoother UX: it closes then scrolls, instead of
scrolling but not closing.
Another possibility would have been to just close manually the offcanvas
without a preventDefault and without a call to our custom scrolling
method.
Doing so, the browser would naturally scroll to the element while we
close the offcanvas but it would be less elegant as you wouldn't see the
scrolling animation.
Note that the offcanvas was introduced with commit [1].
[1]: https://github.com/odoo/odoo/commit/bc13176de8d66bbdc1c536017b1f046c5fd31a86
opw-3604963
closesodoo/odoo#146907
X-original-commit: db881e66785a866319bd4980a9ae7b6393e55457
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the "on hover" animation option would be shown for
images of type url-attachment-redirect.
Selecting that "On Hover" option value would result in a crash if the
image was CORS protected (which is often the case).
Steps to reproduce:
- Drag & drop "Text - Image" snippet
- Double click on an image to replace it
- Select in the media dialog "Add URL" and insert a CORS protected
image URL
- The image is correctly added, and its url is something like
`/web/image/123-redirect/xxx.jpg`
- Click on the image and then click on its "Animation" option and select
"on hover" as value
-> It crashes
The same error will happen with absolute URL of a CORS protected image
(instead of the relative local redirect attachment-url
`/web/image/123-redirect/xxx.jpg`).
Technical stack:
> the XML option `data-animation-mode="onHover"`
> call the js method `animationMode()`
> calls `trigger_up('enable_hover_effect')`
> calls `setImgShape()`
> calls `_applyShapeAndColors()`
> calls `_writeShape()`
> calls `applyModifications()`
> calls `loadImage()` which fails to load the image
-----------
Technical note: JS `fetch()` takes advantage of the browser cache, no
need to create a `Map` cache for it, despite the `_computeVisibility()`
method being called multiple times.
----------
Related to commit [1].
The code is failing since commit [2] which added the "On hover" image
animation.
Other animation values won't fail. And not-cors-protected images will
work fine with the on hover option.
[1]: https://github.com/odoo/odoo/commit/f0fe283c761cd6b1d7293dd41795ac6fc721e341
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85closesodoo/odoo#146732
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
Go to the website's home page > Site > Properties > The control panel
buttons in the footer of the "Page Properties" dialog are not aligned
correctly.
The "Page Properties" dialog extends the `FormViewDialog` component and
updates its template using `xpath` to add extra buttons on the right
side of the footer (to "duplicate" & "delete" the current page).
But since [1], a `w-100` class has been added to the default button
container (`.o_cp_buttons`) on form view dialogs to get the same result
as the "More Options" button on `Calendar > Quick Create` dialogs (the
difference here is that the extra button was added inside the default
buttons wrapper, while on page properties, the buttons are added next
to it).
The goal of this commit is to "safely" fix this misalignment issue on
stable by simply removing the `w-100` class for the page properties
dialog. On master, we will adapt the page properties buttons to have
the same structure as on the calendar dialog.
[1]: https://github.com/odoo/odoo/commit/7dd6e5d1a55de99a4212abc6f24490e47d9ce5bb
task-3642712
closesodoo/odoo#146541
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Using the animation option on an image can turn the image src from
relative to absolute.
It then makes our code crash in some cases (multi domain & cors
protected img). The previous commit makes sure to protect this case by
making the code more robust.
This commit is fixing one of the detected root cause (explained in
previous commit).
The fixed code was introduced with commit [1].
Since we can't guarantee our code has no other way to turn relative into
absolute url, neither that we won't introduce new code doing that, the
very small safety net from previous commit has to be keep as defensive
programming.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85closesodoo/odoo#146731
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The image mouseover animation, introduced with [1], can crash through
legit UI flows:
- Visit your website on domain 1 (you will need to access the same
website from another domain later):
1. On local: use http://localhost:8069/ and http://127.0.0.1:8069/
2. On runbot: use master-all and master in URL
3. On odoo.com: use xyz.odoo.com and xyz.com
- Drag & drop "Text - Image" snippet
- Double click on the image to replace it
- Upload any image
- Click on the image and set its "Animation" option to "On Hover"
- Save
- Outside edit mode, mouseover the image to see the animation
- Behind the scene, the img src is changed from /web/image/xyz to a
hardcoded base64 value to show the animation
- Now enter edit mode, the system will actually reset the src to the
original src (to replace the b64) but it will replace it by an
absolute link and not the initial relative link
- Edit the text below the image, BUT DON'T MOUSEOVER THE IMAGE
(otherwise the absolute url would be turned into b64)
- Save, again DON'T MOUSEOVER THE IMAGE
- Now go on your second domain to access the same page
Bug: Mouseover the image, a `Uncaught Promise > Failed to fetch` error
will be raised because of a CORS error.
Indeed, on http://localhost:8069/, simply doing this in your debug tool:
```js
fetch('http://127.0.0.1:8069/website/static/src/img/snippets_demo/s_image_text.jpg')
```
will throw the same error.
Note: we can't just modify the CSP rule(s) to allow that domain because
we have no way to know which domains are safe and really domains from
the same database:
- When you are on xx.odoo.com, there is no way to know that xx.com is
also your domain for the same website. At best it will be set in the
website domain but it's not always the case (often not the case in
mono website)
- When you are on xx.com, we have no way to know that xx.odoo.com is
also your domain for the same website. At best it will be set in the
ICP `web.base_url` but until that ICP is actually frozen, it will
change every time the admin logs in the database.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146731
Before this commit, when a user uploaded a webp logo through the website
configurator, the colors of the logo were not detected. This commit adds
the possibility to detect the colors of a webp logo.
task-3609329
closesodoo/odoo#145047
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before this commit, when a user was uploading a logo for a website via
the website configurator, the logo was added as an attachment but the
potential previous logo was not deleted. This commit fixes this by
deleting the previous logo when a new one is uploaded.
Steps to reproduce the issue:
- Create a new website
- Fill the configurator until you can upload a logo
- Upload a logo, then upload another one
- Finish the configurator
- Edit a page of the website
- Change an image
=> You can see the first logo you uploaded in the list of images.
task-3609329
Part-of: odoo/odoo#145047
Step to reproduce:
- Create a mega menu
- Enter edit mode and select it
- You can duplicate the top level block (but not remove it)
- If you duplicate it, you end up with a second top level block that you
can't delete ever, even by deleting inner elements one by one.
Technical details:
1. The remove button of the mega menu is already hidden thanks to commit
[1] which used the `forceNoDeleteButton` editor option introduced
with commit [2].
2. The table of content snippet also need to hide both the delete and
clone button. It was done in an "non-ideal" way with commit [3].
3. The delete button removal for table of content snippet was actually
improved to use the `forceNoDeleteButton` option of commit [2].
4. It's also commit [1] which prevent the deletion of the top level
block when deleting inner elements one by one: when the last one is
deleted, it regenerates the whole block.
This commit thus simply makes it so `forceNoDeleteButton` also hides the
clone button.
A first solution was made by introducing a new `forceNoCloneButton`
option, but there is good chances that you always want to either hide
both or show both, so merging those options for now is the simplest
solution.
It also takes the opportunity to remove the (now) useless code in the
table of content snippet.
[1]: https://github.com/odoo/odoo/commit/97810a9c40396bb27cb5779937734849d185cf1f
[2]: https://github.com/odoo/odoo/commit/7ef484377a493ebe558242480d0da6b542d6c247
[3]: https://github.com/odoo/odoo/commit/9fb2dad97cfbd412bee3cb5d1358a9835e721f60#diff-ea32a091d6b1a47aeea680fa39bbc9111260cbdaf07e9f388a9d04741806ea8fR128-R129
opw-3604033
opw-3627319
closesodoo/odoo#146745
X-original-commit: 44b006778df913b847c58b3e405d2a177fcb1a7c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The commit [1] of this PR [2] has been merged requesting some changes to
be made later, which are fixes to the button that can now be dropped
onto the page from the snippet menu.
This commit makes the following changes requested:
- Before this commit, when we duplicated a button (by clicking on the
"duplicate" button), the style of the new button was generated again in
Javascript in the "_adaptButtons" function even though it is not
necessary since we duplicate the HTML of the copied button. That is why
this commit adds the "adaptAppearance" parameter for the "_adaptButtons"
function.
- Prior to this commit, when a button was dropped between two buttons,
the style of the next button was copied as a priority. After this commit
, the style of the previous button is now copied as a priority.
[1]: https://github.com/odoo/odoo/commit/507b80a12574ce19bcb925d88868fb377b1c4b06
[2]: https://github.com/odoo/odoo/pull/126717
task-3555413
closesodoo/odoo#139621
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Steps to reproduce [1]:
- Go to website (blog post page) > Change the layout of the cover
(Customize > 'Regular' Cover).
- Click on the cover (in edit mode) > You can type anything inside and
use the text tools (E.g. if you add an image from the toolbar, it will
be added on all blog posts).
Steps to reproduce [2]:
- Go to website (`/calendar` page) > Unpublish an appointment page.
- Go back to the `/calendar` page > Switch to edit mode > You still can
edit the "unpublished" tag on the items cover (add text, images,...
using text tools).
The editor uses some methods (`getContentEditableAreas()`,
`getReadOnlyAreas()`,...) to check if an area should be marked as
editable on load, there is already a cover selector used to define a
record cover as an editable zone, but this selector is targeting the
whole element, leading to the behaviour described in [1] and [2]. We
actually just need to set the savable content (usually the record `name`
and `subtitle` fields) as editable and not the whole element.
The goal of this commit is to fix this behaviour by removing the cover
along with its descendants from the initial editable zones (especially
to prevent the scenario in [2], see: $editableSavableZones) and only
setting the savable fields as editable areas.
opw-3561659
closesodoo/odoo#146407
X-original-commit: 333e437d6acb227f092f1d152fe68d49076cff94
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Since [this other commit], we add ZWS characters to the edges of links.
Unfortunately, this breaks the label option of the link tools that has
been introduced in [this commit].
Steps to reproduce the issue:
- Go to website
- Edit a page
- Click on the contact us button in the header
- Using the label option of the link tools, delete the final character
=> Nothing happens.
The final character is not deleted as expected.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
[this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022
Related to runbot-44779
closesodoo/odoo#146361
X-original-commit: 593dc52cd5c3362c446395a52a7782f74f445e34
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit and since PR [1], the default "checked" value set on
checkboxes field on the form snippet were lost once the page is saved.
This is because [1] changed the rendering engine of qweb templates from
our own qweb js rendering code to owl templates rendering.
By doing so, `t-att-checked="'checked'"` would toggle the "internal"
checkbox checked value but would not add the checked attribute on the
element.
It's a deliberate choice made in owl. As the checked attributed does not
mean the same as the internal checked value, it makes sense.
Indeed, the checked attribute is about the default value of the checkbox
while the checked internal value is about the current checked state of
the checkbox.
In React, for instance, the same behavior can be seen. And if one wants
to really set the checked attribute, they got to go with
`defaultChecked`.
Same apply with `value`.
Maybe owl will implement the same `defaultXXX` behavior in the future as
it's something that was already discussed on their side.
Step to reproduce:
- Drag & drop a form in the website builder
- Add a new custom field and select "Multiple Checkboxes" type
- Set one of the checkbox checked by default
- It is visually checked, but the attribute is not set
- Save the page
-> The checkbox is back to unset state since the attribute was not set
[1]: https://github.com/odoo/odoo/pull/130467
opw-3607795
closesodoo/odoo#146328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit and since [1] when the website builder was moved from
the "frontend" to the "backend" of Odoo in Odoo 16, the option to enable
URL redirect when updating a page URL was "compressed":
- The toggle/switch element has not enough room to be displayed entirely
if there were too many dependencies
- The toggle/switch label was split in multiple lines, words could even
be split in 2.
Step to reproduce:
- Go to / in the website builder (so the / finds a lot of dependencies)
- Open page property
- Change the URL field, you see the redirect url field appear with the
mentioned issues.
Note:
- In other languages, the switch label could be even longer, splitting
the line makes even more sense
- Removing a class is generally something to be avoided in stable, but
this type of class should not be xpath'd anyway. And given the
template structure, it's unlikely someone would have xpath it as it's
easy to xpath any element without relying on classes.
One solution would have been to add a new class to cancel the first
one but it seems overkill in this case.
[1]: https://github.com/odoo/odoo/commit/2ef7e788263b4742a8e0788f47673b7b31da3726closesodoo/odoo#146244
X-original-commit: 8c17c487e6632192874133a2ce4265a0f1eaf6fb
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit and since commit [1], it was possible to clone a page
in the page list view.
It shouldn't be the case, cloning a page lead to bad result: a page
with the same URL which is not shown in the page list view because pages
are filtered by URL to remove duplicates.
Cloning a page has always had to be done through the page properties >
"clone page" button. Doing it this way will ask the user for a new page
name (and so a new url). The page will then correctly be listed.
[1]: https://github.com/odoo/odoo/commit/3192051806e0da1276604a31ad818f8768105362
opw-3591738
closesodoo/odoo#146173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit correctly aligns certain header elements when the CTA button
has a larger vertical padding.
Steps to reproduce the issue:
- Install 'eCommerce' on your website.
- In Website edit mode, click on the 'THEME' tab.
- Adjust the vertical padding of buttons to 25px.
- Click on the header in the page.
- In the 'STYLE' tab, select the 'Menu - Sales 1' header.
- Bug: The 'logo" and the 'menu items' are not aligned with the CTA
button.
- In the 'STYLE' tab, select the 'Menu - Sales 2' header.
- Bug: The 'menu items' are not aligned with the CTA button.
- In the 'STYLE' tab, select the 'Menu - Sales 4' header.
- Bug: Bug: The 'cart' button is not aligned with the CTA button.
task-3478334
closesodoo/odoo#145683
X-original-commit: d2f6710bcaa5cee7e77fc4df902929264ffa4830
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
See commit [1] for in-depth explanation and framework-js change but
basically, `renderToElement` do not allow multiple root nodes since
[2].
The fix is just about using the correct method to render multiple root
nodes. Without the fix, it just crashed when you click on the page
dependencies links.
Step to reproduce:
- Go to /
- Open Page Properties
- Edit / to /test
- A list of possible dependencies will be shown, it's a link that can be
clicked to open a tooltip to have more details
- Clicking on it crash without this commit
[1]: https://github.com/odoo/odoo/commit/2cff7e4094ebb4b56ab17a1462ff358b4b3e7ffd
[2]: https://github.com/odoo/odoo/commit/6303a3eacdca012649a2ffda627b65c17a7217f1closesodoo/odoo#145715
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Steps to reproduce:
-------------------
- on ecommerce, activate "Extra Info" feature;
- go to the extra info form;
- write something for "Your Reference";
- press Enter.
Issue:
------
The Bad Request message is displayed.
Cause:
------
Pressing Enter triggers the form's default submit.
To use the controller of the `/website/form/shop.sale.order` route,
we need to apply the JS logic of the `s_website_form`
widget (the `send` function).
Solution:
---------
Add an event for the `submit` which will prevent
the default behaviour and send the form data.
opw-3591135
closesodoo/odoo#145707
X-original-commit: 14fc7f3c923847f5e052888c2cfda0bf92316972
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If you have the backend in a language A but the website in English only,
you can:
1) modify a record's (event, product...) name in language A (say "New
Name").
2) visit the page `/new-name-11` => the server will redirect you to the
English page `/origin-11`, with the only slug that actually exists on
the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
In effect, Chrome injects a "Too many redirects" layout inside the
iframe, which in turn raises a CORS error when the app tries to update
it.
At the time of this commit, the flow described here should be expected
of users, because the translation UI in the backend is not clear: the
default field displayed is in language A even though the website does
not use it, and the way to update translations is not obvious (you have
to click on the language tag, which doesn't look like a button).
Another way to artificially reproduce the issue would be:
- Create a website.redirect from /dog to /cat
- Same from /cat to /dog
- Go to /@/dog
After this commit, if we detect that behavior, we reload the iframe with
a new query parameter, making the URL brand-new (and not cached) for
Chrome.
opw-3479651
closesodoo/odoo#145306
X-original-commit: 16d47ddf128f31f13e8d0d74597635faf7f9702a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
This commit converts the industry name in the configurator to lowercase
it in order to optimize the IAP placeholder cache.
task-3626875
closesodoo/odoo#145231
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag and drop a 'Text-Image' snippet onto the
page.
- Select the word "Subtitle" in the title of the snippet.
- Click on the 'Animate' button in the editor toolbar.
- Bug: The 'Highlight Animated Text' icon that appeared on the right of
the title ("Inline Text") of the editor toolbar is too big.
task-3597377
closesodoo/odoo#144892
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The goal of this commit is to prevent the text animation overlay from
blocking small text content selection.
Remark: This behavior was already fixed on 17.0 (by [1]) for text
animations and highlights and was backported here for text animation
options.
[1]: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066
Related to task-3285817
closesodoo/odoo#144086
X-original-commit: b69e105149e5f0dc6a469068ab037b717e017144
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
In the Social Media snippet options, only icons with a `<i>` tag are
considered when updating the social media classes (when adding a new
social network by copying the first one and when replacing the icon by
another one matching the URL). However, there are cases where the icon
is a `<span>` element (with a `fa` class) and not a `<i>`.
For example:
- Replace a social network icon by a real image.
- Re-replace this image by an icon.
=> the icon element tag is `<span>` and not `<i>`.
In this case, after setting its style correctly (e.g. adding the round
shape) to make it look like the other icons, we notice that it does not
behave like the other ones:
- It is not aligned with the other icons, because the CSS rule aligning
them only targets `<i>`.
- Its icon is not replaced by a matching one when changing the URL with
a "relevant" one (e.g. google, facebook).
This commit considers `<span>` icons in the Social Media options, in
addition to `<i>` icons, in order for them to all behave the same way.
opw-3538230
closesodoo/odoo#144076
X-original-commit: a8b5c3045bea0227304306e19ed9d50cf497f518
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
When using the "Social Media" snippet, there are two situations leading
to a traceback. Here are the steps:
1) First issue
- In edit mode, drop the "Social Media" snippet.
- Add a new social network.
- Replace the icon by a real image (so not by an other icon).
- Set the URL of the new social network to a "relevant" one (e.g.
google, facebook).
=> traceback
2) Second issue
- Drop "Social Media" and change the list in order to have the first
social network with a real image as icon: either replace the first icon
with an image, or add a custom one with an image an move it to the top.
- Add a new social network.
=> traceback
Both issues happen because only icons set as `<i>` elements are taken
into account when modifying a social network (`querySelector('i')`) and
this element may not exist if the icon had another tag (like an image or
a span or even a video (as the media dialog allows to upload them)). As
there is no check ensuring that the element exists before changing the
different social media classes, there is a traceback when the `<i>` is
not found.
For the first issue, it happens because when changing the URL, we first
check if it matches with relevant ones or if an icon matching it exists.
If it is the case, we then update the social media classes to set the
matching icon => it can only work if the icon is a `<i>`.
The second issue happens because when adding a new social network, it
actually copies the style of the first one (unless there are none, a new
one is created in that case). If the first one is an image, it fails
when updating the classes because it is not a `<i>`.
This commit fixes these issues by simply adding checks ensuring the icon
element exists before trying to modify it. It also adds tests, ensuring
these use cases work as expected.
opw-3538230
X-original-commit: 0132fa38baee6501f4257dad718359400f1369ad
Part-of: odoo/odoo#144076
Steps to reproduce:
- Enable the "Cookies bar" in website configuration > Go to website
(Edit mode).
- Select the cookies bar > Change its layout to "Popup" > The modal
container becomes visible in edit mode only.
The `#website_cookies_bar` element will automatically get one line
height (equivalent to its current `line-height` value) because of the
`contenteditable="true"` added to it, which makes it visible in edit
mode (The container has this default height in all layouts, but it's
hidden by the cookies bar content in "Discrete" and "Classic" modes).
The goal of this commit is to simply hide this element to prevent this
behaviour.
Remark: The same issue occurred on a `.s_popup` parent with an inner
`.modal` element and was fixed in [1] by keeping their visibility
synchronized.
[1]: https://github.com/odoo/odoo/commit/cfd53b8fae3ad9f677df49a03fe6d2945dbb5da2
linked to opw-3485565
closesodoo/odoo#143913
X-original-commit: 4374adfde3627852d0a932f3d10fa74fe0b76a83
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Soukéina Bojabza
