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
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>
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
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
PURPOSE
Remove complex or technical code adding few value.
RATIONALE
phone.validation.mixin is used in two models: crm.lead and res.partner. It only
add a phone_format method used in onchange. We can inline this code in those
two models and remove the whole mixin itself. It lessens inherit and class
complexity.
SPECIFICATIONS
Remove phone.validation.mixin. Inline code in crm.lead (CRM application)
and res.partner (phone validation module). Make phone_format private as
it is now some internal tool method on those two models.
Everything should behave as before this commit. No functional change is
intended.
LINKS
Task ID-2416789
COM PR odoo/odoo#63333
ENT PR odoo/enterprise#15296
UPG PR odoo/upgrade#2025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
PURPOSE
Prepare sales team membership and lead assignment improvements by
reorganizing and cleaning some code bits.
SPECIFICATIONS
Tools methods should be private by default to indicate those are not part of
official convert or merge API for leads. In this commit we make convert and
merge tool methods private, keeping only main API methods public.
LINKS
Task ID-2428882
Prepares Task ID-2086889
COM PR odoo/odoo#64196
ENT PT odoo/enterprise#15610
PURPOSE
Prepare sales team membership and lead assignment improvements by
reorganizing and cleaning some code bits.
SPECIFICATIONS
Separate business methods from tool methods. It eases their discovering and
their re-use through various other methods and models. Moreover it helps
reading business oriented methods without being disturbed by tools.
LINKS
Task ID-2428882
Prepares Task ID-2086889
COM PR odoo/odoo#64196
ENT PT odoo/enterprise#15610
Fix typo preventing a correct management of won/lost when creating
multiple leads in a row.
closesodoo/odoo#64149
X-original-commit: 0024b592b2d589138f34e27c724b8d471d213a4d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
SPECIFICATIONS
We do not want to explicitly set an user as responsible when an incoming email
creates a lead or an opportunity. We prefer that assignment is done either
automatically (scoring) or manually.
Using environment user would lead to set either root (gateway user - already
prevented) either alias owner (through alias_user_id) either user sending
email if email_from matches. Doing it also allows to exclude portal / public
users that would send an email to the mailgateway.
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
SPECIFICATIONS
When changing "use leads" from CRM settings automatically regenerate apply this
option to all sales teams using opportunities. When de-activating it no team
should have this option activated as menus and options are hidden. When
activating it we consider that all teams should be upgraded by default.
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
RATIONALE
"Incoming Emails" option has many flaws
* it creates collision when you try to set an alias that is already used
and it is not easy to find them back;
* it has no default value (no sales team, no type, ...) and works through the
'owner' field. This is set with the admin on activation of the feature
which is not correct. The admin is potentially not a salesperson. If you
set the field to blank, you get leads without team and without assigned
responsible.
* this alias is not team-bound which thus asks the question: in which team
should the lead ever go? To the first team? Why?
All this make it seem way healthier to handle this through the Sales Team.
=> By default, we'll already have one working with an alias.
If users really want a global lead alias it can be setup manually through
alias menu in configuration. Shortcut and default alias in crm are removed
but feature is still doable if requested.
SPECIFICATIONS
Remove the s "Incoming emails" setting that allows to setup a global alias for
leads / opportunities with a default value being 'contact'. Also remove related
alias data as it has no use anymore.
LINKS
Task ID-2414079
Sort of follow-up of Task ID-2373095.
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
With a recent commit[1], we fixed the issue of false warning while changing
the partner on lead. But that fix ignored the fact that the lead has an
automatic formatting that may lead to false warning.
Right way to detect a phone number change is
* lead phone is different from partner phone;
* lead formatted phone is different from partner formatted phone;
If those two conditions are met we are quite sure numbers are different and
not only differs in their formatting.
In this commit we also fix inverse of phone number. When updating lead phone
value we have to use the same heuristic to update partner phone value. That
was we avoid unnecessary partner update when only formatting differs.
Tests are added to ensure new behavior and that ribbon message is effectively
trig erred with correct content.
LINKS
Task ID-2390287
[1] - https://github.com/odoo/odoo/commit/d29862c1de6208f7fdb7c8104afe0d35241d130bclosesodoo/odoo#63521
X-original-commit: 5154f40544e7913f7bcd0ff73f034d111700f580
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Ijas Ahammed <ija@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closesodoo/odoo#63259
X-original-commit: 47079f67f586adf45da15fc98dbc81571f7a9100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit changes the default crm alias prefix from 'info' to 'contact'.
As the alias of the default sales team is configured to 'info', also having
'info' for the "crm_alias_prefix" setting was leading to an alias collision.
This change allows an easier configuration by the end user and avoids confusion
when first playing with your CRM settings.
Task 2373095
closesodoo/odoo#62025
X-original-commit: 31497e17e2369147fa40ab8b3f82cb2602ec9012
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
When clicking on the stat button "Meetings" on a contact:
- before dac91bc18 (November 2019): only meetings with participant
matching contact name are shown
- after dac91bc18 (November 2019): all meetings are shown => this was
because the view was used to create new meeting, so it makes sense to
see other meetings and not have a conflict.
- after 16206d72 (August 2020): only meeting of the contact are shown
- after 7449c8a6 and d11fb611 (November 2020): more complicated logic
that will also show partner events, and child partner events.
Since August 2020, when you create a new event, since we are showing a
list of IDs at the time the button was clicked, the new event will not
appear unless you go back to the contact, then click on "Meetings" anew.
With this changeset, we still show a list of IDs, but add an alternative
to also show the events of the current partner (that should be in the
list of IDs, but will match new events).
opw-2374021
closes#61490closesodoo/odoo#61690
X-original-commit: eb6e03908bfb6ed8bbe231da2a4422ec2e149834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
The purpose is to ease the onboarding for the default CRM settings.
Now, we do not include any field by default and tags become an option
in the choice of fields apply to the computation.
task-2196200
closesodoo/odoo#48124
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When we clear the configuration parameter crm.pls_fields unlink method is
called. In order to have a correct dynamic compute based on this parameter
we need to re-evaluate the depends. This is done by overriding unlink of
ir.config_parameter, like already done at create and write.
Task-2196200
closesodoo/odoo#61293
X-original-commit: d04cc4df4ec28816aeb6d1d7c7fc0e547fd13fa5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create an opportunity for CH1 and a subscription for CH2
Bug:
The count of opportunities in C was displaying 0 instead of 2
opw:237344
X-original-commit: d11fb611fed3a8541d03b7d3e49973ae7c16a768
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create a meeting for CH1 and a meeting for CH2
Bug:
The count of meetings in C was displaying 0 instead of 2
PS: set() is used to avoid to count several times the same event for a partner.
If for example CH1 and CH2 attend to the same event, only one event must be counted for the
parent C
opw:2360155
X-original-commit: 7449c8a6643477742616bf236f2f2c90aec68581
Co-authored-by: nim-odoo <nim@odoo.com>
Whenever when change the 'Leads' of 'Pipeline' boolean field on sales team,
it should also update the linked alias. Mainly, if 'Lead' is checked, the
'Default Values' on the alias should also be updated.
It used to work before a recent refactoring (see commit [1] and [2] for more
information).
This commit adapts the changes done in refacotring and updates the alias values
while updating the sales team.
[1] - https://github.com/odoo/odoo/commit/7cfd364db54e88970ef51c798df3bd4df44222b3
[2] - https://github.com/odoo/odoo/commit/186cfb5ebd35d572d0f635cd7975de7cff0d1055
TaskId - 2357573
closesodoo/odoo#60008
X-original-commit: 0669ee36e195e8e0f98131219b59fcc5cba4cea7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Handle salesmen allows to assign responsible to leads using a round robin like
algorithm. Currently a write on each lead is done to update its team and
responsible, even if number of leads is far greater than number of available
users to assign.
Current implementation can be simplified by doing one write per sales person
to assign on its batch of leads, or a single write if no salesmen has to be
assigned.
Performance counter on a mass convert wizard on 50 leads show that we gain
about 9% of queries (125 on 1471) with this simple optimization.
Task ID-2351604
PR #59084closesodoo/odoo#59324
X-original-commit: 973a2998666813ca4fbe90f1b486c1b18091c4e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently when trying to find duplicates of a lead with an email that
cannot be normalized and without partner, a crash appears as there is
no domain part to form a valid domain.
Fix it by returning a void set if no valid email and no valid partner
is set on the lead as we cannot determine any duplicate based on void
information.
closesodoo/odoo#59147
X-original-commit: 291db77cf09c6ee76373fd168f575fda28270467
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit we remove the warning logger when not being able to format
a phone number. Indeed this does not indicate there was a real issue.
It simply indicates that either the phone number is not parsable or not
matching given country format.
It happens in a lot of situation that phone numbers are not valid: bad
encoding, country mismatch due to {lead, task, ticket} / partner not always
being the same, ... This should not raise a server warning.
When using frontend SMS composer for phone number, a warning is displayed
to the user telling the number is probably incorrect. This is considered
as sufficient from UX point of view as it warns users. We do not think
we should warn admins that some data is incoherent in database.
This commit also
* Revert "[FIX] crm: avoid linking demo leads with an unrelated partner"
This reverts commit 2c94c4c81ffa171158586cd64828d27c537cd1d6
-> having "invalid" data should be a valid use case of real life
* Revert "[FIX] crm: get correct country for phone validation"
This reverts commit a58f9fc154c038d72031b281e2bec2c0fc2915ba
-> country of a lead comes from its partner if set but can be different.
Same for phone numbers. Values on a lead after a compute are considered
as complete. Sales persons could effectively have incoherent data on their
form view but that is the result of what has been encoded.
Task ID-2325228
X-original-commit: cecc4ca6f02e599e193c3fa688bfcbd02ac0580b
The method _compute_probability has a dynamic depends, that depends on the
crm.pls_fields config parameter. When installing the DB, the depends is
evaluated. If the config parameter is modified afterwards, the depends is not
re-evaluated as the registry is not rebuilt.
The result is that when modifying the config parameter, if an optional
pls_field's value is modified on a record, the compute won't be triggered, as
that pls_field is not in the compute's depends.
This commit force to re-setup the registry after a modification (or the
creation) of the crm.pls_fields config parameter, in order to force the
depends of the _compute_probability method to be updated.
Task ID: 2341829
closesodoo/odoo#58165
X-original-commit: e95afbedc18d198454c7f66b523c4cafb19a4066
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
Purpose
=======
Get rid of the cron.
Always have an up to date frequency table to compute lead probability.
Clean PLS code and ensure to remove unnecessary code
Specifications
==============
Disable the cron:
- Increment won and lost count for lead PLS params from frequency table at
each won/lost
- The complete set of leads won't be recomputed anymore every day
- A lead probability will only be recomputed if one of the PLS parameter will
be modified (stage_id, team_id + the ones checked in settings)
- No more onboarding phase : as frequency table is always up to date and only
the modified leads are recomputed, we can drop this. (So even on onboarding,
winning or losing a lead won't impact other leads, except the ones we modify
manually afterwards)
- Add an button to force the recompute of all the lead probabilities
(kind of reset) in the settings.
The cron has been disabled by default.
Users can know choose to reactivate it if they want to continue updating their
lead probabilities on a daily basis.
Code have been reorganised for better structure and understanding.
Some code parts have been factorised to be usable in both Live Increment and
Full Rebuild mode.
In this commit, we also update probabilities using only computes
Before this commit, _update_probability was called during write and create,
to ensure both probability and automated_probability were correct. That was
necessary because of onchanges and readonly field (automated_probability
was not given to the write method while saving after a change on the lead).
After this commit, we use the force_save tag on the readonly field
automated_probability. So we ensure that write always receives the new
automated_probability value and everything can be handled directly by the
compute. Also, we force the lead to start in automated probability mode.
So when creating a new lead, both probability and automated probability are
computed and aligned.
Finally, when winning a lead, we ensure that both probabilities are aligned
(=100), so that if user take the lead back to a previous stage, the
probabilities are correctly recomputed, and the lead will not be stuck to
100%.
Also, this commit applies some fix and minor changes listed here under:
- Ensure to have always positive frequencies
- Fix lost counts for team not set in pls computation
- optimise set_won : write only once per values
Finally, include tag in frequency table even if less than 50 occurences:
Due to refactoring in which we increment frequency table at each won/lost
instead of rebuilding the frequency table each day, the tags are never added
in frequency table.
This is due to the 50 occurence conditions that avoid to create the frequency
if we have less than 50 won or lost for a tag.
After this commit, we include the tag_ids in the frequency table, no matter
the number of occurences. But, during the PLS computation, we skip the tag
frequencies if the number of occurences for this tag is under 50.
This allows to have a complete vision on the tag frequencies, even for
small number of occurences.
Task ID : 2254543
X-original-commit: cd291b79eb2d2df80899867263ec71438ab8fe87
- Go to CRM > Settings and activate Leads
- Go to CRM > Leads and create 2 Leads with a different phone number
- Select the 2 created Leads and in Action menu, select Send email
- Make sure that "Lead/Opportunity: Mass Mail" is selected as template
- Send it
- Go to Contacts
2 Contacts have been created from the Leads, but both have the same phone number.
The issue comes from the override `default_get` of `res.partner` in crm module.
It is using `active_id` from context to fetch the Lead to populate Partner data.
This cannot work when several Leads are selected as the same `active_id` is used
for all of them.
opw-2333819
closesodoo/odoo#57638
X-original-commit: a84dcfb9475051082c6103f81bfa231ea50ed157
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Before when we tried to duplicate a lead without the mrr option
active, a traceback was raised.
If the MMR option was not activated, then the user was not be able to write
on some field because he was lacking the corresponding group. In this case,
the recurring_revenue and recurring_plan fields.
Now, when copying a lead, we purposefully set those fields to 0/False to
avoid a crash if the option is not enabled.
task-2325629
closesodoo/odoo#56927
X-original-commit: 1a5cc55dfeb03ad7d4a63a0286d5d33eaca3cbe2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
- Create a Meeting for Contact X
- Go to Contacts and open Contact X
The Meetings smart button shows 1, but when clicking on it,
all user & partner meetings are displayed.
opw-2320299
closesodoo/odoo#56753
X-original-commit: 70f441a7ee3d46f6ba25cf56529a972b9e7ab29e
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Create a Contact named "Alpha"
- Create another Contact named "Mister X" with "misterx@alpha.com" as email
- Go to CRM and create an Opportunity for Mister X
- Go to Contacts and open Alpha
The Opportunities smart button shows 0, but when clicking on it,
Mister X's Opportunity is displayed.
The Opportunity smart button displays a "crm.lead" view with a filter on partner_id.
The filter applies an "ilike" with the Contact's name on several fields of "crm.lead",
including "email_from".
As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved.
opw-2320299
closesodoo/odoo#56667
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
PURPOSE
Improve performances of various Odoo code bits.
SPECIFICATIONS
Use a read_group to compute the opportunities_count & opportunities_amount,
like the other compute methods for statistics fields.
Do the same improvement in pos_sale when computing pos_order_amount_total.
LINKS
Task ID-2281297
PR odoo/odoo#53053
PR odoo/enterprise#11299
X-original-commit: 3e30b1e5c1aa25463848d82492f25002bcbf9154
Phone validation of crm_leads was using crm.lead country instead of partner
country code. This was leading to phone number of crm_case_16 coming from
an us partner validated as a uk phone number. (same problem applies for crm_case_14)
The problem was discovered in pre/post upgrade crawler test.
closesodoo/odoo#56348
X-original-commit: a58f9fc154c038d72031b281e2bec2c0fc2915ba
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This module provide routes to manage people, companies, and
leads from the outlook add-on. It could eventually be accessed by
add-ons for other mail clients.
closesodoo/odoo#44936
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
PURPOSE
Make sure the Rainbowman animation is rightly triggered whichever way the user
marks the opportunity as won. Especially relevant for the onboarding as we want
to show the first rainbowman to users completing the tour.
SPECIFICATIONS
Now the rainbowman and its finely-tuned message are displayed to the user when
he uses the statusbar, mark lead as won using action buttons or drag and drop
a lead in the won stage in kanban view.
LINKS
Task ID-2287758
PR #54553
This commit adds a few minor improvements to crm views:
- Add the crm.team currency on opportunity amounts on the crm.team kanban view
- Slightly reorganize "My Activities" view for increased usability
- Remove the "alias_user_id" field in the crm.team form view because it's a
related technical field that is not supposed to be modified there.
Task #2314894closesodoo/odoo#55940
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Jérémy Hennecart