Commit [1] introduced a website tour util to assert the value of a CSS
variable. This was used at the start of theme tours to check we are in
fact on the right theme before starting the tour.
While it's great for those tours when they are started as a test, it was
not meant to be shown to users following that tour. This commit fixes
that. Notice that theme tours are currently broken so the issue was
probably hidden. Those will be fixed at [2].
[1]: https://github.com/odoo/odoo/commit/b29e17765f4e912b2dd472493b5be500b3a32c87
[2]: https://github.com/odoo/odoo/pull/106703
Related to task-3084175
closesodoo/odoo#106756
X-original-commit: 696c45b4e5917d086f60fd960590328b878014f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website homepage tour was starting with an
unresolvable "Wait for the editor to be started", useful only for tests.
This commit removes that technical step for user tours.
task-3035156
X-original-commit: d45ce39b2904bcb4335f74fab3c42f3eebf477d5
Part-of: odoo/odoo#106746
Co-authored-by: qsm-odoo <qsm@odoo.com>
When entering edit mode, the navbar is hidden. The problem is that since
the merge of the website-in-backend feature at [1], it is only not shown
via an animation (height 0 + out of screen) but not `display: none`. The
tour system thus thinks it is still shown and keeps showing the related
tour tips.
E.g. with website_sale installed (and no demo data, to have the tours),
go on the shop page, there is a tooltip pointing at "+ New", enter edit
mode => the tooltip is still there and it even prevents to click on
"Discard" to leave the edit mode.
This commit fixes the issue by making the navbar `display: none` once
the closing animations are finished.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3082439
closesodoo/odoo#106735
X-original-commit: cdc8d4c889b316664323afad0d848403960150d5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
While showcasing your website inside the website application, there is
the possibility to hit the escape key to enter fullscreen (hiding the
backend navbar outside edit mode and the editor panel during edit mode).
There was a problem following this flow:
- Go to your website inside your website app
- Hit escape to enter fullscreen
- Press CTRL-K to switch to another part of the backend
=> You are now somewhere in the backend, without the navbar (fullscreen)
and you cannot exit it.
As it was a one-line fix (except for the re-indentation), this commit
now allows to exit fullscreen mode wherever we are.
Discovered during task-3082439
X-original-commit: bd225ec782e26c87301e9e786ffd7250ad62ebfc
Part-of: odoo/odoo#106735
Quick feedback from client, this is following [1] that added a button
next to the URL input of `we-urlpicket` to be able to preview the link.
The wording was not great, it gives the impression it's an option to
chose to have that URL opened in new tab (eg when form is submitted).
Also, giving it the style of a conventional we-button was also giving
the same impression that it was actually an option that you could click
on to enable something.
Changing the wording and the style of those special we-button should
reduce the confusion.
Arguably, one might think about the usefulness of this button but it
acts as the counterpart of the regular links which have a "Open in new
tab" possibility when hovering the link in their preview tooltip.
[1]: https://github.com/odoo/odoo/commit/acdf3cf7f5aebd803ffa1507e81ed8801727a03a
opw-3060966
closesodoo/odoo#106538
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide
=> There is no active indicator.
Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.
Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide
=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).
So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.
[1]: https://github.com/odoo/odoo/commit/f7055d3dbabfbe471f490bd65c2032f5251f3f37
task-3040931
opw-3051615
closesodoo/odoo#106639
X-original-commit: 212e8ce620f6eb95aeff6426e06cb29b2c06d0c1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:
(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)
- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button
=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.
opw-2967706
closesodoo/odoo#106477
X-original-commit: 076d7ac7795f86d48b532b6c2a1ff76e4503604e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With commit [1] we refactored the cookies bar to let the user decide if
he wants to accept the cookies (and/or only part of it).
Before that commit, the `website_cookies_bar` cookie could only hold
`true` as value, which now is holding an object like
`{"required": true, "optional": false}`.
This creates an issue if a user is coming from a previous version with
`true` as cookie value because since the refactoring it will crash both
in JS and PY because `in` instruction with a boolean value will fail in
both languages.
The decision taken here is simply to remove the cookie if we face such a
case so the user can decide again what he wants (since there is more
choices now).
It also means that we won't be holding an outdated value in the cookie
any longer.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8
opw-3074303
closesodoo/odoo#106621
X-original-commit: 22392755ed4c504e6ba2a5a9c9eb6643f2c95994
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Ever since the website is previewed in the iframe [1], pressing CTRL-K
(or Meta-K on macOS) while previewing the website can result in
focusing on the browser's URL bar on top of summoning the command
palette.
Steps to reproduce:
- Preview the website
- Click on the iframe to focus on it
- Press CTRL|Meta - K
- URL bar is focused
This commit fixes that by preventing the default behaviour within the
iframe and only summon the command palette.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3035637
closesodoo/odoo#106483
X-original-commit: 797a0514b58a37efc5246a655339353c200b4214
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: auth_totp_portal, mail_group, portal, survey, web, website_event,
website_event_track, website_mail, website_mail_group,
website_mass_mailing, website_payment, website_sale
Although this is deprecated since 5 years with [1], new occurrences of
`this.$target` in widgets kept being introduced. `this.$el` can be used
just like in any other widget, or even better: `this.el` to not rely on
jQuery.
For now, this still keeps the definition. This just removes the bad uses
to prevent more copy/paste... let's delay the decision to remove the
definition entirely to another day.
[1]: https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8closesodoo/odoo#106437
Related: odoo/design-themes#618
Related: odoo/enterprise#34343
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the icon to create a blog post in the new content
modal, inside the website "+ new", was not really fitting.
task-2941545
closesodoo/odoo#106269
Signed-off-by: Delacroix Pierre (pde) <pde@odoo.com>
Follow-up of [1].
After [2], color previews on the side panel would be changed by the
wysiwyg adapter. The adapter would add each block individually inside
the iframe and check its current styling to then add the style to the
color preview elements. This was performed many times (as color palettes
all have their own individual rendering of the color previews)
and slowed down the editor.
This commit improves that by relying on the copied variables introduced
at [3]. This removes the "re-render" of the color preview elements,
instead relying on styling rules and CSS variables which are initialized
when the editor is started.
[1]: https://github.com/odoo-dev/odoo/pull/1149#discussion_r900120846
[2]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[3]: https://github.com/odoo/odoo/commit/a396f791da94d064d58cce15892e74f45d29b7b7closesodoo/odoo#106366
X-original-commit: 7f5a9d040348048990b25c271875c77d2c314e4d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce the issue (see opw):
- Add a form to a page
- Add a checkbox
- Add a second checkbox that is required and visible only if the first
checkbox is not checked
- Save
- Do not check anything and try to send => Good, you can't, the required
checkbox is not set
- Check the second checkbox and try to send => Good, you can, the
required checkbox is set
- Go back to the empty form, check the first checkbox and try to send
=> Bad, you can't but you should: the required checkbox is hidden, it
is not supposed to be required anymore.
(Not that arguably, that two checkboxes setup should be replaced by a
required selection field but the issue of the OPW would remain as there
is another required conditionally-hidden field (a file upload) when the
second checkbox is checked.)
Conditionally-hidden fields should not require validation while they are
hidden. Indeed, their purpose is to be able to enter additional data
when some condition is fulfilled. If such a field is required, it is
only required when visible. The problem only occurred with checkboxes,
the other fields were already working in that case. Although there could
be issues with dates too, this commit added a series of FIXME and TODO
comments as well as some things need to be investigated.
opw-3003952
closesodoo/odoo#106204
X-original-commit: f501c25a9d33399cfbb45526d95038266d91686e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when submitting a website form which has invalid
radio buttons, checkboxes or file upload elements, they had no visual
difference. Now they will have red labels as intended with bootstrap.
For alone checkboxes, a warning label will appear after the checkboxes.
This will only take effects for newly added checkboxes.
Related to opw-3003952
X-original-commit: 3268b4c902c92c12f50081d31eb08d4c330ca03f
Part-of: odoo/odoo#106204
With [1], checkboxes in website forms were wrapped in a <div/> with the
"form-check" bootstrap class (as they should). That forgot to mark the
checkboxes themselves with the class "form-check-input". Without it they
are misaligned.
This fixes the error for newly added checkboxes in forms. Old ones will
stay "broken".
[1]: https://github.com/odoo/odoo/commit/9ea276ae2f00c3a5ba4e10af313085947e70e265
Related to opw-3003952
X-original-commit: b3ff062e8add1e9b810a37112f05a0c1d23136be
Part-of: odoo/odoo#106204
Before this commit, if the user tried to setup a required selection
field whose first value is empty, it was possible but the empty value
appeared as a 0px-height div in the DOM preview. That empty value also
shows up when trying to use the conditionally-hidden fields feature: if
another field's visibility depends on such selection field, the editor
UI was visually broken as the first choice was an empty option element.
Now, we show "<no value>" in both cases.
Note: this is not done in earlier versions than 15.0 although the
problem exists, but it was decided that the real problem was about the
visibility select being visually broken and that feature only appeared
in 15.0.
Related to opw-3003952
X-original-commit: a62f3dbef31c4750ba16d55adf28c235a27dbc56
Part-of: odoo/odoo#106204
Since [1], the google map UI to search for locations thanks to the
google map API was not working anymore. Indeed, the lib was loaded
inside the iframe (as it should) but not outside of it, preventing to
use the `google` object in the related editor panel widget. The
autocomplete UI style was also broken as the CSS is not available
outside the iframe.
As a fix, the code outside the iframe now use the `google` object from
inside the iframe (no problem seems to come out of it) and the style is
restored via custom CSS (custom CSS already existed and was already
changing most default style anyway).
As a reminder, this snippet is only available in debug mode or if your
google map key is setup, which we do not allow to enter anymore via
standard flow since 16.0 (15.3).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#106103
X-original-commit: 7d60d0ae4ea195edc4a12e57bf1c3b7c661bcf82
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.
opw-2976261
X-original-commit: 50bf0b7f1677b8125d892fad968ccc8174c974c1
Part-of: odoo/odoo#106103
Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.
opw-2976261
X-original-commit: b761c8fe0762f449bd6d9a1763c152833819247c
Part-of: odoo/odoo#106103
Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.
Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled
Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.
Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.
opw-2976261
X-original-commit: d9f86840e27463ccf370a748cafc7c4be32f901f
Part-of: odoo/odoo#106103
The dot (period) is removed from user-facing strings in powerbox
commands, and the corresponding msgid in .pot files are updated.
task-2901665
closesodoo/odoo#106032
Related: odoo/enterprise#34116
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
After [1], when an option that requires the page to be reloaded is
changed, the editor will try its best to reselect the same snippet.
However, in some scenarios, the snippets' options could not be activated
leaving the menu on the snippet drag and drop menu.
Steps to reproduce (race condition so might not always occur):
- Activate the cookie bar in the website settings
- In edit mode change the header menu style
- The Snippets Drag and Drop menu is displayed
- Instead the Header Options should be displayed
The reason is that an event is not 'awaited'. Indeed, when starting the
editor, a 'widgets_start_request' is fired and not awaited.
It creates a race condition that is visible in this case but could have
caused other issue.
For the in-depth technical reason this happens:
- The wysiwyg is started, the popup is on screen, its options are loaded
by default (since it's needed to populate the invisibleDOM panel)
- activateSnippet is triggered with the Snippet it should focus on after
reloading
- widgets_start_request is triggered which destroys the popup and
triggers an 'onHide' event within the option
- The triggers a 'snippet_option_visibility_update' which triggers an
activateSnippet(false) which hides everything that was enabled prior to
this point.
This commit fixes the issue by re-ordering the events and making sure
that the 'widgets_start_request' is awaited
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
task-2687506
closesodoo/odoo#105816
X-original-commit: 5a2d0a2a88b9ecc2c330a948dfd9140b9edc3af3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since this commit [1], the header language switcher has been moved out
of the header navbar. This created a bug, when the off-canvas option of
the navbar is activated, the language switcher is no longer accessible
on mobile.
As this commit is in stable version, the fix is only in Javascript. It
puts the language switcher back in the navbar when the off-canvas menu
is opened.
A specific case with the "hamburger full" header template, where there
is the same bug with the "call to action" button, is also fixed by this
commit.
This commit also fixes display issues in the off-canvas menu.
[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2
opw-2964824
closesodoo/odoo#105504
X-original-commit: b89dbb2e18c4ccebcd72e87758b5d3363ed875b3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, `view_hierarchy` extended the QWeb view to see
the hierarchy of views.
With the evolution of the javascript framework, this use case has
now more sense in a client action rather than an extension of a
QWeb view.
This commit refactors `view_hierarchy` into a client action.
Part-of: odoo/odoo#103477
This commit updates the tooltips of disabled form field's duplicate &
remove buttons so that they do not reference the concept of "model".
task-2950433
closesodoo/odoo#105278
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_mass_mailing (tests)
- Web Editor facts:
Since the refactoring of the editor done at [1], the cookies bar popup
is receiving a `contenteditable=true` attribute, making it receive the
chrome default `height` style for such elements.
The problem is that if this cookies bar's modal is hidden, the bar will
be shown as a thin empty white bar.
- Website Builder / Popup Snippet / Cookies bar facts:
A popup element is composed of a `.s_popup` parent containing the actual
`.modal` BS modal. Our internal logic and events are hiding and showing
this inner `.modal` modal element without considering its `.s_popup`
parent. It means that when the `.modal` is hidden, its `.s_popup` parent
is not touched and kept visible.
It might looks like it's not an issue as it would just be an empty
element (its only child is hidden) but it leads to some issues as
explained just above: an ugly white bar is shown.
Note that the cookies bar is nothing more than a `.s_popup` snippet.
- Web Editor facts 2:
During the mentioned refactoring [1], they actually added some code to
hide this bug once you were playing with the edit mode (mainly for when
you clicked on the invisible panel element or before saving).
But this code was actually not fixing the case when you just entered
edit mode.
This commit simply remove that "edit only" web editor logic and add a
new one in charge of simply synchronizing the `.s_popup` snippet
visibility with its `.modal` BS modal in a public widget (which is
obviously also executed in edit mode).
Finally:
- note that if there is no way through regular flow to arrive to the
same result with a normal popup snippet, it is still concerned by this
issue and you can reproduce it by moving it somewhere else in the DOM
and/or simply adding it the `contenteditable=true` attribute.
- we already fixed that issue a few months/years ago, I couldn't find
a commit related to that so I don't know if it was due to the same
root cause
- in case one is wondering why we simply couldn't do that in the already
existing `_onHideModal` of the `PopupWidget`, it is because that
`hide.bs.modal` is not called when entering edit mode, because the
`destroy` is destroying it before hiding the modal. The event is thus
not fired. And we can't move the hide part before the destroy's super
because otherwise, it would go through the normal hidden process which
is creating a "seen" cookie for the popup as if it was closed
manually.
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
task-2754108
closesodoo/odoo#105553
X-original-commit: 21a5e7000f08fbd1936173937c7d90b152a5414f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Currently entering custom urls will be missing characters if they
contain unicode.
Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`
Expected output after this commit: `noi-dung-co-dau`
closesodoo/odoo#105195
X-original-commit: 3c1cd65e2eb44c5d2cb695afad19c58f24bde8b1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Part of [1] was lost during the frontend>backend merge [2].
The SEO name field was not "slugified" anymore in JS, it led to 2
issues:
- Bad UX, one could type something and it would end up after save with
something completely different
- 404/crash: as the generated URL in js (based on the seo name value)
would not be slugified, it would redirect to that URL, which would not
be found as the record URL in python would be slugified. There would
be an URL mismatch between the python route and the JS redirect value.
This could still somehow happen as the JS and PY slug are not doing
the exact same things but at least this will restore what we had
before and mitigate the issue.
Step to reproduce:
- Go to a blog post and open the SEO dialog
- In the custom URL input, type "créé"
- You will be redirected to `/@/blog/travel-1/créé-1`
This will be a 404 page, as the correct URL is now
`/@/blog/travel-1/cree-1`.
[1]: https://github.com/odoo/odoo/commit/c387ec19b4648ae52bf3210253febd7825745627
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 3c266751c41ab0a96494ccd6cd1a1fff3a6a7058
Part-of: odoo/odoo#105195
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
*: website_sale
Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.
This fixes the problems with a specific JS patch, we'll review to see if
better can be done in master.
Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.
Note: as a forward-ported fix, this also takes the opportunity to clean
a bit what was done at [3]. (calling `_super`, no duplicated code,
adding comments, ...).
[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3
[3]: https://github.com/odoo/odoo/commit/e2f7b8fad76dc816b2f6864340d3740446117cdb
opw-3031217
opw-3032482
opw-3035289
closesodoo/odoo#104521
X-original-commit: 1636ba5ed2f8a284bef0930313a85cc3dc7cf072
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit if a Table of Content entry was a too long word
without spaces, it span beyond the width of the menu part of the Table
of Content block.
Note that in Chrome, during Edit mode the words are already split
across several lines because the `contenteditable="true"` of the
`#wrap` node applies some built-in extra styles (not from user agent
stylesheet) among which `overflow-wrap: break-word;`.
After this commit long words are split across several lines.
task-2965279
closesodoo/odoo#104559
X-original-commit: ef7174e16663036d3598122d4abdcd5eab0189a0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, opening the Page Manager in debug mode would throw
an error, stating that the website.RecordFilter has a t-foreach with
duplicated keys.
As per the [owl documentation]: "Owl requires the presence of a t-key
directive, to be able to properly reconcile renderings." and "A key
should be a unique number or string."
This commit fixes the keys to be the website id instead of the website
object.
[owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loopsclosesodoo/odoo#104540
X-original-commit: 0d1c263298ca6724a6fe6c31e2a2d3221c5e8c75
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.
This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.
Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:
- Current height is 700px
- There is some code that forces a min-height on all carousel items so
that they are the same height. As the gallery image dimensions depend
on the block forced height (this is how the snippet work), the forced
min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
is already set)... it ends up removing it as it thinks that setting
that height is not needed as the snippet is now "naturally" 800px tall
thanks to the carousel items' min-heights.
opw-2838774
closesodoo/odoo#104068
X-original-commit: d4d0da320d42093e720c7d440cf6611249c0295a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Both dynamic snippets and visible on mobile use the `d-none` class:
- dynamic snippets activate it by default and only remove it when the
content is ready to be displayed
- visible on mobile makes the section `d-none` when it must be hidden on
mobile and the class is contradicted by another class which is only
taken into account non-mobile
This commit introduces a dedicated class to temporarily hide the dynamic
snippets.
task-2930503
closesodoo/odoo#103637
X-original-commit: 7b3be2f183f53bfcb5f365a2c26127da0702dc15
Related: odoo/upgrade#3980
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit there was an issue with the header effects (except
the 'Scroll') if the page did not have much scroll height when the
header decreases in height when scrolling down. When this issue appeared
it was impossible to reach the bottom of the page.
This was due to the fact that when the header size is smaller when
scrolled (e.g. height scrolled logo option), the padding-top of the
`main` is decreased and therefore the scroll height of the page too..
Which meant that, during the transition that changes the height of the
header, this decrease in scroll height immediately increase the height
of the header, then decrease, etc. in an endless loop.
This commit fixes that by no longer triggering an animation that changes
the height of the header if the scroll height is too short.
This commit also fixes an issue with the standard effect which was not
properly destroyed and left a 'translate transform -100%' on the header
when changing the "standard" effect to a "scroll" effect and the page
was scrolled.
opw-2812482
closesodoo/odoo#103804
X-original-commit: 46993910eb31e9cbaf60a7d4e4c3014d60e7bb2b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This `s_social_media` snippet option uses a variable defined in the
module's scope to store social media values. This
reduces the amount of RPCs needed to fetch the data as they will only be
done once per edition.
Prior to commit [1], this cache would only exist as long as the page
lived. Which means that switching website, switching page or going in
the backend would reset its value. Commit [1] moved the edition in the
backend which means that the cache would persist between pages but more
importantly, between websites, only resetting if the backend was
refreshed or left.
Steps to reproduce:
- Go on website 1
- Modify the URL for facebook in the footer
- Go on website 2
- The value is the same when it should still be facebook.com/Odoo
This commit fixes that by resetting the cache when the editor is
destroyed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#103689
X-original-commit: 3efb726575679f62f9ee2894193323bfe45d7938
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1], there would be a traceback due to a wrong DOM selector in the
`configurator_tour`.
Indeed, completing the configurator will activate the configurator_tour
asset which is calling a broken clickOnSnippet tour util to generate an
appropriate homepage tour.
It would end up with the following selector:
`o_website_preview[data-view-xmlid='website.homepage'] iframe #wrapwrap .#wrap > section:nth-child(2)`
See the `.#wrap` which is incorrect and make jQuery crash.
This is because [1] adapted the tour utils to the new WebsitePreview
client action, but the clickOnSnippet function was wrongly changed and
could now be generating wrong triggers selector.
It was creating invalid selectors as it was concatenating a `.` with the
provided string parameter which was basically a class without the `.`,
like `s_popup`, but not in all cases. A whole valid selector could also
be provided, meaning that concatenating it with a leading `.` would
result in incorrect selector.
Basically, this commit revert the change made on [1] in `clickOnSnippet`
to restore the code of [2] that was preventing the wrong selector
creation.
[1]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35
[2]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
opw-3026167
closesodoo/odoo#103651
X-original-commit: 26c4e4a13b642e2856495a8c1f5a36afe3996c02
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website, test_website
Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.
With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).
But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).
This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.
Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.
Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
task-2687506
closesodoo/odoo#103562
X-original-commit: 931d488af0d4dce529e4ea4ab3c8b827bda0d699
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
When the dark mode feature was merged with [1], it adapted the
EditWebsiteSystray item with the 'text-reset' class.
But this class was not removed if the website was translatable, and it
was not added on the TranslateWebsiteSystray item, which was leading to
wrongly colored systray items on a translatable website.
[1]: https://github.com/odoo/odoo/commit/ee3aa3054cdd715720466863239d5aa56186946c
X-original-commit: 9bc4987d8a4a3d1e5ff31d6e2fd3ea4b453fe21c
Part-of: odoo/odoo#103562
Before this commit, the "page anchor" option of the link editor did not
work in Website. Choosing an anchor did not update the link in the DOM.
task-2900529
closesodoo/odoo#103366
X-original-commit: b24b87a688bafac459bdc6ea698378189a1bf071
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit removes the path part of the reloaded page after a module is
installed from the website editor so that it lands on the root page of
the website, when the current page is a 404.
Steps to reproduce:
- Access `/@/a`, an undefined page.
- Edit.
- Discard.
- +New.
- Install Blog.
=> Reloaded `/@/a` but without its assets generated.
closesodoo/odoo#103345
X-original-commit: 886900c33d18f647016e596ba41c193f5fcf8a43
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Previous commit adapted the URL dependencies screen following the
website frontend > backend merge done at [1] and [2].
It allowed to pass other records than website.page and also added the
multi record capability.
This commit is going a step further, by searching for the URL in all
HTML fields and not only views + pages + menu + blog.
It also let the XML take care of the wording instead of the python.
closesodoo/odoo#103136
X-original-commit: 6ac17b93437868cbefbe13448a6fcbb29953f221
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This is following the website frontend > backend merge done at [1] and
[2].
Before that improvement, the old page manager had a button to delete a
page which was behaving as the one in the page properties dialog: it was
showing the list of (possible) dependencies as a confirm step.
But since [2], that delete button was removed as the action menu of the
list view already has a delete button, which is better as:
- It is hidden and take no space, deleting a page is rare
- It is known by odoo users as all list views have that button
- It handles multi delete
So this commit basically just restore that delete warning step for that
list view delete button, and also make it possible to use that
dependencies warning dialog for multiple pages, not only one.
It also now handles records in a generic way, not only website pages.
It's needed because now, all the main Odoo frontend records are sharing
a list view mixin (see `js_class="PageListController"`).
It also fixes the fact that the text of the collapse were inside a font
awesome class, basically using a weird font.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
X-original-commit: 11db2f6ed81419ac724ff27ac95a4438d670cbd5
Part-of: odoo/odoo#103136
This is basically reverting commit [1] which was done a few years ago
as improvement to [2], but it was a bit overkill IMHO.
Indeed, there is a sort of hack when creating a page with special
extension like "my-page.js" that will actually create a special page
with special arch. The goal is for such pages to be `t-call`ed later.
That's commit [2].
On top of that, when deleting such a special page, we introduced a
mechanism to show the views and pages that would possibly `t-call` the
that page which is requested to be deleted.
That's commit [1].
It basically is mimicking what was already done when you change the URL
of a normal page, we tell the user where that url is actually possibly
used.
But since the recent improvement in Odoo 16 done at [3], the page
manager is now a backend list view. It means that multi delete is now a
thing.
Thus, the page dependencies behaviors (key and url) need to be
refactored to handle multiple given URL/Key and not just one.
We choose to remove the key dependencies part (only used for those
special pages) instead of adapting it:
- That 'hack' is probably almost never used
- It's some code to maintain, eg now we need to refactor it
- We would need some extra code to make it only triggered for website
pages and not all records, unlike the url dependencies screen which
concerns all records
- That's an advanced feature (special pages), if you are using it, you
probably knows how to handle a website and you don't need us to remind
you where this special page's view is used.
[1]: https://github.com/odoo/odoo/commit/a91a3a563338e746d6d23cd57551af30e322e367
[2]: https://github.com/odoo/odoo/commit/727d461e1d2bcec4571665b90b6d1630f671a0a3
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 77f03abc56b147171eeba66bc55df5ee92c8af1a
Part-of: odoo/odoo#103136
*: website_event
The 'website_event.menu_edit_menu' menuitem was added on 'website_event'
module to the 'custom menus' registry so it can be displayed by the
'website_custom_menus' service if the event page has menus to edit.
The goal of this commit is to move this code to 'website' by using a
generic 'custom_menu_edit_menu' menuitem that will be cloned to edit
every content menu on the current page with the corresponding
'EditMenuDialog'. This is needed as a fix as it would be a regression
to not have this in 16.0 since it was possible to edit any menu on a
page in previous versions.
task-2973149
closesodoo/odoo#102997
X-original-commit: 6af5ad67c9657c7dcaf4afa1ecb4561e9c72270a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, there was a conflict between 2 of the ways to open
the WebsitePreview iframe.
First, introduced with [1], when a user click on the 'edit in backend'
systray button, the URL he was on is stored to be used later if the user
click on the "Website Preview" breadcrumb. When he will click on that
breadcrumb entry, we want him to go back to where he was, not on the
homepage.
Second, some records in form views have a "Go to website" stat button
that will go to the website preview action, loading the iframe with the
URL of the record from the form view.
Before this commit, the second flow was not working if the user
previously click on "Edit in backend" on a record (first flow
described).
Indeed, if that "last url" was set, it would always be used, ignoring
the requested one from the second flow.
Step to reproduce:
- Go to a record in the website preview, like a product
- Click on edit in backend
- You land on the product form view, and that url was saved in JS
- From there, navigate to another record through the form view, like a
m2o relation or a stat button, or by whatever other mean, but don't
hard reload the page (F5)
- For the example, let's say you landed on a blog post record
- Click on "Go to website" on that blog post form view
-> You land on the product page you were initially, not on the requested
blog post page.
Courtesy of @rdeodoo
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#103010
X-original-commit: 7cd55e8a1d9516a6f457320064160328a49210f9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
qsm-odoo