We noticed users may have difficulties noticing where the tip is in the
page, even when searching explicitly for it. This commit reviews the
design and improves the scss: the tip shape is now made of an unique
transformed element with a white border all around. The box shadow was
also made more visible. The visibility over white elements stays the
same as before but it is now way more visible over dark content (like
the website editor panel).
task-2357170
closesodoo/odoo#61731
X-original-commit: dbf966f6f012ccf5aa9b501586e2aa0fde05be5d
Related: odoo/enterprise#14735
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As the tips can be put anywhere in the DOM, external css rules may
target them by mistake. This was for instance discovered on the frontend
where the boxed layout does something like this:
```
#wrapwrap > * { width: XXX; }
```
which does breaks the tips which would be placed in the #wrapwrap.
This commit solves the problem by forcing rules with !important flags.
closesodoo/odoo#58874
X-original-commit: 5084ea9b4d24c41a8171f5c9ad92f903f1067705
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This reverts commit 27158a0f612897e41601bf9e9d20861e9b87279f
Why keep a new option now that it has been developped ?
X-original-commit: bd4628e69df1e27498f88f348812a269cc9d3648
* Prior to this commit only one selector could be provided in order to got to the
next tour step.
* After this commit an additional selector can be provided in order to consume
a tour step. This additional selector can be specified through the step property
alt_trigger. We also toke the opportunity to remove $actualAnchor in tip.js as no
more used.
task-2325001
Related PR: odoo/enterprise#12711closesodoo/odoo#57680
X-original-commit: 9606e9e231be9e1e7d15ea0efdedbf5afff47102
Related: odoo/enterprise#13214
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit add a button in a step to be able to consume it.
It allows to have optional steps that the user can skip.
Part of https://github.com/odoo/odoo/pull/44328
task-2172208
X-original-commit: 27158a0f612897e41601bf9e9d20861e9b87279f
Task 2327599
In some cases, we want a function to evaluate the string shown by the
rainbow man.
For instance, if the message should depend on the state of other tours.
- reduce the size of the tooltip box when the tip is short
- display the rainbow message longer on the screen to allow
the user to read it.
closesodoo/odoo#56562
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Two things have been introduced in this commit:
The first is a change in the way the tour tip widgets are updated when
a DOM mutation is triggered: before this commit, each active tip would
evaluate its current anchor to elements matching its "trigger" selector.
If the element was not the anchor, it was set as the new anchor and
would be bound to the tip event handlers. Now, the unbinding/rebinding
of event handlers is done regardless of the new element.
This is helpful when the anchor is on a field monetary for example,
which keeps the same input element while internally unbinding and
rebinding the widget event listeners to it on each rendering. This
process does not include external event listeners such as those of the
tip and they were lost until now, breaking the tour step.
The second change is a modification of the CRM tour: the "Expected
revenue" field being an input, the according step trigger has been set
to target the input element instead of its parent. This means that the
step will await an "input" event instead of a click to be consumed,
making the tour step feasible with a keyboard.
Task: 2314864
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Before this commit, when we doing the tour. If we move the mouse fast
enough. We may trigger the tip_consumed event before its
_transitionEndTimer call its callback to update the position, and a
bubble will be left there.
In this commit, we clear the _transitionEndTimer timeout before we
destory the widget to prevent the issue.
Task 2298950
PR #55155
When you hover on the bubble tooltip infobox then sometimes its glitch,
and moves left. once you leave the mouse over from the tooltip info then
it will be repositioned as before.
So with this commit, we have resolved this issue by giving the condition
on the repositioning of every time the _updatePosition methods execute.
If the tooltip infobox is open then we are not repositioning the box's position.
otherwise, it will be repositioned.
closesodoo/odoo#55162
Task: 2263600
X-original-commit: 1d62b9d5fbe17cb1cc33dd335cff129ce9b13570
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The tour system is made such that we always have at most one tip
displayed on every screen. Since commit [1], "inactive tips" (i.e.
tips that aren't displayed because there's already an higher
priority tip displayed), are rendered, but turned invisible (s.t.
their action is still consumed when their anchor is clicked on),
whereas before [1], those inactive tips weren't rendered.
As a consequence, in the enterprise Home Menu with **a lot** of
apps installed (e.g. on runbot), it lags when the user scrolls,
because all those invisible tips still do a lot of computation to
reposition themselves.
This commit skips these positionning computation for invisible
tips.
[1] 3bf1d8418f41bcaa0ba4b153620def11aaea0a2b
Issue spotted while testing task 2263600
closesodoo/odoo#54920
X-original-commit: cac1689718299fcf509de8228ed6cf2bfdb7c57c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Now that for a single visible button there is no 'Action' dropdown, the
tour helper function has to be adapted.
Related PR odoo/enterprise#10602
Task ID: 2225270
Prior to owl, dom changes is normally performed by removing an element in the
dom and replacing it with new one. This is not a problem for the tour service
even if the used mutation observer is only observing attributes and childList
changes.
However, using owl is now a different story because it can change even just a
text of a node when rendering. If after a step this is the only change that
happened in the dom and you are expecting in the next step that the text has
changed, then the tour fails in that next step, but you are given a screenshot
containing the value you are expecting in the failed step. This is a false
negative.
It means that observing only classList and attributes changes in the dom is
not enough, and it is now necessary to observe characterData changes in order
to avoid the false negatives in tour tests.
This change is expected to incur performance tradeoff so the delay in calling
the mutation callback is increased from 500 to 750ms.
closesodoo/odoo#53649
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When several tips (coming from different tours) can be displayed on
the same screen, we only display one of them [1], the one from the
tour having the lowest priority [2]. For instance, with CRM and
Sales, there are two tours starting from the HomeMenu, but we only
display the tip on the CRM app.
Before this commit, if the user entered the Sales app, the first
step of sales tour wasn't consumed, so no tip were displayed inside
the Sales app, even though the user "discovered it by himself".
This commit ensures that tips that aren't displayed because there
is another one with a lower sequence still get consumed when the
user clicks on their anchor.
[1] f0a7d69dcf
[2] 61ed0409c3c419f9624874fb0743d707eee673b1
closesodoo/odoo#53606
X-original-commit: 3bf1d8418f41bcaa0ba4b153620def11aaea0a2b
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
Before this commit, the rainbow man message at the end of tours is fixed
to a hardcoded message.
This commit allows to customize the message within the definition of the
tour, to add the ability to use tailored messages depending on the app
the tour is about. If no custom message is set, the old default will
still be used.
Task ID: 2241549
closesodoo/odoo#49779
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit places a tip to indicate the user to scroll when the anchor
is out of viewport.
Also now allow to wait that the user types on his keyboard before
consuming a step when text modification is required on a contenteditable
element.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
closesodoo/odoo#48678
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit adds some untracked modifications rules that ignore
these DOM modifications:
- Ignore when the class "o_tooltip_parent" is added or removed (will
be important with the next commit)
- Ignore when the ID of an element changes (normally never in Odoo
codebase (at least not alongside other changes), but jQuery uses
ID modification for some performance improvements).
This is required to avoid loops in the update system (the
o_tooltip_parent class is added, thus we update tips, which search the
DOM so jQuery changes IDs, thus we update tips, which ...). Previously,
this already occured but less frequently than it is about to be
with future tips improvements.
To be able to do that change, the system had to be reviewed. Indeed,
the DOM mutation observer was debounced thus leading to considering a
very small portion of DOM mutation. As we now have to check the addition
or removal of a specific class or ID, we have to consider them all. In
fact, it worked by chance before... this occured:
1) The user clicks on something, the UI is updated -> DOM mutation
2) The code uses jQuery so a strange ID update is done -> DOM mutation
3) As the observer is debounced, we only see (2), which was not an
ignored DOM mutation -> we update the tips.
Now that (2) is an ignored DOM mutation, if we still debounce, (3) will
not update the tips while it should have because of (1). In fact, this
could theoratically break already: if (2) is a tip update for some
reason, (1) will be forgotten in the current codebase.
Instead of debouncing we now register all DOM mutations and process
them in a debounced way. So if I receive 3949 mutations over half a
second, I will save them all but only start processing them once I am
not receiving some anymore. And most of the time, only a couple of
processing is needed to know that a tracked DOM mutation occured, which
thus needs to lead to a tip update.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
This commit adds the case where the overflow of an anchor ancestor is
'hidden auto' and not only 'hidden'.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
A system was implemented to not close/open a tip if the user
leaves/enters the anchor and immediatly re-enters/re-leaves it but that
system was broken at some point.
This commit restores it.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
This commit concerns tours executed in onboarding mode (the user
manually follows the steps and consumes the tips).
Commit [1] changed the default event type to consume a tip from
'mousedown' to 'click'. This caused an issue when a tip was
attached to an element that had to be dragged and dropped. The
issue has been fixed by [2]. This fix is based on the fact
that draggable elements have classname 'ui-draggable-handle'.
Kanban records are draggable, but their implementation uses the
'sortable' feature of jQuery instead of the 'draggable' one (the
records are also sorted in their column). So [2] isn't enough in
this case. For instance, in the crm tour, the tip telling to drag
and drop a record to another column can't be consumed.
This commit handles the case of sortable elements that have to be
dragged and dropped.
[1] e5bc2e7306251a55ce90adeef992840517c240e6
[2] 3f458fe06e6a629edc72428eab749068c2eba1ba
closesodoo/odoo#49072
X-original-commit: 67335bda1653f592011a57146fb750d7b69cfc27
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit improves the "Start tour" dialog accessible via the
DebugManager. It is now possible to reset a tour to its initial
step, so that it can be re-executed (in onboarding mode). The
content of the dialog has been reworked as well:
- testing tours are displayed in another table
- tour sequence is displayed
- tours are sorted by sequence, and by name.
Task 2229909
closesodoo/odoo#48892
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the template of the "Tip" widget was loaded on test runtime
and caused a concurrency issue.
Now, the template is loaded before the test suite is launched and is ready when
the test is executed.
closesodoo/odoo#48589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Now we have the mobile search_panel in enterprise,
this commit simply adapt the Odoo repos part with:
- Css Clean up
- Remove the no longer existing step inside the tour
the button 'o_enable_searchview' no longer exist
inside a M2X dialog
Task ID: 2200099
closesodoo/odoo#48376
Related: odoo/enterprise#9494
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this commit, tours were activated in a non deterministic way and there was
no way to control the order.
Now there is a `sequence` key in the options dict (i.e. the second parameters of
`tour.register`) which will determine the tour sequence order, the lowest being
first and going upward. Unsequenced tours will behave as before with no particular
order.
Task 2191192
1. Test utils helpers adapted to properly instantiate the new Owl control panel
2. New file 'test_utils_control_panel' to create a control panel and use helpers
3. New helper: createComponent (creates a generic component, see jsdoc)
4. Use of the new helpers in the current tests (more in sibling commits)
5. Helper 'addMockEnvironment' is now asynchronous
6. Owl config mode set to 'dev' in test suite (props validation)
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit moves some step utils in a dedicated file and add new ones.
These steps will be very useful for the Main Flow Tour to avoid
duplicated code.
To do this, we also had to transform it into functions to allow
utils to call each other. Existing one are converted for
standardization purpose.
Note that 'WEBSITE_NEW_PAGE' wasn't considered as an util.
This is a very simple step only used twice.
We are not able to precise in which case a step should be executed.
We already have 'edition' and now we introduce 'mobile'.
undefined: Desktop + Mobile*
true: Mobile* only
false: Desktop only
*: Responsive (<= SM), see isMobile
Before this commit, the tip for a many2X field was consumed with a
input event.
But on mobile we doesn't have the same behaviour; a kanban modal is
opened when we click on the many2X field input instead of writing in it
(auto-complete) like on desktop.
After this commit, the tip is consumed with a click event for many2X on mobile.
Since commit: odoo/enterprise@e662ef3629
a 'div' wrapper was added around the notebook header.
The tip was not visible due to it's location in the wrapper with
'overflow: hidden'.
After this commit, the tip is appended to the ancestor of the wrapper
and so it's visible again.
Before this commit, when you tried to run a tour by clicking on
"Start Tour" in the debug menu, nothing happened and a warning
message appeared in console:
"debug_manager.js:53 No handler for start_tour".
Now it will work on mobile too (debug mode only).
We had to do this to be able to run the main flow tour on mobile.
Note that another commit (in enterprise) will automatically consume
all tours to avoid to display it for demonstration purposes.
Task ID: 2149402
The date range picker works with 2 fields but we only listen on
the one that has the tip. If we change the field that doesn't have
the tip the event "tip_consumed" is not triggered. So we need to
listen on the 2 fields.
This issue is not met before 13.3 but we fix it from 13.0 when
daterangepicker was added.
Task with the issue: 2180175
closesodoo/odoo#46561
X-original-commit: e2c7498e05318b774badc3a93d0b31b955f15b2d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- install sales
- install any rtl language and set your user language to it
- go to sales
this.info.position can have any of the 4 values 'bottom', 'top',
'right' and 'left'. It only needs to be reverted in rtl if it's left
or right.
Previous behavior:
tooltip is not positionned properly and covers the create button
Current behavior:
toolips align the way they are supposed to
opw-2193479
closesodoo/odoo#46156
X-original-commit: c75595bd8f2b44197a4a0751bd8622916ea5ef8c
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
When applying the selected date range using the widget the
tip wasn't consumed. This commit fixes it by listening on the
event triggered when clicking on button apply.
closesodoo/odoo#45916
X-original-commit: 150d69f70a505efa298c66119eced29d8caa3699
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue
- Deactivate demo data
- Install several modules (e.g. Sales, Helpdesk)
- Go on Home
- Hard refresh
All tours' tips are shown
Cause
In 02dab5dc88, we wait the DOM to be ready.
The DOM wasn't ready in previous version, this is
why it seems to work.
As the DOM is ready, in check_for_tooltip we
have a visible trigger so trigerred = true
and the tip is activated.
If you activate the debug mode, the DOM is
not ready too, this is why it works fine
in debug mode.
Solution
I don't think that not waiting the DOM to be
ready is good so I think we should keep that
and handle the case when we update the tours
from the _register method. So that, we use
the else part of the update method which
will break after a tip has been activated.
OPW-2188525
closesodoo/odoo#45073
X-original-commit: 5f0451c54cb785cc940b78a489316bed5ad9d888
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* remove misleading documentation about a "test failed" message, in
13.0 any uncaught exception or console.error will cause the current
test to be interpreted as failed
* fix tour manager to console.error its step and not add a second
useless error message
* fix menu tester to try and display the failure cause on failure
* improve qunit's test reporter to print the number of tests failed in
case of test suite failure
Should make test failures in tours a bit clearer.
closesodoo/odoo#44296
X-original-commit: 78121b68d099b16f2d775a7a8a963a2a0f474843
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
A number of steps have a last step which may trigger some async
operation (e.g. reopen a menu, close a modal, ...).
This async operation can span over the cleanup of the browser, in
which case its callback will try running in a seriously broken state.
It's simpler to just assume that the last step's side-effects should
not matter to the test's success and interpret it as a "wait" (used
only for its trigger to wait until a proper end-state).
There was a question of whether we should ignore all final actions,
all non-function actions, or all implicit (default) actions. The
latter seems the least disruptive as hopefully developers having
provided a `run` in the final action have a good use case for it.
The 'text' helper does not focus out of the inputs after adding the
text. The new 'text_blur' one will.
It will be needed for future tasks of the website editor since the
inputs in the left panel are only considered on blur or on ENTER.
See https://github.com/odoo/odoo/pull/42189 for example.
closesodoo/odoo#43337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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.
qsm-odoo