*: calendar, iap_mail, im_livechat, mail.
Until now, one had to subscribe to the global "notification"
event of the bus service and to loop through each notification
to handle the one that was targeted.
This PR introduces the `subscribe` method on the bus service
in order to subscribe to a single notification type.
closesodoo/odoo#120893
Related: odoo/enterprise#40848
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
The new MockServer has no _mockCallButton method. Due to an issue with
the patch function that does not reasign this._super correctly when
entering the _mockCallButton function, a crash did occur.
Part-of: odoo/odoo#112756
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, website_livechat_chatbot_flow_tour failed
frequently and non-deterministically at 1st step "Hello! I'm a bot".
This happens because the tour starts on url `/`, then reload the url
`/`. The livechat button is configured in `auto_popup` mode, which
could let chatbot starts running before the 2nd url that must precede
the steps.
The 2nd url reload is actually useless, and removing it also fixes
the issue.
closesodoo/odoo#108160
X-original-commit: 402b6e98009017e04245d92cabcc35184014b280
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
Before this PR, the website_livechat request tour would fail
in an indeterministic fashion. This was due to the fact that
the message that was supposed to be sent through the bus was
directly given to the message notification handler.
The second message could or could not be received according to
the timing of the channel subscription. Indeed, the listen/notify
mechanism is not activated during test, but the subscribe method
directly fetches notifications from database and return them through
the bus.
In order to solve this issue, let's rely solely on the bus instead
of directly calling the message notification handler.
closesodoo/odoo#103590
X-original-commit: 8964453597fb01161791b2b2064f45efa42277a6
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: bus, calendar, hr_holidays, im_livechat, note, rating, snailmail,
website_livechat.
The mail mock server is getting bigger and bigger. As a consequence,
navigating/keeping it up to date is quiet inconvenient.
This commit solves this issue by splitting it by model/controller.
closesodoo/odoo#98374
Related: odoo/enterprise#32314
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Model patches are now defined using the `registerPatch` function. This
function takes an object as argument which keys match those of a model
definition.
Benefits:
+ More consistent shape between model definitions and patch definitions
+ No need to import one function to each type of patch
+ No need to repeat the model name for each type of patch
+ No need to import the original definition
Task-2998282.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#101827
X-original-commit: 7d23491b44b7372209057ea2abc565a95710b316
Related: odoo/enterprise#32136
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
*: hr, im_livechat, snailmail, website_livechat
This commit introduces the public livechat bundle, which
contains the models that are specifically used in public livechat.
Doing so reduces the amount of model and data in frontend and
external lib, which makes the page load faster.
Task-2990182
Task-2990191
closesodoo/odoo#100768
Related: odoo/enterprise#31608
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: im_livechat, website_livechat
Access right should be based on channel type and membership instead.
Chat always private, group always private, channel private should
disapear and be a group instead (migration needed), and other channel
always public (but they can still be further restricted with
the "allowed groups" feature)
task-2632861
closesodoo/odoo#90415
Related: odoo/enterprise#30980
Related: odoo/upgrade#3850
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-2961782
closesodoo/odoo#98798
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-2943607
closesodoo/odoo#97403
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-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-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-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>
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>
*: 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>
*: 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>
*: 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>
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>
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>
*: hr_holidays, im_livechat, mail, mail_bot, sms, snailmail, test_mail,
website_livechat, website_slides.
Mail tests are currently relying on this during tests to make env, widget,
data available. We don't wan't to add magic keys to this anymore.
task-2792108
closesodoo/odoo#86559
Related: odoo/enterprise#25341
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: hr, hr_holidays, im_livechat, mail, snailmail, test_mail, website_livechat,
website_slides.
This commit will remove the need to duplicate models definition for
test purposes. Indeed, for now, we need to mock the model definitions
on the client side. Those models definitions are often very different
from the ones found on the server.
This approach will allow us :
- to ease model definitions during tests
- to get closer from the real models
task-2767820
closesodoo/odoo#84828
Related: odoo/enterprise#24486
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
tsm-odoo