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".
"create_lead"
Special step_type that allows creating a crm.lead when reaching it.
Usually used in addition to 'question_email' and 'question_phone' to create
interesting leads.
LINKS
Task-2030386
closesodoo/odoo#84000
Related: odoo/enterprise#24894
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This commit adapts the "button_background_color" field default value from a
grey to a purple (the same color as the default header background).
The grey color makes the button look disabled, which is counter intuitive for
visitors as they will think the livechat is not active even though it is.
Task-2030386
Part-of: odoo/odoo#84000
PURPOSE
This commits adds a special step_type on the chatbot.script.steps that allows
creating a crm.lead when reaching it.
SPECS
In addition, we let the end user configure in which crm.team that lead will
land upon being created, making it possible to sort your leads based on
previous questions.
e.g: "In which country do you live"
And based on the answer, you assign to a different sales.team.
This commit comes with the necessary business code to make this feature work
as well as some extra testing methods that ensure it is correctly implemented.
Task-2030386
Part-of: odoo/odoo#84000
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.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>
Currently, when inviting members to a mail.channel using the "add_members"
method, it is not possible to signal to web client to automatically open that
conversation in a chat window.
This commit adds a parameter to that method to allow that behavior, and also
slightly adapts the notification handling to open the chat window accordingly
on the web client side.
This is necessary for the upcoming chatbot, where we want to invite operators
to the channel and make them see the new conversation immediately.
Task-2030386
Part-of: odoo/odoo#84000
Currently, when adding members to a mail.channel using the add_members method,
we always post notification message on the channel mentioning that someone has
joined the channel / was invited to join by another user.
This commit simply adds a method parameter allowing to disable that behavior.
This change is necessary for the upcoming chatbot, where we want to add members
but handle the join notifications differently.
Task-2030386
Part-of: odoo/odoo#84000
Currently, when creating a partner, there could be a situation
in which a commerical field has some access restriction
due to `groups` being set on a the field declaration.
The `sudo()` makes sure it does not happen.
closesodoo/odoo#83205
Related: odoo/enterprise#25828
Signed-off-by: William André (wan) <wan@odoo.com>
The basic idea of this functionality is for users
to be able to put limits on Partners that would
trigger non-blocking warnings when trying to confirm new:
- Sales Orders
- Invoices
when that partner has too many open invoices.
task-2722165
Part-of: odoo/odoo#83205
In case you applied inventory in batch the system would create a lot of useless
stock moves and stock move lines.
closesodoo/odoo#87771
X-original-commit: 07f18f62db490608b316cc9482f228252ed8fc63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Current behavior:
In some particular cases bootstrap was throwing an error "Uncaught Error: Please use show on visible elements"
wich appeared on the users screens.
Steps to reproduce:
- Could only reproduce on copy of clients Db
- Go in CRM and go in any lead
- Create a new activity
- Swap to an activity with less fields
- Then quickly put your mouse on the top of a field that just disappeared
- The "Please use show on visible elements" error appears.
Here's a video where I reproduce it on clients Db : https://watch.screencastify.com/v/gksBwwF0McirZzSFwaAP
opw-2720853
closesodoo/odoo#87770
X-original-commit: 3404c9500fad4004d6d8beef6041ac51439078cd
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior :
When you delete a record (for example project.task), all the messages related
to this record aren't deleted.
This, in case a user has his notifications managed in Odoo, may prevent him
from accessing the History tab in the Discuss app because these messages are
linked to a record that doesn't exist anymore and it will raise a Missing Record
error
Steps :
*with demo data*
- Install Project
- Make Marc Demo notifications managed in Odoo
- Delete a task project to which Marc Demo is assigned
(*with Marc Demo*)
- Go to Discuss and try to access History tab
OPW-2764855
closesodoo/odoo#87732
X-original-commit: ee8feeb73c920827090b1a5ecf78e8b1d21bbae4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Steps to reproduce:
1) start from a clean database (http_routing should not be installed).
2) go to the app menu and install project (don't install via `-i`!!).
3) traceback: `request` has not attribute `is_frontend` while rendering
a template.
The `is_frontend` attribute on request is set by the http_routing
module. At the moment the "install now" button is clicked, http_routing
was not installed so the `is_frontend` attribute was not set.
FF to the end of the installation: the registry is reloaded to include
the modules that have been installed, http_routing among them.
We are in a tricky situation: (1) there is a request, (2) http_routing
is installed and (3) the `is_frontend` attribute is missing from the
request.
This situation is illegal, when http_routing is installed, the
`is_frontend` attribut should always be set. In this work we reset the
missing attributes using sensitive default values via post-init hooks.
closesodoo/odoo#87684
Signed-off-by: Julien Castiaux <juc@odoo.com>
Improve a few things in accounts modules:
- Users wants to be able to change the account in the general ledger
list view
- Do not group by date by default when auditing a tax line.
- Make the currency fields only show in debug mode for accounts and assets
- Disallow to delete taxes linked to a tax repartition line, and
clarify the error message when trying to delete one linked to a
fiscal position's account mapping
Task id # 2810379
[IMP] account_*: some Back2Basics improvements
Improve a few things in accounts modules:
- Users wants to be able to change the account in the general ledger
list view
- Do not group by date by default when auditing a tax line.
- Disallow to delete taxes linked to a tax repartition line, and
clarify the error message when trying to delete one linked to a
fiscal position's account mapping
Task id # 2810379
closesodoo/odoo#87659
Related: odoo/enterprise#25770
Signed-off-by: Laurent Smet <las@odoo.com>
* = website
Change the wording of the sms reminder template to make it sound friendlier and
more complete. The sms will include the event address if it is defined.
Otherwise, it will link to the event page if website is installed.
A one line-formatted version of the venue is added to the model to be used in
the template and other places.
This required to update `event_registration.get_date_range_str` to not include
the time when describing an event happening more than a month from the current
date, which makes sense as there is no reason to specify the time only in that
case, and we add the time somewhere else when it's useful anyway.
For consistency, Wembley Stadium is updated to London timezone in the demo
data.
Task-2777183
closesodoo/odoo#85664
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Skip the confirmation step when wanting to get rid of a notification
for emails, sms or letters that were not sent.
Technical:
- All 3 wizards to confirm the discarding of the notification have been removed
(the ones for mail, sms and letter) have been removed
- The method to discard notification has been centralized in MailThread
(notify_cancel_by_type in addons/mail/models/mail_thread.py)
- This centralization has been done as well on the client code as the same
server code is called whether it is a mail, a sms or a letter
(in addons/mail/static/src/models/notification_group/notification_group.js)
- Existing front and back test have been adapted
- A test of notify_cancel_by_type for mail has been added
(addons/test_mail/tests/test_mail_management.py)
- add missing author_id in mail_notification demo data
Task-2752190
closesodoo/odoo#84452
Related: odoo/upgrade#3246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A reorganization of the calendar alarm form view was necessary for easier
extension with new fields
(such as the one from appointment, see links).
The partner is now the author of notifications about their invitation
(instead of public user).
Task-2709580
See odoo/enterprise#23191closesodoo/odoo#82387
Related: odoo/upgrade#3383
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create a fiscal position [FPOS]
- Assign [FPOS] to a customer [DEMO]
- Add [FPOS] to the available fiscal positions of POS
- Open pos session, add a product, select [DEMO], [FPOS] will be
automatically selected. Confirm order and pay
- Click on refund button and select the previous order
[FPOS] will not be automatically selected for the refund order
opw-2799179
closesodoo/odoo#87503
X-original-commit: 4f8e257f2fc8e3d505342f9e1d6cb243a25e83e2
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Have a Reconciliation model [DEMO] without tax
Create a bank statement
Open reconciliation widget
Select 'Manual Operation', select [DEMO], add any tax
Traceback will raise
This occur because the server will generate a line without `tax_ids`
field, that will remain undefined in the frontend
opw-2777191
closesodoo/odoo#87704
X-original-commit: 08f5dc605ccf42429d6405ec6c192322909c6c34
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Because the `savepoint` and `clear` calls are nested inside the
`assertRaises` context, if one of them happens to throw *the exception
we're looking for* the interpreter will jump back to the `with`, the
`assertRaises` will swallow the exception (and count it as a success)
and the function will end having not gone through a `yield`.
This is rather frustrating to debug as it's easy to forget that a
`with` is a control flow structure, leading to a seemingly impossible
error.
We can fix this by initializing and `__enter__`-ing the savepoint
first, but doing this by hand is a bit iffy and not really
future-proof as the addition of more fallible steps during the
initialization phase of `_assertRaises` could lead to the savepoint
not being properly disposed of. Furthermore once in the scope of the
"actual" assertRaises we want the savepoint to unwind first (otherwise
the savepoint won't be rolled back when the exception *we are
expecting* gets raised).
As it turns out `ExitStack` offers the solution to our woes though
it's a bit tricky at first glance: while modifying the cleanup queue
in-place is haram, `pop_all` allows moving cleanup callbacks from one
queue to the next.
This means we can first add the savepoint to one stack and get its
errors (if any) correctly reported, cover the rest of the
initialization, then move the savepoint from one stack to an other, in
order to correctly order the coverage of the `yield` (and the userland
code).
closesodoo/odoo#87733
X-original-commit: b1cd4e4e3c918b4b08d27b30b1017fc898d4b08a
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
As it has been done for Gmail, we want to add the OAuth authentication
for the incoming / outgoing mail server.
Specifications
==============
The user has to create a project on Outlook and fill the credentials
in Odoo. Once it's done, he can create an incoming / outgoing mail
server.
For the authentication flow is a bit different from Gmail. For Outlook
the user is redirected to Outlook where he'll accept the permission.
Once it's done, he's redirected again to the mail server form view and
the tokens are automatically added on the mail server.
Technical
=========
There are 3 tokens used for the OAuth authentication.
1. The authentication code. This one is only used to get the refresh
token and the first access token. It's the code returned by the user
browser during the authentication flow.
2. The refresh token. This one will never change once the user is
authenticated. This token is used to get new access token once they
are expired.
3. The access token. Those tokens have an expiration date (1 hour) and
are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP
connection.
During the authentication process, we can also give a state that will
be returned by the user browser. This state contains
1. The model and the ID of the mail server (as the same mixin manage
both incoming and outgoing mail server)
2. A CSRF token which sign those values and is verified once the browser
redirect the user to the Odoo database. This is useful so a malicious
user can not send a link to an admin to disconnect the mail server.
Task-2751996
closesodoo/odoo#87731
Forward-port-of: odoo/odoo#87682
Forward-port-of: odoo/odoo#87040
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
As it has been done for Gmail, we want to add the OAuth authentication
for the incoming / outgoing mail server.
Specifications
==============
The user has to create a project on Outlook and fill the credentials
in Odoo. Once it's done, he can create an incoming / outgoing mail
server.
For the authentication flow is a bit different from Gmail. For Outlook
the user is redirected to Outlook where he'll accept the permission.
Once it's done, he's redirected again to the mail server form view and
the tokens are automatically added on the mail server.
Technical
=========
There are 3 tokens used for the OAuth authentication.
1. The authentication code. This one is only used to get the refresh
token and the first access token. It's the code returned by the user
browser during the authentication flow.
2. The refresh token. This one will never change once the user is
authenticated. This token is used to get new access token once they
are expired.
3. The access token. Those tokens have an expiration date (1 hour) and
are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP
connection.
During the authentication process, we can also give a state that will
be returned by the user browser. This state contains
1. The model and the ID of the mail server (as the same mixin manage
both incoming and outgoing mail server)
2. A CSRF token which sign those values and is verified once the browser
redirect the user to the Odoo database. This is useful so a malicious
user can not send a link to an admin to disconnect the mail server.
Task-2751996
X-original-commit: 18dad5b13b0af81ef2089fc039b3a866a2895a53
Part-of: odoo/odoo#87731
Purpose
=======
Do not reset the email configuration when unchecking "is Gmail".
Task-2751996
X-original-commit: d65aef9829cf5554c8d4a6c107ba5269a054ed78
Part-of: odoo/odoo#87731
Bug
===
When we copy a GMail outgoing / incoming mail server, an error
occurs because we try to refetch the access token, based on the same
authorization code (which can be used only once).
To fix this issue, we do not copy the authorization code (and other
related fields).
Task-2751996
X-original-commit: 47c056215c5f50d8a1d9e862ee275eceefdb09e7
Part-of: odoo/odoo#87731
* Redesign views
* New layout for the job kanban card + redesigned menu
* Create new reports
* Candidate Sources: get a better view on where applicants are
coming from;
* Time in Stage: shows how long an applicant is in the current
stage.
* Archiving a job archives applicants as well
odoo/enterprise#24816odoo/upgrade#3395closesodoo/odoo#85479
Taskid: 2738082
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The resequence feature and the possibility to edit the invoice number in
draft are powerful flexibility tools. Though, misusing them can lead to
holes in a sequence that can be hard to detect.
This task aims at providing alerts on the dashboard (on Sales and
Purchases journals' cards) highlighting the holes in the sections
_____________
Suppose the following sequence on a journal
BILL/2022/01/0001
BILL/2022/01/0002
BILL/2022/01/0004
> BILL/2022/01/0003 is missing.
Then show a link on this journal's card in the kanban view of journals
(accounting dashboard) mentioning.
> Check the sequence
Pressing the button opens the list view of bills on this specific
journal.
BILL/2022/01/0004 appears in red ; since it is after a hole
task-2767272
closesodoo/odoo#84788
Signed-off-by: Laurent Smet <las@odoo.com>
This commit adds an information in the topbar (thus always visible)
to indicate the number of tests that have passed, failed and the
number of tests that have been skipped.
closesodoo/odoo#87713
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In 2685472 new computed fields were added in calendar_event. This commit
updates the query counter tests that were failing.
task-2685472
closesodoo/odoo#79654
Related: odoo/upgrade#3182
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit aims to integrate the calendar module with discuss video calls.
Now it is possible to add discuss videocalls by clicking on a button below
the videocall_location field. The discuss videocall_location is a URL that
is computed and it creates a discuss channel only when someone accesses that
URL.
For recurring events, the same discuss channel is used for all events.
However, each event in the recurrency has its own videocall_location URL.
This is done on purpose in order to allow the functionality even if the base
event of the recurrency is deleted. For single events, each event will create
a discuss channel.
task-2685472
Part-of: odoo/odoo#79654
Currently in calendar if you double click an event in the calendar view, it
opens a dialog with the event title as undefined. This occurs, because the
title is not correctly passed in the context. This commit adds the correct
title to it, therefore fixing the error.
task-2685472
Part-of: odoo/odoo#79654
Italian translation added.
Add string parameter to the fields so that the filter names are more
usable. Since the filter names are taken automatically from the field
names, the string paramter allows us to change the filter names:
L10N It Edi Transaction -> FatturaPA Transaction
L10N It Edi Attachment -> FatturaPA Attachment
L10N It Send State -> FatturaPA Send State
closesodoo/odoo#87711
Task-id: 2795241
X-original-commit: 6473aa55f08d130119aceb15deee68eb041bf25e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
This commit adds a name argument to the create_group method as it is
useful to create a group channel and set its name directly on the
create.
task-2685472
closesodoo/odoo#87703
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In mail we currently create the invitation URL by concatenating the values when
needed. However this could be improved so that when this url is used in other
places we don't need to create it again. Therefore it makes sense to have a
computed field that does that for us.
task-2685472
closesodoo/odoo#87701
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In preparation of test adaptation after introducing a new way to
seed test data, the fake model present on the m2x avatar employee test
has been registered to the model definitions instead of being
declared on it's test.
task-2792108
closesodoo/odoo#87665
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When getting l10n_ar/l10n_cl starting_squence check with the proper
company (self.company_id) and not self.env.company_id
We do not put a journal_id anymore as it should take the correct one
automatically in v15.
Original commit d6f4fee58edf103c63836ac488be240961fd671a
closesodoo/odoo#87219
X-original-commit: f2f76dfa195226b7604076830412706447c168f2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this change, we have the errors that documents generated on
pre-printed sales journals mark as unified book were wrongly
named using the wrong doc prefix code.
This was visible thanks to the demo data were we notices that the credit
notes were having FA- doc prefix instead of NC-
This was because we are reusing the shared sequence directly, now we
check and fix the doc prefix for those cases and all documents generated
on shared sequences are properly named.
closesodoo/odoo#86612
X-original-commit: df5bfd22c20d3a3bd72b04acbdae63657e025ce3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently, when changing qty_producing on a MO, consumed number of each
component will always be updated. In this commit, we add a new boolean
field manual_consumption to bom.line. If checked, that line won't be
updated when changing qty_producing.
The same but invisible field manual_consumption is also added to each
line on MO. It will use the value on BOM as defualt value. When user
manually set the consued qty, it will be checked automatically. Also,
when user manually update the SML, the field on SM will also be set to
true.
Task-2687494
closesodoo/odoo#80118
Related: odoo/enterprise#25607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit:
At least if website_livechat is installed, the livechat visitor (website visitor)
country is displayed twice in channel name: once from the country inside the
name of livechat_visitor and once from the country of the actual
website_visitor.
After this commit:
Livechat visitor country will be displayed only once instead of twice
Task-2668051
closesodoo/odoo#81398
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
