*: 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>
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>
when we are using the sharable support page (url : "/im_livechat/support/"),
There is no "visitor left" message sent to the operator when any visitor left
the channel.
Ideally, when any visitor left the channel from the website or the support page
should notify the operator that "Visitor has left the conversation".
With this commit, the operator will get notified every time when visitor left
the conversation from anywhere.
Task-2210040
closesodoo/odoo#87414
X-original-commit: 8c6affdb7a59436c6fdba1ad0a7c68a7273c0468
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@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>
Move model definition files from `models/thing/thing.js` to
`models/thing.js` and remove the now empty intermediate directory.
Task-2759582
* = calendar, crm_livechat, hr, im_livechat, mail_bot, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#86464
Related: odoo/enterprise#25291
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: calendar, hr, hr_holidays, im_livechat, mail, mail_bot, note, sms, snailmail,
website_livechat, website_slides.
This commit prepares the removal of beforeEach function in the
mail test suite. Cleanup was relying on beforeEach adding widgets,
components, unpatch method 'this'. We need to clean things up without
using either beforeEach or 'this'.
task-2792108
closesodoo/odoo#86526
Related: odoo/enterprise#25326
Signed-off-by: Sébastien Theys (seb) <seb@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>
*: calendar, hr, hr_holidays, im_livechat, note, sms, snailmail,
website_livechat, website_slides.
This commit prepares the ground for the model definitions PR.
In order to reduce the noise, all mail module's beforeEach
functions will be made async.
task-2767820
closesodoo/odoo#84845
Related: odoo/enterprise#24489
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Rename javascript model `website_livechat.visitor` to `Visitor` in order
to distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81440
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.partner` to `Partner` in order to
distinguish javascript models from python models.
Part of task-2701674.
* = hr, hr_holidays, im_livechat, website_livechat
closesodoo/odoo#81406
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.country` to `Country` in order to
distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81331
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Rename javascript model `mail.thread` to `Thread` in order to
distinguish javascript models from python models.
Part of task-2701674.
* = hr, hr_holidays, im_livechat, website_livechat
closesodoo/odoo#81433
Related: odoo/enterprise#22910
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.messaging_notification_handler` to
`MessagingNotificationHandler` in order to distinguish javascript models
from python models.
Part of task-2701674.
* = im_livechat, website_livechat
closesodoo/odoo#81389
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, on touchscreen device, when we clicked on the
livechat button, the popover remained visible over the chat window.
After this commit, the popover is never displayed on touchscreen devices
to avoid this bug but also because it makes no sense to have a popover
on touchscreen devices in this case.
task-2677132
closesodoo/odoo#81151
X-original-commit: 556168efd20727e044a9825435cdc887821a4f80
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = website_livechat
Before this commit, some elements (e.g. sidebar, livechat button) were
not correctly positioned in edit mode or/and full screen mode.
task-2677132
X-original-commit: 42db4d432d39a8db87c66cd682064ab76fd0aa27
Part-of: odoo/odoo#81151
After this commit:
- The livechat button is redesigned as a floating icon in website.
- The "colliding" check between buttons and bottom fixed elements is no
longer done only on the buttons but also on the <a> elements.
- When the livechat button hides a button/link, it is moved up rather
than made invisible.
task-2614762
closesodoo/odoo#78891
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
* = calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot, sms,
snailmail, website_livechat
This commit will change the declaration of the models with the aim of
getting closer to a plain JSON-object. It allows us to eliminate a wide
portion of boilerplate code, making the declaration shorter, more
declarative, and less redundant, but mainly, it prepares the ground for
further changes.
Task-2695223
closesodoo/odoo#79259
Related: odoo/enterprise#22042
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>
* = hr, hr_holidays, sms, snailmail, website_livechat
Message model incorrectly contained data related to a specific component (only
one) even though there can be multiple message components per message model.
This cascaded to adapting related component/models to the same principle.
closesodoo/odoo#76718closesodoo/odoo#77779
Related: odoo/enterprise#20964
Related: odoo/enterprise#21426
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: hr_holidays, im_livechat, sms, snailmail, website_slides
Most messaging related components have common needs concerning
subscribing to model changes, and not needing to be rerendered unless
their props change. Previously, most components would call the hooks
"useModels" and "useShouldUpdateBasedOnProps" individually. Messaging
components also depend on one another quite a bit, requiring a lot of
explicit imports of other components. It would also be useful to be able
to have cyclic dependencies between component (eg Message renders a
component that allows to delete the message, and the delete component
renders the message in a confirmation dialog), but that doesn't work
with explicit imports (the odoo module system doesn't support cyclic
dependencies).
This commit adds a Component decorator that:
- Registers the component in an internal registry
- Makes all components in this registry available at render time to
components that have been registered in this way
- Calls the useModels and useShouldUpdateBasedOnProps hooks during
component initialization (setup)
enterprise PR: odoo/enterprise#20304closesodoo/odoo#74982
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: web, website_livechat, website_sale_comparison
Before this commit, bottom fixed elements (e.g. the livechat button)
hid the buttons to go to the next step in website sale when these
buttons are located at the bottom of the page, on some screen sizes.
After this commit,
- A bottom fixed element is hidden if this element hides a button at
the bottom of the page.
- Bottom fixed elements are hidden if a modal is open
to prevent it to hide buttons or any important part of the modal.
task-2501400
closesodoo/odoo#74515
X-original-commit: a851db9495fe9d8c1951f218a71e4d4a427cf96d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = hr, hr_holidays, im_livechat, sms, snailmail, website_livechat,
website_slides
Exporting directly on the line of the class or variable definition is less lines
of code and less repetition (and risk or mistake).
Exporting with a name instead of default allows to catch typos more easily when
importing and ensures the same name is used for consistency (and ease of grep).
closesodoo/odoo#72597
Related: odoo/enterprise#19224
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
currently, Across Odoo, there are bugfix folder in around 13 module,
New manifest system allows to add new files in stable so the bugfix files are no
longer required.
after this commit,
all the bugfix files are removed from all module.and all the code in those file
is maintained as per New manifest system.
Task : 2510653
closesodoo/odoo#69830
Related: odoo/enterprise#17936
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* hr, hr_holidays, im_livechat, mail, snailmail, website,
website_livechat
This commit removes `patchMixin` and improve `utils.patch`.
`utils.patch` now supports native classes and has a new parameter
used to patch class members.
`utils.patch` is now used everywhere `patchMixin` was and it must
be used to patch classes.
closesodoo/odoo#65967
Related: odoo/enterprise#16278
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: ged-odoo <ged@odoo.com>
* = hr_holidays, im_livechat, website_livechat
A huge amount of components where rendered for no reason, notably when typing a
new message (at every key press), which significantly slowed down the interface.
There were 2 causes to this number of renders:
- OWL rendering all children automatically, even if their props didn't change,
unless `shouldUpdate` is overridden, which is now done.
- `useStore` selectors being way too generous in what they observed
task-2399731
closesodoo/odoo#64958
X-original-commit: a0472425251d429a0828eff1675c84b3f24527d8
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: im_livechat
Also, fix its unopened position so that it stays at the same horizontal
position when opened.
task-2369225
closesodoo/odoo#61898
X-original-commit: eb3aa203fa3033b6583a6ffddca7e80e6e1de0d2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
tsm-odoo