* 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>
PURPOSE
Visitors are useful in terms of marketing analysis but they can bloat the
database really quickly if you have a lot of traffic on your website.
This commit aims to relieve the database by fully deleting inactive visitors.
SPECS
On an active website, you can easily reach hundreds or even thousands of
visitors per day.
While active visitors are useful for marketing purposes, inactive ones were
archived after a period of inactivity (i.e: not connected for X days in a row,
where X is configurable as a parameter and 30 by default).
But archiving visitors is not really useful either.
We don't see any specific cases where you would want to restore some visitors.
That means we are better off unlinking the visitors completely to save database
storage space.
We want to make exceptions and avoid deletion of inactive visitors in some
cases:
- When they are linked to a partner (meaning most likely linked to a
registered user)
- When they are linked to leads
- When they are registered to events
Several tests were added to ensure that leads matching these conditions are not
unlinked.
We also took this opportunity to enforce the "_link_to_visitor" rules in those
tests to make sure that:
- When visitors are linked, the leads are merged into the main visitor
- When visitors are linked, the event tickets are merged into the main visitor
- When visitors are linked, the wishlisted tracks are merged into the main
visitor
This is also preliminary work for a commit that will move the push_token of
website.visitors to a separate table.
That will in turn allow us to link the push_tokens within the
"_link_to_visitor" method and delete the linked visitor instead of archiving
it.
LINKS
Task-2410217
Part-of: odoo/odoo#65113
PURPOSE
Prepare sales team membership and lead assignment improvements by
reorganizing and cleaning some code bits.
SPECIFICATIONS
Tools methods should be private by default to indicate those are not part of
official convert or merge API for leads. In this commit we make convert and
merge tool methods private, keeping only main API methods public.
LINKS
Task ID-2428882
Prepares Task ID-2086889
COM PR odoo/odoo#64196
ENT PT odoo/enterprise#15610
Currently there are several limitations in visitor email and phone
computation, notably phone of partner is not taken into account (only mobile)
and computation does not work in website_crm if there are no leads.
In this commit we
* support both mobile and phone fields of partner. Indeed generally all
SMS flows check for those two fields and not only for mobile;
* replace the SQL by standard ORM computation. As those fields are not stored
and displayed in list views ORM should be capable of managing them;
* avoid crash when creating visitors through the UI (no ids -> don't go
into raw SQL);
* correctly keep partner-based values when no lead is linked to the visitor;
Tests are also added in order to ensure behavior.
Task ID 2196869
closesodoo/odoo#48369
X-original-commit: 02ceb42e204be2b40b334b4e554eef6dfaffd228
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
As CRM is going to be updated (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving code is a necessary first
step.
SPECIFICATIONS
Purpose of this commit is to rewrite code located and/or used in convert or
merge wizards. Indeed it holds unnecessary variables, dictionaries manipulation
that hides the real business flow, badly named variables, unclear methods, ...
Logic of those wizards seem quite simple but is hidden behind a wall of
bloated code.
Notably for wizards
* try to set explicit arguments in methods;
* less use of context values, replaced by arguments when possible;
* try to make better use of lead2opportunity wizard in its mass wizard that
inherit from it, notably by correctly calling super;
Notably for tools
* ``get_duplicated_leads`` was just a shortcut to ``_get_duplicated_leads_by
_emails``;
* ``_get_duplicated_leads_by_emails`` is renamed to ``_get_lead_duplicates``
because email is not the only way of finding duplicates;
* try to make better use of record sets instead of propagating ids, notably
for partner. For example input of ``_get_lead_duplicates`` or output of
``_find_matching_partner``;
* ``_create_lead_partner`` rename to ``_create_customer``, and its sub
method ``_create_lead_partner_data`` to ``_prepare_customer_values``;
* ``handle_partner_assignation`` was difficult as its use is not documented
and its docstring was not updated. Parameter have been renamed to be more
explicit about what it does. Method is renamed to ``handle_partner_
assignment`` as assignation has other meaning in English;
* ``allocate_salesman`` is renamed to ``handle_salesmen_assignment`` to match
the partner assignement and code is slightly cleaned;
No functional change should occur with this commit. Tests have been gradually
added to try to ensure behavior does not change.
LINKS
Task ID 2088565 (crm: from onchange to compute)
Purpose of this commit is to clean mail and SMS composer calls in website_crm
and website_crm_sms by separating composer preparation (context, values) from
customer preparation (check valid data exists, creating partner).
Indeed most of message composer code is based on records having a partner_id
correctly set, unless some templates are used that dynamically creates the
partner. SMS composer is more tolerant and check for phone / mobile numbers to
use.
By the way we make the action name translatable, because why not.
LINKS
Spotted when working on task ID 2056759 (remove crm.partner.binding mixin)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
Try to understand a bit this code with comments. Some unnecessary code is
removed, and some parameters are added to try to understand the various flows,
but main purpose is to understand that mighty spaghetti, not destroy it.
LINKS
Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterpreise#7656
Related: odoo/enterprise#7656
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a lead entered a wrong email address in the contact form,
this crashes when loading visitor view.
We were doing a email concatenation to have all the email address
of the leads linked to the visitor.
But as it is a cornet case that shouls not happens often
(to have multiplus email address linked to the visitor)
we will only keep the last email addresse entered by the visitor.
Task ID: 2077182
PR #37472
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit allows to send an email to a visitor if the visitor
is linked to at least 1 lead that has a valid email address.
If multiple leads have valid email address, email field on visitor
will contain a comma separated list of the leads' valid emai addresses.
Task ID: 2056080
PR #36290
In order to keep all the visitors from all the leads to merge,
the relation between leads and visitors becomes a many2many.
So that after the lead merge, a lead can have multiple visitors.
This commit re-add the page view stat button that were removed
during website_visitor introduction and page tracking refactoring.
This button counts all the pages views from all the visitors linked
tho the current lead. Clicking on it redirect to the complete
navigation history, from all visitors linked to the lead.
Task ID : 2057428
PR #36180
If a website_visitor submit a contact form (and becomes a lead),
the website_visitor is linked to the crm.lead.
the website visitor name is than adapted to match the name of
the first crm.lead linked to the visitor, ONLY if the visitor doesn't
already have a res.partner.
A visitor can have multiple crm.lead as he can send multiple
contact form and create multiple leads.
Task ID: 34624
PR #2028059
Romain Derie