Currently phone_sanitized computation on lead model works only if crm_sms
is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
dependency hides the issue as those modules are auto-install. However if
``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.

Task ID-2528169
Oversight of odoo/odoo#45315

Purpose of this commit is to improve phone, email and mobile synchronization
tests for lead / partner. Notably

  * mobile is not synchronized: only a void mobile is set to partner's mobile
    when changing partner. It is not synchronized back onto partner;
  * email / phone are correctly synchronized;
  * phone_sanitized is computed on both lead and partner based first on mobile
    then on phone. It means records having the same phone numbers could have
    different phone_sanitized values if mobile numbers differ;

Task ID-2461308
PR odoo/odoo#66890

Add tests related to lead / partner contact fields synchronization. Add tests
with user input and/or partner synchronization to ensure editable stored fields
work as expected on lead model.

Warning: those tests are failing. Next commit will split computed fields into
several methods in order to fix computation.

LINKS

COM PR odoo/odoo#65381
Task ID-2451339

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

RATIONALE

Activities are a way to organize our daily pipe. Notably in a sales pipeline
salesmen may have multiple leads with activities to perform in the next few
days. We would like to be able to have a list view displaying a list of leads
with "my" deadline, and to order leads based on this field.

PURPOSE

As activities are linked to records through a one2many and as my activities
are only a subset of those activities, it is impossible to store a field
on lead model. Indeed it would depend on the current user which makes storing
it impossible.

However ordering on a column in list view asks for a stored field. As it is
not possible, this commit proposes to hijack the web client and search of lead
model in order to allow it.

SPECIFICATIONS

Introduce a activity_date_deadline_my field, computed and searchable that
behaves like activity_date_deadline. It is filtered on current user activities
instead of being global to the record activities. "My" deadline is the earliest
deadline of my activities, even in the past.

Ordering through web client calls search_read with an order parameter set.
Search_read then calls search. In this commit we therefore override search
to intercept a search without count with an order on activity_date_deadline_my.
In that case we do the search in two steps.

First step: fill with deadline-based results

  * Perform a read_group on my activities to get a mapping lead_id / deadline
    Remember date_deadline is required, we always have a value for it. Only
    the earliest deadline per lead is kept.
  * Search leads linked to those activities that also match the asked domain
    and order from the original search request.
  * Results of that search will be at the top of returned results. Use limit
    None because we have to search all leads linked to activities as ordering
    on deadline is done in post processing.
  * Reorder them according to deadline asc or desc depending on original
    search ordering. Finally take only a subset of those leads to fill with
    results matching asked offset / limit.

Second step: fill with other results. If first step does not gives results
enough to match offset and limit parameters we fill with a search on other
leads. We keep the asked domain and ordering while filtering out already
scanned leads to keep a coherent results.

All other search and search_read are left untouched by this commit to avoid
side effects. Search_count is not affected by this commit.

As web client order availability is simply based on field being stored we
have to allow hijacking its value. A new option 'allow_order' is added that
display the order icon in list view column headers. It allows calling
search_read with an order based on the column but nothing more. Using it
on a not-stored field will give a warning log and ORM ignores it by default.

LIMITATIONS

At least following limitations apply

  * search on "my activities" gives a list of ids that is used for searching
    and ordering. It means that having too much activities on a given user can
    result in poor performances.
    -> we consider that activities assigned to a given user should be kept
    under control. Leads with activities for a given user should be a small
    subset of leads without activities.
  * ordering on activity_date_deadline_my always put those records on the top
    (deadline asc or desc) whatever the actual ordering of order items given
    to search. This is done to avoid complex implementation where deadline
    would be used to order records within groups ordered by another field.
    -> for example: order = 'priority DESC, activity_date_deadline_my ASC'
    actually behaves like 'activity_date_deadline_my ASC, priority DESC'.

WARNING

This implementation is a hack. It has been done by professionals. Do not try
to do it at home.

More seriously this is hackish and should be avoided. IN our case we consider
that the use of activities in sales pipeline is mainly driven by "my activities
deadline", which is not necessarily the case with longer processes like tasks.

Moreover user tests tend to show that this feature could be interesting. It
will improve quality of Odoo CRM and its adoption by improving its daily
use. A framework solution has to be found. Until this is done we keep this
hack and hope it is not duplicated in other applications.

LINKS

Task ID 2276011
Prepares Task ID 2243124 (My activities in CRM)
PR #52232

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

PURPOSE

Get rid of email / phone behavior on lead that is hard to understand: if
and contact is set fields are readonly, if not they are editable.

SPECIFICATIONS

We want to be able to edit them if a partner is set. If we write on the
email/phone of the lead, it should write on the partner (and vice-versa).

Even a Falsy value is propagated to the customer. Reason is that if you update
a contact information, it should be available for all other records. Setting
a void value probably means you want to stop contacting this contact. This is
now also propagated.

SIDE NOTE: MOBILE FIELD

Mobile field is a bit different. Main phone contact field is phone, and is
placed in the main contact section of the lead view. Mobile is under a more
technical / detailled tab and is not completely synchronized with the partner.
Like zip, city or country, changing partner updates lead information but
changing lead values does not propagate those to the customer. Those fields
can be used for deal-specific information if needed.

Statistics: 5k crm.lead use mobile for 80k active records which means it is
a "lesser field".

LINKS

Task ID 2207636
PR odoo/odoo#48395
Upgrade PR odoo/upgrade#1025

PURPOSE

Prepare enhancements of sales team membership.

SPECIFICATIONS

Purpose of this commit is to prepare modifications in sales team management
notably by cleaning sales team tests. We also move some data preparation in
sales team. It allows to rely on some common data while doing sales team
then crm tests.

LINKS

Task ID 2086889 (sales team enhancements)
Task ID 2234698 (preparation lint)
Community PR odoo/odoo#49520

PURPOSE

Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.

SPECIFICATIONS

Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.

Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.

Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.

SPECIFIATIONS: CONSTRAINT USER_ID / TEAM_ID

In this commit we also remove all the better implementations of "not really a
constraint" constraint about user_id and team_id. Indeed as this is a computed
field normally we should not have to call the onchange manually, even through
a hackish call to a falsy constraint (see fdc8749, 222cca2, 4e8ebc7 ). You are
all inferior to SM team.

SPECIFIATIONS: DATE_OPEN

Assignment field, namely ``date_open``, has a random definition as it seems
linked to assignation, with several behaviors intended

  * ce39ca8a978bfc2d4c431693fa4c56610fd14368 : reset only when going from
    no salesman to a salesman (aka, keep assignation when changing)
  * 8e540558ee1670dc32f00c6fc8cbb04838b4b972: reset when changing salesman

We choose to keep first implementation as it seems a bugfix broken again
by second commit. It will also replace the ``assign_date`` defined in
``website_crm_score`` module.

SIDE EFFECTS

Several side effects occur with this commit. Indeed behavior is not always
exactly the same, notably as code rewriting allowed to fix some issues,
incoherent behavior or was simply not able to achieve exactly the same
result. Notably

  * at lead creation: default probability is the one coming from PLS and not
    0.0 anymore, since field is already computed. Synchronization with PLS
    still works the same way (change probability, you are out of syn);
  * various user_id / team_id combinations notably in convert / merge wizards
    may change, notably we do not reset team_id if user_id is reset. We
    consider we could keep a team_id set without user_id;

LINKS

Task ID 2088565 (crm: from onchange to compute)
Upgrade PR odoo/upgrade#781

Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Florent Lejoly <fle@odoo.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

Add tests. Amazing. Notably about matching partner / duplicate based on email
as there is some weird behavior.

closes odoo/odoo#45477

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

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

After ff6b35f759c64e49db787775e5df150ce0f53f9a that added some first tests, this commit will add more tests
notably about convert wizards.

Notably

  * add tests for crm.lead2opportunity.partner wizard, notably options about
    action (do nothing, exist or create partner), as well as some corner cases
    like stage update, lost leads, ...
  * rewrite and improve tests about crm.lead2opportunity.partner.mass, aka the
    mass converted wizard that implements some random behavior on top of the
    crm.lead2opportunity.partner wizard;

Some strange behaviors spotted

  * partner action works on lost leads, but not the convert;
  * user_id / team_id / stage_id coherency is not enforced during convert
    as it relies mainly on onchanges that are not called;

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