Those are not launched anymore by default. Indeed framework and code followup
is not ready for that level of details.
Task ID-2480727
closesodoo/odoo#67678
X-original-commit: f950399e6e4aaaf88b743abfeb37a2de4c99fa5c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to last runbot state. Should probably be removed someday as actually
there is not much gain with those tests.
X-original-commit: dc05f873571ca60b7fbbb701a86760f13a6d3172
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>
commit at each lead makes the system spend 80% of the time recomputing
bayesian probabilities. Avoid to commit too often speed up the process
while not altering final result.
Task ID-2475352
closesodoo/odoo#67275
X-original-commit: 34f6e38e68208b9509a429cdb09f8316a7ef566f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* The "Mark As Won" button should first look for "won stages" that
have a higher sequence than the one the opportunity currently is.
If none is found, then it's "ok" to go to a stage with a lower sequence.
* In Fine, we would like to prevent a "not won" stage to have a higher
sequence than any "is won" stage. But while this is not the case, searching
for the "is won" stage while alterning the sequence order will correctly
handle the following case :
- stage sequence :
[x] [x is won] [y] [y is won] [z] [z is won]
- scenario :
an opportunity in [y] and marked as "won" should go to [y is won].
(not in [x is won] nor [z is won])
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
* Replace the "Snooze 7d" action for lead-related activities linked to
a calendar event by a "Reschedule" action, which will redirect the user
to the calendar view with the focus on the next event related to the
opportunity
- The "Snooze 7d" action only impacted the activity and not the meeting,
and snoozing a meeting is not very logical anyway. The "Reschedule" fits
better in this use case.
* It was discussed to show only a modal allowing to reschedule the next
calendar event, but that could lead to inconsistent states (out of order
sequence of scheduled events, if the first is rescheduled after the
second).
* The reschedule option will be shown next to any activity related to a
calendar_event regardless of its activity type. There are some edge cases
that we may want to change in the future :
- When changing the activity type of a 'meeting' activity associated to
a calendar event to any other activity type, but without removing the
calendar event, the reschedule action is still showing (since the event
is still ongoing and was not deleted from the calendar).
- Conversely, with a meeting which is not (yet?) related to a calendar event,
the reschedule action will not be available.
* Add a new field to MailActivityMixin in the calendar module context. This
field is the event linked to the next activity, if there is one such event.
It is used to check whether the reschedule action should be available to the user.
* Add a test for this new field to validate the expected behavior.
* Add the priority widget to the priority field in the opportunity tree view
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
This commit improves the action helpers for the actions bound to below listed
menus for better usability:
* My Activities
* Leads
* Leads Analysis
Along with that, this commit also improves the following:
* while generating leads, make 'Industries' field required on the modal so
that results obtained are actionable instead of random leads;
* after trying to generate leads, if no result is found, the same pop-up
opens again with same criteria and displays a waring in the pop-up. It
informs users that leads are not found and no credits are spent for their
last search;
* improve the warning message for unsuccessful enrichment due to invalid
email;
COM PR odoo/odoo#64075
ENT PR odoo/enterprise#15561
Task ID-2393253
When we create a partner on lead form view, the user and team are
propagated to the created partner, while they do not when we do the
same from lead kanban using quick create.
With this commit, user (salesperson) and team are propagated to the
partner created through lead kanban (quick create) as well.
Task ID-2446969
PR #65846
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When setting a partner on a lead if we select the individual customer that
is not a company with company_name being set, propagate it to partner_name
on lead.
Task ID-2446969
PR #65846
Right now, if someone changes the `crm.pls_start_date` system parameter
to something that is not valid, opening a settings gives you traceback.
This commit improves the behavior by making sure that the compute field on
settings page `predictive_lead_scoring_start_date` always contains a valid
date. For doing so, if the system parameter is not a valid date(or not set
or deleted), we set the above field to the date 8 days prior to current
date, and thus, when saving the settings, the system parameter is again
set with a valid date.
closesodoo/odoo#66988
Taskid: 2448248
X-original-commit: 19577c40f8f2878286ef63da5d30b341d7ab5cbf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Context
-------
Lead assignement is now based on PLS probability.
We want to avoid giving the same score to real email addresses
and email addresses that are just well formed
Flanker try to acheive that be checking specific
criteria according to the domain, check the dns and mx record
Improvement
-----------
Define a mail_validate function seach as phone_validate.
If flanker is installed, use flanker for validation of
email addresses else use email_normalize.
It should help the PLS to give a bad score to well formed addresses
that flanker suspect to be wrong.
Setup
-----
NB: flanker is not available as debian package, we make it optional
To install flanker
```
pip install flanker
pip install redis
pip install dnsq
```
If you have installed it as root you may need to run
```py
from flanker.addresslib import address
```
as root for the first initialisation
closesodoo/odoo#66429
X-original-commit: f540976c8751e2bf402fed8db830ec0fbf98f654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves multiple small details in the calendar application.
UI, UX mostly:
* some labels were confusing
* the invisible attribute were not set in popover view
* the sample data were missing
* ...
taskid: 2342252
For odoo-master Transifex project, no demo data
closesodoo/odoo#66500
X-original-commit: 813931ac850e5ba4181259a5957ec72226fb670c
Related: odoo/enterprise#16510
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the crm tour, we have a step where we want the user to drag and drop the
card. But the bubble for this step is just besides the icon to schedule the
activity. So if user tries to schedule the activity and hovers on the tour
bubble, the tour help overlaps the drop-down of activities and prevents
user from scheduling one.
This commit fixes the issue by moving the bubble for this step at the right
side of kanban card so that tour does not prevent user from scheduling the
activity.
closesodoo/odoo#66136
Task-id: 2449223
X-original-commit: e9b5a0522f019adb7ae17164e314206a61c71cc6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This display colors of the tags on leads' kanban view,
same as opportunity.
Task-id : 2453047
closesodoo/odoo#65677
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Right now, if the expected revenue is not set on the opportunity, the
rainbowman is not displayed and it does make sense to ask for a revenue
so that we can measure if this is a record or not. However, revnue is not
necessary to congratulate the user for his first win.
With this commit, for the first won lead of a user, we congratulate user
with rainbowman, even if there is no exptected revenue set.
closesodoo/odoo#65378
Task-id: 2410443
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Probably linked to merge and forward of odoo/odoo#65688 that split some
computed fields. This may have an impact on some fields computation and
therefore queries.
Task ID-2455236
closesodoo/odoo#65748
X-original-commit: b1520ad39c7abd18f8af1c3b23e6e3e897916004
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Primary action buttons should suggest the next logical flow to the user.
On contrary, the opportunity form view is having too many primary
buttons, losing their actual meaning.
In this case we consider that next logical steps should be:
- the creation of a new commercial document (Sale / Rental) if
any / all of those apps are installed;
- the winning of the deal (as losing would stop the flow);
With this commit, we make following changes to achieve that:
- rename the 'Mark Lost' and 'Mark as Lost' buttons to simply 'Lost'
and make them secondary buttons;
- rename the 'Mark Won' button to simply 'Won', and keep it primary;
- once the 'sale_crm' is installed, make the 'Won' button secondary;
closesodoo/odoo#64834
Task-id: 2247355
Related: odoo/enterprise#15977
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Stored editable fields receive their values either from compute either from
user input. If a user input is given to create / write compute method is not
called. If multiple fields are computed through the same method giving one
field value discard call to compute method and other fields are not called.
SPECIFICATIONS
Split ``_compute_partner_id_values`` compute method so that partner related
fields are independent :
* have a method for address fields as those are computed in group. Indeed
either we take all from partner either none. Otherwise it would create mixed
addresses that make no sense;
* have a specific computation for partner_name and contact_name coming
from ``_prepare_partner_values``;
* have other fields separated (function, title, ...) acting like related on partner
if not set by user;
LINKS
COM PR odoo/odoo#65381
Task ID-2451339
X-original-commit odoo/odoo@78eb46352eclosesodoo/odoo#65658
X-original-commit: bb13421d3a7f04ede9350b3b28c1650c3d9890f8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
X-original-commit odoo/odoo@18cd93ded8
X-original-commit: 94d618ff3ff8ee13d23f893836d00a5a71981938
Right now there is a button in the CRM settings called 'Update Probabilities'.
When clicking on it probabilities of leads created after certain date
are updated. Problem with this flow is that user can click on the button by
mistake and there is no going back.
Moreover this does not trigger a save on settings and changes done by user
are not saved. This is standard behavior of config settings.
This commit improves the behavior by opening a wizard on click of the button
instead of directmy updating the probabilities. It allows users to change
fields used in PLS, change start date, or even cancel the update process.
Task ID-2355562
closesodoo/odoo#60733
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
Right now, the 'CRM > Reporting' menu is accessible only to the sales
managers. However, we should let users of all access right levels to
see their reporting while making sure it does not give them access to
data that does not match their rights.
This commit thus changes group applied on 'CRM > Reporting' menu from
'sales_team.group_sale_manager' to 'sales_team.group_sale_salesman' so
that from sales person to manager, everyone is able to the reporting
based on their rights.
For the below sub-menus, record rules already exist, preventing data breach:
- Dashboard (crm_enterprise)
- Leads (crm)
- Pipelines (crm)
- Activities (crm)
However, for data under 'Partnership'(website_crm_partner_assign) and
'Lead Generation Views' sub-menus(crm_iap_lead_website), we introduced
the needed access rights / record rules to ensure basic users can only
see the data they have rights for.
TaskId - 2357311
closesodoo/odoo#64202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some tests sometimes require some more queries to be finished.
Task ID-2444908
closesodoo/odoo#65379
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With commit[1], we introduced a feature that from the sales team, we can
see the overdue opportunities for a particual teams. However, the filter
that we use for related action which is supposed to show overdue opportunities
is not not added, and the filtration is not working as expected, showing us
all the opportunites for a team.
This commit fixes the issue by adding the invisible filter with proper
domain set within opportunities' search view and thus enables us to
filter overdue opportunites.
commit[1] - https://github.com/odoo/odoo/commit/1da63f0ab0fb4212bee46f960c6bbe8ca9251cac
TaskID : 2323612
closesodoo/odoo#65258
X-original-commit: 68577d32c7fe0cb18ba4fb788cee65ec8b54b65b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
with this commit we are updating sequence of onboarding tours
task-2444153
closesodoo/odoo#65244
X-original-commit: a928beccb09f4db4234356e5e4f7bdf090ecc964
Related: odoo/enterprise#16026
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When merging leads final priority is currently the one of the lead considered
as the master lead. This is based on ``_sort_by_confidence_level`` who sorts
on confidence but not on priority.
We think final priority should be the highest one from merged leads. Indeed
if a top priority lead is merged into a low priority one we should not loose
the priority information. It is better to keep the final lead with an high
priority and let salesmen move it downwards.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose of this commit is to make clearer how final opportunity value are
computed or chosen when merging leads. Functionally nothing should change
with this commit.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose is to test internals of lead merge method, notably about values
of final opportunity. That way we ensure future changes will be reflected
in tests and regressions will be avoided.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
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
with this commit we fixes various tour steps, remove steps from crm and sale
tour and improve step selector in project tour.
task-2444272
closesodoo/odoo#65073
X-original-commit: f6c05693f857acfb0f74bb76c4bd72f83d9fb335
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the user had to type in the exact same formatting to find contacts.
After this commit the user will be able to get better search results and does not have to type the same formatting.
To avoid code duplication, the existing _search_mobile_phone method has been moved to the mail_thread_phone class, so that it could be used by both the crm and res_partner models.
Task-2435233
closesodoo/odoo#64490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes a nondeterministic issue during the rainbowman tour.
We make sure that the record is properly created and the kanban reloaded before
moving on to the next step, ensuring that the tour completes without race
conditions.
Task-2426257
closesodoo/odoo#64921
X-original-commit: f332541bc84d6110c90d4c5e736892f185fff3df
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
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 clean
SPECIFICATIONS
Set _check_company_auto on lead model to enable automatic company check when
updating company_id field.
Add a company check on user_id field to ensure user and lead company match.
Also add a company check on team_id to ensure team and lead company match.
Add a dynamic domain to be used in form view to limit available users to set
on leads to those matching domain.
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
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
Compute default team id for sales related documents. Note that this method is
not called by default_get as it takes some additional parameters and is meant
to be called by other default methods. Heuristic (when multiple match: take
first sequence ordered)
1- any of my teams (member OR responsible) matching domain
2- any of my teams (member OR responsible)
3- default from context
4- any team matching my company and domain
5- any team matching my company
Note: ResPartner.team_id field is explicitly not taken into account. We think
this field causes a lot of noises compared to its added value. Think notably:
team not in responsible teams, team company not matching responsible or lead
company, asked domain not matching, ...
We also improve various places where sale team is computed on sales documents.
Purpose is to try to use same heuristic as much as possible in various
team_id fields.
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
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
When counting assigned leads for members when dealing with automatic assignment
exclude won leads. Indeed purpose of automatic assignment is to ensure
salespersons always have some leads in their pipe. If they won a lot of leads
instead of stopping assignment we should simply fill their pipe again.
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
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
Assignment max being set to 0 means member is out of automatic assign process.
In that case assignment information (domain in form view, gauge in kanban
view) are hidden to lighten member form view.
Its default value is now set to 30. It means that newly created members by
default are available for automatic assignment.
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
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
Include leads with probability 100 but not in a won stage when doing automatic
assignment. Otherwise those are not assigned but still not really won as not
in the right stage. Probability 100 means they will be won easily but they
still have to be managed by a salesperson.
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#9966
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
Remove safe_eval and its support of datetime and context_today. Check in
existing dbs show that it is not used in team or member assignment domains.
We therefore choose to limit content of domains to what goes through a
literal_eval. It allows to reduce potential issues.
We also improve warning messages in order to give clearer message to users
when dealing with input errors.
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
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
Improve wording and feedback given when running automatic assignment. When
running on a single team some more details can be given on its configuration.
Log a message when a manual assign is called from a team. Purpose is to
ensure this action is logged. Otherwise team leaders may try to fetch some
quality leads without notifying anyone.
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#9966
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
Currently when assignment runs all free leads are allocated to teams. They
are then assigned to members according to their capacity. This means that
no lead is kept free. If assignment is performed on a subset of teams this
means that other teams have no free lead anymore.
During assignment evaluate which teams still need to receive leads. This is
based on team maximum capacity. We consider a team should receive twice its
capacity as leads. That way members will receive leads and can pick some leads
in team unassigned pool of leads.
e.g. a team has a total of capacity of 90 leads / month among its 3 members.
When running a daily assignment process, an equivalent of twice this running
time is assigned to members (see previous commits). It leads to assignment
of (90 / 30) * 2 = 6 leads. Twice this count is allocated to the team aka
12 leads. Remaining leads will be allocated in next assignment run or are
available for manual assign.
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
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: TEAM OPT-OUT OF ASSIGN
Allow teams to individually opt-out automatic assignment. If automatic
assignment is activated one can make some team opt-out of automatic process.
Manual assignment on team through an action button is possible even when
opt-outed.
Allow teams to individually opt-out automatic assignment. If automatic
assignment is activated one can make some team opt-out of automatic process.
Manual assignment on team through an action button is possible even when
opt-outed.
SPECIFICATIONS: RESTRICT ASSIGN TO OPPORTUNITIES ENABLED TEAMS
Only teams with use_leads or use_oppotunities should be included in automatic
assign. Indeed other teams like POS, website) do not handle opportunities
or leads. Automatically assigning them leads makes no sense.
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
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
Make final integration of members management by taking into consideration
both multi-membership and automatic lead assignment features.
Correctly hide assignment options and fields if auto assign is not activated.
This means that
* when being in mono membership mode without automatic assign: display
users on team form view;
* when being in multi membership mode or with automatic assign: display
members o2m records, as configuration is done on this model;
* hide the whole right column in sales team form view about assignment when
assignment is not activated in settings;
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
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
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
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: SETTINGS VIEW
Move Multi Teams checkbox below Recurring Revenues / Leads checkboxes. On its
right alias configuration should appear if Leads is checked.
PLS take third configuration line. On its right future commits will gradually
add automatic assignment configuration.
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
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: MODEL CLEANING
In this commit we improve team member model to make it more usable and
aligned with current Odoo views and usability.
This commit contains notably
* add some related fields on the user: phone, mobile, company, email;
* rename "team_user_domain" to "assignment_domain";
* rename "maximum_user_leads" to "assignment_max";
* improve member views globally;
We also introduce dynamic domain computation for users and teams when seeing
team members. This allows to limit selection of users or teams depending
on already existing configuration. Purpose is to avoid having people trying
to create wrong configuration (duplicates, ...) and receiving error messages.
Also
* clean some data and demo about teams and members;
* fix some views glitches;
* improve views: add some fields in search views, improve wording of
fields or actions, ... globally improve usability and US as well as
feedback given to users;
* group sales team members by team by default as it help getting an
overview of team members distribution;
* update tests to create team members instead of writing directly on m2m
towards users;
SPECIFICATIONS: SALE_TEAM_ID FIELD ON RES.USERS
In this commit we also rewrite sale_team_id field of res.users. Previously in
crm it was simply a many2one field linking to a crm.team. It was used to compute
team membership as a standard many2one / one2many relationship. In enterprise
module ``website_crm_score`` this field was set as a related on first user
teams. Indeed scoring changed relationship between users and teams to a
many2many.
This field is now directly a computed many2one field that links to the
"main" team of the user even in multi memberships mode. As memberships can
now be de-activated we changed this field to a computed stored field. It is
based on oldest active membership of user. That way default team of documents
will be the user's oldest team considered as its "main team".
SPECIFICATIONS: LEAD_ALL_ASSIGNED_MONTH_COUNT
Improve crm_team ``lead_all_assigned_month_count`` field computation. It is
now simply the sum of assigned leads of team members. Differences may
happen if a lead in teamA is assigned to an user working in teamB. This should
not happen if team / user is correctly set at lead level which is generally
the case. However if that happens, old field counted it. New field will not
count it as it is not directly linked to a team's member.
SPECIFICATIONS: DEMO DATA
Make crm.lead demo data coherent with user_id / team_id . As demo data should
be using a mono-membership behavior for users and teams, we have to ensure
user_id and team_id effectively matches. It allows to have coherent reporting
and assignment demo flows.
Also avoid having Odoobot responsible of leads. Instead of undefined user_id
and team_id leading to Odoobot being responsible of some leads, force it
to be False. Those demo data allow to test automatic assignment of lead
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
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.
SPECIFICIATIONS
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.
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#996996
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
Rename views according to guidelines in order to better understand what
they are. As there are few views let us take a few minutes naming them
correctly.
Also prepare sales team enhancements and ease migration scripts addition by
bumping version numbers.
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
Thibault Delavallée