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>
Commit [1] allowed restricted editor to use the optimize seo dialog:
- When they have write access on the record, they can fill the form and
save changes
- when they don't have the write access, the form is in readonly and a
warning is shown to explain it.
But a mistake was made: the restricted editor, when opening the SEO
dialog on a website.page, would receive an access error directly when
reading the SEO fields, instead of the expected readonly SEO dialog
without a save button.
Step to reproduce:
- Login with a restricted editor with no extra rights
- Go to / homepage
- Open the optimize seo dialog
- An access right error is shown
[1]: https://github.com/odoo/odoo/commit/891162574eead15cf64a4f934e5f12346cbcfbbfclosesodoo/odoo#148280
Signed-off-by: Jérémy Kersten <jke@odoo.com>
On website (with “developer” mode enabled), The “Model Pages” menu item
is accessible even when there are no created module page records, which
is not relevant in most use cases.
The code from [1] introduced a way to expose models (both manual and
existing models) publicly on the website by creating pages for them,
these records are accessible through the model pages' menu (which is
currently visible in debug mode only).
A first spec aimed to make this menu item visible only when module pages
are created for the current website, But since we need to perform async
calls for that (to check if some module page records exist), and after
further discussion, it was decided to remove it completely.
[1]: https://github.com/odoo/odoo/commit/198e226f5bd66dba6598d1ef85e5fa5fb82b38b2
task-3659626
closesodoo/odoo#148175
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>
This commit is fixing a last minute error in commit [1] after a push
force which move its code above the existing line `vals['url'] = url`.
After the code move, `vals['url']` was not the updated url value (which
went through slugify and unique path functions).
- Create a /test page, publish it.
- Set /test as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /test_un
-> The page url is /test-un but the website homepage_url is still
/test_un (not slugified) in the website settings
[1]: https://github.com/odoo/odoo/commit/374a1b31f70a3209b1ae11db8e5886350579c7f9closesodoo/odoo#147641
X-original-commit: 3c8a58b654418fc2fc0dc9bc28420c7dcb1bafee
Signed-off-by: Colin Louis (loco) <loco@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>
- Create a "/test" page, publish it
- Set "/test" as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /else
From there, the website setting (`homepage_url` field) was still set to
/test and not /else.
It means that the first "published" menu would then be used to avoid
serving a 404 as homepage to your visitors.
It is a bit confusing and people probably just expect to change that
website setting too when changing the page URL.
We had some feedback about similar flows (that couldn't be reproduced or
where people weren't sure) where people ended up writting on the wrong
page or losing their content.
Maybe this will mitigate the issue.
Kind of related: task-3476840
closesodoo/odoo#147086
X-original-commit: 374a1b31f70a3209b1ae11db8e5886350579c7f9
Signed-off-by: Jérémy Kersten <jke@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 `test_01_multi_domain_assets_generation` was introduced in PR [1].
But afterward, the commit [2] introduced a unique constraint on the
`domain` field. With this additional constraint, this test broke when
run with multiple existing websites as it assigns the same domain for
each of them.
This commit made the dummy domain assigned in this test non-unique,
which doesn't alter the original meaning of the test but, allows to run
it with multiple existing websites.
[1]: https://github.com/odoo/odoo/pull/118526
[2]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d
runbot-20848
closesodoo/odoo#146666
X-original-commit: 0c522e42a82ec596e69611c556c4fc0d50e6e978
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@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>
Commit [1] removed the `email_from` field from the `project.task` model
but forgot to adapt/delete some field occurences.
One of those is related to the form in the website builder which allows
to create task when the form is sent.
Two errors were detected:
- Non critical:
The field is still passed to the form field whitelisting process.
Since the whitelisting is done in raw SQL, it didn't crash or log
anything even if the column did not exist anymore.
- Critical:
The field was still marked as model required in the form JS registry,
altering the form builder behaviors.
One of those is that when the form input related to this field was
re-created (eg when changing / hovering an option in the right panel),
it would lose it's "name" attribute.
Two possible issues from that point:
1. When a visitor submit the form, the "email_from" field value is not
set anymore in the task description and that information is just
lost. You then have no way to reach back to him.
2. (Minor) The auto-fill behavior of the form was not working anymore
Probably more issues were introduced but only those ones got detected as
of today.
Step to reproduce:
- Drop a website form, choose "Create a Task"
- Focus the default "Email" field
- Hover the mouse on the "eye" icon ("Invisible") next to the Position
attribute. If you inspect the DOM, the input has now lost the `name`
attribute.
- If you save, you will face the issues reported above.
- If you then reopen the editor and focus the email field again, the
tooltip will now say that the "null" field is required.
[1]: https://github.com/odoo/odoo/commit/a424cf481c676a230beeb6102fc67bedf472a882
opw-3626573
closesodoo/odoo#146170
X-original-commit: 6679fddbcaf7d9146ab242e0eed61ee0628f047f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Arthur Detroux (ard)
