Currently, when the user is using the quick create card of the kanban view, the
card will automatically close itself if the user clicks on a tooltip element
from a tour.
This can lead to bad user experience since the tour tip can be visually
*within* the quick create card, and the user will not understand why the card
is closing.
More importantly, the tooltip element "zone" is bigger that what it visually
looks like and you may click on an element (a field, ...) that seems to be
perfectly within the quick create card but is in fact part of the tooltip.
This commit fixes that behavior by preventing the click event propagation in
the tip widget handler.
The fix is made in version 14.0 because this is especially problematic for the
tour of the "CRM" app, that heavily uses the quick create card in combination
with tour tips.
Task 2388450
closesodoo/odoo#62175
X-original-commit: 48d30e1375cc25fd430cdcb53e9b849be295ac26
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.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>
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.
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>
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>
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
Aurélien Warnon