The CHF currency was duplicated. Instead of using an hard coded list,
select from all the active currencies.
These are USD and EUR on a clean DB but it is easy to change if we want
to populate with another currency in some use case, without changing the
code.
* When setting company_id on the res.partner, the parent might have had
a different company_id
* We should not consume res.partner's when creating res.user's but
creating new ones instead.
Set up a DEMO product with
- warning message on sale
- variant
- Order Grid Entry as Sales Variant Selection
Create SO, configure this product
Warning message doesn't display
opw-2442352
closesodoo/odoo#64894
X-original-commit: 50ccbdb983fda289cb9fe740ae711d510386d878
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Configure an email server and create a login account with a space like
"foo bar". In odoo configure an Outgoing mail server using that account,
there is an error because the username is misconsidered invalid.
The errors resides in the IDNA implementation of Odoo, we try to split
the username to get a login and a domain in order to encode the domain
using the ponycode algorithm. In case the username was not an email
adress but just a single name, the single name was mistaken for a
domain. As domain cannot have spaces, an error was thrown.
opw-2419024
closesodoo/odoo#64885
X-original-commit: 61b0a859b76ebffe083e10b25e4af52702dfb61f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before when there were long labels, this was leading to an overlapping
of the text.
Now, we display the whole label but in multiline with a maximum number of
characters per line depending on the number of columns.
The font size will also be compute depending of the number of characters
per line and with the length of the longest word in the labels.
task-2382681
closesodoo/odoo#64877
X-original-commit: 58bd6a51041d1c0c011810823caf540995428c2a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A purchase journal cannot be created without a default expense account
A sale journal cannot be created without a default income account
opw:2431278
closesodoo/odoo#64854
X-original-commit: c0af2df89dbe8f0cea384f15b2a7e3d53a16dfc6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
account_tour_upload_bill is using an inherits only to use a single m2m
field. This will remove the inherits and simply add the field directly
into the account_tour_upload_bill model.
task id #2339702closesodoo/odoo#59169
Related: odoo/upgrade#1899
Signed-off-by: William André (wan) <wan@odoo.com>
RATIONALE
For historic as well as internal reasons many CRM features were added into a
module called "website_crm_score". This module was mainly developed to manage
Odoo's prospects based on our own processes and rules. It included
* automatic lead assignment on teams, based on a score (lead scoring) and
team- and salespersons- specific domains;
* support of web pages (page views);
* support of multi sales team membership for salespersons;
This task aims at dismantling this module to make sure those valuable features
can be used by all CRM users
* lead assignment is moved into CRM;
* lead scoring is replaced by PLS and automatic probabilities computation;
* page views is now managed through visitors;
* multi sales team memberships is moved into CRM;
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: SALES TEAMS MEMBERSHIP
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.
SPECIFICATIONS: MONO / MULTI TEAMS
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: COMPANY-BASED DOMAINS
Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.
When using mono membership mode
* members are res.users records;
* a domain is added on users to belong either to the team company, either
to all available teams if team has no company;
When using multi membership mode
* members are crm.team.member records;
* a domain is added on user_id field of membership records so that they
belong either to the team company, either to all available teams if team
has no company;
Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.
SPECIFICATIONS: CHECK_COMPANY
``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.
SPECIFICATIONS: LEAD ASSIGNMENT
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.
SPECIFICATIONS: REMOVE WEBSITE CRM SCORE
Remove website_crm_score module as its core business is not moved. Scoring
itself is not used anymore as it is replaced by automatic lead computation
(PLS) and all other features are moved to core CRM application.
SPECIFICATIONS: IMPROVE ASSIGN PROCESS
Various commits are added to improve assign process. See sub commits for
more details. Global behavior is not changed but details are improved like
* include leads with probability being 100 but still not won
* ensure automatic assignment works out of the box
* continue filling salespersons pipe when they win leads
* improve team opt-out from lead automatic assignment
* limit allocation to teams when running automatic assign
* log manual assign and improve feedback message
* simplify evaluation of assignment domains
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#9499
Upgrade PR odoo/upgrade#996
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Move mail.channel.partner and mail.moderation models into their own file.
This makes some noise in diff but as channel is quite an heavy model let us
do this once for all.
Move mail.channel.partner views in their own file, as for python models.
Also containing
* separate and reorganize fields by main definition;
* separate and reorganize methods by categories, notably CRUD + orm, members
management, moderation, mailing, IM, commands;
* reorganize compute section: compute (by field order), constraints then
onchanges;
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
Some tools methods do not necessarily require to be public.
Cleanup a bit mail addon by moving menu definitions in their own file
according to guidelines.
No functional change should be involved in this PR as only some code move
and light renaming has been performed.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR #64862
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Purpose is to better spot future query counter updates by ensuring current
thresholds effectively match runbot state. Some query counters for admin
are currently a bit lower than expected, probably linked to various ORM
improvements and cleaning done since last counter update.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Cleanup a bit mail addon by moving menu definitions in their own file
according to guidelines.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Some tools methods do not necessarily require to be public.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Move mail.channel.partner and mail.moderation models into their own file.
This makes some noise in diff but as channel is quite an heavy model let us
do this once for all.
Move mail.channel.partner views in their own file, as for python models.
Also containing
* separate and reorganize fields by main definition;
* separate and reorganize methods by categories, notably CRUD + orm, members
management, moderation, mailing, IM, commands;
* reorganize compute section: compute (by field order), constraints then
onchanges;
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
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: COMPANY-BASED DOMAINS
Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.
When using mono membership mode
* members are res.users records;
* a domain is added on users to belong either to the team company, either
to all available teams if team has no company;
When using multi membership mode
* members are crm.team.member records;
* a domain is added on user_id field of membership records so that they
belong either to the team company, either to all available teams if team
has no company;
Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.
SPECIFCIATIONS: CHECK_COMPANY
``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.
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
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
When offering services, it is critical to make sure that the time being
delivered is billable. Otherwise, the company is loosing money.
This commit adds two fields in product.template:
1. service_upsell_warning
2. service_upsell_threshold
The first one is a boolean, if it is checked than the second one is
displayed to add a threshold. This threshold is used to create a upsell
activity want the (qty_delivered / qty_ordered) in a SOL of this product
is greater than the threshold defined in the product.
Moreover, when the following condition for a SOL:
(delivered quantity / ordered quantity) >= threshold set in the product
is True, then we display an upsell warning for the corresponding
SO. The problem is we don't check if the warning has already displayed
by a certain SOL. Thus, each time we timesheet for this SOL, we display
one more time.
This commit avoids to spam the salesman, to do this, we add a new
boolean field in sale.order.line, this field will be True if the warning
upsell activity is shown thanks to the SOL.
A method is added in sale module to create the upsell activity for each SO.
This method is used in sale_timesheet module to avoid duplicated code.
Finally, an unit test has been added to check the feature.
task-2411291
closesodoo/odoo#64252
Related: odoo/upgrade#2066
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
3 fields were useless in `stock.move` (only one store):
- `picking_partner_id` not used and we should use `partner_id` instead
- `backorder_id` not used and no sense
- `note` (store), not used and always empty. remove it.
task-2424248
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
To improve the scalability of `_free_reservation` avoid use RecordSet
union. Simplify the parameter `ml_to_ignore` of the method into
`ml_ids_to_ignore` which take only OrderedSet of ids instead of
RecordSet.
task-2424248
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2424248
Add a way to validate pickings in the stock populate,
used to fill a historic of validated picking. it allows to
measure the performance of `_action_done`.
task-2424248
Issue
- Connect on smartphone (or use chrome debug mode to switch to mobile view)
- Install "Ecommerce" module
- Add a delivery method D with a price on product P
and publish it
- Go to shop and add product P to your cart
- Go to payment and switch delivery method
Total amount above the summary is not updated.
Cause
Update is done on JS when delivery method is changed.
No targeting Total Amount in summary head card (seen only on small device).
Solution
Add ID on Total Amount in summary head card element and update it with JS
in same time as other fields (taxes, total, ...).
opw-2424355
closesodoo/odoo#64808
X-original-commit: 7ab63d323680a6a69e77dcc59819928aa7872582
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
- When trying to timesheet on a task that is linked to a sale order
line from a different company than the user's current one.
An error is triggered due multi company access rights issue.
This is due to two computed fields that are not computed in sudo
mode.
They make more sense as `computed_sudo` fields as they are only
computed stats and are not leaking private data.
closesodoo/odoo#64828
X-original-commit: 721378370f5aadb476e8cc606be9a41a3ffad74a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit 7fa9ec2638 create accounting entries from stock_account in
batch. The test on `self.company_id.anglo_saxon_accounting` is
problematic in case of multi recordset. Instead, this commit evaluate
the company_id for each record of `self`.
closesodoo/odoo#64813
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit the image wall and image gallery snippets had no
default images (unless overridden by some themes), and the buttons to
add or remove images where not easily visible
After this commit the image wall and image gallery snippets have default
images and the action buttons are their first option line and have
highlighted backgrounds colors
task-2431420
https://github.com/odoo/design-themes/pull/442closesodoo/odoo#64427
Related: odoo/design-themes#442
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps:
- Go to "Website" > "Go to Website"
- Click Edit in the top right corner
- Click Options
- Select "Add a Google Font" in the Font Family field
- Insert an erroneous Google Font link (e.g. https://fonts.google.com/specimen/Robotoj )
- Save & Reload
- Click Edit again
Bug:
The Edit button is not responding anymore
Explanation:
We try to `@import` the link in multiple files.
For example, here: https://github.com/odoo/odoo/blob/70eb39b0cf30c1acf9a7116e109874b60e27aa2c/addons/website/static/src/scss/website.scss#L10
An erroneous font family results in an error 400 from the Google Fonts
server. This prevents parts of the JS to load and makes it impossible to
enter the edition mode.
`EditPageMenu` handles the behavior when clicking on the Edit button.
This menu depends on `website.compiled_assets_wysiwyg` as seen here:
https://github.com/odoo/odoo/blob/b02a99bec709b5a6dc4dabb6cb81435dadc24e7e/addons/website/static/src/js/menu/edit.js#L10-L14
Since there is an error generating the file, the Promise fails but the
error is not handled:
https://github.com/odoo/odoo/blob/70eb39b0cf30c1acf9a7116e109874b60e27aa2c/addons/web/static/src/js/core/ajax.js#L164-L168
This commit prevents CSS loading errors from silently failing. The crash
screen will only show up if the user is logged in and has edition
rights.
This commit also prevents the user from posting the form if the font is
not accessible. At the moment, querying an unknown Google font from a
script will result in a CORS error. A valid one will pass just fine. In
case Google changes the behavior of these queries and allows the 400 to
be sent, the fix also checks if the query returned an `ok` status code.
opw:2439073
closesodoo/odoo#64824
X-original-commit: 604c07edcd4da8cf2a663d06ba91f137eb74691b
Signed-off-by: backspac <backspac@users.noreply.github.com>
The graph controller _attachDropdownComponents is not safe: it assumes
that it is not destroyed whenever it manipulates its own measureMenu sub
component, but it is certainly not guaranteed. This commit protects
against this possibility.
Also, at the same time, we return the promise in updateButtons, so it
can be chained if necessary (which is useful in the Dashboard view for
example). This is a new problem, because with the change to Owl, we go
through multiple phases of rendering.
closesodoo/odoo#64820
X-original-commit: 2dcf251c2d7a8bd43193e3e0b715ef3692d4e00f
Related: odoo/enterprise#15869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Create a promotion auto applied with 0 minimum amount on any product in
catalog.
Have a DEMO product invoiced on delivery
Create a sale order with DEMO, apply the promotion. Confirm.
Click on 'Create Invoice'.
The invoice will only contain the promotion because the line for
DEMO is to be invoiced only after delivery, while by default the
promotion product has the invoice policy 'on order'
This commit will:
* avoid highlight the button 'create invoice' if the only
invoiceable lines are promotion lines as well as raising an error if the
invoice is created in the same scenario
* refuse to invoice only promotion lines from a SO.
* adds a test to cover the case
opw-2414630
closesodoo/odoo#64826
X-original-commit: 6532c6ba7acb2de53fc839d5a7c5d8b200716565
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
william