This commit prevents from erasing the origin part of the url
when the tour manager does a redirection. This was an issue in
phantomjs if it allows local url as in this case, it will try to
load file://<tour_url> instead of <origin><tour_url>.
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
Since commit 8ac1c19fac7615fecd51e670f798d13158a4e53c the odoo brand primary color
changed, which also changed the color of tips. The problem
was that they lose a lot of contrast in the appswitcher.
When users switch from one version to another, the localstorage is not
cleared and users can get errors because the tour manager is trying to
load steps (according to the localstorage content) which could not
exist anymore.
This could also happen when a module which extends another module tour
is installed.
* The debug manager contains a feature to launch tours, adapt it
to new web_tour.tour system
* The website help menu allowed to relaunch tutorial tour in debug
mode. This feature is not adapted to new tour system and was useless
in the first place (debug mode in frontend is barely used anyway).
-> remove the website help menu and the feature
Previous implementation was checking if the element we want to click
on is a link and if this is the case, only forced a redirection. This
had been done because the redirection was not working by simulating a
click, but in fact it works, the click simulation only had to be
improved.
Also, only forcing a redirection is wrong as some links have both a
real redirection link and a event handler binded to them.
When checking for a DOM element in a run method thanks to the action
helper, visible elements are now considered first, then, if none is
found, we take the first invisible one.
Previous implementation allowed to run tour as a non-superuser but
this was only working in the backend where the static file tip.xml
is always loaded. In the frontend or in other non-backend context,
this file has to be loaded just before trying to launch the tour as
a non superuser (indeed, previous implementation loaded the file in
the frontend only if the user is a superuser).
* crm, project, website, website_event, website_blog, website_forum,
website_sale
Eg: the tour 'shop_buy_product' is extended by the website_sale_options
addons to add a step to close a modal.
The current solution was requiring the module that defines the tour
to extend, then add/remove steps in the "step" key of the tour
definition.
Some of the problems with this method were:
* The "register" method calls the "update" method to immediately
search for tip to place once registered (as register may be called
after the DOM is ready). So extensions of tours were happening after
the tours were started (and the tours were not restarted).
* The addition/removal of steps was happening after they were filtered
according to the "edition" key.
To allow extension, the system is changed as follow:
* The "register" method now only saves the steps and options without
modifying them and does not call the "update" method.
* Once the DOM was ready, the tour service started listening to DOM
mutations and called the "update" tour method. Now, this "update" call
is replaced by a "_register_all" call, on DOM ready and at the end of
the current call stack (which makes sure all modules are loaded). This
"_register_all" method marks the registered tours as ready after having
filtered the steps according to the "edition" key and initialized the
current step to trigger.
* Also, tours can now define a "wait_for" option which allow them to
be marked as ready for run and update after the given deferred. Those
tours can now also be extended without having to wait for the deferred.
PhamtomJS must wait for the "ready" key to be true to run the tour.
If a tour step action induces a direct redirection the _consume_tip
method was called while the redirection was being done. Now,
_consume_tip is always called before any redirection really begins.
Note: as the run method also has to detect redirections and do actions
according to if there is one or not, a function has been created to
implement the redirection detection.
The change event has to be triggered when changing an input, a select
and even another DOM element with contentEditable attribute.
When changing an input, the "keydown" and "keyup" events also had to
be triggered.
Previous simulation was "mousedown" then "mouseup" then "click". It is
not enough for some feature (like bootstrap, web_editor...). These rely
to have a "mouseenter" before and a "mouseleave" after the click.
The default action for a tour step whose trigger is a <a/> tag is:
* Redirection to the a href if it is a valid link
* Clicking on it if the <a/> is used as a handler-binded button
The previous condition forgot to consider href="javascript:void(0)" as
a non-valid redirection link.
When checking the consume type of an input element, the type attribute
was checked. Indeed a "text" input has a "input" consume event, while
a "button" input has a "mousedown" consume event. The problem here was
that when the input has no type, the "mousedown" consume event was
chosen while the default type for input is "text" for browsers.
When searching the ideal location for a tip on the body or the html
element, the previous implementation was wrong. In that case, the ideal
location is always the body.
Instead of logging "Killing tour x" when calling the run method a
second time and then logging "ok" when consuming the old running tour,
the message "Killing tour x" is now logged as an error for phamtomJS.
Also, let "x" be the tour which is killed and not the one which wanted
to be runned.
The previous implementation took the parent of the element to begin
the check, which was wrong when the initial element was the html root.
This commit changes the method to a recursive implementation, which is
clearer.
When checking the DOM for tour step trigger, the ":visible" jQuery
filter was used to get the visible elements. The problem is that this
filter does not care about the visibility css property. So, for jQuery,
a display:block and visibility:hidden element is visible.
This was an issue as kanban ghosts or settings panels in odoo are
hidden thanks to the visibility property instead of display.
Aaron Bohy