*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
With [1] in 13.0, the blog post layouts were reviewed. At the same time,
new demo data was introduced. By default, with demo data, you have now
two different blogs. The JS tour was adapted so that when you create a
new blog post, a step explains you have to select the blog you want to
create the post in with the dialog that opens. The main problem that
this PR aims to solve is that all users start without demo data and thus
with only one blog... so with the current tour, the users are blocked
very early in the tour as they do not have the dialog to select the blog
in which to create their blog post. The simple solution that was chosen
is to set the step as "auto", meaning it will only be used in runned
tours (like via python tests), allowing to still test the blog selection
dialog in our python test. Users will not be guided via a tip for this
specific modal but this is not a problem as this is very straightforward
to understand in the case the user explicitely created multiple blogs
before creating blog posts.
This commit also review commit merged at [2] which made that python test
more robust by not relying on the demo data. That was here improved with
explanations.
However, allowing the tour to go further than the blog post creation for
the user... revealed that the rest of the tour was still blocking the
user. The very next step is to modify the blog post title. That step was
simply not possible to consume. Indeed the tour system asks for a click
event on the title... which is never detected because our old editor
removes all click handlers on that specific top-level editable area. The
cleanest way of fixing that is actually to not wait for a click but wait
that the user actually types text. For this purpose a feature was
introduced in 14.0 with [3] (even if unfortunately, that commit was not
well split). Unfortunately again... that 14.0 feature is currently buggy
during test tours as choosing the "input" consumeEvent alongside the
"text" run method... changes the behavior of that "text" run method when
the affected element is a contenteditable element. That should be fixed
but this will be done in a further update. Meanwhile, this commit
chooses to use the consumeEvent 'mouseup' which circles around both
issues.
[1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72
[2]: https://github.com/odoo/odoo/commit/f16f2e212a30352ead86c2f876be02b5c5e23b07
[3]: https://github.com/odoo/odoo/commit/a34cd7c662b3753d630d83793ffcb53b4a0a92d2
Bug revealed by testing task-2728994
closesodoo/odoo#83721
X-original-commit: ca82efe0c7b9a5e98d5c9623b3ae0f1b88fc8091
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, web_unsplash, website_blog
We have recently created an odoo media library that exposes a public API
for searching for open-source media, including dynamic SVGs that can be
used with the dynamic background-shape system to create illustrations
whose colors can be changed by the user. This commit adds the
corresponding client-side functionalty: search for the images in the
media-library, creating a corresponding attachment when selected, as
well as an option to customize the colors of the dynamic SVGs.
In the process, adaptations have been made in the web_unsplash module to
avoid duplicating code and to adapt code that was making assumptions
that are no longer valid.
To make new users more aware of this feature, all default images have
been hidden from the media-dialog, so that the user is prompted so
search for images. Some tests and tours that were relying on having
default images in the media-dialog (eg in website_blog) have been
adapted to match.
task-2316651
Linked to: odoo/iap-apps#235closesodoo/odoo#57888
X-original-commit: 7a1308b426f94b33e2bd55e5d58e661067e26ff3
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the syntax to start a tour was extremely verbose.
With this new method, it is possible to start a tour by just giving the
essential parameter: the tour name.
The full set of features from browser_js are kept by using **kwargs.
closesodoo/odoo#32316
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
* 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.
