When alias domain is not configured always display "Configure a custom
domain" link instead of an email having only a left-part or "Inactive
alias" if left part is void. This is already the case in edit mode but
not in read mode.
New specification is
* domain is not configured: display link in both read and edit mode;
* domain is configured and left part is set: display alias;
* domain is configured and left part is not set: display "Inactive alias"
in read and display alias name for edition in edit;
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
SPECIFICATIONS
We do not want to explicitly set an user as responsible when an incoming email
creates a lead or an opportunity. We prefer that assignment is done either
automatically (scoring) or manually.
Using environment user would lead to set either root (gateway user - already
prevented) either alias owner (through alias_user_id) either user sending
email if email_from matches. Doing it also allows to exclude portal / public
users that would send an email to the mailgateway.
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
SPECIFICATIONS
When changing "use leads" from CRM settings automatically regenerate apply this
option to all sales teams using opportunities. When de-activating it no team
should have this option activated as menus and options are hidden. When
activating it we consider that all teams should be upgraded by default.
LINKS
Task ID-2414079
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
PURPOSE
Remove the alias setting option because it is a weird and hackish way to
proceed. We would prefer users to configure their alias through sales teams.
Improve alias configuration on teams.
RATIONALE
"Incoming Emails" option has many flaws
* it creates collision when you try to set an alias that is already used
and it is not easy to find them back;
* it has no default value (no sales team, no type, ...) and works through the
'owner' field. This is set with the admin on activation of the feature
which is not correct. The admin is potentially not a salesperson. If you
set the field to blank, you get leads without team and without assigned
responsible.
* this alias is not team-bound which thus asks the question: in which team
should the lead ever go? To the first team? Why?
All this make it seem way healthier to handle this through the Sales Team.
=> By default, we'll already have one working with an alias.
If users really want a global lead alias it can be setup manually through
alias menu in configuration. Shortcut and default alias in crm are removed
but feature is still doable if requested.
SPECIFICATIONS
Remove the s "Incoming emails" setting that allows to setup a global alias for
leads / opportunities with a default value being 'contact'. Also remove related
alias data as it has no use anymore.
LINKS
Task ID-2414079
Sort of follow-up of Task ID-2373095.
COM PR odoo/odoo#63160
UPG PR odoo/upgrade#2017
This commit adds few missing default values for some of the partner
fields while we create partner on the fly with quick create kanban
card of lead. Below are the fields that we added
* name
* is_company
* company_name
* phone
* email
Task ID-2409462
closesodoo/odoo#63622
X-original-commit: 5b3290b0869e3954ff1606ad0ca0a35cfd948698
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the display of the rainbowman message when leads go through
the "won" stage.
Currently, some flows don't show the message when they are supposed to or show
the message when they are NOT supposed to.
This is because the case when the form is saved through the regular "Save"
button is not handled at all.
The CRM form controller extension was completed with the missing use case and
fixed.
An additional QUnit test ensures the correct behavior.
Task-2418294
closesodoo/odoo#63599
X-original-commit: c5cbb9975897935e9ed4e1bce80335207758fa24
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With a recent commit[1], we fixed the issue of false warning while changing
the partner on lead. But that fix ignored the fact that the lead has an
automatic formatting that may lead to false warning.
Right way to detect a phone number change is
* lead phone is different from partner phone;
* lead formatted phone is different from partner formatted phone;
If those two conditions are met we are quite sure numbers are different and
not only differs in their formatting.
In this commit we also fix inverse of phone number. When updating lead phone
value we have to use the same heuristic to update partner phone value. That
was we avoid unnecessary partner update when only formatting differs.
Tests are added to ensure new behavior and that ribbon message is effectively
trig erred with correct content.
LINKS
Task ID-2390287
[1] - https://github.com/odoo/odoo/commit/d29862c1de6208f7fdb7c8104afe0d35241d130bclosesodoo/odoo#63521
X-original-commit: 5154f40544e7913f7bcd0ff73f034d111700f580
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Ijas Ahammed <ija@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closesodoo/odoo#63259
X-original-commit: 47079f67f586adf45da15fc98dbc81571f7a9100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to avoid the use of sets in convert wizard. This set
is used to compute ids of leads to merge and to convert. Using a set make order
impossible to predict. Using lists allows to have reproducible tests notably.
Spotted when working on task ID-2086889
Crm holds a blank template that adds no real value. Its purpose was to
give a base for salesmen to perform a mass mailing on leads. Using a template
and its action menu entry it was possible to launch a mail composer in
mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
This commit changes the default crm alias prefix from 'info' to 'contact'.
As the alias of the default sales team is configured to 'info', also having
'info' for the "crm_alias_prefix" setting was leading to an alias collision.
This change allows an easier configuration by the end user and avoids confusion
when first playing with your CRM settings.
Task 2373095
closesodoo/odoo#62025
X-original-commit: 31497e17e2369147fa40ab8b3f82cb2602ec9012
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
This commit slightly changes the crm tour by changing the position of a tip
bubble.
During the quick creation (kanban) of a record, the tip text was placed on top
of the m2o selection proposals, making them hard to read / click.
We simply moved the tip text to the top of the selection instead.
Task 2373095
X-original-commit: 878bffce2582a3abbc9285631af947be78086e19
When clicking on the stat button "Meetings" on a contact:
- before dac91bc18 (November 2019): only meetings with participant
matching contact name are shown
- after dac91bc18 (November 2019): all meetings are shown => this was
because the view was used to create new meeting, so it makes sense to
see other meetings and not have a conflict.
- after 16206d72 (August 2020): only meeting of the contact are shown
- after 7449c8a6 and d11fb611 (November 2020): more complicated logic
that will also show partner events, and child partner events.
Since August 2020, when you create a new event, since we are showing a
list of IDs at the time the button was clicked, the new event will not
appear unless you go back to the contact, then click on "Meetings" anew.
With this changeset, we still show a list of IDs, but add an alternative
to also show the events of the current partner (that should be in the
list of IDs, but will match new events).
opw-2374021
closes#61490closesodoo/odoo#61690
X-original-commit: eb6e03908bfb6ed8bbe231da2a4422ec2e149834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Pupose of the task is, to set up a dedicated 'dashboard' reporting menu
item, and make the graph view the default the other 'leads' and
'opportunities' reporting menus.
So in this commit, change the default view graph in normal report
(except dashbaord menu) and each menu should be submenu of reporting
menu Also apply default filter for lead reporting menu
TaskID: 2311392
Related Enterprise: https://github.com/odoo/enterprise/pull/12419
closes odoo/odoo#55598
Closes: #55598
Related: odoo/enterprise#12419
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Make the "activity_state" searchable on the "mail.activity" mixin.
This field is not stored as it depends on the current time.
Technical
=========
To make the search, we perform a SQL query.
The "activity_state" depends on the state of each activities on the
record. And this state also depends on the timezone of the user of
the activity. That's what made things tricky and we need to make the
conversion in SQL for performance purpose (we can not fetch all records
and compute them in python).
There's a special case, where there's less than 24 hours between the
deadline and the current time but one day of difference. In that case
the state should be "planned" and not "today". This case is handle by
the function "DATE_TRUNC" (e.g. 23h 01/01/2020 & 1h 02/02/2020).
Also for performance purpose, we compute the delay only once and we use
the function "SIGN" so we can use a switch/case instead of duplicating
3 times the expressions.
Task 2354754
closesodoo/odoo#60074
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose is to ease the onboarding for the default CRM settings.
Now, we do not include any field by default and tags become an option
in the choice of fields apply to the computation.
task-2196200
closesodoo/odoo#48124
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, in multiple modules, long names would result in an overflow of text.
With this commit long texts should appear like this: [aaaaa...] instead of
going out of their boxes.
Various views are updated, depending on which fields we wanted to prevent
from overflowing and the probability they do so.
Task ID-2325219
PR odoo/odoo#57713
PR odoo/enterprise#13226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When we clear the configuration parameter crm.pls_fields unlink method is
called. In order to have a correct dynamic compute based on this parameter
we need to re-evaluate the depends. This is done by overriding unlink of
ir.config_parameter, like already done at create and write.
Task-2196200
closesodoo/odoo#61293
X-original-commit: d04cc4df4ec28816aeb6d1d7c7fc0e547fd13fa5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
WHAT: apply 93a7695f65baf00d1f82481d6a2a97e6c11940a8 for all res.config.settings
menus
WHY: the same reason as in 93a7695f65baf00d1f82481d6a2a97e6c11940a8:
When saving, a read is called. By default, read has
bin_size to true to avoid performances issues.
It will return the image size instead of the content
it may lead to image dissapearing or "Incorrect padding" error
HOW:
find . -iname "*.xml"|xargs grep "\"context\".*'module'" -l | xargs sed -i "s/\(\"context\".*'module'.*\)\}/\1, 'bin_size': False}/"
git checkout -- addons/base_setup/views/res_config_settings_views.xml
---
PR for General Settings: https://github.com/odoo/odoo/pull/47297
opw-2346644
closesodoo/odoo#61215
X-original-commit: 7c55efa88b72bd1f3f0f32f7f738e2fda5aa4abd
Related: odoo/enterprise#14547
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create an opportunity for CH1 and a subscription for CH2
Bug:
The count of opportunities in C was displaying 0 instead of 2
opw:237344
X-original-commit: d11fb611fed3a8541d03b7d3e49973ae7c16a768
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create a meeting for CH1 and a meeting for CH2
Bug:
The count of meetings in C was displaying 0 instead of 2
PS: set() is used to avoid to count several times the same event for a partner.
If for example CH1 and CH2 attend to the same event, only one event must be counted for the
parent C
opw:2360155
X-original-commit: 7449c8a6643477742616bf236f2f2c90aec68581
Co-authored-by: nim-odoo <nim@odoo.com>
The 'Mark as lost' server action raises an AccessError when executed by
a non administrator.
Due to de4213b771
opw-2371490
closesodoo/odoo#60866
X-original-commit: b80e44bac5de3ccffad42917307bb5f049a7bec6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Improve ui in CRM settings to ease user understanding and using settings.
SPECIFICATIONS
This commit re-organizes some crm related settings groups for better
usability by interchanging their positions and by putting related
groups together.
Crm PLS warning improvement: https://tinyurl.com/y67ug3fr
* Reword PLS explanation and button (followup of 9a57a7edfb)
Settings cleanup: https://tinyurl.com/y5lwqwe6
* Move "Leads" option on the right, next to Recurring revenues;
* Move "Incoming Emails" below "Leads";
* Switch "Visits to Leads" and "Outlook CRM Extension";
LINKS
TaskID - 2351582
closesodoo/odoo#60264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes few of the strings / layout for the settings related
to CRM and makes it less technical and thus more understandable and
also updates the required translation strings.
TaskID - 2351582
closesodoo/odoo#60790
X-original-commit: 55b05ed5e2cf083ac1e6d807d59e5533f4fb94b6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit:
When accessing activities from the systray, any existing breadcrumb-item should
be clearer.
After this commit:
Clear breadcrumb-item when access activities from the systray.
Task-2342246
closesodoo/odoo#60018
X-original-commit: a9b32448c4a6227ef8e729436cb793ea9c24c289
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Whenever when change the 'Leads' of 'Pipeline' boolean field on sales team,
it should also update the linked alias. Mainly, if 'Lead' is checked, the
'Default Values' on the alias should also be updated.
It used to work before a recent refactoring (see commit [1] and [2] for more
information).
This commit adapts the changes done in refacotring and updates the alias values
while updating the sales team.
[1] - https://github.com/odoo/odoo/commit/7cfd364db54e88970ef51c798df3bd4df44222b3
[2] - https://github.com/odoo/odoo/commit/186cfb5ebd35d572d0f635cd7975de7cff0d1055
TaskId - 2357573
closesodoo/odoo#60008
X-original-commit: 0669ee36e195e8e0f98131219b59fcc5cba4cea7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem
-------
Sales people can have restriction on partner they can see
Private addresses, multi company, ....
When they convert a lead to opportunity, it's currently possible
that the wizard will find and link a partner that the current user
cannot see.
Solution
--------
Field that are now computed store field, that were previously
normal field with onchange, should not be computed as sudo
to respect the record rule
closesodoo/odoo#59957
X-original-commit: 182fa38d7f28a92e7171c4ee3a42c8f73217b765
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To investigate a bit. Sometimes a few extra queries are generated.
Task ID-2359847
closesodoo/odoo#59869
X-original-commit: 36bb56a5e9704c76e84960ec84588524b52406f8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The URL to the mail extension module documentation in the settings view is
currently wrong.
It only works temporarily because of a redirect we setup on our website.
This commit updates the URL to the proper location of the documentation.
When we later support Gmail, the view will have to be updated to contain two
documentation links: one to Outlook and one to Gmail.
Task 2356910
closesodoo/odoo#59503
X-original-commit: 3968cfebfabcf34f800203d880c4a719c0f1174c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Handle salesmen allows to assign responsible to leads using a round robin like
algorithm. Currently a write on each lead is done to update its team and
responsible, even if number of leads is far greater than number of available
users to assign.
Current implementation can be simplified by doing one write per sales person
to assign on its batch of leads, or a single write if no salesmen has to be
assigned.
Performance counter on a mass convert wizard on 50 leads show that we gain
about 9% of queries (125 on 1471) with this simple optimization.
Task ID-2351604
PR #59084closesodoo/odoo#59324
X-original-commit: 973a2998666813ca4fbe90f1b486c1b18091c4e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to
* move tests about mass management of leads (mass assignment + mass convert
wizards) in its own file to ease writing of tests;
* add some performance tests :
* performance for assignment;
* performance for convert wizard in mass mode;
Task ID-2351604
PR #59084
X-original-commit: 950dd491bc4b680e0bcfab83815313e909a3c282
Currently when trying to find duplicates of a lead with an email that
cannot be normalized and without partner, a crash appears as there is
no domain part to form a valid domain.
Fix it by returning a void set if no valid email and no valid partner
is set on the lead as we cannot determine any duplicate based on void
information.
closesodoo/odoo#59147
X-original-commit: 291db77cf09c6ee76373fd168f575fda28270467
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
While running 'crm_tour' in test mode and quick creating record on
crm kanban, adding a partner and moving to another field from
tour opens a confirmation dialog asking whther or not you want to
create a new record. This dialog remains open sometimes, breaking
the further flow of tour.
This commit fixes the issue by selecting or creating the record from
drop-down after adding a partner (and before going to further steps),
thus avoiding the confirmation dialog.
Note:
- Because we create/select the partner, the 'name' field is auto filled
and we don't have to set anything in there. So this step is not needed
anymore in the tour.
TaskID - 2323196
closesodoo/odoo#58823
X-original-commit: a592ba14f82028487cee0b060a86881f0175aeda
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds sequence to CRM tour so that it can be prioritized over other
apps.
Task ID-2302572
closesodoo/odoo#58799
X-original-commit: 7372d9995aaad2fd8a259cbdea6e176bac6017b0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the salesperson(user_id) field with many2one_avatar_user
widget that will display avatar before user name.
Task Id : 2302572
PR #565013closesodoo/odoo#58781
X-original-commit: ec05118e85d7e3d4611c5688f3c4a572c86d0afa
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: D J <dja@odoo.com>
Fix the redundancy of "Send email" menu on the crm.lead model. We now correctly
have a form action in comment mode, and a list action in mass mail mode.
We also update the use of those actions according to the business flow: form
based from a single record, mass mail from a batch of records.
Task ID-2310462
Somehow forward-port of X-Original-Commit: odoo/odoo@9ded57d87fclosesodoo/odoo#58774
X-original-commit: ad7d28ab1abe484102cd3ec18ee6ce9c9ac7b5bb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes a missing default_partner_id in context of 'Opportunities'
stat button on contact form. It allows to immediately link a new opportunity
to the contact we came from.
Task ID-2343221
closesodoo/odoo#58722
X-original-commit: 77d4ba222630fa0f97351186782d09d2ec59a42a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit we remove the warning logger when not being able to format
a phone number. Indeed this does not indicate there was a real issue.
It simply indicates that either the phone number is not parsable or not
matching given country format.
It happens in a lot of situation that phone numbers are not valid: bad
encoding, country mismatch due to {lead, task, ticket} / partner not always
being the same, ... This should not raise a server warning.
When using frontend SMS composer for phone number, a warning is displayed
to the user telling the number is probably incorrect. This is considered
as sufficient from UX point of view as it warns users. We do not think
we should warn admins that some data is incoherent in database.
This commit also
* Revert "[FIX] crm: avoid linking demo leads with an unrelated partner"
This reverts commit 2c94c4c81ffa171158586cd64828d27c537cd1d6
-> having "invalid" data should be a valid use case of real life
* Revert "[FIX] crm: get correct country for phone validation"
This reverts commit a58f9fc154c038d72031b281e2bec2c0fc2915ba
-> country of a lead comes from its partner if set but can be different.
Same for phone numbers. Values on a lead after a compute are considered
as complete. Sales persons could effectively have incoherent data on their
form view but that is the result of what has been encoded.
Task ID-2325228
X-original-commit: cecc4ca6f02e599e193c3fa688bfcbd02ac0580b
Using this partner will copy his phone number on the lead.
However, the lead and the partner don't have the same country, which
will lead to ad invalid phone number (for the lead country).
It avoids a warning emitted by the `phone_validator` module, while
browsing the lead.
closesodoo/odoo#58352
X-original-commit: 2c94c4c81ffa171158586cd64828d27c537cd1d6
Signed-off-by: Christophe Simonis <chs@odoo.com>
The method _compute_probability has a dynamic depends, that depends on the
crm.pls_fields config parameter. When installing the DB, the depends is
evaluated. If the config parameter is modified afterwards, the depends is not
re-evaluated as the registry is not rebuilt.
The result is that when modifying the config parameter, if an optional
pls_field's value is modified on a record, the compute won't be triggered, as
that pls_field is not in the compute's depends.
This commit force to re-setup the registry after a modification (or the
creation) of the crm.pls_fields config parameter, in order to force the
depends of the _compute_probability method to be updated.
Task ID: 2341829
closesodoo/odoo#58165
X-original-commit: e95afbedc18d198454c7f66b523c4cafb19a4066
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
Setting a lead to won or lost should not impact others leads' probability
until they are modified.
Tests have been added to ensure that.
Task ID: 2254543
closesodoo/odoo#57681
X-original-commit: 7edc12e366659d226d56197e09bd65d17c80bd2f
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
Purpose
=======
Get rid of the cron.
Always have an up to date frequency table to compute lead probability.
Clean PLS code and ensure to remove unnecessary code
Specifications
==============
Disable the cron:
- Increment won and lost count for lead PLS params from frequency table at
each won/lost
- The complete set of leads won't be recomputed anymore every day
- A lead probability will only be recomputed if one of the PLS parameter will
be modified (stage_id, team_id + the ones checked in settings)
- No more onboarding phase : as frequency table is always up to date and only
the modified leads are recomputed, we can drop this. (So even on onboarding,
winning or losing a lead won't impact other leads, except the ones we modify
manually afterwards)
- Add an button to force the recompute of all the lead probabilities
(kind of reset) in the settings.
The cron has been disabled by default.
Users can know choose to reactivate it if they want to continue updating their
lead probabilities on a daily basis.
Code have been reorganised for better structure and understanding.
Some code parts have been factorised to be usable in both Live Increment and
Full Rebuild mode.
In this commit, we also update probabilities using only computes
Before this commit, _update_probability was called during write and create,
to ensure both probability and automated_probability were correct. That was
necessary because of onchanges and readonly field (automated_probability
was not given to the write method while saving after a change on the lead).
After this commit, we use the force_save tag on the readonly field
automated_probability. So we ensure that write always receives the new
automated_probability value and everything can be handled directly by the
compute. Also, we force the lead to start in automated probability mode.
So when creating a new lead, both probability and automated probability are
computed and aligned.
Finally, when winning a lead, we ensure that both probabilities are aligned
(=100), so that if user take the lead back to a previous stage, the
probabilities are correctly recomputed, and the lead will not be stuck to
100%.
Also, this commit applies some fix and minor changes listed here under:
- Ensure to have always positive frequencies
- Fix lost counts for team not set in pls computation
- optimise set_won : write only once per values
Finally, include tag in frequency table even if less than 50 occurences:
Due to refactoring in which we increment frequency table at each won/lost
instead of rebuilding the frequency table each day, the tags are never added
in frequency table.
This is due to the 50 occurence conditions that avoid to create the frequency
if we have less than 50 won or lost for a tag.
After this commit, we include the tag_ids in the frequency table, no matter
the number of occurences. But, during the PLS computation, we skip the tag
frequencies if the number of occurences for this tag is under 50.
This allows to have a complete vision on the tag frequencies, even for
small number of occurences.
Task ID : 2254543
X-original-commit: cd291b79eb2d2df80899867263ec71438ab8fe87
- Go to CRM > Settings and activate Leads
- Go to CRM > Leads and create 2 Leads with a different phone number
- Select the 2 created Leads and in Action menu, select Send email
- Make sure that "Lead/Opportunity: Mass Mail" is selected as template
- Send it
- Go to Contacts
2 Contacts have been created from the Leads, but both have the same phone number.
The issue comes from the override `default_get` of `res.partner` in crm module.
It is using `active_id` from context to fetch the Lead to populate Partner data.
This cannot work when several Leads are selected as the same `active_id` is used
for all of them.
opw-2333819
closesodoo/odoo#57638
X-original-commit: a84dcfb9475051082c6103f81bfa231ea50ed157
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
For the graph views based on reporting models (e.g sale.report), click
on a group in the chart redirects the user to an "empty" list view. Here
we use the attribute disable_linking to avoid that redirection for those
views.
Task ID: 2336960
closesodoo/odoo#57622
X-original-commit: 0b0ae92b6bdac25843ba24d767dbcab3b75703e5
Related: odoo/enterprise#13192
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before when we tried to duplicate a lead without the mrr option
active, a traceback was raised.
If the MMR option was not activated, then the user was not be able to write
on some field because he was lacking the corresponding group. In this case,
the recurring_revenue and recurring_plan fields.
Now, when copying a lead, we purposefully set those fields to 0/False to
avoid a crash if the option is not enabled.
task-2325629
closesodoo/odoo#56927
X-original-commit: 1a5cc55dfeb03ad7d4a63a0286d5d33eaca3cbe2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Thibault Delavallée