*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2937174
closesodoo/odoo#97030
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2928837
closesodoo/odoo#96690
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2925850
Part-of: odoo/odoo#96447
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2898692
closesodoo/odoo#94914
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: im_livechat, website_livechat.
The autoOpenDiscuss parameter was used but is deprecated for a while now.
This PR removes it.
closesodoo/odoo#94716
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2896237
closesodoo/odoo#94722
Related: odoo/enterprise#28913
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2896237
Part-of: odoo/odoo#94722
*: auth_signup, knowledge, mass_mailing, portal, survey, test_website,
test_website_modules, test_website_slides_full, web, web_editor,
web_tour, web_unsplash, website_blog, website_crm,
website_crm_partner_assign, website_customer, website_event,
website_event_exhibitor, website_event_meet, website_event_track,
website_forum, website_hr_recruitment, website_knowledge,
website_links, website_livechat, website_mail_group,
website_mass_mailing, website_membership, website_sale,
website_sale_autocomplete, website_sale_comparison,
website_sale_loyalty, website_sale_slides, website_sale_wishlist,
website_slides, website_slides_forum, website_twitter, base
A new client action is introduced, to display the website in an iframe.
This allows to remove the "frontend" Odoo UI entirely. Everything
related to the website configuration (and especially the edit mode) will
now be done on the backend side.
The idea behind this mainly comes from the fact that we needed the
website in an iframe during edition to be able to render a mobile
preview properly. It was also required so that options which reloads
the page... are able to only reload the page and not the entire editor
with it. From there, it was decided that actually, since the website is
in an iframe, it could be in the backend and every website UI could
rely on this.
In the end, this comes with many functional and technical advantages.
Here are some of them (a few of them are not entirely done with this
merge but will follow the merge in the upcoming weeks, see this as a
non-exhaustive list of possibilities that are unlocked by this work):
Technical:
- No duplicated logic for website UI and backend (purple navbar is the
backend one, slightly customized).
- No conflicting logic for website UI and website content (like dialog
opening, ...).
- No forced CSS for our website / web_editor UI, no conflict with
website themes.
- Everything converted in OWL, in backend code (no special OWL for
frontend).
- "Legacy" code moved as frontend code or removed.
- No website content CSS for the case "when there is the Odoo purple
navbar at the top".
- Backend views & features available (e.g. creating a new event -> form
view instead of custom code with onchanges, validations, etc)
Functional:
- All website features available while editing your website (product
configuration, settings, etc), no switch backend/frontend, no
redirection, no reload (just the iframe).
- All other app features available while editing your website (discuss,
calendar, all other apps, ...).
- Typing a website URL in your browser reaches your website (very small
Odoo UI overlay at the top left as a connected user).
- Mobile preview: directly resizing the website rendering, in edit mode
too and with a better phone image.
- Editor: mobile view edition (the editor is instanciated around the
website content instead of inside of it (iframe))
- Can reload the website without reloading all the tools (editor, html
editor, menu edition, etc) (customize_show options for instance ->
moved as standard editor options which reloads the website only)
- Website UI in your language instead of website language
On the backend side, some customizations were done so that the UI feels
like it works as before (note that it will be reworked in upcoming weeks):
- A `website_systray` registry is defined to replace the systray items
with the website's one when previewing the website.
- The webclient's navbar is patched to display additional dropdown menus
related to the website edition.
- A website service that holds the global state of the website is
introduced. Components from the systray and the dropdown menus can
access and modify it.
- A component adapter for the wysiwyg (that will display the snippets
menu) is added, that allows for caching the wysiwyg libraries, thus
improving editions responsiveness.
See sub-commits for details. This work is known to not be bug-free and
will be bug-fixed, improved and reworked in the upcoming weeks.
task-2687506
Thanks to the whole team for reviewing and testing !
(ARD, BVR, BSO, GDI, MOU, PDE, QSM, RDE, SOBO, YOL)
closesodoo/odoo#89223
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: Mehdi Outagant <mou@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
*: web, web_editor, web_unsplash, website_blog, website_event,
website_forum, website_hr_recruitment, website_links,
website_livechat, website_sale, website_slides, website_twitter
This commit fixes two issues related to the loading the wysiwyg and
editor assets.
The media dialog components are now defined in a new assets_media_dialog
bundle, to make them available both in the frontend (needed to post
comments on the forum for example), and in the backend (used in the
context of the wysiwyg edition or in the seo dialog). Ideally, The media
dialog component would lazy load its own bundle, but right now, it is
not possible when used in a ComponentWrapper.
The wysiwyg assets are now completely loaded in the frontend, after
creating the website root, when the frontend is displayed in an iframe.
It would be better if the frontend loads only what it needs of the
wysiwyg assets (some editor classes and the drop zones css), an
improvement would be to create an assets_wysiwyg_frontend or
assets_wysiwyg_minimal bundle.
The website edition components are moved to the assets_editor bundle.
For now, this bundle is included in the backend and the edition menus
are hidden from the users that are not website publishers. Ideally, the
client action would lazy load the assets_editor, only if the user is a
website publisher.
Many optimizations regarding assets will be done post-merge.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_links,
website_livechat, website_slides, survey, web_editor
This commit removes the website navbar root widget, as the edition is
now handled in the backend through the client action and custom menus.
It removes associated widgets and their css.
See merge commit for more information.
task-2687506
*: mass_mailing, web, web_editor, website_blog, website_event,
website_event_meet, website_livechat, website_sale, website_twitter,
base
This commit does 3 things:
- Adapt existing code so that the editor can be run outside of its
editing element. Prior to this commit, it was expected that the
editor would be attached to the element it was currently editing.
This needs to change however as the editable is now inside an
iframe for the website edition. mass_mailing already had a similar
approach but the editor was started within the iframe.
With these changes, the editor is alongside the iframe, editing
the content that's inside it. This allows multiple features
such as reloading the iframe while keeping the editor visible and
resizing the iframe for a mobile preview.
- Adds logic to the wysiwyg_adapter so that it can undertake
the duty of the previous widget sytem. The wysiwyg existed not only
in the legacy widget system, but most importantly in the frontend.
One of the duties of this adapter is to send events inside the
iframe when it is necessary to reach the frontend public widget
(i.e. widgets_start_request)
- Removes existing SCSS that is no longer used.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides,
website_slides_forum
The goal of this commit is to add dialogs to create new website content
using a 'target:new' action on the form view and an overridable
"website" form controller.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_livechat, website_sale, website_slides
The NewContentModal component is added. It displays tiles, which will
install a module if not already installed, or perform an action defined
by the module otherwise. So that modules can patch that component to
define an action when installed (for example, website_sale will handle
the logic of creating a new product), the elements to displayed and
their state (NOT_INSTALLED, INSTALLING, INSTALLED) are listed in the
state of the component.
A key 'isDisplayed' is added on the new content elements that should not
be displayed to the user, depended on his security groups.
By default, the new content elements are displayed to the system user.
See merge commit for more information.
task-2687506
*: web_editor, web_unsplash, website_event, website_blog,
website_event_meet, website_forum, website_links, website_livechat,
website_sale_slides, website_slides
With [1], many files will move as the website UI is moved in the
backend. This commit moves all the static files (JS/CSS/XML) to their
final destination without modifying them, in an attempt to preserve
some history and ease some forward-ports.
After this commit, everything works as before as the files are simply
renamed and the references to them adapted.
However, technically, many files will actually be split into multiple
files by the work made with [1]. While it is theoretically possible to
preserve history over multiples files, this would require inner merge
commits, which does not go well with robodoo. In those cases, the "main"
file of the split was chosen. Mainly, 4 worth-noticing splits were
detected (and so the history moved only to the first file):
move: addons/web_editor/static/src/js/wysiwyg/widgets/media.js
to: addons/web_editor/static/src/components/media_dialog/file_selector.js
- addons/web_editor/static/src/components/media_dialog/search_media.js
- addons/web_editor/static/src/components/media_dialog/image_selector.js
- addons/web_editor/static/src/components/media_dialog/document_selector.js
- addons/web_editor/static/src/components/media_dialog/icon_selector.js
- addons/web_editor/static/src/components/media_dialog/video_selector.js
move: addons/web_editor/static/src/js/wysiwyg/widgets/upload_progress_toast.js
to: addons/web_editor/static/src/components/upload_progress_toast/upload_progress_toast.js
- addons/web_editor/static/src/components/upload_progress_toast/upload_service.js
move: addons/website/static/src/js/menu/content.js
to: addons/website/static/src/components/dialog/edit_menu.js
- addons/website/static/src/components/dialog/page_properties.js
- addons/website/static/src/components/wysiwyg_adapter/page_options.js
- addons/website/static/src/js/website_page_list.js
move: addons/website/static/src/js/menu/edit.js
to: addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js
- addons/website/static/src/systray_items/edit_website.js
- addons/website/static/src/components/editor/editor.js
Notice that as those moves were made post-work and the rest of the work
(80+ commits) rebased on top of it, some commits may remove more than
they should in a moved file to then reimplement some of what was
removed in a later commit... ideally this should have been avoided of
course but keep in mind that the final files are just entirely rewritten
and split as converted to OWL. It seemed however worth it to keep most
of the inner history of the work made here to see step by step what was
done. [1] will obviously be merged with a merge commit, binding the
whole work together.
[1]: https://github.com/odoo/odoo/pull/89223
task-2687506
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2894102
closesodoo/odoo#94508
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2890189
closesodoo/odoo#94190
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2888734
closesodoo/odoo#94090
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
* hr, im_livechat, mail, sms, snailmail, test_mail_full, website_livechat,
website_slides
PURPOSE:
Creating a record with no values has no sense but is sometimes useful during
tests.
The support should be dropped for `default` parameter in `create`.
SPECIFICATION:
All the occurrences of `create()` have been replaced by `create({})`.
Task-2869394
closesodoo/odoo#93917
Related: odoo/enterprise#28538
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2887296
closesodoo/odoo#93966
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit make messaging service available in the frontend and in
the livechat external lib bundle.
This is preparation to refactoring JS livechat to use models and OWL.
*: bus, mail, survey, web, website_livechat
Task-2870899
closesodoo/odoo#92786
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
*: website_livechat
The goal is to split the public_livechat.xml file into multiple parts,
and move each template into its own file located in
`im_livechat/static/src/legacy/widgets/`
Task-2825235
closesodoo/odoo#92671
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Followup of: 623fdb15ce9a6f3f586254dca549a72869336729
The previous attempt at fixing the tour issue was non-conclusive as it still
breaks occasionally during runbot nightly builds.
That issue is near-impossible to properly debug, because it *only* happens
during nightly builds (cannot be reproduced locally and cannot be reproduced
with a multi-build configuration on the runbot).
We decided instead to slightly modify the tour step to click on the
"restart button" from the end of the conversation instead of the restart button
from the chat window header.
This should hopefully do the trick.
closesodoo/odoo#91656
X-original-commit: 50044dc7f547e2fcd7416f725987236b6185e6d6
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In some cases, the runbot running the tour was clicking on the
"restart conversation" button before we had the chance to register the click
event on it.
This small commit adds a "ready" class on the button when we have correctly
registered the click event, and makes the tour step wait for that class before
clicking to restart.
closesodoo/odoo#91505
X-original-commit: 623fdb15ce9a6f3f586254dca549a72869336729
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: im_livechat, website_livechat.
In order to reduce the noise in the PR introducing the new environment in
the discuss app, calls to widget.call, env.bus_service.call during tests
have been replaced by a mocked implementation of _sendone/_sendmany. Moreover,
this approach will allow us to mock the longpolling during tests, resulting in
a more realistic behavior.
task-2582313
closesodoo/odoo#90724
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Now that pyEnv is available, using it in the mock_server lighten the syntax.
task-2582313
closesodoo/odoo#90783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: hr, im_livechat, snailmail, website_livechat.
This PR prepares the ground for the one introducing the new environment in the
discuss app. Indeed, tests will now use the mainComponentRegistry in order to mount
those components. Doing so, the parameters has{Discuss/Dialog/ChatWindow} will become
obsolete. Removing those parameters now helps reducing the noise in the main PR.
task-2582313
closesodoo/odoo#90120
Related: odoo/enterprise#26759
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: hr, hr_holidays, im_livechat, website_livechat
This commit turns some `link`/`unlink`/`unlinkAll` to `replace`/`clear`.
The commands `replace`/`clear` are easier to understand, and also clearly tells what’s the expected resulting value of this field.
This change will help turning big and imperative code into smaller declarative code.
Task-2834598
closesodoo/odoo#89852
Related: odoo/enterprise#26673
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: calendar, hr_holidays, im_livechat, note, website_livechat.
This PR helps reducing the noise in the discuss new env PR. Indeed,
the new mockServer has the same method except that they are not prefixed
by any underscore. All calls have been changed, and the corresponding
methods created. They will be deleted later.
task-2582313
closesodoo/odoo#89659
Related: odoo/enterprise#26603
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit improves the livechat to always allow website visitors to be able
to see the operator avatar, regardless of ACLs.
Indeed, we currently depend on ACLs and when website is installed, the
visibility of the operator avatar depends on his website_published status.
Which does not make much sense as it requires extra configuration to make it
work.
Instead, we now consider that all livechat operators and all chatbot operators
have their avatar publicly available, using a custom livechat route.
Task-2813529
closesodoo/odoo#89756
X-original-commit: 127bf62a5d701f8d2f1d4b246f55cc8ca8630dcf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Follow-up of: https://github.com/odoo/odoo/pull/87597
This is the 2nd and final step of splitting public_livechat.js
into several files.
This is part of refactoring public livechat so that it uses
essentially the same codebase as discuss in the web client.
Splitting in smaller files helps following steps to refactor
the code.
Task-2818675
Part of Task-2212347
closesodoo/odoo#88654
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
In discuss, livechat website visitor info is displayed above thread view topbar.
After this commit:
Livechat website visitor info will be displayed below the thread view topbar.
Task-2668036
closesodoo/odoo#88532
X-original-commit: 5294def72da677c75f980ffcfb1bb50508ee0760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit simply lowers the delay between receiving an answer and reacting to
it within a chatbot.script.
The previous delay of one whole second would slow down the testing phase and
could even break builds as the tour would not detect the messages fast enough
if under heavy load (such as during multi-builds).
This comes from the fact that adding and displaying a message within the chat
window actually re-renders the whole thread (see '_renderMessages').
closesodoo/odoo#87904
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit introduces a chatbot operator that works based on a user-defined
script with various steps.
SPECS
A im_livechat.chatbot.script can be defined on a livechat rule.
When a end-user reaches a website page that matches the rule, the chat window
opens and the script of the bot starts iterating through its steps.
The chatbot code is currently directly integrated with the existing livechat
Javascript code.
It defines extra conditions and layout elements to be able to automate the
conversation and register user answers.
AVAILABLE STEPS
A script is defined with several steps that can currently be one of the
following types:
"text"
A simple text step where the bot posts a message without expecting an answer
e.g: "Hello! I'm a friendly robot!"
"question_selection"
The bot will ask a question and suggest answers, the end-user will have to
click on the answer he chooses
e.g: "How can I help you?
-> Create a Ticket
-> Create a Lead
-> Speak with a human"
"question_email"
That step will ask the end user's email address (and validate it)
The result is saved on the linked im_livechat.im_livechatchatbot.mail.message
"question_phone"
Same logic as the 'question_email' for a phone number
We don't validate the input this time as it's a complicated process
(requires country, ...)
"forward_operator"
Special type of step that will add a human operator to the conversation when
reached, which stops the script and allow the visitor to discuss with a
real person.
The operator will be chosen among the available operators on the
livechat.channel.
If there is no operator available, the script continues normally which allows
to automate an "answering machine" that will redirect the user in case no
operator is available.
e.g: "I'm sorry, no operator is available right now, please contact us by email
at 'info@company.com', we will try to respond as soon as possible!".
(Or even something more complex with multiple questions / paths).
"free_input_single"
Will ask the visitor for a single line of text.
This text is not saved anywhere else than in the conversation, but it's still
useful when combined with steps that create leads / tickets since those print
the whole conversation into the description.
"free_input_multi"
Same as "free_input_single" but lets the user input multiple lines of text.
The frontend implementation is made by waiting a few seconds (currently 10) for
either the next submitted message or the next character typed into the input.
This lets visitors explain their issue / question with multiple messages.
Which is very useful since new messages are sent every time you press "Enter".
LINKS
Task-2030386
Part-of: odoo/odoo#84000
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Alexandre Kühn