Purpose
======
When offering services, it is critical to make sure that the time being
delivered is billable. Otherwise, the company is loosing money.

## Details

Two fields have been created in product.template:

1. service_upsell_warning
2. service_upsell_threshold

The first one is a boolean, if it is checked then the second one is
displayed to add a threshold. This threshold is used to create an upsell
activity because the (qty_delivered / qty_ordered) in a SOL of this product
is greater than the threshold defined in the product.

Moreover, when the following condition for a SOL:
(delivered quantity / ordered quantity) >= threshold set in the product
is True, then we display an upsell warning for the corresponding
SO. The problem is we don't check if the warning has already displayed
by a certain SOL. Thus, each time we timesheet for this SOL, we display
one more time.

To avoid to spam the salesman, we add a new boolean field in 
sale.order.line, this field will be True if the warning upsell activity is 
shown thanks to the SOL.

A method is added in sale module to create the upsell activity for each SO.
This method is used in sale_timesheet module to avoid duplicated code.

Finally, an unit test has been added to check the feature.

task-2411291

RATIONALE

For historic as well as internal reasons many CRM features were added into a
module called "website_crm_score". This module was mainly developed to manage
Odoo's prospects based on our own processes and rules. It included

  * automatic lead assignment on teams, based on a score (lead scoring) and
    team- and salespersons- specific domains;
  * support of web pages (page views);
  * support of multi sales team membership for salespersons;

This task aims at dismantling this module to make sure those valuable features
can be used by all CRM users

  * lead assignment is moved into CRM;
  * lead scoring is replaced by PLS and automatic probabilities computation;
  * page views is now managed through visitors;
  * multi sales team memberships is moved into CRM;

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: SALES TEAMS MEMBERSHIP

Move sales team membership model from website_crm_score (enterprise) directly
into sales_team. It allows to have the base requirements to correctly handle
mono and multi sales team for salesperson.

Membership is modeled using a decorated many2many relationship. Members of
a sales team are res.users. Subscriptions are crm.team.member linking a team
and an user. It is a rename of team.user model coming from website_crm_score
as well as some other relational fields renaming.

Part of old team.user model is moved directly to sales team, part of it to
crm module (notably assignment limits). Its support will be improved in the
upcoming commits. Assignment related fields will be cleaned and used when
moving assignment directly into CRM.

SPECIFICATIONS: MONO / MULTI TEAMS

Purpose of this commit is to allow to use either mono salesteam mode, either
multi salesteams mode. Basic CRM use mono membership: a salesperson belongs
to a single sales team. It is however possible to choose to work using multiple
memberships. This is configured through a configuration parameter available in
CRM configuration settings.

Mono salesteam behavior
  * a given user can be member of a single sales team at a time;
  * when moving an user from team to team, its existing memberships are
    archived to keep history of what has been done within this team;
  * display an alert when creating a new team member that would archive
    existing memberships;
  * displayed members on team form view are directly res.users records to
    avoid displaying unnecessary layer when using a simple CRM;

Multi salesteam behavior
  * a given user can be member of several sales team at a time;
  * unicity contraint (user_id, crm_team_id) is still enforced;
  * displayed members on team form view are crm.team.member records as
    advanced configuration can be done directly at that level;

In all cases when adding a new member check for archived membership before
creating it. If an archived version of the member exists it is unlinked in
order to avoid breaking the unicity constraint.

Archived memberships can be managed in its dedicated menu for advanced sales
team use.

SPECIFICATIONS: COMPANY-BASED DOMAINS

Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.

When using mono membership mode
  * members are res.users records;
  * a domain is added on users to belong either to the team company, either
    to all available teams if team has no company;

When using multi membership mode
  * members are crm.team.member records;
  * a domain is added on user_id field of membership records so that they
    belong either to the team company, either to all available teams if team
    has no company;

Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.

SPECIFICATIONS: CHECK_COMPANY

``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.

SPECIFICATIONS: LEAD ASSIGNMENT

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.

SPECIFICATIONS: REMOVE WEBSITE CRM SCORE

Remove website_crm_score module as its core business is not moved. Scoring
itself is not used anymore as it is replaced by automatic lead computation
(PLS) and all other features are moved to core CRM application.

SPECIFICATIONS: IMPROVE ASSIGN PROCESS

Various commits are added to improve assign process. See sub commits for
more details. Global behavior is not changed but details are improved like

  * include leads with probability being 100 but still not won
  * ensure automatic assignment works out of the box
  * continue filling salespersons pipe when they win leads
  * improve team opt-out from lead automatic assignment
  * limit allocation to teams when running automatic assign
  * log manual assign and improve feedback message
  * simplify evaluation of assignment domains

LINKS

Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#9499
Upgrade PR odoo/upgrade#996

RATIONALE

For historic as well as internal reasons many CRM features were added into a
module called "website_crm_score". This module was mainly developed to manage
Odoo's prospects based on our own processes and rules. It included

  * automatic lead assignment on teams, based on a score (lead scoring) and
    team- and salespersons- specific domains;
  * support of web pages (page views);
  * support of multi sales team membership for salespersons;

This task aims at dismantling this module to make sure those valuable features
can be used by all CRM users

  * lead assignment is moved into CRM;
  * lead scoring is replaced by PLS and automatic probabilities computation;
  * page views is now managed through visitors;
  * multi sales team memberships is moved into CRM;

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 AND IMPROVE MEMBERSHIP MODEL

Move sales team membership model from website_crm_score (enterprise) directly
into sales_team. It allows to have the base requirements to correctly handle
mono and multi sales team for salesperson.

Membership is modeled using a decorated many2many relationship. Members of
a sales team are res.users. Subscriptions are crm.team.member linking a team
and an user. It is a rename of team.user model coming from website_crm_score
as well as some other relational fields renaming.

Part of old team.user model is moved directly to sales team, part of it to
crm module (notably assignment limits). Its support will be improved in the
upcoming commits. Assignment related fields will be cleaned and used when
moving assignment directly into CRM.

SPECIFICATIONS: MOVE ASSIGNMENT

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.

SPECIFICATIONS: REMOVE WEBSITE CRM SCORE

Scoring module can now be removed as

  * scoring itself is not used anymore and is replaced by probability on
    lead using PLS;
  * rule-based scoring update is considered as not relevant compared to
    automated probably update by PLS;
  * members management has been moved to CRM and improved allowing to be
    in mono- or multi- membership modes;
  * automatic assign to teams and salespersons is moved to CRM and improved
    allowing more configurable behavior;
  * rule-based tagging et lead management (unlink) can be replaced by
    automated actions;

LINKS

Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#9499
UPgrade PR odoo/upgrade#996