* 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>
Steps to reproduce:
- In CRM seetings, activate Leads
- Create a sales team with "Pipeline" selected in Sales Teams Settings
- Set a form. The action is "create opportunity" and the Sales Team is the one you created
- Send a form
Issue:
A lead will be created. Not opportunity.
Solution:
Fetch the info related to the team
opw-2856520
closesodoo/odoo#92563
X-original-commit: 1e35d5a2f832901e1269c0f133eb846350f4ba0a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Currently stat button on crm.lead form view still shows page views count of
archived visitor records. This is not coherent with the action performed
when clicking which filters out archived records.
We now correctly count only active visitors page count.
closesodoo/odoo#87574
X-original-commit: 325aaebca2d7b6b3a0e285f957e2be5736e7c69e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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
=======
It's configurable from the website editor itself.
Keep the default fields on the website model in case someone
changes its mind though.
closesodoo/odoo#82999
Related: odoo/upgrade#3210
Related: odoo/enterprise#23612
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Side effect of https://github.com/odoo/odoo/commit/69cc2911b52fd17b37fb71544574f63cf09dd17e.
On a lead, there is a smart button allowing to see his page views on the website.
In case we have many views, we are grouping them by page. Currently, the check on
the pages is made through field page_ids which is restricted to Website Editor
access group. We should allow a regular salesman to see page views without error,
and this can be achived by using field website_track_ids.page_id instead.
closesodoo/odoo#75761
X-original-commit: 76e1d609ad0e6d9a3dd2703185f4b87759823c70
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Reorganize module according to guidelines. Notably correctly name files,
split python fiels and views according to their model, split some data
to ease module organization and understanding.
Perform some code re-ordering in some big files in order to have code clearly
separated by main usage and ease future changes.
Quickly lint or update some view names.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
Purpose of this commit is to make clearer how final opportunity value are
computed or chosen when merging leads. Functionally nothing should change
with this commit.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
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
Now, compute's methods are executed on default, which leads to a crash
when these methods try to use the actual records but there isn't one
yet (e.g. at the creation of a record).
- Fix the traceback raised when creating a lead because of the
visitor_page_count method when self.ids is empty on default compute.
- Since the default_get() and the first_onchange() are also now combined,
we need to adapt the syntax of the default get for the field opportunity_ids,
replacing the array of ids by the command syntax '[(6, 0, ids)]'.
task-2325629
X-original-commit: acbc97bfe290ef3c7b8f7a1160266e49485099ae
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
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>
Lead/Opportunity type
=====================
In the settings, if ``group_use_leads`` is checked, we add the group ``use_leads`` to all users in the group ``base.group_user``
To know if the setting is checked, in the model ``crm.lead``, we compute this code,
```
self.env['res.users'].has_group('crm.group_use_lead')
```
In 12.0
=======
When we compute ``sudo``, we are as the admin user.
The admin user is in the group ``base.group_user`` and so, he can be in the group ``use_leads``,
so everything work fine.
In 13.0
=======
When we perform a ``sudo``, we keep the same user.
But the visitor is not in the group ``base.group_user`` (he is in the group ``base.group_public``)
So, the visitor can never be in the group ``use_leads``
Fix
===
To fix it, we just need to compute the method ``has_group`` as the super user (which is in the group ``base.group_user``).
```
self.with_user(SUPERUSER_ID).env['res.users'].has_group('crm.group_use_lead')
```
Task #2124421closesodoo/odoo#40418
X-original-commit: 8758bdc24297032ba8fd65f637a6990c6351dd27
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>
since e33172e832,
visitor_page_ids have been renamed into website_track_ids.
But the renaming of this field has not been applied on all usages.
This commit applies the renaming to usage in website_crm.
Task ID: 2056080
PR #36290
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
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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
This commit improves the ux in CRM by changing a few things:
- Restore the use_leads and use_quotations fields
along with their features as they were in 12.0.
- Hide the email alias if use_upportunities and use_leads
are unchecked.
- Show a link to the general settings instead of the alias_domain
if no alias_domain has been configured.
- fixes the "unassigned lead(s)" link so that
it redirects the user to the actually unassigned leads
Task: #1962182
PR: #32372
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Functional
==========
Sales teams become sales channels. Their dashboard cards now include a graph
displaying customizable data for managers (comparable to those in accounting).
By default, you now have the following sales channels (non-demo):
Direct Sales (with installation of crm or sale)
Sales Channel type: Sales
Works same as before, what's changed is:
- their cards display one big button directing to the start of their
workflow
- the links on the right-hand side have been reworked, and are only
displayed when there is at least one item requiring attention.
- 'More' tab remains unchanged.
Website (with installation of website_sale)
Sales Channel type: Website
Differences lies in the links displayed in the dashboard card:
- it displays abandoned carts, awaiting payments and payments to capture
Default Channel linked to all sales made from the eCommerce.
Point of Sale (with installation of sale and point_of_sale
-> auto-installs pos_sale)
Sales Channel type: Point of Sale
Linked to pos.configs and their pos.sessions and pos.orders.
- only links to their linked pos.config dashboard and open sessions
- can't use opportunities, lead or invoicing and can only display
pos.order data in the graph.
Default Channel linked to the default pos.config.
Technical
=========
- Add a channel type: sales, pos, website that have different actions/settings
- Add a graphs to the kanban cards in the sales/crm dashboard, configurable in
the form view in the new dashboard page.
- Rename sales teams to sales channels, rename and add default and demo sales
channels
- Change dashboard links depending on the channel type and add a related
computed fields on crm.team
- Rename strings and improve channel form view.
- Leads are now checked by default once activated for 'sales' type channels
- Disable checking "leads" without using "opportunities".
- Hide invoicing and invoicing target depending on channel type.
- Move currency_id to sales_team
To set utm values (medium, source and campaign) on created record, the
system use default function which check cookies and other funny things.
But for website form creating a record, the medium value would be
overrided always to Website whilst that should be a fallback (and the
set medium should have priority).
closes#10848
opw-668853
In ddac26c `crm.crm_medium_website` was replaced by
`utm.utm_medium_website`.
There was one place where it was not reverberated so the medium_id was
always unset in that instance (a crm.lead created from a website form).
opw-668853
note: equivalent of saas-6's 3ea3348
Romain Derie