PURPOSE

Allow users to configure contract recurrences and Monthly Recurring Revenues
on Opportunities they're trying to close. One short revenues are not sufficient
to cover real life use cases of CRM revenu analysis.

SPECIFICATIONS

Adds an option in the settings to activate the recurring revenue feature.
This feature is set on an opportunity to indicate a revenue that could be
perceived over time. This time indicator is set by the crm.recurring.plan
model in which the number of months is determined.

By default some plans are added in data. When using plans, revenues are
computed across the plan months.

LINKS

Task ID-2283052
odoo/odoo#54194
odoo/enterprise#12423
odoo/upgrade#1463

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

As the crm.lead.tags model shall be used in CRM and/or Sales apps,
it has been moved to the sales_team module, which is a depedency
of the CRM and Sales apps.

As these tags becomes more generic than just "lead tags", the model
has been renamed from crm.lead.tags to crm.tags.

Tags on sale orders were already present but not visible. They are
now visible in the "Other Info" section, and optionally in sale order
tree views.

When a quotation is created from an opportunity (CRM app), existing tags
are populated from the opportunity to the sale order (Sales app).

Views and demo data of several modules have been updated accordingly.

Task ID 2191276

PURPOSE

This refactoring commit removes the crm.partner.binding mixin. Indeed it
defines a mixin for unnecessary fields, generally either redefined in
inheriting models, either not used at all. It also holds an utility method
we moved directly on crm.lead model.

SPECIFICATIONS

Code move

  * move _find_matching_partner to crm.lead model;
  * move action field into inheriting models, except crm.lead.convert2ticket
    that does not use it;
  * move partner_id to inheriting models;
  * remove crm.partner.binding model and inheritance;

Improve behavior

  * correctly store lead and partner many2one fields on all inheriting
    models. It allows to support a default_lead_id instead of always
    relying on active_model / active_id, making the wizards more generic;
  * update default_get accordingly in various inheriting models in order to
    correctly compute lead / partner values;

LINKS

Part of Task ID 2056759 (remove crm.partner.binding mixin)
Part of Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
Upgrade PR odoo/upgrade#750

Related: odoo/enterprise#8307
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>

Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value

account*: use account.group_account_user for all transient by default
	  remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
      additional verifications are made to ensure they are executed
      only on the documents the user has access to you
      give portal access to mail.compose.message as portal still does
      some actions like posting messages on the forum
      add ir.rule to avoid reading somebody else messages
      increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
     partner manager for actions linked to partners
     avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
     give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
	    event user inherit from  sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
    manager can set a plan according to group on button
    anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
	 as the source is an account.move
	 keep the payment.acquirer.onboarding.wizard to system user
	 only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
	       never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
      add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
	     add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation

base: base.language.*: allow employee (cf lang_install)
      change.password.user: can not read change password wizard of
      other users
      test.*: no access is needed

Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl

This new Predictive Lead Scoring (aka PLS) replaces the stage based probability mechanism.
It uses Naive Bayes probability computation theorem.

The lead probability is now computated automatically based on multiple criteria (= frequency fields).
Some are mandatory and will always be used, some are optional and can be activated
in the settings.
- Mandatory fields :
    - team_id
    - stage_id
    - tag_ids

- Optional fields :
    - email_state (validity of the email_from field: correct / incorrect or empty if email_from is empty)
    - phone_state (validity of the phone field !! not the mobile one !!: correct / incorrect or empty if phone is empty)
    - country_id
    - state_id
    - source_id (UTM Source)

PLS uses a start date to consider only the lead created after that date to generate the frequency table
and to recompute the lead probability. This date is also configurable in the CRM settings.
Default start date is date.todays() (at module install).

The settings for PLS are NOT company related :
PLS Fields = Many2many to a model that store only the fields allowed for PLS computation.
PLS Start Date = Date
As Date and Many2many fields are not allowed for config_parameters,
Char fields are used to store the configuration
and Date and m2m fields are used to ease the configuration by the user in the config panel.
Date and m2m fields are both computed fields based on their corresponding Char fields.
Char field for Date store a strigified date.
char field for Many2many store a comma separated string which is a list of activated fields.

Each mandatory field is used in a specific way
- Team_id : the frequency table is split for every team_id, plus once for leads that don't have a team_id.
Considering Lead A from Team 1 and Lead B from Team 2.
Even if Lead A and Lead B have the exact same attributes (country, phone, email,stage, ...),
their probability will most likely not be the same.
That's because each teams compute their leads' probability based on their own won/lost leads.

- Stage_id : if no optional fields are activated and if there is no tag on the lead,
this will make PLS work quite the same way as it was working with removed stage based probability,
as only the stage will count in the computation.
But here, instead of fixing manually the probability for each stage,
this stage related probability is automatically computed based on past experience (won and lost leads).

- Tag_ids : each tag is considered separatelly, as if the lead had only one tag.
(no link between tag on same lead is made). To avoid that a tag take to much importance if his subset is too
small, we include the tag frequencies in the frequency table only if at least 50 won or lost leads had this tag.

The frequency table is a table where all won and lost leads are aggregated by fields
(mandatory or optional if activated). For each team_id / field couple, we store the number of
won and lost leads that has that fields values.
For example: Lead A is assigned to team 1 and client comes from France and has been won.
If we consider only this lead A, the frequency table will looks like :
   id   |  variable   | value | won_count | lost_count | team_id
--------+-------------+-------+-----------+------------+---------
    1     country_id     FR         1           0            1

To computed the probability of a lead, we get all the records for the frequency table
that match all fields (per team_id) and we compute a won score and a lost score.
The probability is computed and normalized based on those scores
- P = S(Won) / (S(Won) + S(Lost))

Considering two variables A and B :
- S(Won) ∝ P(A∩B | Won)*P(Won) = P(A|Won) * P(B|Won) * P(Won)
- S(Lost) ∝ P(A∩B | Lost)*P(Lost) = P(A|Lost) * P(B|Lost) * P(Lost)

To overcome the 'zero frequency problem',
we do not start at 0 for the won or lost count for each variable / value combination.
It suggested to start at 1, but to avoid that a small subset take to much weight compared to
a larger one, we start at 0.1.

For example :
If we start at 1 : If team 1 has few records from France,
it can get high probability to win even if every lead where lost.

  variable   | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
 country_id     FR         1           7            1         0.125
 country_id     FR        198         7306          2         0.0263

If we start at 0.1 :

  variable   | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
 country_id     FR         0.1         6.1          1         0.0161
 country_id     FR        197.1       7305.1        2         0.0263

The more we have records for each couple, the more the computation become precise.

The allow the user to decide himself which probability should be set on the lead,
a manual probabiltiy system has been implemented using 2 stored fields + 1 computed field :
- probability (stored): Probability set on the lead, can be set manually in the lead form.
- automated_probability (stored): Probability computed by PLS.
- is_automated_probability (computed): If both previous fields are equal, the probability is considered
as automatic. and each time the automated_probability is updated, the probability is aligned.
If both are not equal, the probability is considered as manual. The automated_probability is still
updated but the probability is not aligned. The user can reset the probability in automatic mode
by clicking on the estimated probability displayed in edit mode in the lead form.

probability and automated_probability are not computed fields as they are manually computed at write and create.
The computation is triggered if one of the activated frequency fields is modified or set.
To trigger also the computation when modifying the lead values on the lead views (form and kanban),
_onchange methods have been added for each frequency field.

Also, a cron has been added to run every day to rebuild the frequency table and to recompute all active
and pending leads (not won nor lost) probability.

Task ID : 1925439
PR #33589

remove rerun cron on action lost and won

Use crm.lead instead of a the crm.opportunity.report object for
reporting. This allows to show more fields (e.g. tags_ids). The only
field not accessible in the report is #activities, but there is a
deicated report dedicated to activities.

Improved the default search. Example: when reporting on leads, you want
leads+opps by creation date (and not only leads) as an opportunity has
been a lead created too.

First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.

Also including :

 * ease default computation for res_model_id of activity types: using
   default_res_model in context it is possible to specify a default
   res_model_id. It is useful for example to give a specific context
   in configuration menus;
 * add a domain on res_model_id field in order to limit it to models
   inheriting from mail.thread and not being transient;
 * various improvement in activity type form view to ease configuration
   notably the # days renamed to planned in;

Thanks to ksa 87d531400f867a110167645e1208959723cfb6bc

Was part of PR #19820. Courtesy of Vauxoo

CRM module depends on base automation only to have some automated
actions as demo data. To avoid having unnecessary dependencies
automated action demo data have been removed. This allows to remove
the dependency between CRM and base automation.