Currently when converting leads we may end up with False being compared to
a void partner recordset. Due to the use of != this leads to unnecessary
update of leads when no partner is involved in lead convert.
By comparing recordsets everytime we save queries and performance each
time a convert on a lead without customer is done. This leads to about
saving 150 queries in heavy duty tests.
Task-2722512 (Lead: performance in convert without customer)
Task-2722513 (Lead: performance master task)
closesodoo/odoo#81028
Related: odoo/enterprise#23094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When creating an opportunity, set the language of the Lead/Opportunity
to the partner's language if it is set instead of leaving it blank.
Also update tests to correctly test lang propagation.
Update event_crm so that lang of lead from registration is directly set
to False when there is no partner. Indeed we have no clue which lang we
should set and we can skip the field computation that otherwise triggers
some additional queries.
Task-2709436
Part-of: odoo/odoo#81028
PURPOSE
After this commit when creating a partner the language will default
to the crm lead value.
LINKS
Task-2580065
Pr: odoo/odoo#76812
Related: odoo/enterprise#20689
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Currently no chatter is added on team member form views. Indeed this model is
mainly technical and accessed through a dedicated menu in configuration.
However some fields are tracked and being able to see tracking information is
important in day to day dealing of team members. This is why we add chatter
on team members form view.
We also add context key to avoid autofollow when creating team members. As
chatter is mainly present for tracking and information no need to add extra
followers automatically. This causes unnecessary notifications.
Task-2679897
closesodoo/odoo#79356
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit consolidates UTM usage across all applications.
Global purpose is to avoid having undesired side-effects, such as unlinking an
utm.source/utm.medium/utm.campaign and at the same time cascading the deletion
to various records without noticing.
SPECS
ALLOW MORE PEOPLE TO CLEAN UTM RECORDS
Currently, not even the system administrator can delete utm.mediums and
utm.sources (he can only delete campaigns).
These were considered as "technical records", but allowing some cleanup is
a good idea since these records are often automatically generated and can
create a lot of unnecessary noise in the database.
That's why we now allow the following groups to delete all UTM records
(sources, mediums and campaigns):
- group_system
- group_mass_mailing_user
- group_social_manager (enterprise)
PREVENT DELETION
For some use cases, removing an utm.source/utm.medium/utm.campaign would
cascade delete the related record, which was unintended / hidden side effect.
These combinations were secured by preventing to unlink:
- mailing.mailing source_id field
Trying to delete the utm.source will throw an error message
- mailing.mailing medium_id field
Trying to delete the utm.medium will throw an error message
- hr.recruitment.source source_id field
Trying to delete the utm.source will throw an error message
ADDING CLEAN ERROR MESSAGES
When trying to delete an UTM record that is linked with ondelete="restrict", we
improved the error message to give a clear explication to the user, e.g:
"You can't delete these UTM sources as they are linked to the following
mailings in the Mass Mailing APP, and deleting the source would break the
statistics: Newsletter"
SPECIFY 'ondelete' strategy
For a lot of uses of sources/mediums/campaigns, the 'ondelete' strategy was not
specified, leading to the confusion of "is this really how we want to handle
this?".
A lot of ondelete="set null" have been added in various field definitions to
ensure that this is the desired and logical strategy we want for that
specific model.
PREVENT REMOVING HARDCODED UTM RECORDS
In some functional flows, UTM records are hardcoded using their direct
record reference.
This is notably the case for the recruitment process and its creation of
aliases, and for the Email / SMS Marketing flows.
As deleting them would break these flows, we prevent their deletion in a
"api.ondelete" method.
ENFORCE NEW RULES WITH TESTS
A lot of python tests have been added to make sure we enforce the decisions
taken here above.
LINKS
ENT PR odoo/enterprise#19048
Task-2459480
closesodoo/odoo#72239
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As this is a many2one, it should end with an ``_id`` suffix. Otherwise we
may think this is a char field, which was probably the case at one point.
Task-2671709
Part-of: odoo/odoo#78648
Purpose
=======
Give the user a more organized view of the digest KPIs in the backend and
improve global wording of digest sections and KPIs.
Specifications
==============
Reorganize order of KPIs in digest view. Fix some typos, move buttons in
list and form views.
Task-2582128
closesodoo/odoo#77507
Related: odoo/enterprise#21340
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When an user clicks on the Meeting tab to open the calendar,
it should onyl display the events linked to the opportunity.
task-2665863
closesodoo/odoo#79860
X-original-commit: 5a6e6e9fdd5bc85e8c79c09ef17b63bf4b95dd39
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When lead is won/lost, 'date_closed' field should be updated. But since
recent commit[1], this field was not updated while marking lead as lost.
It used to work prior to commit because we used to set `active` and
`probability` together from `action_set_lost` method.
But now, won and lost action are handled with `toggle_active` method.
In case of the lost leads, it first sets the `active` field to False,
and the `date_closed` is correctly updated by write method. After that,
it sets the `probability` to 0, and during that the write method sets
the `date_closed` to False.
This commit fixes the issue by updating `date_closed` field from write
method, only if the `probability` is greater than zero, and thus not
discarding the already set value.
[1] - https://github.com/odoo/odoo/commit/9b76c6b7f1eec4057289de90d62b8a7a266b0aac
TaskID-2343223
closesodoo/odoo#79154
X-original-commit: 3b9db86b76a838c0ae6cc9d517d7a29bff2c0544
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Context
-------
Leads get assigned a different company than the one defined on the salesman
after being merged with another lead.
This happens because some leads assigned to a user_id have no company set. They
are merged with leads that receive self.env.company during assigment to the
to the team and then get merged with the lead without company. So the company
of the new lead is written on the old one.
Behavior before this PR
-----------------------
When the crm.team have the field company_id = False
With the following flow
1) Create a lead without a user_id and a team_id
2) Assign a team to the lead
3) Assign a user_id
The status of the company field on the lead is the following
1) set the company of the env.user
2) Keep the company of the lead
3) set the user company if the current company is not one of the allowed
company of the user
Behavior after this PR
----------------------
1) set the company of the env.user
2) set the company of the team even if it's False
(so erase the company if the team has no company set)
3) set the user company if the current company is not one of the allowed
company of the user
Other changes
-------------
When resetting team and user: void company to avoid having leads without
any information but a company set. It eases assignment.
Task-2520276
closesodoo/odoo#78860
X-original-commit: ff2a6949c3a59be98cd1849e7a2e38c6ccc3187e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Thibault François <tfr@odoo.com>
The validation error raise
"AttributeError: module 'odoo.exceptions' has no attribute 'ValidationEreror'"
Instead the the correct message
"Member assignment domain for user %(user)s and team %(team)s is incorrectly formatted
closesodoo/odoo#78943
X-original-commit: a7ae22d0206eb833d584755e55351c41a12fd274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When merging multiple leads, we want to move the followers to the
destination lead if they posted a message in the last 30 days.
A message will be added in the merge note to know which followers have
been added.
Task-2447721
PR odoo/odoo#75742
Purpose
=======
Add more fields when we merge multiple leads to be sure not lose
valuable information.
Specifications
==============
Those fields are propagated to the destination if the value on the
destination is Falsy
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
The "lost_reason" field is propagated to the destination only if it's
lost (otherwise, it makes no sense to have a lost reason on a non-lost
lead).
The field "iap_enrich_done" is set to True if at least one lead has been
enriched.
We also keep the sum of all the lead tags (and remove any potential
duplicates).
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple lead have the same amount
of non-empty fields).
Task-2447721
PR odoo/odoo#75742
Purpose
=======
This commit remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views. This group was used
only to turn on / off the feature, not for security reason. So it's
fine to move the group in the views.
It will help for the lead merge so we will not be forced to use SUDO
during the merge.
Task-2447721
PR odoo/odoo#75742
Bug
===
Since fe8c5b9b01 , if you have a team
with set to `assignment_max` and you try to automatically assign the
leads an error is raised.
Technical: in `_allocate_leads` we skip a team if `assignment_max` is
Falsy. So when we prepare the values for the notifications, the key
might not be present in the dict an error is raised.
Task-2658696
closesodoo/odoo#78054
X-original-commit: 7c46b441266ff0336bf86d10ac2ee45d2a2c2959
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the crm.lead is of type 'lead', we don't want to display the
"Customer" field on the form view unless it's set (or debug mode).
Indeed, most of the times leads will not have this information set,
since when we assign a Customer we usually convert the lead to
an opportunity as well.
This means that on the lead form, we don't want to display this field
since it may be misleading for the end user.
When it's set however, we want to display it, mainly because there are
a few automatic synchronizations between the lead and its partner
(phone and email for examples), and this needs to be clear that modifying
one of those fields will in turn modify the linked partner.
Task-2596955
closesodoo/odoo#76233
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Right now, when we choose to automatically enrich the leads from CRM
settings, it activates a cron to periodically enrich the leads using
IAP service.
This commit improves the behavior by enriching the leads after the
records creation using cron trigger. That way it is done nearly after
creation and user gets enrich information sooner.
To make it clear to users, the description for 'auto' mode is improved to
'Enrich all leads on creation'.
Also, now we select 'auto' mode by default instead of 'manual', and
display 'Enrich' button on form view irrespective of the selected mode
(if lead meets certain conditions) unlike before. Rest of the behavior
is still same as before. For example, we still have server action which
can enrich the selected leads in batch, which is useful if there are
existing leads before we enable 'Lead Enrichment' feature.
Task-2269743
Part-of: odoo/odoo#60605
Use a template for merge post messages and clean how fields are displayed,
notably by fixing the display format, and the field order.
Indeed, previously posted lead merge message contained all fields in an
alphabetical order, even ones that had empty values, which is not very user
friendly in terms of display.
Now, the displayed fields are determined and ordered by sections, which greatly
improves understanding the various information.
Please note however, that it has the downside of not including all fields
anymore.
The merged leads information are included in a "read more/read less" enabled
block using the "data-o-mail-quote" feature to get a nice rendering and avoid
cluttering the Odoo chatter UI.
Within the sent mail however, the full text is directly visible when viewing
through a mail client.
Task-2451164
closesodoo/odoo#75946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
If for some reason we cannot compute lead probability, we should simply
continue to the next value without causing a division by zero.
For example, this can happen if all stages are team specific, as there is
a current limitation regarding the first stage (used to know how many lost
and won there is) that requires to have no team assigned to it. This is a
side effect of the commit https://github.com/odoo/odoo/commit/cd291b79eb2d2df80899867263ec71438ab8fe87 introduced in V14, and we should add
a test to ensure we do not crash in that case.
closesodoo/odoo#76379
X-original-commit: 9793bb29fe6c4d0d59905b2fcfe78ebe51e17579
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Purpose of this commit is to clean field definitions by
* doing compute in batch: especially when the loop can be reduced to a single
computation / batch assignment (based on groups or config parameter for
example);
* remove default when having a compute as computes should completely define
the field value at any time;
Some side dish code cleaning is performed at the same time: unnecessary
import or dead code removal.
Task-2638444
PR odoo/odoo#76005
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
- if the alias is configured for the team, the action helper
with the link of that email will be displayed. Otherwise, it will
simply indicate user to either create lead manually, or to configure
email alias.
- This commit improves action helper for the tags and adds
sample data for better onboarding.
- This commit adds action helper on action 'sale.action_invoice_salesteams'
for better onboarding.
- This commit updates the action helper for 'CRM > Customers'
and 'Contacts' actions and make the helper message consistent.
TaskID-2582208
Part-of: odoo/odoo#73530
Before this commit, editing a mail.activity with the "meeting" category would
open a modal form for the mail.activity, which did not make much sense.
When editing a mail.activity that is linked to a calendar.event, you will now
jump on the calendar view to edit the related event, which is much more
convenient.
In addition, when scheduling such an activity, the "Edit" button in the chatter
is renamed to "Reschedule", to show the user that he will land on the calendar
view.
Furthermore, trying to delete an activity that is linked to a meeting will now
prompt a confirmation dialog warning the user that the meeting will be deleted
as well.
Finally, we moved the 'phonecall' activity category from the 'voip' module
(enterprise) to the base 'mail' module.
Scheduling a phonecall activity will let the user choose if he wants to:
- Simply save the activity, which will schedule a regular mail.activity
- Open the calendar to create a related calendar.event
Used typically when you want your colleagues to see that you are busy in your
calendar during this call.
Task-2486126
ENT PR odoo/enterprise#20431
UPG PR odoo/upgrade#2775closesodoo/odoo#75530
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Before this commit, it was not possible to create events with defined attendee state. The default value was always set.
This was a limitation when the events were part of a recurrence and all events attendee needed to be created with a known state.
To reproduce, one would create a recurrent event, sync it with Google and in Google, 'decline' this event and the following.
The attendee state was not properly set.
closesodoo/odoo#68700
Taskid: 2484335
Related: odoo/upgrade#2537
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Rename ``crm_iap_lead_website`` to ``website_crm_iap_reveal``. This module
is an addition to ``website_crm``, notably using visitor based information
to generate leads based on rules.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Rename ``crm_iap_lead`` to ``crm_iap_mine`` . Indeed it adds lead mining
feature on top of crm.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Rename ``crm_iap_lead_enrich`` to ``crm_iap_enrich`` . Lead naming is not
really required as it is a bridge build on ``crm``.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
When creating a meeting from a partner/lead, the invitations won't be
created/sent
To reproduce the error:
1. Open a lead
2. Click on Meeting
3. Create a meeting
- On meeting creation, directly click on "Create", not "Edit"
Error: No invitation has been sent. When editing the created event,
there isn't any invitation on Invitations tab. Same error will happen
when opening the form of a customer instead of a lead (step 1)
For an attendee to be created, the partners associated with the meeting
must be explicitly listed in the creation values:
https://github.com/odoo/odoo/blob/3e20e68f0790a0b0f3b5c4d43f59f235b7d20fef/addons/calendar/models/calendar_event.py#L710-L713
However, in the above use case, the partners identifiers are given
through the context. This explains why the attendees are not created.
OPW-2531496
closesodoo/odoo#75353
X-original-commit: a8b4f8f6c009d8abd7210973005fd755ac3bc573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Currently,when merging opportunities, they are sorted by "confidence level",
which has following criterion for sorting:
- type (active opportunity is best, inactive opportunity is better)
- stage sequence (higher is better)
- ID (older is better)
For better sorting, this commit improves the confidence level by adding
probability as a third criterion, and so now criterion for sorting is:
- type (active opportunity is best, inactive opportunity is better)
- stage sequence (higher is better)
- probability (higher is better)
- ID (older is better)
This commit also adapts the test cases accordingly which now considers
probability as a factor for calculating confidence level.
Task-2198562
PR odoo/odoo#51893
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use Case
========
The cron run perfectly well when there is no concurrent transaction.
But in real life users may interact with leads modified in the cron.
This cause two issue:
Concurrent update
-----------------
If a lead is modified in another transaction during a the transaction
where the lead is modified. The parameter crm.assignment.commit.bundle
allow to reduce the size of the transaction but before this commit
the first transaction was always way longer because it took the time
to handle the bundle + the fetching of all the data at the begining of
the cron.
The solution: start a new transaction after the preparation
of the data is done
Missing record
--------------
If the a lead is deleted in another transaction before
the transaction that modified the lead starts.
The code will then try to access a record which does not
exist anymore in the database causing a Cache Miss and Missing record
error.
The solution: Make sure a record exists in the current transaction
before using it. It reduce a little bit the performance of the cron
but avoiding the crashes is at this price.
Discussion
----------
This commit does not remove completely the risk of crash
due to concurrent update but reduce its probability a lot.
To remove the risk of crash, a proper exception management should be
implement in a further commit
closesodoo/odoo#74166
X-original-commit: 4a70f7539ec53b9c3419f83d584ad99111d2e172
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a new submenu "Forecast" in "Reporting" for CRM
The Forecast shows 4 views:
1. Kanban
2. Graph
3. Pivot
4. List
Objective
Shows the short term forecast for opportunities (crm_lead) based on their
expected closing (date_deadline) and have an overview of the prorated
revenues for each period (defaults to month).
Implementation
1. Kanban
- the progressbar is using the prorated_revenue
- the forecast_field is date_deadline
- the default groupby is date_deadline
2.3. Graph, Pivot
- the measure defaults to the prorated_revenue
- the row defaults to date_deadline
4. List
- shows the prorated_revenue
The special filter "Forecast" is defined to be used by the
forecastModelExtension (JS). (define the forecast_filter context key)
The forecast_field context key is defined in the action to be used by the
forecastModelExtension and the forecastService (JS).
The demo data for opportunities is updated to spread date_deadline over 4 months
Enable drag&drop and quickCreate features for the kanban view with the use of
the allow_group_range_value <field> xml attribute
Add a "Won" flag for the forecast view to better distinguish opportunities that
need to be worked on
Test tour
Task-ID: 2243913
PR odoo/odoo#69380
ENT PR odoo/enterprise#18547
PURPOSE
Purpose is to avoid loosing frequencies and also avoid rebuilding the whole
frequency table. We choose to merge frequencies from team about to be unlinked
with "no team" frequencies.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case
LINKS
Task ID-2507750
COM PR odoo#70645
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
Next to the addition of a generic field adding a compute to find
my next activity deadline there is no need to keep a custom field
on crm.lead model.
Task ID-2438822
COM PR odoo/odoo#72219
Related: odoo/upgrade#2566
Related: odoo/enterprise#19044
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
1. Create a new database from the database selector
2. Do not select a country for your company
3. Install CRM
4. Create a new opportunity and select your company
5. The sync "warning" will be displayed, and it should not
The reason for that is the phone of the company is an empty string and the
phone of the lead is False. So we try to sync them and we show the warning
message even if for the user, nothing will happen.
This commit fixes that behavior by correctly checking that False / empty
strings are considered as equal.
UPDATE
In this commit we also display warnings about update only in edit mode to
avoid displaying irrelevant information to the user. Indeed email and phone
will be propagated at save, aka in edit mode.
TaskID-2499659
closesodoo/odoo#72286
X-original-commit: efea8fce6c7cb6e40b590cd827fe22e134cc3d13
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
-----
When a lead with an automated probability is merged with other leads and
if its probability is 0, it will be considered as null value and will be
erased by the value of the next lead with a probability > 0
The final lead gets a probability != automated_probability and is now
considered is_automated_probability = False. Therefore automated probability
computation will not be triggered anymore.
Expected behavior
-----------------
Possible use cases
* if the probability is auto on the master keep the auto probability;
* if the probability is manual on the master keep that manual value even if
it is 0 as sales people know their pipe and gave an accurate probability;
In other words: never take the probability from the merged records and always
keep the master one.
Task-2526926
PR odoo#70270
X-Original-Commit: odoo/odoo@4e14997f92closesodoo/odoo#70270closesodoo/odoo#72073
X-original-commit: 8fa6c154b196ec5bebb37293e70f9009a56e7974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, leads without any team_id set had their automated
proabbility computed based on the subset of all leads without team id.
Unless wrongly configured or strange pipeline use, all leads end up with
a team_id set. Therefore subset of leads without team is not really a
good set used to estimate probability of new leads.
After this commit, a lead with no team_id set yet will have its
automated probability computed based on the entire lead set.
Task-2526926
PR odoo/odoo#70270
X-original-commit: be1a55b305057803a67ec2b016e51325c992586f
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault François <tfr@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) crm.lead -> description
2) event.event -> note
Task Id: 2499504
X-original-commit: 524e2f089a611d897b98d86001bda5d17263db66
This commit fixes the UserError message by properly displaying the
number of maximum leads that can be merged.
Apart from that, this commit also hides 'email_from' and 'phone' fields
on merge wizard to avoid scroll and to make sure that the 'x' icon is
always visible, which previously was far right and user had to scroll
a bit for removing the lines with that button.
TaskID-2542260
closesodoo/odoo#71523
X-original-commit: abbf3419767c149f338a4a48f15c2af7dfbed2bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to ensure side documents are redirected to the
master opportunity when merging leads. Those side documents include
* communication history (mail.message);
* attachments (ir.attachment);
* visitors (website.visitor);
However some documents are currently not specifically handled :
* meetings (calendar.event);
* activities (mail.activity);
* sale orders (sale.order);
* attendees (event.registration);
In this commit we ensure all are attached to the final master opportunity.
That way we prevent loosing access to those documents and ensure we keep
the complete history of all merged leads.
Also tests are added to ensure the merging of leads and its contents.
A new field is added to have the o2m field between leads and calendar events.
In order to clarify naming, ``meeting_count`` is renamed to
``calendar_event_count`` to match naming.
Task Id-2457941
COM PR odoo/odoo#68884
UPG PR odoo/odoo#2494
Related: odoo/upgrade#2494
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When sorting by confidence level, put lost (inactive) leads last. This should
not happen when using the merge tool that filter out inactive leads but may
happen in case of manual merge.
Task Id-2457941
COM PR odoo/odoo#68884
Move the meeting stat button and kanban pill from CRM to Calendar, purpose is to
allow its usage even if CRM is not installed as this makes more sense since this
field is usually related to Calendar.
Increase query number limit in company leave test, in order to take into account
the newly introduced query in Calendar.
UPG-PR: https://github.com/odoo/upgrade/pull/2423
Task-2514473
closesodoo/odoo#69846
Related: odoo/upgrade#2423
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
All unassigned leads should be assigned to teams as soon as possible to ease
lead analysis.
Purpose of assign thresholds is to ensure sales people receive at least this
amount of leads within 30 days, counting lost and won leads. Giving them leads
regularly is also one goal of automatic assign.
SPECIFICATIONS
Counting every lead whatever its state may lead to an inconvenient situation.
If a salesman always reaches its maximum every days he will always receive the
number of lead he got 30 days ago. For example if the salesman goes in holidays
for few days and set the max to 0 he receives no lead during his vacation.
Then after a few days of assign he reaches its maximum and receive 0 leads
for a few days. This leads to having windows of leads that repeat themselves
every 30 days.
* Solution: do not limit at maximum capacity anymore. Compensation is voided
if limit is achieved. However asked assignment is done. Salesman could
receive more than its max capacity but 30 days window ensure old leads
are regularly going out of count.
``assignment_max`` is now more a mean target of leads to be assigned during
a 30 days window than a real maximum capacity. Field is renamed accordingly.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: 3d1841f26ce64f0106122e48750d2c653ea9790f
Co-authored-by: Thibault François <tfr@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
PURPOSE
All unassigned leads should be assigned to teams as soon as possible to ease
lead analysis.
Purpose of assign thresholds is to ensure sales people receive at least this
amount of leads within 30 days, counting lost and won leads. Giving them leads
regularly is also one goal of automatic assign.
SPECIFICATIONS: TEAM ALLOCATION
Team assignment has to be updated as we may have team domains that overlap.
We therefore remove maximum number of leads to allocate to teams. Instead all
available unassigned leads are allocated within teams.
- Solution: assign all available leads and not a count based on team's
capacity. This notably reverts the main goal of odoo/odoo@6df2f0cfc0
(see odoo/odoo#48422)
This assignment process is done proportionally to the team capacity. It is
computed as the sum of each member's maximum assignment counter. This means
that with a team having twice as much sale capacity than another team sharing
the same domain: first team should receive about 2/3 of leads while the second
one should receive the remaining 1/3.
- Solution: assign lead one by one. Choose a team randomly using a weighted
random algorithm, based on team's members capacity.
SPECIFICATIONS: MEMBER ASSIGN
Counting every lead whatever its state may lead to an inconvenient situation.
Moreover salespersons may opt-out from assign by setting their max capacity
to 0, for example when going on holidays.
When doing that lead assignment is not smooth and getting back to a full
pipe may take several days. To solve that issue a compensation is added in
assignment quota done to sales people. Salespersons having few leads will
get a boost in assign as soon as they get back in assign process. When being
near maximum compensation is nearing 0 and daily quota is given.
PERFORMANCE
During team assignation, assigning lead one by one may cause performance issue.
Since PLS is computed at each flush, so we want to flush after a bunch of lead.
To solve that we obviously need to not commit at each assignation but
also avoid to search for duplicate at each assignation, that why the
search for duplicates is done at the beginning of the process and stored
in memory.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: 83f72711e7affa8b0ad997b9ee262326e9577d54
When running the cron is should assign leads based on its frequency. If cron
runs once every day, work_days given to sub methods should be 1. If it runs
more than once day it should be less than 1. We therefore remove the *2
multiplier and support fraction of days.
As assign process will soon change, assigning more strictly compared to
salespersons capacity will not be an issue anymore. Assign process is best
designed to run every few hours (~4 times / day) or each few days. Code and
work_days are updated accordingly.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: c59ba43d1e9eb0c016b9a113c9475dec28fa413b
Automatic assignment is performed on leads that are unassigned and not won
nor lost. This commit fixes the condition that should be based only on
stage being set to a stage with ``is_won`` being True.
Current code fails with won unassigned leads that are assigned even if it
should not. This happens rarely as won leads have probably been taken care
of. However having the right condition ensure filtering won and lost leads
is not correctly done.
Followup of odoo/odoo@5016b47a06 (see odoo/odoo#48422)
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: d9fe86ec2ca6459a34b31e65c0702d8a80a7ec61
Co-authored-by: Thibault François <tfr@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
PURPOSE
Purpose is to try to reduce friction between searches in loops, team assign
on leads and unlink during merge process that unlink leads and forces flush
/ cache reset, as well as PLS computation.
SPECIFICATIONS
During team assignment setting team on leads one lead at a time may cause
performance issue. As PLS is computed at each flush we want to flush after
a bunch of lead. For that purpose we need to avoid too much commits and
also avoid to search for duplicate at each assignation.
We therefore perform the search for duplicates before going into allocation
and use a cache through loops to ease using pre-fetched information.
Unlinking duplicates at each iteration is also sub efficient as it causes
recomputation or invalidation. We therefore aggregate all duplicates to
unlink and unlink them in the main team-based loop instead of the sub loop
that is lead-based.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: c5310102210fb9afc6ab786f4c8f6eaf5aee59bb
Co-authored-by: Thibault François <tfr@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
New leads are automatically assigned to sales team and salesman during assign
process. Some of those leads are duplicates of existing opportunities. If a
new lead is merged into an existing opportunity, the opportunity is the master
data and the lead is duplicated. However the opportunity should keep its sales
team and not be assigned to the team being under automatic assign.
Before this commit, the merge was forcing the crm team to the 'current' team
during auto assignment and thus it was changing the team of the opportunity.
In this commit we now assign team to lead to merge before the merge and do
not force the crm team during merge process.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: 356a55053eb1cc49ae6eed0e58338cff08eddc42
Thibault Delavallée