This commit changes the method _get_default_team_id so that it removes
the xmlid reference to the default team. Instead, we will now use
the team sequence (with default team's sequence being set as 1)
and falling back to the next team with the highest sequence if the
default team got deleted.
Therefore, teams will now be ordered by sequence instead of name,
allowing the users to reorder their teams as they see fit
This commit also removes useless sudo when searching teams
Task: #1962182
PR: #32372
wip
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
By default the main Leads menu doesn't have a submenu anymore
But when the website_crm_score module is installed, it appears
as a submenu like before
PR : #34595
Task ID : 2031626
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = website_crm_partner_assign
Purpose of the commit is to set the new attribute OPTIONAL = SHOW/Hide on tree
view so the user can easily hide/show the optional fields on the tree view.
task-1997453
Closes: #33888
Purpose
=======
Currently, when we click on “Settings” on the Home Dashboard, we arrive
on a new Dashboard with several pieces of information like Installed Apps,
invite new users, or translations. Some informations are reachable in
several ways, which is not necessary.
We would like to remove this page and replace it with the General Settings
page directly. That makes more sense to the user who click on “Settings”. The
present informations will be dispatched in the menu or in the general settings
for a better usability.
Specification
=============
This commit move code from web_settings_dashboard in order to put the features
in settings directly. To do so, we choose to move code to base_setup, and create
widget on the settings form view to keep features. Concerned features are: invite
users, dev tools, odoo edition number and IAP account link.
TaskID: 2006910
closesodoo/odoo#34290
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now we can deselect all the optional fields to compute the predictive
lead scoring.
Task 2028666
closesodoo/odoo#34614
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit f60825b439 moved phone validation addition on res.partner model
from a specific module to crm directly. However the inherit from the validation
mixin class was forgotten, leading to a crash when changing phone from the UI.
closesodoo/odoo#34545
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Backport from 12.0 to 11.0 (commit: 3cbdfe8807)
- Have two crm teams with the same team leader, and without team members
(team1, team2 as instance).
- Create a new lead, add as Salesperson the team leader, and as Sales
team the second previously created team (team2).
- Save the new lead.
Before this commit, when we save the lead, the sales team will change,
to set the default sales team for the chosen Salesperson, in this case
team1.
opw-2005924
closesodoo/odoo#33898closesodoo/odoo#34327
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce:
- Go to CRM > Reporting > Sales Channels
- Click on link Open Opportunities,
Bug:
It displayed all the opportunities instead of just the open opertunities.
opw:2009808
closesodoo/odoo#34365
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The 'predictive lead scoring' task (#1925439) changed the way stages are marked as 'won'.
This introduced a bug in the 'Won' filter of the crm 'Activites' reporting view.
This commit correctly applies the domain on the 'is_won' property of the crm.stage.
Task #2009515closesodoo/odoo#34087
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
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
This commit prepares the next Predictive Lead Scoring (aka PLS) ones.
With the new PLS implementation, stage based probablility is not relevant anymore
as the probability will be computed based on multiple criteria
following the Naive Bayes probabilist theorem.
To determine if the stage is a won stage, a new 'won_stage' boolean field replaces
the old probability field that is now removed.
won_stage = True is equivalent to stage.probability = 100.
Task ID : 1925439
PR #33589
This commit moves phone validation from bridge module to crm directly.
This commit prepares the PLS feature (see next commits).
PLS needs the phone state to evaluate the probability to closes a lead.
So as crm will depend of phone_validation, the content of the bridge
module is moved in crm module.
Task ID : 1925439
PR #33589
PURPOSE
We want to integrate SMS with crm.lead in the same way it is integrated
with res.partner.
SPECIFICATION
Add phone/SMS widget on 'phone' and 'mobile' to call the same 'Send sms' modal
than on partner. This modal can also be called from the action menu in list
view. This modal should behave the same as for res.partner (same number
selection and warnings). The SMS text message should also be logged in the
chatter (similarly to res.partner)
SMS sent in batch should be logged in the chatter of the corresponding record.
Linked to task 1925950
Part of PR #34864
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Some formviews are useless since there are so few relevant fields https://nimb.ws/1EdMV7
For instance, to create a new lost reason the user is forced to:
1. Hit create
2. Type in the name of the record
3. Hit save
4. Go back to the treeview
While he could simply type them away in an editable treeview.
The goal of this task is to allow for creation/edition of records in such models
directly from the treeview.
Specification
=============
Modify tree views from a given list of models for which the
treeview has to be made editable bottom.
If not specified otherwise, the content treeview should stay the same.
If a field is readonly/required/etc. in the formview, it should be in the
editable treeview as well.
Relabeling has to be done of the field itself, not in the view.
TaskID: 2026126
closesodoo/odoo#34577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
For the model 'crm.lead'
- Rename the action menu 'Send an email' by 'Send email'.
- Remove the action menu 'Mark Late Activities as Done' and
'Mark All Activities as Done'.
- Set 'Mark as lost' menu action only for the list view.
- Remove the action menu 'Assign salesman of assigned partner'.
- Rename the action menu 'Forward to Partner' by 'Forward to partner'
and set it for both form and list view.
For the model 'res.partner', remove the actions menu 'Meetings'.
Linked to task 1984526
Related to PR #33720
Purpose of this commit is to remove of the legend_priority field in the crm
and project addons since they are not used anywhere.
Those were initially introduced at dd343c8633 . Purpose was to be able
to customize displayed label of priority field used in kanban view in
replacement of standard string. However kanban view does not support it
anymore since whatever web refactoring and this feature will not be
reintroduced. Let us therefore remove the fields.
Linked to task ID 1935620
closesodoo/odoo#33444
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
qmo-odoo