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
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: 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
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>
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
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.*
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>
PURPOSE
Link field name with their content.
SPECIFICATIONS
This commit changes the field name "expected_revenue" into "prorated_revenue"
and the field name "planned_revenue" into "expected_revenue".
Indeed content of those fields evolved since their first naming. Their content
is not what the field name indicates. Better rename those fields to understand
code flow inside CRM.
LINKS
Task ID-2283052
odoo/odoo#54194odoo/enterprise#12423odoo/upgrade#1463
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Prepare enhancements of sales team membership.
SPECIFICATIONS
Lint crm data and demo, notably about sales team and file organization.
Also move crm menu entries declaration in a single file and remove some
menu entries not imported anymore.
LINKS
Task ID 2086889 (sales team enhancements)
Task ID 2234698 (preparation lint)
Community PR odoo/odoo#49520
When `_synchronize_alias` was introduced into crm.team.write, the write
method become incompatible with batch writes because
`_synchronize_alias` assumes `self` is a recordset of length 1 and
performs attribute accesses directly on self, this makes the __get__
crash because it performs a `self.ensure_one()`
With this commit, crm.team.write will iterate over the self recordset
and call `_synchronize_alias` on every record of the recordset.
This also solves a uninstallation problem in sale_crm because a write is
performed on crm.team in an uninstall_hook.
closesodoo/odoo#49088
X-original-commit: a9511cd42be365e58371d717b8197aac644eaf33
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
PURPOSE
Purpose of this commit is to clean statistics fields definition on crm.team.
Future tasks will improve the use of sales team in crm and first steps is to
clean a bit models linked to sales team.
SPECIFICATIONS
New statistic fields
* ``lead_all_assigned_month_count``: all assigned lead and opportunities
in the last 30 days; used notably for scoring mechanism;
Renaming performed on some statistic fields
* ``unassigned_leads_count`` -> ``lead_unassigned_count``;
* ``overdue_opportunities_count`` -> ``opportunities_overdue_count``;
* ``overdue_opportunities_amount`` -> ``opportunities_overdue_amount``;
All those fields are used for display and management purpose, and are
computed not stored fields. No migration is therefore required.
LINKS
Task ID 2088565 (crm: from onchange to compute)
Enterprise PR odoo/enterprise#7322
Upgrade PR odoo/upgrade#781
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFIATIONS: CONSTRAINT USER_ID / TEAM_ID
In this commit we also remove all the better implementations of "not really a
constraint" constraint about user_id and team_id. Indeed as this is a computed
field normally we should not have to call the onchange manually, even through
a hackish call to a falsy constraint (see fdc8749, 222cca2, 4e8ebc7 ). You are
all inferior to SM team.
SPECIFIATIONS: DATE_OPEN
Assignment field, namely ``date_open``, has a random definition as it seems
linked to assignation, with several behaviors intended
* ce39ca8a97 : reset only when going from
no salesman to a salesman (aka, keep assignation when changing)
* 8e540558ee: reset when changing salesman
We choose to keep first implementation as it seems a bugfix broken again
by second commit. It will also replace the ``assign_date`` defined in
``website_crm_score`` module.
SIDE EFFECTS
Several side effects occur with this commit. Indeed behavior is not always
exactly the same, notably as code rewriting allowed to fix some issues,
incoherent behavior or was simply not able to achieve exactly the same
result. Notably
* at lead creation: default probability is the one coming from PLS and not
0.0 anymore, since field is already computed. Synchronization with PLS
still works the same way (change probability, you are out of syn);
* various user_id / team_id combinations notably in convert / merge wizards
may change, notably we do not reset team_id if user_id is reset. We
consider we could keep a team_id set without user_id;
LINKS
Task ID 2088565 (crm: from onchange to compute)
Upgrade PR odoo/upgrade#781
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Florent Lejoly <fle@odoo.com>
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider a sales team ST in C1
- Let's consider that the partner of your current user is in ST
- Log your user in C2
- Go to CRM > Sales > My pipeline
- Create a lead
Bug:
An access error was raised.
opw:2191517
closesodoo/odoo#45234
X-original-commit: 42cdf368bdec41918b9f4b131b838cb1c76928b4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Indeed since a lot of cleaning has happened, notably merging lead and
opportunity views and actions cleaning, let us have a real name for
that main action instead of a bad and error-prone name.
Task 2070287
closesodoo/odoo#36676
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the ux in CRM by changing a few things:
- Restore the use_leads and use_quotations fields
along with their features as they were in 12.0.
- Hide the email alias if use_upportunities and use_leads
are unchecked.
- Show a link to the general settings instead of the alias_domain
if no alias_domain has been configured.
- fixes the "unassigned lead(s)" link so that
it redirects the user to the actually unassigned leads
Task: #1962182
PR: #32372
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
- Create 2 `crm.lead`:
Expected Revenue: 100; Probability: 99 %
Expected Revenue: 200; Probability: 0 %
- Go to Reporting > Sales Channels
The amount displayed next to 'Open Opportunities' is 148.5 is instead of
99.
opw-1947975
closesodoo/odoo#32011
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, in some cases, clicking on a crm.lead
triggered a traceback saying "the column crm_team.alias_user_id does not exist"
This was because the field alias_user_id on mail.activity.mixin,
was itself _inherits from mail.alias
In that case, "overriding" the field in the child class is actually
a plain definition of the field, making it "loosing" its related nature
After this commit, there is no traceback anymore
closesodoo/odoo#31511
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
Purpose : Various relabelling and design improvements in crm:
- opportunity, lost reason, lead, team, tag forms
- hide "convert to opportunity" button for inactive/lost
leads (actually nothing happened when clicked anyway)
- Checkbox in crm.team to hide all alias related fields
- New many2one field appearing in crm.team form to select the user to
whom lead created by alias will be assigned.
- Set the admin as leader of the initial crm.team
closesodoo/odoo#28851
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
On the pipeline action change the sequence of the view_ids to
change the order of the view_mode string
Put tree first instead of kanban for example
Before this commit, clicking on CRM menu app still displays the kanban
This was because the action window is wrapped around a server action that modifies it
After this commit, we recompute the view list to match what is on the original action
OPW 1863425
closes#26159
In order to be able to add some enterprise views to crm, we need to
define the views as act_window.view, we also want to define a graph and
a pivot view for the leads.
We also want to have a more powerful search view associated with these.
Task: #1831168Closes#25400
Use crm.lead instead of a the crm.opportunity.report object for
reporting. This allows to show more fields (e.g. tags_ids). The only
field not accessible in the report is #activities, but there is a
deicated report dedicated to activities.
Improved the default search. Example: when reporting on leads, you want
leads+opps by creation date (and not only leads) as an opportunity has
been a lead created too.
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
When a stage on crm leads is removed, the leads appear in an
"Undefined" column in a kanban view, but this was not handled when
getting the "graph data" (eg. in version 11.0 for sales team graphs
when grouping by stage in CRM > Reporting > Sales Channels).
opw-784455
closes#21507
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, remove deprecated generation of alias on sales team.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
Default mail.alias for crm.team are currently recomputed/modified
when *setting* use_leads on the team (type changes from opportunity to
leads), but not the other way around (*unsetting* use_leads doesn't
rollback type to opportunity).
Fix this issue.
Leaves over the issue that *disabling* the global setting doesn't
recompute aliases, which it probably should.
OPW-728690
rename values of selection field to actual model names.
this prevents the need of a separate function to get the sql table
and allows to get direct access to the model.
(needed for the next commit)
Thibault Delavallée