Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.
Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
select a theme.
- Redirect is with enable_editor but nothing happens.
The editor isn't started if not in the source's lang.
This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.
[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
task-2687416
closesodoo/odoo#85058
X-original-commit: 02e08af7278cd66d768fe6a4f23aa17eb816be3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.
Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
"Pages and Features"
With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.
[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
task-2687416
closesodoo/odoo#84810
X-original-commit: a0f8fdc65566fafe98dab21f5c2dbab9505c3d5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, during edit mode, the user was able to interact with
form elements. In 13.0, it was somehow prevented by some JS code by
losing the focus immediatly but it was not enough: if typing quickly the
user was able to type text. But the real problem was the user seeing the
input focused for half a second then not anymore, making him think a bug
occured. Worse, the datepickers of the form snippet were able to be used
entirely during edit mode, making the user think it is possible to
configure a default value (which was not true in 13.0). In following
versions, the bug is indeed worse as it messes up with the default
values configuration. In 14.0, it is apparently possible to type
normally in all of those inputs... although still ignored on save. In
15.0... the 13.0 behavior of losing the focus immediatly is back though.
This commit fixes that via CSS, still allowing a click on the elements
to be considered as a click on the parent, but preventing to focus our
snippet inputs (this fix is limited to our own snippets as stable fix).
Note: the 13.0/15.0 JS code which prevents the focus right now was not
found (if it even exists...) but it would not be ok to remove it in
stable anyway. More investigation and review will be done once this
reaches master.
task-2523496
closesodoo/odoo#84717
X-original-commit: ab9fbfb43365fcd39cc782f94b74911155e3f73e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit ensures that changes are applied in the same order as the
events are triggered on the we-matrix. This was not the case because of
another bug we had to consider and which is not there anymore, this is
why this fix is done in 15.0 and not before.
This commit is the continuation of [1] which applied the same change for
we-input.
[1]: https://github.com/odoo/odoo/commit/db62a5fac123fc72e37e94709b1a0c80f32a8a29
task-2761187
closesodoo/odoo#84486
X-original-commit: 703e1ec69c2cbdbdbafeef9ac359db9f0f3b7021
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Before this commit, on Chrome browser, the page url input and the
visiblity password input were autocompleted with the user's login and
password in the page properties options.
After this commit, they are no longer.
Regarding the url input page, it seems to be because Chrome considers
that the first text input located before a password input in the DOM is
a login input.
task-2502747
closesodoo/odoo#84393
X-original-commit: 7f45822919f8ef5f070a40a4dd41d22757a9da76
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the framework's navbar uses the hamburger_menu in community too,
the `navbar_mobile.scss` code initially shared between frontend and
backend is now needed for the frontend only.
This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Prior to this commit the topbar responsiveness was exclusive to
enterprise.
This commit moves to community the mobile logic for navbar, burgermenu,
user_menu and company_switcher.
The design has been adapted to v16, reviewing font size/colors and
icons. This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Before this commit the target of options and nested options tour steps
could be hidden under an opened palette.
After this commit the tips of options and nested options tour steps
require that no palette is opened.
An 'allowPalette' parameter can be used to remove this condition, for
example if 'changeOption' is used to select an option within the
palette during a test tour.
A step is added to close the color palette - which, while opened,
prevents the next `changeOption` step from being activated.
task-2728994 (was task-2675252)
closesodoo/odoo#84093
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With commit [1] (and the parent commit here which reviews it), we
move the scrollbar to the modal instead of the website content if the
modal has scrollable content even in the case there is no backdrop. An
exemple would be the cookie bar, configured in popup mode, with a tall
content inside.
This was however not enough: the computation which determines if the
modal should be scrollable or not was not re-done after an image was
loaded. So if the popup was around the height of the window, it could be
smaller than the window's height before images loading and taller after
which would result in having the scrollbar on the body instead of the
scrollable popup.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6closesodoo/odoo#84139
X-original-commit: b83b465dd98345afeca3844a4796e4a83d15f72b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Commit [1] was not coded defensively enough: after it, dialogs not using
a proper bootstrap structure triggered a traceback once they were opened
(this was discovered on odoo.com where such unconventional dialogs do
exist). Bad luck: there was actually a check to allow unconventional
dialogs but it was not done at the right location.
However, fixing this, it was found that more than this was not ok. There
is actually no need to consider the modal-content element at all. Just
using our `hasScrollableContent` method is enough and requires no extra
search in the DOM. This actually also properly computes if the modal
overflows or not while it was not the case before as it did not consider
the modal-dialog element's paddings.
Finally, the whole customized behavior of the modal scrollbar here was
only designed to affect our Odoo modals with the s_popup_no_backdrop
class (see original commit [2]). Indeed, only in that case we want to be
able to switch between body scrolling and modal scrolling while the
modal is opened. In custom cases and other Odoo cases, we want the
standard Boostrap behavior of only being able to interact with the modal
while opened. This commit cleans the code to restore that spirit
(hopefully this does not cause stability issues as [1] was introduced
only a week ago). Sorry for any inconvenience.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6
[2]: https://github.com/odoo/odoo/commit/e5a5f98819b3a70b3e2564fb91722cab415ceea9
X-original-commit: a2363337355ccf4363249657000cd85bfcb3ab4e
Part-of: odoo/odoo#84139
Since [1] when web was migrated to OWL, the cookies bar was considered
as a parent modal of any openend modal that got closed - thus preventing
scrolling the full page.
After this commit the cookies bar in the front end is not considered as
a remaining modal anymore, and therefore does not prevent scrolling on
the currently displayed website page.
[1]: https://github.com/odoo/odoo/commit/29731b404fe624b733d784cd4321113d6b0d27b7
task-2741894
closesodoo/odoo#84128
X-original-commit: c1aab97e6b4e8b916c7d79db5f278c746fd6b119
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit the phone fields inside forms did start in a blank
state.
After this commit the empty phone fields are pre-filled with "+" and the
country phone code.
The country is determined based on the IP address with the GeoIP
database. The phone code is obtained from `res.country` where it is
kept in cache.
task-2463563
closesodoo/odoo#78068
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
When selecting the text content of a link
the underline and italic commands were not working in Firefox.
We re-implement the Browser command to fix this.
task-2667950
X-original-commit: 52a5b2bb692ab6712d497492f4f2fbef3a9a7874
Part-of: odoo/odoo#83895
When a user clicks on 'could be used in' in the page properties after
chaing the URL, a list is displayed in a popup. This popup was
not properly rendered:
- the content could not be scrolled through, it was thus truncated
- the popup appeared behind the technical modal that kicks in on small
screens
Now the popup is better positioned, a scrollbar is available to access
its content when it is too long and on small screens it is displayed on
top of the technical modal, making it visible on small screens.
task-2092269
closesodoo/odoo#83693
X-original-commit: e2f1f4967a2dd4d730895e924f0c7ca02e23a17b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Jitendra Prajapati <jpr@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
*: web_editor
Steps to reproduce:
- Activate the cookie dialog from the website settings
- Remove the backdrop from the cookie dialog
- Add some blocks to the cookie dialog in the website editor
until the dialog height is bigger than the page height.
Result:
The cookie dialog is not scrollable, so it's impossible to reach
the "I agree" button and close the dialog, leaving the user stuck
at the first page.
I check if the popup content is higher than the window. If it is, I
give priority to the popup scroll over the page one. I had to
overwrite the _showElement method to call _setScrollbar after
the content rendering, in this way I can get its correct height.
I also try to update the scrollbar each time a block in the cookie bar
has been changed and each time the window resize. This is optimize, so
if the overflow isn't changed from the last time I tried to update the
scrollbar no action will be taken. In this way you can always see the
whole popup without refreshing the page.
Also I have to set 'pointer-events' to none only if the popup is
smaller than the page itself (to interact with and scroll the
page behind), otherwise the popup won't be scrollable. I did
this by adding a class "s_popup_overflow_page" if the popup is
higher than the page and I adapted the pointer-events
property accordingly.
opw-2660786
closesodoo/odoo#83691
X-original-commit: 022a4486a99d855a3c6e2cef326bb3b0c5e66db9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the step about the slider to adjust the padding was
only consumed on click, which does not happen if the slider is used in a
drag'n'drop operation as expected.
After this commit this step is consumed on mousedown so that the
drag'n'drop operation is also taken into account.
task-2728994 (was task-2675252)
closesodoo/odoo#83692
X-original-commit: 42ce224fbe97f8d99ca5feec6d271412ce0647e1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
Since [1] when web's owl services were made available to the frontend,
the navigation mixin does conflict with the hotkey service.
E.g.: navigation mixin consumes the 'alt' keyup event, which prevents
the hotkey service from cleaning up the hotkey overlay.
After this commit the old mixin is neutralized and hotkeys in website's
pseudo-backend layer are handled by the general hotkey service.
Also since [2] the menu items are inside `<div>` instead of `<li>`,
adapted the scss to take this into account.
Also added a CSS rule to neutralize the outline on website's menu
dropdowns which are `<a>` instead of the already handled `<button>` in
web.
[1]: https://github.com/odoo/odoo/commit/db7b485d984e50fae5a52308634166460e5fc908
[2]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-2738578
closesodoo/odoo#83529
X-original-commit: 88438fa9b363530aa4e5dec5599c1568fb7ccea0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when we selected a variant of a product and then
clicked on a share button, the changed variants attributes in the shared
URL were not considered.
This commit also takes the opportunity to convert the whole file to new
Odoo modules and stopped using jQuery. The code actually had to be
refreshed following the merge of [1] so it was a good occasion to do it.
[1]: https://github.com/odoo/odoo/commit/8f7c6997e8ab381563a9fa8d06feef4e89fff4aa
task-2122733
closesodoo/odoo#83503
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In order to anticipate an anomaly in the network to prevent
a save, wait for an rpc to finish.
task-2742008
closesodoo/odoo#83103
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When Jabberwock was introduced in [1], forms were not selected anymore
by clicking on the form fields.
That behavior got fixed when Jabberwock was removed in [2] but this
commit introducing a test about it was not attached to a task - and did
not get merged at the time.
Before this commit there was no test to verify if the form became
selected when clicking on one of its input field or textarea.
After this commit there is a test that makes sure that the form is
selected when the user clicks on either an input field or a textarea.
Also added the renaming of a field label followed by a blur to ensure
it triggers all UI events.
[1] https://github.com/odoo/odoo/commit/347f4413d1b1a2b1a6a9ecd6d9c20cf7f3ec5ff3
[2] https://github.com/odoo/odoo/commit/e5572c317a7775a58675ed73efc89b5c9f6c0c39
task-2729643
closesodoo/odoo#83379
X-original-commit: fe4000cd521b5e1426b9093f7671fa457ef45eb8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, since [1], when the cookies bar is opened, the pages'
animations would not work at all.
Animated images would not even be shown, remaining invisible.
This is because the s_popup when not using the layout 'popup' is still using
the modal/popup snippet structure but is not really a modal anymore.
As BS provide a built-in way to know if there is an open modal, which works
well with the cookies bar, use it instead.
[1]: https://github.com/odoo/design-themes/commit/e025296ccf5b8d8ea19bd354d9fbd52a12fc4d94
opw-2712755 (detected during migration)
closesodoo/odoo#83291
X-original-commit: 48bb9efee99d3bee2b4b60eec0f59ed2cb13a096
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit introduces a new social_media snippet that allows social
networks to be displayed. This snippet shares the same options as the
share snippet, but also provides a list to edit the URLs of the social
networks in the company data (social_facebook, ...). This list also
allows to manage links to custom social networks (which are not stored
in the DB).
Headers and footers now use this new social_media snippet instead of the
share snippet and in the settings, the urls to the DB social networks
are editable/visible only in developer mode.
task-2687447
closesodoo/odoo#80217
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
This commits introduces new behaviors on the we-list:
1. Possibility to add a placeholder on inputs
2. Possibility to make elements non deletable
3. Possibility to make element activated/toggled by default
4. Possibility to generate ID for new elements
task-2687447
Part-of: odoo/odoo#80217
This restores a (basic) feature that was lost in 15.0 by mistake.
Allow the user to set a link on an image. The user can access this link
tool in the editor panel or via the CTRL+K shortcut. This tool is very
similar to the existing link tool for texts. This tool uses the
suggestion system already existing on the text link tool.
task-2666467
closesodoo/odoo#82512
X-original-commit: bfcd25c5d66765b7436114dba3316ac7331a4d97
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
A mega-tour was introduced with [1] to test every single snippet.
This tour, despite being very useful as it tests the core behavior of the
website builder, is creating a lot of race conditions.
This commit should prevent one of those race condition:
When the step was removing the snippet, it was then clicking on the "Blocks"
tab to get ready to drag and drop the next snippet.
The issue was that in some cases, it would click on the "Blocks" tab before the
snippet removal process was fully done.
Basically, when the race condition happened, it was the same as doing:
```
$('we-button.oe_snippet_remove:first').click();
$('.o_we_add_snippet_btn').click();
```
which, when done in the browser console, will result in the same visual than
the screenshots on the failing runbot builds.
[1]: https://github.com/odoo/odoo/commit/460d5ecb926c13a79ba363f8f86442433d91bf6f
task-2726529
closesodoo/odoo#82214
X-original-commit: 49c7bd39826b428430c08c5faedca51dde9e2359
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Install `website_hr_recruiment` module
- Go to `your_website.com/jobs`
- Activate Edit mode and add a "3 Columns" block
- Select one of the columns and set the shadow to `None`
Issue:
Shadow is not removed, and by default the "outset" mode is selected.
Cause:
When we check the state of the shadow with `css('box-shadow')`, it
will always be set because a custom css 'box-shadow' is set by the
module website_hr_recruitment on card element, and therefore the value
will always be either 'inset' or 'outset'.
Solution:
If widget value is set to '', replace `box-shadow` style to 'none'
(only if needed) so it will override the style from css file.
opw-2701512
X-original-commit: 212d8ec10bb48e8fd7de3d3ff7660447b968c62a
Part-of: odoo/odoo#81980
Co-authored-by: qsm-odoo <qsm@odoo.com>
This PR allows the user to put a transparency effect on the mega menu.
The transparency effect did not work on the mega menu because
the container that contains the mega menu did not have transparency.
Note that the mega menu templates use a default background color
since [1] to not be transparent by default because of this commit.
[1]: 967d21a
task-2623335
closesodoo/odoo#77871
Related: odoo/upgrade#2929
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the "ripple effect" no longer worked because the
assets were never activated for the following reason:
- To activate the ripple effect assets via the editor options, we
activated a template that no longer exists (with
data-customize-website-views). Instead of activating the assets with the
new system of assets using records.
After this commit, a new "data-customize-website-assets" xml attribute
was created so that the assets can enable/disable in the same way as the
views. The "write" method for ir.asset has also been overridden in
website so that each website has its specific assets (via COW).
task-2686370
closesodoo/odoo#81833
X-original-commit: 9f56357cc1f4a7b8606ef4d5fd431fc396bdf1e8
Related: odoo/design-themes#546
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the cover dataset was only updated during updateUI()
but if the cover was saved before closing the color palette after
selecting a solid color, the selected color was not confirmed and the
saved cover dataset was based on the previously selected color.
After this commit the cover dataset is updated whenever an option is
selected to handle the specific "save before close color palette" case.
task-2678100
closesodoo/odoo#81835
X-original-commit: ad59cbd33e0eaf5c7c77f9e5c0b0435917e2c155
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Commit [1] did adapt the selection of savable to include cover
properties detected through `[data-name="Cover"]`, but [2] did rename
the blog cover option block from `Cover` to `Blog Post Cover` therefore
it did not get detected. Because of this, only changing attributes on
the root element of the blog post cover was not marking it dirty, and
therefore not saving it unless other changes also happened (e.g. change
the picture)
Given that the name might even be translated, this commit does not use
the value of `data-name` anymore but relies on either the `s_cover` or
the `o_record_cover_container` class.
[1] https://github.com/odoo/odoo/commit/fc67a3370ab04facff28dd956590e4dfa71f8441
[2] https://github.com/odoo/odoo/commit/27e4f8a3e164cad6814cc8d77e4f46515eab5fb4
task-2678100
X-original-commit: 1a37f57e5cbc9a5557efe3ae281790fadc6498ff
Part-of: odoo/odoo#81835
Before this commit, the ripple effect did not work when a button was not
in the same location/size when clicked compared to its position/size
when the page was loaded. (e.g. after scrolling the page)
task-2686370
closesodoo/odoo#81756
X-original-commit: 95728886ef3abd4e5809a5749c803c312b9267b8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, in some cases the submit button of the form snippet
never stopped loading after being clicked (e.g. redirect to an anchor in
the same page).
Now, the form and the button loading effect are reset at the same time
at the appropriate time depending on the post-send action:
- Redirect to another page: never (we leave the form values and the
button loading effect for the whole redirection duration)
- Redirect to an anchor on the same page: after the scroll animation
- Show a custom HTML message: never (this type of post-send action is
meant to hide the form after that message is shown, there is no need
to restore it to its initial state)
- "Nothing" (= small message next to send button): once the data is sent
In the last two cases, a 400ms delay was also added before showing the
message so that the send flickers less and seems more smooth. In the
last case, it also prevents to double click and double send the form.
Related to task-2172312
closesodoo/odoo#81703
X-original-commit: 42f6887bb4406d4aa636040c8325e8ecab202778
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when the redirection of a form was an anchor and
that anchor link came from the anchor option, the scroll animation was
not triggered.
task-2172312
closesodoo/odoo#81622
X-original-commit: 5db838cfc91d8438d6234df00bd8174768445974
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the color presets generated by the color palette
would always be visible by the user which could lead to confusion.
Most users would click on the presets and edit them instead of editing
the color palette.
This commit groups the presets into a collapsed section under the color
palette to incentivize the user to click on the color bubbles instead.
task-2687469
closesodoo/odoo#79921
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When inserting a new paragraph by pressing 'enter', it would
automatically close the mega menu.
As inserting a new paragraph triggers a historyRevert at the editor
level, it was leading to two issues:
- The widgets of the public root were stopped then restarted. The
StandardAffixedHeader (the public widget for the header), as an
Animation, would start its effects when started, which would close its
dropdowns. This commit changes the _updateHeaderOnScroll method to close
opened menus and dropdowns only when the animation has scrolled.
- Opening the dropdown was a recorded step. When history was reverted,
it would close it. Now toggling the mega menu is done with the editor
observer unactive.
task-2668908
closesodoo/odoo#81559
X-original-commit: 675430d53f6ef048b77afe95395bd760d3f5a2be
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
[1] changed the structure to adapt it to the new dropdown menus. This
commit changes the css according to these changes so that mega menus are
correctly displayed inside the extra menu items dropdown from the auto
hide menu.
[1]: 29b9280c44534d2f210dbcea83e0049365949f48
task-2668908
X-original-commit: fdd06d70fa78098cbfe0bd5200acd2fa171f4576
Part-of: odoo/odoo#81559
This commit adds the possibility to modify some background colors of the
mega menus so that the templates are fully editable.
Some of these templates have a column with an extended background, using
the :before css pseudo element.
As this is not a DOM element, it cannot be changed from javascript.
It was decided that using shapes would not produce the same effect as
the designer intended, and that it would be too confusing for the user
to be provided with an option allowing to extend the background of a
column.
Therefore, these specific s_mega_menu_gray_area elements must have their
background hardcoded.
task-2668908
X-original-commit: f01c74118ad4c772fb18866956ab9fb214f781fa
Part-of: odoo/odoo#81559
Co-authored-by: qsm-odoo <qsm@odoo.com>
Arthur Detroux (ard)