Purpose of this commit is to highlight current behavior of multi company
in lead. Notably a company is set at creation even when no team or user
is set, leading to a lot of issues when dealing with lead merge or convert.
Task-2520276
X-original-commit: dc8d82bbe032cef2f732fdfb1ded3068edc37371
Part-of: odoo/odoo#78860
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Thibault François <tfr@odoo.com>
Before, when the user clicked on a crm opportunity "meetings" smart button,
the calendar view was centered on the present day, and with default mode
(week, month,...) as a scale. This behavior leads to calendar views that
were possibly not including those meetings.
This smart calendar improves this by computing the target date and the scale
to make sure that the user is taken to the useful time period when using the
smart button from crm opportunity. The meetings considered are only the
relevant one, that is only the ones not finished yet, if there are some, and
all (finished) meetings otherwise. The calendar works as follows :
-If no meetings: show current week
-If one: show that week
-If more than one and same week : show that week
-If more than one and same month : show that month
-If more than one month, show month of the first meeting.
This is done according to user language week_start and timezone. This way
the user always see what is the most relevant.
Also added python tests in class TestCRMLeadSmartCalendar.
Task ID-2431245
closesodoo/odoo#64807
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Duplicate lead records are an issue for CRM users
To prevent sales representatives from contacting a prospect that:
- Already refused an offer from another sales
- Already accepted an offer from another sales
- Is already discussing with another sales
The purpose of this task is to inform the CRM user that there are
some possible duplicates for one lead and let the user decide how
to handle the case.
SPECIFICATION
- Add a computed field to count the number of potential duplicates.
- Add a stat button on the form view of a lead to display the number
of potential duplicates. When the user clicks on it, the leads
considered as duplicate will be displayed in a kanban view.
- Add a lost ribbon on the kanban view to quickly visualize the lead
state since the duplicates can be lost leads.
LINKS
Task ID : 2151017
closesodoo/odoo#61834
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to split assign tests related to results (leads being assigned,
with deduplication, compared to team and member domains) from tests related
to performance (query counters).
Assign process is a random process: randomizing teams leads to searching,
assigning and de-duplicating leads in various order. As a lot of search
are implied during assign process query counters may vary from run to run.
"Heavy" performance test included here ranged from 6K to 6.3K queries. Either
we set high counters maximum which makes those tests less useful. Either we
avoid random if possible which is what we decided to do by setting the seed
of random in tests.
SPECIFICATIONS
For results oriented tests remove query counters. Those tests should simply
ensure results of assign process, notably that even with random choice between
team and users we always have leads assigned with right domain and counts.
For performance oriented tests using query counters set random seed to have
a reproducible scenario and have less random in query counters.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Move sales team automatic lead assignment from website_crm_score (enterprise)
directly into sales_team. Some cleaning and renaming is performed while moving
the code as it is old fashioned.
Scoring feature is removed completely from lead assignment. Indeed we consider
PLS is a better feature and provides more accurate results.
Minimal scoring specific field on team is removed. Indeed it can also be
integrated directly into domains linked to a sales team as this is a field
directly available on lead using ``probability``. It allows to reduce fields
of team model and move all logic in the team's domain itself.
Overall behavior as been kept as close as possible from the original one.
Purpose is to avoid too much undesired changes between versions.
In this commit we also add tests for automatic lead assignment.
ASSIGNMENT PROCESS DESCRIPTION
1- LEAD TO TEAM ALLOCATION
Allocate leads to teams given by self. This method sets ``team_id`` field
on lead records that are unassigned (no team and no responsible). No
salesperson is assigned in this process. Its purpose is simply to allocate
leads within teams.
Heuristic of this method is the following:
* first we randomize all teams;
* then for each team
* find unassigned leads, aka leads being
* without team, without user -> not assigned;
* not in a won stage, and not having False/0 (lost) or 100 (won)
probability) -> live leads;
* if set, a delay after creation can be applied (see BUNDLE_HOURS_DELAY)
parameter explanations here below;
* keep only leads matching the team's assignment domain (empty means
everything);
* assign maximum BUNDLE_SIZE leads to the team, then move to the next team.
This is done to ensure every team will have leads enough to fill its
capacity based on its domain;
* when setting a team on leads, leads belonging to the current batch
are also merged. Purpose is to clean database and avoid assigning
duplicates to same or different teams;
* for all teams that still have capacity (aka: a search on unassigned
available leads with team domain still give results), do another
assignment round. Each round teams are randomized so that team order
is not always the same;
Note that leads are assigned in batch meaning a team could receive leads that
could better fit another team. However this heuristics is based on hypothesis
that team domains do not overlap. Indeed if a company has several teams they
will probably target separate market segments: country-based, customer type or
size, ... Having several teams using same assignment domain could lead to less
fairness in assignment process but this should not be the target use case of this
heuristic.
Leads are allocated by batch. This can be configured using a config parameter.
Batch size depends on cron frequency, lead pipeline size and members assignment
maximum. Finding an optimal heuristic for this parameter is not easy as it
depends on internal processes and organization. Higher batch size leads to
better performances when running automatic assignment. It can also give unfair
results if teams domain overlap or if pipeline is not big enough to fill all
teams capacity.
2- LEAD TO MEMBER ASSIGN
Main processing method to assign leads to sales team members. It also converts
them into opportunities. Its main purpose is therefore to distribute team
workload on its members based on their capacity.
Preparation
* prepare lead domain for each member. It is done using a logical AND with
team's domain and member's domain. Member domains further restricts team
domain;
* prepare a set of available leads for each member by searching for leads
matching domain with a sufficient limit to ensure all members will receive
leads;
* prepare a weighted population sample. Population are members that should
receive leads. Initial weight is the number of leads to assign to that
specific member. This is minimum value between
* remaining this month: assignment_max - number of lead already assigned
this month;
* days-based assignment: assignment_max with a ratio based on ``work_days``
* e.g. Michel Poilvache (max: 30 - currently assigned: 15) limit
for 2 work days: min(30-15, 30/15) -> 2 leads assigned
* e.g. Michel Tartopoil (max: 30 - currently assigned: 26) limit
for 10 work days: min(30-26, 30/3) -> 4 leads assigned
Assign process then follows the following heuristic
* take a weighted random choice in population;
* find first available (not yet assigned) lead in its lead set;
* if found:
* convert it into an opportunity and assign member as salesperson;
* lessen member's weight so that other members have an higher
probability of being picked up next;
* if not found: consider this member is out of assignment process,
remove it from population so that it is not picked up anymore;
Assignment is performed one lead at a time for fairness purpose. Indeed members
may have overlapping domains within a given team. To ensure some fairness in
process once a member receives a lead, a new choice is performed with updated
weights. This is not optimal from performance point of view but increases
probability leads are correctly distributed within the team.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
Purpose of this commit is to
* move tests about mass management of leads (mass assignment + mass convert
wizards) in its own file to ease writing of tests;
* add some performance tests :
* performance for assignment;
* performance for convert wizard in mass mode;
Task ID-2351604
PR #59084
X-original-commit: 950dd491bc4b680e0bcfab83815313e909a3c282
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving tests is necessary to avoid
regressions.
SPECIFICATIONS
This wizard has no tests at all. Even if it not really complex it is better
to have some tests ensuring at least marking a lead as lost with a reason
correctly updates it.
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving tests is necessary to avoid
regressions.
SPECIFICATIONS
Improve and clean tests about leads and opportunities merge.
Some strange behaviors spotted :
* user_id / team_id interaction is somehow unclear;
* probability is not taken into account in confidence level, which is very
very strange;
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
In this commit we add tests for the lead 2 opportunity converters. Indeed
it is strange that such a critical wizard has so few tests. Notably the
use of single-lead / multi-lead mode is more tested, allowing to see that
code is somewhat oldish.
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/enterprise#7656
