Changed the triggering of some events to dispatch native events instead of
jQuery ones and extended the api of the keydown helper to support text keys.
After the rainbowMan issue was fixed here: e5bc2e7, steps were consumed
on 'click' events. This caused an issue with the drag and drop event
(which breaks tour, because it is expecting a click event). If the user
dragged an element, thetip was not getting consumed as no click event
was triggered.
closesodoo/odoo#40819
X-original-commit: 3f458fe06e6a629edc72428eab749068c2eba1ba
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
In certain case, a non blocking traceback pops-up.
It happens when the page loads, if the dom is modified
before the tour has been fully loaded.
Theorical steps to reproduce:
- Open a page with an active tour
- Trigger any domain change before the tip-dot is loaded
On every change in the DOM, the MutationObserver tries
to update the page. If the tip-dot has not been loaded yet,
it will try to update the position of a non-existing element.
In that case, we simply ignore it. The update will be called
anyway when the tip-dot has finished his loading.
opws:
1923348
1965964
2011027
2008708
2001867
2000228
1998906
1972914
1972629
1963173
1961373
1956962
1949591
1947390
1947286
1944577
1944459
1941764
1938887
1936518
1935831
1934788
1934471
1934225
2006977
1970672
1931721
1931593
closesodoo/odoo#34199
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Now that the debug mode is stored in session, we need a clear indication that
debug mode is activated.
In backend, the 'fa-bug' is doing the trick but in frontend there is no visible
clue that debug mode is enabled.
This commit separate the debug manager code/feature so we can instanciate it in
frontend only with usefull options (such as enable assets, leave debug mode..).
Now, in frontend, people having access to the navbar (o_main_navbar) will see
the same 'fa-bug' icon with minimal options as mentioned above.
Also, in the footer, there will be another 'fa-bug' icon without any options.
It will be usefull when the navbar is not shown, typically the case for
public user, or for portal (without website installed)).
Clicking on it will simply leave debug mode as hinted in tooltip.
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
As now the debug state is stored in session, the JS framework code and some
templates needed some changes.
First, the debug state is retrieved from session and not the URL anymore.
Second, the debug state does not need to be forwarded as it is now persistent.
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
* web, survey
This commit takes advantage of the other commits of this PR to enable
lazy loading for most frontend javascript:
1) Extract the minimum part of the assets common:
- promises library and polyfill
- boot.js
2) Create "assets_common_lazy" which is "assets_common" - "minimum"
3) Include the "minimum" assets in frontend layouts using "defer"
loading and "assets_common_lazy" using "lazy" loading
4) Create a script to do the actual lazy loading in a "minimum" frontend
assets
5) Lazy load the current frontend / website editor assets
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
It's quite common that the `$().text()` method returns lots of random whitespaces at the beginning and end of the string. They're pretty unpredictable (extension views can add or remove them) and invisible to the end user.
This code chunk should allow to select an `<option>` based on its raw text content, but most of them will just fail without this patch. And most chances are that current ones just work equally with this patch.
This will make frontend tours more pleasant to write.
closesodoo/odoo#32718
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Create a tour with only one step for Community
`edition: 'community'`
- Install a database in Enterprise
`tip.in_modal` in `_check_for_tooltip` cashes since `tip` is undefined.
opw-1998603
closesodoo/odoo#33430
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
Before this rev., steps were consumed on 'mousedown' events. This
caused an issue with the RainbowMan displayed at the end of tours
(which closes itself on 'click' events outside its $el).
Here is what occured when the user clicked on the last step's
element:
- 'mouseenter' event triggered
- current step consumed, as well as the tour, and a RainbowMan
is instantiated and appended to the DOM
- 'click' event triggered
- RainbowMan closes itself because of that 'click' event
closesodoo/odoo#31148
The 500 page has `session.is_frontend === undefined` as it has its own
whole HTML template.
In that case, the ajax.loadXML is not done, making the tour crash when
visiting a 500 error page.
This is needed for #29957 that has a test tour on 500 error page.
closesodoo/odoo#30240
This rev. concerns automatic executions of tours. It makes each
step executed in a setTimeout, thus ensuring that the call stack
has been emptied before executing the next step (which is the case
when the user manually executes the flow).
For historical reasons, the tour manager executed each step of tour
in a setTimeout (10ms). When a step could be executed (i.e. when
its trigger selector has a match in the DOM), the element matching
its trigger was saved as a jQuery element (the $anchor), and in the
setTimeout, the action (e.g. click) was performed on that element.
However, it could happen that, after the delay, the $anchor was no
longer in the DOM, either because
1) the tip selector had no match anymore, meaning that the element
had been removed from the DOM meanwhile
2) the tip selector still had a match in the DOM, but that element
had been rerendered meanwhile
Case 2) occured sometimes when the main_flow_tour was executed in
community, when trying to open a Manufacturing Order after having
reloaded the Manufacturing Order list view (because the row of the
order to open that was saved as $anchor was the one of the list
before the reload, and that list was re-rendered during the delay).
This rev. removes the default delay of 10ms, but the feature is
kept such that one can still manually run a tour slowly (e.g. to
debug or to make a demo).
This is important if the mouse must stay on the element after it has been
clicked. This is the case for the product image zoom, which will be tested in
the following commit.
With this commit, a failing tour will display more information in the logs,
which may be useful for debugging purpose.
- display full html instead of just the content of body
- display the 'content' flag of the step, which is very useful to see
which step failed
closesodoo/odoo#28863
The refactoring also had to be done in order to create a set of unit
tests.
Each behavior can be tested, including the behaviors performed as a
consequence of keyboard interactions (for instance: Enter, Tab...).
This commit also contains some changes to test_utils that were
necessary given the new structure of the wysiwyg editor.
Co-authored-by: Gorash <chm@odoo.com>
Tour steps on m2x widgets are now consumed only when an actual record
is selected (not on random click on the widget).
closesodoo/odoo#21625
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
As a start_tour helper was added on the python side (PR #32316),
a javascript helper counterpart was needed as suggested on the PR.
closesodoo/odoo#32441
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the code for the tour system was kind of naive and
simply activated tips for each tour. This was not really an issue,
since most user install one app at a time, so they had the time to
follow a tour, and when they install the next app, it is no longer
active.
However, since we activated the multi-app feature in our website, it now
happens that multiple apps are installed at once. Because of this, this
commit is now necessary.
closesodoo/odoo#28178
Currently:
- normal modals have a z-index of 1050 ($zindex-modal)
- chat window have a z-index of 1051
($zindex-model + 1 == $o-mail-thread-window-zindex)
- document viewer modal have a z-index of 1052
($o-mail-thread-window-zindex + 1)
- tour tooltip ball and messages have a z-index of 1051 ($zindex-modal)
A tooltip ball is in the DOM next to the element that is pointed out, so
if the element is inside a document viewer modal we see the ball.
But a tooltip message is positioned inside the body, so if we hover a
ball inside the document viewer modal, the tooltip message is behind the
modal.
In this commit, we set tooltip to bootstrap $zindex-tooltip value (1070
a of now).
opw-1893035
closes#27928
A previous rev. odoo/odoo@2672143 has prevented a tip to be consumed
in automated tours when blockUI was displayed.
This condition is not exactly correct. A blockUI element can be displayed
on any node, not only the webclient (which is the case when calling
`framework.blockUI`. This is the use case we want to deal, not the others.
So the tip cannot be consumed only with `o_ui_blocked` now.
closesodoo/odoo#28060
Rev. 2f7c03d added a second admin user (id 2), the 'human' one, on
top of the 'technical' one (id 1, also known as the superuser).
Basically, all calls to _is_superuser() should have been changed to
_is_admin(). They weren't. As a consequence, some features that
were previously available for the admin weren't anymore (e.g.
tours).
This rev. replaces all calls to _is_superuser() by calls to
_is_admin().
Before this commit, a tip on a dropdown menu item was visible.
This is due to the positioning of the tip, which was on the
dropdown-menu (because it has overflow `auto`). The tip was
appended on the dropdown-menu, and may overflow as a result.
This commit handles specifically the case of dropdown-menu,
so that dropdown-menu is never a candidate for the placement
of the tip.
*: crm,
hr_expense,
hr_recruitment,
point_of_sale,
project,
sale,
stock,
web_tour,
test_main_flows,
test_new_api
To sum up:
- Click on "Apps Menu" then the app item.
(previously: click on '+' then the app item).
- Click on navbar section menu item.
(previously: click on sidebar section menu item).
Since chrome headless has been merged, js error messages are
difficult to read: some information was missing or only displayed in
full all log.
All console.error() will now be displayed in build details, and will
appear just before the python assertion.
XMO's improvement will also be used on all log: Using module and
classname of the class calling phantomJS.
Also: some small improvements on error messages to make them easier to read
Note: this commit also shown that some error were not detected:
now we will fail in any case if js log an error.
In both test util functions (`dragAndDrop`) and tours, using elements in iframe
was not supported.
As a jQuery selector won't work with an iframe, when using a selector like
`div.o_my_class iframe p:first` the tour manager will split the selector, which
will result to `$('div.o_my_class iframe').contents().find('p:first')`.
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
* portal, web_tour, website, base
Before this commit, there were 3 different implementations for the same
feature: the "more" button in the community navbar, the "+" button for
the website menu and the "+" button in the enterprise navbar. As those
implementation were now broken with BS4, it was a good time to share the
code of those 3 features.
Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.
BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.
The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:
$gray-darker -> gray 900 (unused before)
$gray-dark -> gray 900
$gray -> gray 700
$gray-light -> gray 600
$gray-lighter-darker -> gray 400 (the old variable was created by us)
$gray-lighter-dark -> gray 300 (the old variable was created by us)
$gray-lighter -> gray 200
Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.
- The dropdown structure was simplified, allowing to get rid of the
3-levels structure induced by <ul/> elements and dropdowns can now
contain anything. The class 'dropdown-item' is now mandatory for
each dropdown clickable element. The class 'dropdown-item-text' can
be used to add same padding and style but without making the element
have a clickable look.
- Dividers now use the class 'dropdown-divider'
- The way dropdowns are opened and hidden also changed (before the
'open' class was added on the `.dropdown-menu` parent, now the
'show' class is added on both the `.dropdown-menu` parent and the
`.dropdown-menu` itself).
- JS-wise, no click event handlers can be put on `.dropdown-toggle`
elements anymore (instead, use handlers for dropdown events).
- Carets are automatically put on `.dropdown-toggle` elements, so this
commit replaces the `.caret` elements with this. This feature was
possible to disable but would prevent us from adding a caret with
scss. Also, this simplifies the DOM. The 'o-no-caret' class was also
introduced to allow using the 'dropdown-toggle' class on non-caret
elements.
- Also adapt the scss to use $caret-width instead of $caret-width-base
Odoo made the bad choice of using the 'btn-sm' class for every button
instead of configuring the padding for default 'btn' to be smaller.
In BS4, the style of btn-sm is actually more complex, lowering the
font-size too. Also, btn-xs was removed so we would not have the
possibility to display smaller button than our default ones.
This commit removes btn-sm wherever it was used. Unfortunately, this
might remove it at some places where it made sense but this can be
restored in a second time.
fja-odoo