This commit fixes several bugs with the navbar and the header templates:
- The "right" alignment options didn't work with most headers. This was
due to a missing CSS rule.
- The "right/left" alignment option was reversed with the "vertical"
header template.
- The navbar collapse style was broken with the "Hamburger Full" header
template.
- This commit hides the alignment options in cases where they have no
effect ("Hamburger Full" or "Magazine" header template + not
"off-canvas"). It also changes the options label to "Mobile Alignment"
when the alignment only impacts the mobile view (since this commit =>
[1], the "alignment" option no longer only impacts the mobile view,
depending on the templates, it can also impact the "desktop" view).
- The text section of the "Magazine" header template had no background
color (It was transparent after scrolling the page).
- The "off-canvas" navbar was not positioned correctly with several
header templates (e.g. "Boxed" header template).
[1]: https://github.com/odoo/odoo/commit/2a1aa808e939eeaa3caec6a1a82e19f023f1d010
opw-2951315
closesodoo/odoo#117237
X-original-commit: ca621a292c659f60dd8fdf19a7e77a52f05742c0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog,website_event,website_forum,website_hr_recruitment,
website_livechat,website_sale,website_slides
Prior to this commit, elements inside the New+ modal had a `isDisplayed`
property that was meant to be changed by the patches done by each
module. Unfortunately, this was forgotten in the refactor done in [1]
and more precisely when the component was introduced in [2].
This commit fixes that by checking the access rights of the user on each
individual model used on the create form.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/ca2e143d54622d598201826a2cd669bad64b205d
opw-3198700
closesodoo/odoo#117206
X-original-commit: 58704cb7615addd7d40291431e05a894776320d8
Related: odoo/enterprise#39066
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] fixed the editor not being able to start when clicking on a
link that triggers a download. This was caused by the
websiteRootInstance being undefined when a page is about to be
unloaded (beforeunload). Unfortunately, this event can be canceled.
This means that the websiteRootInstance had to be undefined when we are
certain that a navigation is going to happen within the iframe. However,
the condition introduced by [1] does not take into account multiple
factors, which lead to the websiteRootInstance being undefined during
edition.
This commit fixes that and introduces a test to make sure this behaviour
is not easily broken again.
Steps to reproduce:
- In edit mode, on the Home page, go in the footer and click on any link
(except "Contact Us") under "Useful Links" or on the house icon in the
Social Media snippet.
- Change the footer height with the Height option.
=> The option is applied correctly (because the link stays on the same
page).
- Click on "Contact Us" or another Social Media icon.
- Try to change the footer height again.
=> The preview works but when we leave it, we see that the option was
not applied.
- Drop a snippet and click on it.
=> Infinite loading.
[1]: https://github.com/odoo/odoo/commit/e47a9900e4a7842774d33a332b325e1f08c3ca45
opw-3196324
task-3212501
closesodoo/odoo#114366
X-original-commit: 15a17656b42442b40f4476efe8c985a9ba28ff93
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Co-authored-by: Soukéina Bojabza <sobo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The Bootstrap/Popper code which is in
charge of positioning the sub-menu could not work because the dropdowns
were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented
Bootstrap/Popper from aligning the sub-menu items correctly.
Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.
=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.
task-2904507
closesodoo/odoo#116535
X-original-commit: https://github.com/odoo/odoo/commit/03c82f6b0094c9d038b1699376d49f2846298bcd
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
*: web_editor
The table of contents menu entries are generated automatically which
poses a problem in translation mode. The menu translation entries
are not be editable separately, but the users might be trying to.
This commit shows a notification when the user clicks on the menu
entries while in translation mode, explaining that they are generated
from the title entries.
It was initially intended to use a tooltip - but the amount of code
needed to display a tooltip without marking the DOM as modified is
needlessly complex.
To avoid that styles applied on a plain text during translation were
also appearing in the navigation menu, an attempt at adding a span
around them to make sure that their translation was distinct from the
one inside the main content. But this led to the risk of losing
existing translations.
Because of this, and because that situation seems unlikely, any
remaining style in the navigation menu is instead stripped when the
table of content is started to maintain consistency with what is shown
during translation.
An `o_translation_without_style` class has been introduced to indicate
to the synchronization mechanism that only the text must be replicated
for those elements.
For labels that have a different `data-oe-translation-initial-sha` than
their related header, that value is temporarily kept in another
variable, the value is replaced by the one from the header, which make
the synchronization mechanism properly associate them, then on save
the initial value is restored so that the translation is saved for the
right slot.
task-2752391
closesodoo/odoo#116270
X-original-commit: 5776a358e1b42186d2c26c9bc25010a12811f416
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before [this other commit], it was possible to add a wrong video on a
page of its website. If the user did this and saved the page, it was no
longer possible for him to enter edit mode. To solve this, two
improvements have been made:
1. We now prevent the user from putting a wrong video on his page when
he goes through the media dialog (see [this other commit]).
2. Since there are probably websites that have a bad video (it was
possible before [this other commit]), this commit allows users to edit
the pages that have these wrong videos.
Steps to reproduce before [this other commit]:
- Edit a page.
- Via the media dialog add a video with the following URL: 'google.com'.
- Save the page.
=> It is no longer possible to enter edit mode.
Note that part 1 was merged from 14.0 but part 2 was merged from 16.0
because the media dialog adds `iframe` without `src` attribute since
[the refactor of the media dialog] and we cannot edit a page containing
this code `<div class="media_iframe_video"><iframe/></div>` since the
merge of the frontend into the backend.
[this other commit]: https://github.com/odoo/odoo/commit/fbab1bffa033638553750d49fcde89a9a2fc5e6c
[the refactor of the media dialog]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
opw-3167707
closesodoo/odoo#116128
X-original-commit: 242d6f2e1dc35c3d22314a4c92c2420f69eb9970
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
==== Purpose ====
There is an issue with the `/@/` symbol website is using to display a
page in the backend: if someone copy paste a link with `/@/` in it and
send it in an email, some mail client will block those mails.
It was reported by our internal team, after feedback from some sales
persons.
Office 365 was incriminated (not the outlook.com web platform). While we
couldn't reproduce the issue, it was decided by the hierarchy to get rid
of it as it was judged impossible to educate our sales to not send such
links.
It's probably a good decision as:
- `@` in URL are usually used for HTTP Authorization:
`http://username:password@example.com`
Link [1] seems to mention that some mail client will not implement
correctly the URL check to see if the `@` is problematic and will
simply block mails having links containing `@`.
- The tradeoff of removing it is impacting dev/tech people, not the end
user (except for F5, see below).
==== Technical ====
Before this commit and since commit [2] the following behaviors were
introduced:
1. a `/@/` prefix was added visually in the URL bar of the browser when
accessing the website app (previewing your website in the backend) to
differentiate it from the regular website/frontend URL
2. the possibility to type yourself `/@/` in the URL to access a website
page in the backend app
It was improving the following pain point:
A. On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
B. When the user edited the URL (Like removing `/shop` and typing
`/jobs` instead, he would land on the frontend version too.
C. Impossible to directly go to the backend version of the website.
This commit is now reverting point 1. while keeping the possibility of
point 2.
It means that while you can still reach directly your page in the
backend, the backend URL part `/@/` won't be kept.
About the mentioned point above:
A. This pain point will be back
B. This one too but workaround possible: need to edit the URL but also
need to now add the `/@/`
C. This one will still be "fixed" as `/@/` still reachable.
While it seems to be decreasing the UX, it actually is an acceptable
tradeoff as:
- It mostly impacts dev/tech people, lambda end user don't play with
URLs (low risk)
- It will prevent their mail to be blocked (high value)
--------------
Finally, note that in the meantime commit [3] was introduced which
relied on this `/@/` presence. This had to be adapted.
[1]: https://www.malwarebytes.com/blog/news/2022/05/long-lost-symbol-gets-new-life-obscuring-malicious-urls
[2]: https://github.com/odoo/odoo/commit/030d3cb10ee79aa1f010134578f4bcf65a1cfcde
[3]: https://github.com/odoo/odoo/commit/a0b3499d348d252c3abd48154e1fd8dd545c7504closesodoo/odoo#116100
X-original-commit: b01337710b5fde995a184e442f48b687cd17967a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to a website page (edit mode) > Duplicate the footer (or any
snippet with a Social Media block).
- Save > Traceback.
Starting from [1], a `dbSocialValues` variable was used to update the
"Social Media" DB links for the current website (on save).
These URL values are fetched from database (see: `_fetchSocialMedia()`)
to "compute the widget state" and when the snippet is dropped
(`onBuilt()`).
The specific case of "snippet clone" will lead to a situation where the
editor is created with an `dbSocialValues === undefined`, leading to
trigger the website `write` method with an empty update value...
Remark: The "save" works correctly after calling `_computeWidgetState()`
The goal of this commit is to simply prevent triggering the `write`
update on `clanForSave()` when `dbSocialValues` is `undefined`.
[1]: https://github.com/odoo/odoo/commit/f243bcbafb9291d94840795951c8fd51cab0cae1
opw-3204862
closesodoo/odoo#115912
X-original-commit: d3edef46426d1fefb31dae482f4c05dade4865a6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
New text_cover snippet added for the editor. Editors are now able to use
a cover composed of an image and some text on the side.
task-2691555
closesodoo/odoo#105650
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this first commit], the elements that make up the submenu of the
navbar of a website can no longer overflow the page. Depending on
whether the content is too long, the elements are aligned to the left or
to the right. Unfortunately, since [the merge of the frontend into the
backend], the dynamic alignment no longer works in edit mode. This commit
restores the dynamic alignment of the submenu items so that they no
longer overflow the page in edit mode.
Steps to reproduce the bug:
- Have a submenu with a long element in it
- In edit mode align the navbar elements to the right
=> When opening the submenu in edit mode, the long element goes over the
page instead of being aligned with the right side of the menu.
Technical explanation:
In edit mode, the dropdown opening in the navbar is done by
`WebsiteWysiwyg` which is instantiated in the backend while the function
that allows to align the submenu elements correctly is declared in
`menuDirection` in the iframe. So the dropdown must be opened with the
Bootsrap instance of the iframe in order for the iframe to detect that
the dropdown has been opened.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this first commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
task-2904507
closesodoo/odoo#115607
X-original-commit: 11f817e8d0b0764427f0db7d62fb0cdd403e3012
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Since [this first commit], the elements that make up the submenu of the
navbar of a website can no longer overflow the page. Depending on
whether the content is too long, the elements are aligned to the left or
to the right. This was done with the public `menuDirection` widget which
looked at the available space on the left and right and depending on the
size of the submenu elements, aligned the submenu in an optimal way. It
has now been decided to get rid of all this widget because Bootstrap
(with Popper) knows how to position dropdowns dynamically. Unfortunately
Bootstrap has limited this dynamic positioning by disabling it on
dropdowns that are in a navbar. So this commit removes the public widget
and replaces it with a bootstrap patch so that dropdowns are dynamically
aligned in navbars too.
Note that if we had not made this patch in master, we would have had to
adapt the public widget to the migration to Bootstrap 5 (see original
commit).
[this first commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
task-2904507
X-original-commit: b6963dc21bad4b012aace16b9ea9264c33a0d618
Part-of: odoo/odoo#115607
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
The following basic case has been broken in website forever since [1] in Odoo 8:
```html
<p><span>a</span><span>b</span></p>
```
Saving the above html results in:
```html
<p>
<span>a</span>
<span>b</span>
</p>
```
Which, when re-rendered back in the DOM renders equivalent to:
```html
<p><span>a</span> <span>b</span></p>
```
Note the space between "a" and "b". That is because etree will pretty print
nodes with indentations as long as they do not have text content, and that
indentation is collapsed into a single visible space by the browser when
inserted in the DOM. This is not limited to span nodes as the same applies to
any inline node. This is very easily reproduced in website on any version:
- Drop a Text snippet.
- Replace all the content of the snippet by "ab".
- Put "a" in bold and "b" in italic.
- Save.
- Notice that the saved version is now "a b" instead "ab".
The user has no way of removing this space easily because even if they manage to
do it by any mean, the server will pretty print the html again and the space
will reappear. The only way to circumvent this is to have some text content as
sibling of the inline nodes.
Consider this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span></p>'), pretty_print=True)
b'<p>\n <span>a</span>\n <span>b</span>\n</p>\n'
```
Which is incorrect, while this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span>c</p>'), pretty_print=True)
b'<p><span>a</span><span>b</span>c</p>\n'
```
Is correct.
We could fix it using a heavy hack that would leverage this behavior by
inserting one of the few unicode control characters that etree considers to be
actual content, and therefore preventing pretty printing for this node. The
server would then remove the control character to avoid polluting the actual
views. This would have the side-effect of forbidding this control character to
ever be used in a view however, and would obviously be an extremely ugly hack.
The alternative which was chosen in accordance with Antony (al) and Xavier (xmo)
is to disable pretty printing altogether, since the original commit [1] seem to
have introduced it as a fix for an old version of the editor rather than for the
intrinsic qualities of having pretty printed views.
If we ever want to re-enable pretty printing in the future, I suggest it be
implemented in JS because the browser is the only one able to assert whether a
node is going to be treated as a block or as an inline with respect to the
current CSS rules in application.
task-3142796
opw-3122373
opw-3186250
[1]: https://github.com/odoo/odoo/commit/6b857b6eeb59137a71385f98c82c440ac82cd45dclosesodoo/odoo#115159
X-original-commit: 3c6b9249482454a931f384ffc66ceec64dffbcfc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit, the event handlers that prevents the default
behaviors of a click was bound onto the $editable after the wysiwyg
editor had started.
This meant that during a very short period, the element could have the
"editor_enable" class but would not prevent clicks on the document
from triggering a default behavior.
This issue is not as important in versions prior to 16.0, because most
of the clicks on link would trigger navigation within the page,
canceling edit mode. If a traceback had appeared, it would be removed
quickly after, as the page was unloaded.
However, in 16.0, if the iframe leaves its current page, it can crash
the editor which now resides outside the page we are currently
editing.
Furthermore, the test introduced in [1] highlights the problem, as it
clicks on a link directly after checking if "editor_enable" is added to
the body within the iframe. This created a race condition, which means
the test crashed often.
This commit fixes the issue by using the click handler of the
website_preview to prevent the default behavior while in edit mode.
[1]: https://github.com/odoo/odoo/commit/050378dd8599b907ad429d4d1812602b557d0f73
runbot-18660
closesodoo/odoo#115119
X-original-commit: f9e51a8ab1cc469bd3dd4dba21856597d5e0f902
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [the merge of the frontend into the backend] and more precisely
since [this commit], clicks on some elements makes the user switch from
the backend view to the frontend view.
Steps to reproduce (just an example):
- Go to /blog from the backend (/@/blog)
- Click on a tag (eg: adventure)
=> users are redirected to the frontend view, we do not want that. This
commit makes the user stay in the backend. For some scenarios (like the
one above), we create a fake form and submit it. The forms have a target
attribute that specifies where the form response should be displayed.
This commit set back the default value for the target attribute when a
user clicks on a blog tag, a course tag, the pager, ... so that the
response is displayed in the current context (the iframe when the user
is in the backend).
Note that [this commit] introduced the target attribute change to fix
two issues:
1. The opening of the payment gateways in the iframe.
2. The create page from a 404 page in the backend.
After [this other commit] has been merged, to prevent the first issue so
here we just remove the target attribute change except for the case of
the second issue.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this commit]: https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64
[this other commit]: https://github.com/odoo/odoo/commit/3a32b9e1efa6277b345dc9239334680651690df7
task-3054970
closesodoo/odoo#114056
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: web_tour, website_blog
Since [1] when the search box autocomplete was introduced, the URL
parameters are implicitly included into the RPC that fetches the
autocompletion results.
Those parameters were not correctly unescaped before being sent to the
RPC call.
Because of this, a timestamp such as "2023-01-01 23:00:00" was sent as
"2023-01-01+23%3A00%3A00" to the server. If that string reached the SQL
layer, the "+" was interpreted as defining a timezone.
This commit unescapes the URL parameters before using them in the RPC.
Note that javascript's `decodeURIComponent` does not handle the '+'
encoding of spaces inside URL parameters.
For testing purpose, the following updates were needed to make it
possible to select the `<option>` within the Archive month `<select>`:
- because the `option`s are in a tree, the tool was adapted to take all
`option`s into consideration instead of only the direct children of the
`select`.
- because the `option` text is dynamically created from the date of the
test execution, the tool was adapted to allow targeting an `option`
based on its index by specifying the tour step's `run` as
`'text index N'`, `N` being the index of the `option`.
Steps to reproduce:
- Enable the sidebar of the `/blog` page.
- Select a month in the sidebar.
- Type something in the search box.
=> Did show an error popup while obtaining the autocompletion records.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-3213916
closesodoo/odoo#114913
X-original-commit: 115fc399461c37b57127684cf5c28f05443fbb54
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This reviews [1] which solved the problem in most cases (hopefully) but
not in all cases. Animated elements which overflow the screen on the
right made an horizontal scrollbar appear on iPhone <= 8 using Safari,
even when they were not animating yet.
This was due to Safari ignoring the `transform: none` rule on inactive
elements, preferring to consider the animation transform. As a fix, we
forced no possible overflow of the page when we saw this safari bug on
the first animated element.
The problem here... is that this Safari bug does not occur in every
situation. For example, if the animated element is inside a column which
is marked as hidden in mobile, Safari actually understands the no
transform rule. So if the first animated element was in such a situation
but another element in the page had the safari bug... the problem was
there again.
As a fix, we now check all animated elements for the Safari bug, instead
of only the first one. That should do the trick.
This commit also reviews the comment: the problem is not confined to
old iPhones. This was reproduced on the latest iPhone with latest iOS
and up-to-date Safari.
opw-3204613
opw-3201937
Related to opw-3165651
[1]: https://github.com/odoo/odoo/commit/c1447835786e04f342342540c09e46d1226d5fc0closesodoo/odoo#114999
X-original-commit: 8fe2d91e05e85ae2e50f1066214d0af5796e5296
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When using the 'toggleDeviceVisibility' option, we can see that there is
a mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> at 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding/showing an
element in the mobile/desktop view (for example, if it does not look
good in one of them) has no effect until the screen reaches 768px.
This commit increases the screen breakpoint at which the 'toggleDevice-
Visibility' option is applied, that is, at 992px instead of 768px, in
order to be consistent with the display.
task-3110770
closesodoo/odoo#114977
X-original-commit: b062b280fdadcde857fff4f7a57876da50542cb3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
This commit will rename the font "Muli" to "Mulish" as it has been
renamed in Google Fonts.
closesodoo/odoo#114932
X-original-commit: c24602e882f87c361866a739459a9d6e3f4fc6ef
Related: odoo/design-themes#638
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, if the window was big enough to not be in mobile,
it could still be small enough so that the menu items overlap with the
systray item when the website client action was first mounted.
Steps to reproduce:
- Choose a language with long words (such as Slovak) or translate one of
website app menu terms to a word with more than 12 characters
- With the browser's dev tools set screen size to be responsive with a
resolution of 847 x 867
- Start odoo and go in the website app
- The menu items overlap with the systray items
This commit fixes that by not only re-rendering the navbar when the
website content is properly loaded (which was already done before) but
also by adapting it afterwards. However, to do so it copies the code
already present in the "web" navbar.
task-2687506
closesodoo/odoo#114869
X-original-commit: 690f420ceae799ed991f49afa405c917b3c101d2
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
There is a weird deeper low level misbehavior which makes concurent
click to not acts as they should.
Depending on the runbot/tour speed, the misbehavior might kick in and
makes the tour fail.
When you click on multiple options very quick back to back, their click
will be registered and processed one by one, waiting for the previous
one before considering the next one.
You can see that by simply printing a console log in both
`renderListItems` and `_computeWidgetState` method from `s_social_media`
`options.js` file. Then click quickly on the options related to this
snippet like the active toggle and/or remove custom media.
Despite respecting the click order and not overlapping, some click
results (like hidding or removing) will be rollbacked visually and only
the latest click result (starting from the DOM state before the first
click) will be applied.
Long story short: spam click on every toggle option of all the social
media, you will see that all your click will be processed one by one:
- The first media you toggled off will be toggled off
- Then the second media you toggled off will be toggled off but the
first one will be back to toggle on.
It seems to be correctly applying the click result one after the other,
but always starting from the initial DOM state/option widget state
(before the clicks), and not as it should: process the second click
based on the state of things altered by the previous click.
This will need a deeper and longer investigation to fix the root cause.
In the meantime, as this tour is failing multiple times a day, this
commit introduce a workaround to avoid this error in the tour.
task-3212519 (later fix)
runbot-16628
closesodoo/odoo#114600
X-original-commit: e9bd67672ea0517771998ec56f155709cd7c310e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes two bugs with the table of content snippet:
- Before this commit, the scrollspy position for the table of content
navbar was incorrect in fullscreen or edit mode due to the calculation
being based on the presence of the main navbar, which is not present in
those modes.
- Before this commit, when the table of content navbar contained enough
elements to exceed the height of the page, the bottom elements were not
accessible without first scrolling through the entire table of content.
This commit addresses this issue by adding a scrollbar to the navbar,
allowing for easier access to these links.
opw-3115597
closesodoo/odoo#114569
X-original-commit: e5d826e03be1fe8c617ef9a8bb8169ad196657fd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this commit], it's possible to change the connectors style in
edit mode, unfortunately the code to determine if the connectors should
be visible or not was not compatible with small width screens. As a
result, when a user edited his site on a small screen, he saved hidden
connectors even for visitors with larger screens (while the connectors
should be visible). This commit allows the user to manage the connectors
correctly without taking into account the screen size at the time of
editing.
Steps to reproduce the fixed bug:
- Drop a steps block.
- Reduce your screen width to < 992px or Switch to mobile view from 16.0
- Activate an option of the block.
- Save.
=> The connectors are not visible anymore in desktop view/large screens.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-2687506
closesodoo/odoo#114447
X-original-commit: https://github.com/odoo/odoo/commit/6f507a315a64529627c8805d5947ffe4a7f6f509
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.
The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.
Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.
opw-3133464
closesodoo/odoo#114472
X-original-commit: 6ae5d73332d5413495cc25e28cba86f8be18b570
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the height of the Image Gallery snippet was set to
auto on screens smaller than 400px.
This ensures that the snippet looks the best on phones.
However, when using Bootstrap, what defines a smaller screen is not
any screen below 400px, but any screen below 768px.
This meant that the Image Gallery snippet did not look the same on an
iPhone 11 Pro max as it would on an iPhone 11 for example.
This commit fixes that by using the built-in mixin that relies on
Bootstrap's breakpoints (in this case MD).
Steps to reproduce:
- Go in edit mode and drop an "Image Gallery" snippet
- Open the dev tools and choose "iPhone 11" or 375x812
- The image gallery does not have white bands
- Change the resolution to "iPhone 11 Pro Max" or 414x896
- The image gallery has white bands / has a different layout
opw-2995100
task-2997119
closesodoo/odoo#114319
X-original-commit: 94a1a8535b9bd9590ff5212e1d15653a6a6ccdb7
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
To reproduce the issue:
- Website (edit mode) > Drop a snippet with icons (e.g. "Steps").
- Open mediaDialog to change an icon.
- Select the same one (or click immediately on "ADD") > This will set an
empty icon (without any "fa" specific class).
The code on `MediaDialog` > `save()` adds CSS classes from the original
icon to the new created one then removes the old 'fa' classes from it.
(see `initialIconClasses`), as a consequence, the class will be deleted
(not replaced) when the selected icon is the same as the old one.
The goal of this commit is to fix this behaviour by simply closing the
dialog if the selected icon remains the same as the old one.
task-3210472
closesodoo/odoo#114345
X-original-commit: 0515e987b985622bc7b913dbbb37c0d0cd69eb4b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
From BS4 to BS5, the `form-control-file` class has disappeared and
became `form-control`.
This commit replaces the occurrences of the old class by the new one.
It is necessary because by letting the old class, it is impossible to
place a form label above a `File Upload` field.
Indeed, since the `.form-control-file` CSS rule setting the `display`
property to `block` has been removed, the file input now has `display:
inline-block` by default, which is why the label would end up on the
same line as the input, instead of on top. With `.from-control`, this
rule is back, allowing to place the label on top again.
After this commit, the look of the file input will change. This is
because in BS4, with the `form-control-file` class, the input was the
browser native one. It could be customized using `.custom-file` (and
the associated `custom-file-*` classes). But in BS5, the file input is
directly a custom one, thanks to custom styles added on top of `.form-
control`.
task-3071151
closesodoo/odoo#114261
X-original-commit: 7dcfe19c15bd96d65e5fda463ad65d083c6b8fcf
Related: odoo/enterprise#37744
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit, on iPhone 8 (and lower) it was possible to scroll
the page to the right when there were animated elements in the page.
A "transform: none" property was applied to non-visible animated
elements to prevent the page from expanding to the right. However, this
property wasn't properly overriding keyframe transforms on iPhone 8 and
lower. This has been resolved by adding "overflow-x: hidden" on the
wrapwrap in case "transform: none" is not applied correctly.
Steps to reproduce the issue:
- On iPhone 8 (Safari).
- Drop a few snippets into a page.
- Add a "Fade In-Right" animation to a column of a snippet.
- Scrolls the page so that the animated element is invisible.
- Bug => a horizontal scrollbar appears and it is possible to scroll the
page to the right.
opw-3165651
closesodoo/odoo#114207
X-original-commit: 1354d337eba26f48699d9eb9bc02287383fc10e5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This reviews [1] (in particular changing my mind about [2] upon further
review). Indeed this was marking potential non editable tab panes as
editable by searching the whole DOM instead of editable savable zones.
In the end, what is searched for is also reviewed. Instead of searching
for a very specific structure, we now mark all oe_structure which are
direct children of tab-pane as editable (if in an editable zone) and
their parent (the tab-pane who have a direct oe_structure child) as
readonly.
[1]: https://github.com/odoo/odoo/commit/5fd99855654d220bafb8887cd0ae267042836d4b
[2]: https://github.com/odoo/odoo/pull/109430#discussion_r1115792052closesodoo/odoo#114069
X-original-commit: d5d646281f1de672cff0e03903b88059ac17be18
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when only website is installed, dropping a dynamic snippet
produces an error because no dynamic filter is defined and it tries to
specify one selected by default.
This commit avoids setting a default filter when there is none.
It did work in 15.0 because the log was inside
`_renderDynamicFiltersSelector` which contained an
`if (dynamicFilters.length > 0)` that avoided the problem.
In [2], when most of that logic was moved from the render method to the
fetch method, that condition was lost.
Steps to reproduce:
- Install website only
- Go to debug mode
- Drop a "Dynamic Snippet" or a "Dynamic Carousel"
=> Traceback appears because there cannot be a default filter when there
is no filter.
[1]: https://github.com/odoo/odoo/commit/3355dc16235355fe51e894f14e275210464608c6
[2]: https://github.com/odoo/odoo/commit/9e0b398fe608e716835260c5f9923f933d723f8e
opw-3166634
closesodoo/odoo#114068
X-original-commit: 8e23f08b1470ec5fe47a4459c4d3a8ad314c43b0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, we-matrix could create a horizontal scroll bar in
the editor. This was because the inputs had a minimum width size.
Steps to reproduce the bug:
- Drop a chart block on a page
- Add some series
=> The matrix overflows from the editor.
There is no perfect solution to this problem... We have the choice
between:
1) Leave the existing overflow on the editor.
2) Put a horizontal scroll on the we-matrix.
3) Distribute the available space between the columns.
As we don't want a horizontal scrollbar, the best solution is to
distribute the available space between the columns. This solution has a
drawback which is that the cells can become really small if there are a
lot of columns but this solution seems to be the least bad from a UX
point of view.
task-3094162
closesodoo/odoo#114062
X-original-commit: 356e0a1fe5243078ba5f162b383279ae7e6a8136
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
To reproduce the issue:
- Go to website > In a website page with content menu (Event,...).
- Edit mode > Click on a menu item > Click on the "Edit Menu" on the
displayed link popover.
- A dialog to edit the menu appears, but this time it targets the main
website menu instead of the currently edited one.
Starting from [1], an OWL component `EditMenuDialog` is used to edit
website menus. It gets the targeted menu as a `rootID` prop value and
fallbacks to the current website main menu if this value is not
provided.
The goal of this commit is to target the right content menu by providing
the corresponding `rootID` value.
Remark: before [1], a different code was used to open the "Edit Menu"
dialogs and it was based on sending a `beforeReloadCallback` to the
`edit_menu` action (to save page updates once the menu edition is saved,
before finally reloading the page). Now, this callback is sent as a
`save` prop value to `EditMenuDialog`, which means the old callback is a
dead code => removed in this commit too.
[1]: https://github.com/odoo/odoo/commit/2c77b90eee4945d25e9d7f0ffe24484cf91b650a
task-3172234
closesodoo/odoo#113995
X-original-commit: 15deee2424434e9f520a8651b771627704a784a5
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit doesn't introduce any functional change but allows to manage
header and footer visibility with the already existing data-invisible
system. This simplifies the code and avoids doing an RPC at the start of
the `VisibilityPageOptionUpdate` option.
Related to opw-2971181
closesodoo/odoo#107387
X-original-commit: 07fdbc8847d254498b908a1cde0d910a77666f25
Related: odoo/upgrade#4120
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when a popup was created and the user wanted to have
this popup on all the pages of his site, the popup was moved to the
footer. Unfortunately, this caused a lot of problems:
1) We had to disable the effects on the footer when the popup opened, so
that the popup would not block the page when the footer had a slideout
effect (see original commit).
2) The popup shared on all pages was attached to a footer template so
that if after setting the popup, the user changed the footer template,
he lost his popup.
3) Putting the popup in the footer led to an important limitation which
is that it was impossible to have a popup shared on all pages on a page
where the footer is voluntarily hidden (via the page visibility option).
This commit fixes all these problems by adding a shared section
dedicated to the shared popup on all pages.
Related to opw-2971181
X-original-commit: 0f131160097deb0693d7bdb4adc43fd69ea49c09
Part-of: odoo/odoo#107387
Since [1] when BS5 was introduced, the keyboard navigation of search
autocomplete suggestions did not work anymore.
This commit avoids relying on bootstrap and JQuery to navigate the
suggestions.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-3148871
closesodoo/odoo#112733
X-original-commit: be549b7b64a253149d55b7f73f1d1a25a29388f9
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, in some instances when editing text in a popup, the
popup would close.
The issue was introduced by this commit [1]. A 'd-none' class is since
added on the 's_popup' section when the modal closes but when the widget
starts with the modal already open (e.g. during a widget refresh), the
'd-none' class is not removed from the section.
Steps to reproduce:
- Edit a page.
- Drop a popup.
- Select a word or a sentence and delete it or press "Enter" to
create a new paragraph.
- Bug => the popup closes.
[1]: https://github.com/odoo/odoo/commit/cfd53b8fae3ad9f677df49a03fe6d2945dbb5da2
task-3102275
closesodoo/odoo#113746
X-original-commit: fb2495d3b87223be65f98583056a070439a7df7e
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a trigger in the table of content test to make sure the
edit mode is ready before clicking on the first TOC block. This is
necessary because the test often failed on the runbot.
task-3203031
runbot-17505
closesodoo/odoo#113668
X-original-commit: 4775cfc38ed4e601c9ab6ae88c39c77299a50636
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
When selecting the content of a tab with Chrome, if the selection
reaches the end of the tab content and there is additional content after
the Tabs snippet, the selected range also includes the next inactive
tabs that are hidden. Because of this, when replacing that selection,
the next inactive tabs are removed, and the Tabs snippet is corrupted.
This commit avoids this by including the `.tab-pane`s in the read-only
areas while including its `.oe_structure` in the content-editable areas.
This makes the selection adjustment mechanism stop within the active
tab pane.
Steps to reproduce:
- Use Chrome.
- Drop two Tabs blocks inside a web page.
- Select the first tab of the first one.
- Select the last word, including the dot. (Double-click the word and
drag beyond the dot before releasing the mouse button.)
- Change the selected text's color.
=> The content of the second and third tab also had the chosen color.
- Select the text in the first tab with a triple click.
- Type something to replace the text.
=> The content of the second and third tab were removed and clicking
on the tab's header did therefore not reach them anymore.
opw-3117305
closesodoo/odoo#113624
X-original-commit: fd57dae13179c286da99749e77a3b26efd2f73f2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce the bug:
- On the website application, add an image gallery snippet.
- Change the "Speed" parameter.
- Save.
-> Nothing happens: The displayed image is always the first one and
there is no cycle between the images of the snippet.
Since Bootstrap 5, the amount of time to delay between automatically
cycling to the next item is defined by `data-bs-interval`. The bug
comes from the fact that some parts of the code still used the old
parameter name (`data-interval`).
opw-3165570
closesodoo/odoo#113423
X-original-commit: 8368fa1f5e45a14ed8938017b2da90a810dbf0c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this commit], it is possible to have a block only displayed on
mobile screens. This feature can break the steps snippet by following
these steps:
- Drop a steps snippet in a page
- Set the third step to be visible only on mobile
=> The connectors are broken.
This commit fixes this issue by only considering steps that are visible
in desktop view for connectors drawing.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
closesodoo/odoo#113184
X-original-commit: d8521d197518e90d63443d1095b2df84487ad4ae
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From [this commit], it is possible to define the visibility of blocks
according to the device on which the page is displayed (either hide on
mobile, or hide on desktop). This change has brought two problems on the
table of content block:
1. The sub-component s_table_of_content_main (the right part) can be
invisible, which does not make sense.
2. The sub-component of s_table_of_content_main can be invisible but it
did not change the navbar of the TOC.
This commit prevents hiding the main part of the TOC and rebuilds the
navbar of the TOC according to the device visibility of its
sub-components.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
X-original-commit: b7f9c26a93e58f2ace964ab6b05132cc9f8f3366
Part-of: odoo/odoo#113184
By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view
=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).
The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).
[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3116227
opw-3135927
X-original-commit: f2b86dda77133ed9c4f02394693e771758d18bad
Part-of: odoo/odoo#113184
The first objective of this commit is to polish the website
configurator:
1) On page 1 of it: - The size of the text is increased.
2) On page 2 of it: - The font size inside dropdown is reduced.
- 30 results are displayed inside dropdown instead
of 15.
3) On page 3 of it: - The size of the text is increased.
3) On page 4: - The cards are refactored.
- The end line is removed.
- The "Build my website" button is moved to the left.
4) On page 5 : - It is now impossible for the user to click on a theme
preview before it is completely loaded.
5) On all pages, the size of the "Skip and start from scratch" button
has been increased.
On the second page of the website configurator, the user has to choose
an industry type. Sometimes, it happens that the user is searching for
an industry that is not known by the server. Before this commit, a
message of type "No result found" appeared and the user had to choose
an other industry among the existing ones. From this commit, the
"No result found" message is replaced by the name of the industry that
the user is writing. To choose its industry type, the user can click on
the displayed industry name or outside of the input area. This last
option calls the `_blurIndustrySelection` function and the written
industry is kept as the final industry choice. If the user chooses an
industry name that is not known by the server then the remaining of the
website configuration is done with the "abbey" industry. Moreover, this
unknown industry name as well as the language used by the user is sent
and stored to the IAP database. The goal of it is to regularly update
the industry list so that it becomes as most complete as possible.
IAP PR : https://github.com/odoo/iap-apps/pull/549
task-3062171
closesodoo/odoo#110187
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Benjamin Vray