Tours can now be launched flawlessly thanks to the run method of the
tour service.
In a tour definition, here what you might have to do to make it
functionnal in auto mode:
* If actions are required between two steps of an onboarding tour:
* If the actions have to wait for elements to appear on the screen,
define new tour steps with no content and add the "auto" key
and set it to "true".
* If the actions concern elements which are already on the screen,
you can use the "run" key in a step to make the tour faster to
execute actions after the step.
The "run" key may take several values:
* A string with the values "click", "text" or "drag_and_drop". By
default, you will not have to specify "click" for normal elements
or "text" for form elements as they are the default values for
those. Note: the "text" value can be followed by the text to enter
(default to "Test") and the "drag_and_drop" value can be followed
by a jQuery selector to specify where to drop the element (default
to the body element).
* A function which takes an "actions" parameter. This allowed to do
anything but here are common uses in the run definition :
* a call to "actions.auto()" will do the default action on the
step element (click on normal element and add text on form
elements).
* a call to "actions.auto(element)" will do the default action on
the given element. Note: this.$anchor is a reference to the
step jQuery element.
* a call to "actions.text([text], [element])" will add the optional
text (default to "Test") to the optional given element (default
to the step element).
* a call to "actions.click([element])" will click on the optional
given element (default to the step element).
* a call to "actions.drag_and_drop([to], [element])" will drag and
drop the optional given element (default to the step element) in
the optional given "to" element (default to the body element).
Note 1: all the "element" parameters can be given as a jQuery selector,
a DOM node or a jQuery element.
Note 2: the run method is designed to do actions on elements which are
already on the screen. If this is not the case for some of them,
consider using an "auto: true" step as explained above.
Note 3: "auto: true" steps can also contain a run definition.
When defining a tour, you can also add predefined steps (auto or not).
These are defined in the object STEPS of the tour service object. These
include opening the "More" menu if any in community before clicking on
an app, opening the appswitcher in enterprise, ...
The full list is accessible in the tour_manager.js file.
Commit cf925c2a58 introduced the test_forum_process file which launches
the UI tests of the website_forum module. Unfortunatly, the file was
not linked in the __init__.py file.
This is a temporary workaround, which probably deserves
further thinking by @ged-odo, as the root cause
stems from commit 96bf5b2656
The problem is that the list view looked for composite group_by
keys such as "create_date:month" within `fields_get`, which
only contains true fields.
When there is no `color` field on the model
e.g. On invoice line taxes
The color class to apply on the badge was set to
`o_tag_color_undefined`
which doesn't exist. It must be set
from `o_tag_color_0` to `o_tag_color_10`
in order have a color.
Because of this, the taxes in the invoices lines
were not visible, because they were written in white
on a white background.
This has been broken by the below revision:
fe66472e2c
removing the or statement (`||`) to set a default
color for models not having a `color` field.
We choose to set `10` as default value, so the color
remains the same compared to the previous release
(light grey). However, if the new behavior chosen
by the usability is to have these in black, it should then
be changed to `0` again.
This filter must be added in the regular searchview,
and not have his own search view.
Without this:
- view_sales_order_filter_ecommerce is a not search view
for the sale orders, having the same priority than the regular one,
and therefore this view can be loaded by default for other menus
(In this case, this was for the menu Website Admin > Orders).
e.g. Clicking on the `Sales` stat button on a contact no longer
filtered the orders of this contact, but displayed all the orders,
because it was this view which was loaded instead of the regular one.
- In Website Admin > Orders, it was simply not possible to type a string
and search for it in the search bar.
* Move files and reorganize directories according to guidelines
* Lint and clean code, remove dead code
* Migrate code to the new API
In REF commit, some fields of calendar.event models changed. Due to
bad design, the code was not clean with the new API. Changing computed
fields make it more performant, and reduce code complexity.
See commit "[REF] calendar: change computed fields for start and
stop dates" for details.
Change `send_email_to_attendees` signature to force setting email
template and remove `email_from`, since it is not usefull.
Now, when sending email to attendee, meeting author will also received
an invitation.
`get_ics_file` has been modified to be executed in batch.
- `start` and `stop` fields are not computed anymore. Indeed, it was not normal
to have required stored computed field. Normally we shouldn't write on these
fields, but since client calendar api need them, we keep them as normal
datetime fields
- `start_date` and `stop_date` become stored computed date fields depending of
`start`,`stop` and `allday`. An inverse method allow to write on these fields,
since it can be the case from the form view
- `start_datetime` and `stop_datetime` follow the same logic
- `onchange_allday` code is mostly moved in `_inverse_dates` of new computed fields
- `_set_date` method (called in create/write) is now removed, since it does the same
thing as old onchanges
- `_onchange_duration` is kept to adapt `stop_datetime` when changing `start_datetime`
or `duration` on form view
- Duration is now 'zero' in database for allday meeting. Before, it was not changed.
Setting it to zero is less falsy. `duration` can not (yet) be a computed field since
it depends on others computed fields.
After migration, we manage to keep old behavior but the code was crap. Switching stored computed
fields make it cleaner, and respecting new API standarts.
This changes avoid multiple methods doing almost the same thing, and is less 'buggy'.
- move `get_ics_file` from calendar.attendee to calendar.event
- remove calendar.event arguments to convert method into
`api.multi`, which make more sense
- `create_attendees` now returns recordset instead of list of ids
- change signature of `get_interval` method
Migration of all python code, mostly withtout chagnes. And adapting
xml files to guidelines.
On calendar.py, some changes have been perform to make the migration works :
- `_compute` method has been split into `_compute_dates`, `_compute_attendee` and `_compute_display_time`.
- remove unused method `onchange_partner_ids`, `check_partners_email`
- make `compute_rule_string` use a cache record instead of a value
dict to avoid crashes
- remove `new_invitation_token` method, and make it a default value on attendee creation
- add a default value on `day` field, otherwise the "Please select a
proper day of the month" exception is raised during the onchange
A string attribute value can be translated,
and therefore the inherit broken if the term is indeed
translated.
This was the case for this term "Tracked link" in the Dutch
language, the "Tracked link" term of the inherited view has
been translated, and the inherit was therefore broken as
it couldn't find the given node in the base view due to the
fact this term was translated.
opw-683128
When the schema of a view change (e.g. drop of column), the "CREATE OR REPLACE"
will not be enough and dropping the view is required.
Fixes#12754Closes#12756
Fabrice Henrion