When installing the website_livechat module, the `_compute_livechat_operator_id`
method is run on every record to update the value for `livechat_operator_id`.
On a large `website_visitor` table this leads to timeouts and livechat installation
stops with a traceback.
We can safely assume that at the moment of installing livechat,
no livechat operator was attributed to any visitor. initializing the value to
a default FALSE seems acceptable.
That way PostgreSQL will not need to touch the rows at all, the operation will
be instantaneous, and the actual values will be lazily initialized when the rows
are modified later.
Example, client database with +7 million `website_visitor` records to run
`_compute_livechat_operator_id` on installation:
- before commit: more than 3 hours (timeout)
- after commit: less than 3 mins
Previous implementation: cc9f59b , c426a45
opw-3095632
rebase + squash :
Switched to using the `create_column` method instead of a raw SQL query.
Added some comments in the `_auto_init` definition.
closesodoo/odoo#108570
X-original-commit: f7eae96e1aeb29a518eddd7dd18267dfc0a39fca
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
* 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>
The concept of 'parent_id' on website.visitors was introduced in the saas-13.3
stable while implementing the "event online" feature:
However, it should have been part of the website module from the start since
it's a 'global' concept that does not depend on events at all.
See #53540 for more details.
This commit aims to clean the code by moving the field to the website module,
which allows a nice cleaning of associated overridden methods as well.
Along with that, we move the website.visitor demo data from the event module to
the website module, allowing a fresh install of website to showcase some of our
visitors feature.
We also took this opportunity to do some minor improvements in the visitors
kanban view in order to make relevant information more visible.
Task-2429652
Part-of: odoo/odoo#65113
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@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>
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
This commit fixes two issues encountered during the visitor lifecycle.
1. When a visitor arrives on the website on a non tracked page, a
website.visitor is not created yet, but the visitor can still start a livechat
session. When navigating to a tracked page, a website.visitor is created but the
lifechat session already started is not recovered and the discussion is lost at
visitor's side. This commit links the already started livechat session to the
newly created visitor to ensure that the conversation can still continue
normally.
2. When a visitor logs in, his attributed visitor is linked to the partner. But
there can be only one visitor per partner. If there was already a visitor linked
to the partner, the later visitor's livechat session are updated with the
partner and the visitor is then deleted. But the visitor's livechat sessions are
not linked to the main partner visitor. So when looking at all the session the
partner had, we can only see the main visitor's livechat session.
This commit copy the livechat session of that later visitor to the main partner
visitor to ensure keeping the complete livechat history for each partner.
Task ID: 2460892
closesodoo/odoo#69402
X-original-commit: 4e1034ff2f08fa20bcdc9ac39eb2489d34a9715d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we force messages to belong to a single document using
``model`` / ``res_id`` pair. It is not possible anymore to link a message
to channels using ``channel_ids``. A message belongs to a document and
is displayed in that document's chatter.
This change implies modifying a lot of domains, notably in chatter. Indeed
discuss for channels does not use ``('channel_ids', 'in', [3])`` domains.
They now use ``('model', '=', 'mail.channel'), ('res_id', 'in', [3])`` like
other documents fetching their messages.
This commit also removes ``channel_message_ids`` field on ``mail.channel``
model. As channels are now considered as standard documents they will use
``message_ids`` field like all other documents. Linking a channel on a message
is possible only as a link in message from now on. It is not possible to push
it into a channel anymore (no more listener channels, no more channel link).
Finally a global cleaning also linked to all previous commits is done.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Purpose of this commit is to better differentiate channel members technical
model from partner members in code :
* ``channel_partner_ids``: contacts member of a channel, filtering notably
on active and checking ACLs on res.partner business model. This one
should be used whenever we deal with members of a channel at business
level;
* ``channel_last_seen_partner_ids``: memberships of a channel and technical
model. This one should be used for internal processes and members
management;
Also containing
* clean naming or API of methods managing channel members. This should
not change anything functionally as only code renaming / cleaning is
performed;
* improve performances of channel member auto subscription by aggregating
all members to add and creating them at once;
* check the use of ``mail.channel.partner`` and ``res.partner`` records
through ``channel_last_seen_partner_ids`` and ``channel_partner_ids``
Channel fields;
Functionally nothing should change with this commit. It only cleans code
in order to prepare future modifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Also fix an issue with livechats not being considered in 'chat'
filter of messaging menu.
Task-Id 2282426
closesodoo/odoo#58468
X-original-commit: 631e52536964763bbfe857305f023e5e67084e95
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose
=======
Whenever a visitor start a livechat session but finally close the session
without sending any messages, the livechat session is empty and stay in DB.
Livechat session counter counts all the sessions (with and without message)
but when opening the sessions tree view, the view is filtered by default on
session with messages. There is no reason to see the empty sessions as it
does not give any information (except "the visitor hesitated to start
livechat and finally did not" which is quite useless info)
The goal is to keep only sessions with messages.
When the visitor is closing the livechat window, if the session is empty,
the session should be deleted. But what happens if a visitor start a livechat
session, send no message and just leave the website without closing the
livechat window ? --> empty live chat session will remains in database.
The ir_autovacuum already handle the deletion of empty sessions to main a
clean DB.
Specifications
==============
- Apply 'with messages' domain on session count in the livechat channel view
- Apply 'with messages' domain on session count in the lead view
- Apply 'with messages' domain on livechat session view
- Remove With message filter
- Remove Without message filter
- If send message on a deleted session :
just tell the visitor that operator is not available anymore
AND delete livechat session cookie (as he waited 1 day to send a message)
Empty sessions becomes invisible : not possible for users to see empty session
(in count or in views) and cron is cleaning empty sessions every day.
This commit also adapts visitor session count and view accordingly.
Task ID: 2146962
PR #41065
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, only the tracked page can start the chat request at visitor
side. Which is a bit sad as the operator can send the visitor a chat request
but if the visitor goes on a non tracked page but has the opportunity to start
a livechat, the chat request won't reach the visitor.
This commit refactor the way a chat request is sent to the client side.
Instead of looking for a opened chat request on every page request,
the chat request information (if any opened) is added to the channel info
that are given to the Livechat button widget.
If the widget receives chat request infos, the widget set himself, before
starting, the cookie of the livechat session using the chat request
informations. Then, the conversation (from chat request) is automatically
loaded as any other opened chat session.
Task ID: 2081550
PR #40274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit launch a server with --db-filter that match at least 2 dbs name
Try to authenticate
You will have an error request is unbound when you try to access request.env
Now we retrieve the user from self instead of the request.
New test to ensure rpc authentication is tested.
Related to commit 245ef4b1
closesodoo/odoo#38969
X-original-commit: 4b3400c430bec7539aada0619fd203978daca2d8
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
As since 5b9a81a2c6
website.visitor.name can be null
if the visitor is not linked to a lead or a res.partner,
we cannot use the name anymore to build the name of the mail.channel, etc..
Using display_name will always return the correct value,
and will include the numbering of the visitor,
in order to identify easily the chat windows
(if operator is speaking with multi visitor at the same time)
Task ID: 2076190
PR #37340
Before this commit, the visitor cookie was expiring by default on
browser session close on firefox. On Chrome, the cookie was always
valid after browser session closing.
On Firefox, the expiration date must be set to make the cookie still valid
after closing the browser.
The same thing happened with livechat_session cookies set
in context of livechat request.
The cookie expiration date (100 years to 'never' expire) have been added.
Linked to original Task ID : 2028059
Task ID : 2060381
PR #36126
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit allows a livechat operator to send a chat request to a
connected and available website_visitor.
A visitor is considered as connected if his last tracked website.page request
was within the last 5 minutes.
A visitor is available if he doesn't have an active livechat conversation
(mail_channel with type = livechat).
- If another operator sent him a chat request
- Or if the visitor asked himself to speak with an operator
(via the normal and existing flow)
A livechat conversation is active while the visitor haven't left the conversation.
An operator cannot leave a livechat conversation, only the visitor can.
The flow to send a chat request:
- On the visitor view (tree or form), operator click on 'send chat request'
(button or livechat icon)
- A empty conversation with the visitor pops up at operator side.
- While the operator didn't send a message, the visitor won't see the conversation.
- The operator can type a message to the user
- If the operator close the chat without sending any messages,
the chat request AND the mail_channel are both deleted.
In this case, the visitor is then available to send him a new chat request.
- If the operator send a message, at the visitor's next action
(page navigation on pages that allows livechat, based on livechat rules),
the conversation will pop up at visitor side, using the livechat button widget.
The visitor won't be able to request a livechat conversation with an operator until
he leaves the chat requested by the operator.
- Once the visitor leaves (with or without rating) the conversation :
- the operator is notified that the visitor has left the conversation
- the chat request is deleted to keep the chat request table clean and minimal
- the livechat conversation if set to inactive.
- The visitor is now available again to send him a chat request.
This feature uses the already existing livechat_session cookie mechanism,
so no further code modification was needed to make this work.
It's directly integrated is existing livechat flow.
The chat_request model is only useful to quickly check if a visitor has a chat request
and to send the livechat conversation info to the visitor via the livechat_session cookie.
This commit also add a website_visitor banner info on discuss view :
To be able to quickly see all the relevant information of a website visitor
while talking with in discuss view, a fixed banner have been added.
Only the discuss view will benefit from this because detached chatter window
is to small to display such banner.
Task ID: 34624
PR #2028059
jorv