Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
PURPOSE
Make sure the Rainbowman animation is rightly triggered whichever way the user
marks the opportunity as won. Especially relevant for the onboarding as we want
to show the first rainbowman to users completing the tour.
SPECIFICATIONS
Now the rainbowman and its finely-tuned message are displayed to the user when
he uses the statusbar, mark lead as won using action buttons or drag and drop
a lead in the won stage in kanban view.
LINKS
Task ID-2287758
PR #54553
This commit adds a few minor improvements to crm views:
- Add the crm.team currency on opportunity amounts on the crm.team kanban view
- Slightly reorganize "My Activities" view for increased usability
- Remove the "alias_user_id" field in the crm.team form view because it's a
related technical field that is not supposed to be modified there.
Task #2314894closesodoo/odoo#55940
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
PURPOSE
Allow users to configure contract recurrences and Monthly Recurring Revenues
on Opportunities they're trying to close. One short revenues are not sufficient
to cover real life use cases of CRM revenu analysis.
SPECIFICATIONS
Adds an option in the settings to activate the recurring revenue feature.
This feature is set on an opportunity to indicate a revenue that could be
perceived over time. This time indicator is set by the crm.recurring.plan
model in which the number of months is determined.
By default some plans are added in data. When using plans, revenues are
computed across the plan months.
LINKS
Task ID-2283052
odoo/odoo#54194odoo/enterprise#12423odoo/upgrade#1463
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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
Avoid automatic partner finding and update on lead to erase too much data.
RATIONALE
On crm.lead, the address fields, email_from and phone, are computed field
since saas-13.3 based on the partner_id. Previously they were synchronized
with an onchange on partner_id which was never triggered during automatic
flows on the lead.
Now computed field are triggered each time the partner_id is written.
Problems
- If someone uses the mass conversion with the action "Use existing partner
or create", the partner is found for each lead with the method
_find_matching_partner. This method can find any partner with a name that
contains the lead name, the lead contact_name or partner name. It can find
wrong partner. Previously, only the partner was changed and the contact
information remained on the lead. Now, all the information are erased with
the wrong partner information.
- If at creation all the address information are set and the partner_id
as well, the address field from the partner won't be synchronized.
The lead will end up with the address information we forced.
During the conversion to opportunity, the partner_id defined on the
lead, will be written again. It will trigger the synchronization
of the address field on the lead. Those info can be incomplete or wrong
You will end up with a data loss.
SPECIFICATIONS
Tell _find_matching_partner to match partner only based on exact email address
in the case of mass convert. Avoid fuzzy matching based on name likeliness.
During opportunity conversion, don't write the partner_id if the partner is
already the one set on the lead.
LINKS
Task ID-2316828
PR #55825
X-original-commit eed0a31e1e2c428c94dae4703c9575534a49ec1d
X-original-PR #55194closesodoo/odoo#55838
X-original-commit: e82b5a92f44709592b25fa66d9555d64abef1ec9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Distinguish synchronization of partner values on lead: address fields (all
or none), classic fields (propagate if set) and special cases (names-alike).
SPECIFICATIONS
Follow up of https://github.com/odoo/odoo/commit/f8179007f9aa662be7318edeb18426ea1c906c15
Context: many fields are now synchronized from the partner_id: address fields
as well as other contact fields. A first commit 9c9f477f04e8f4ee9b18092fe894890c2ab31b58 kept the value
from the lead if the value from the partner was empty. This lead to mixed
address fields.
A second commit fixed that behavior f8179007f9aa662be7318edeb18426ea1c906c15 by taking the value from
the partner only when it was set.
Problem: This erases too much information.
```
>>> lead.partner_name
'testtest'
>>> partner_id.name
'testtest@mailinator.com'
>>> partner_id.parent_id
res.partner()
>>> partner_id.is_company
False
>>> lead.write({'partner_id': partner_id.id})
>>> lead.partner_name
False
```
We indeed need a consistent address but for the other fields we want to keep
the maximum of data.
SOLUTION
For the address fields, take all the values from the partner if one of the
address fields is defined, otherwise keep the information defined on the lead.
For all the other fields keep the lead information if the partner information
is empty.
LINKS
Task ID-2316828
PR #55825
X-original-commit https://github.com/odoo/odoo/pull/55194/commits/f53fba6663a34e8e6b13354dde3dc225f5814de3
X-original-PR #55194
X-original-commit: b136df8530279a54c9be96beeea9bdda01643000
PURPOSE
Improve user experience by improving copy writing of tour steps and first
encountered screens.
SPECIFIFCATIONS
Improve Pipeline empty list help to be more catchy and help users doing their
first opportunity related steps.
Improve tour copy writing.
LINKS
Task ID-2316699
PR #55604
Followup of 9c9f477f04e8f4ee9b18092fe894890c2ab31b58 and f8179007f9aa662be7318edeb18426ea1c906c15
In some cases (notably event_crm addon in 13.4) a country record is propagated
instead of a country ID; converting as write values ensure we always deal with
IDs in all cases.
Also add some tests to cover more test cases. Notably phone and email behavior
in 13.3 compared to other fields. For example phone is kept is partner's phone
is void. It may leads to inconsistencies (partner US, Belgian phone number).
We think it is better to keep values and let salesmen change them than
voiding values customer gave.
PR #55390
Task ID-2311981
closesodoo/odoo#55412
X-original-commit: a26735f516e48acb77e234862e17e29be71d7d1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Consider a lead with valid email and/or phone. Some process assign a partner
to it, like mass convert. This partner has no email and/or phone. We should
not void lead values for email and/or phone, as this is information loss.
This is a followup of 89ca89ca92 . Test cases are added to try to
avoid future regressions.
Task ID 2311981
PR #54619
X-original-commit: 0b69d98cf4cbd2c99d7c3fb510e324f49652eea5
FIXUP of 9c9f477f04e8f4ee9b18092fe894890c2ab31b58
[FIX] crm_lead: do not erase computed field based on partner
Don't erase the field on the lead if you emptied the field partner_id
but erase them if you select a partner_id that have empty value
for the corresponding field
otherwise you end up with mixed address field.
Make an exception for the phone and the email_from
Keep the value from the lead if the partner_id has no value
for those field
X-original-commit: ed3979f84e65ebfa9534f12196a8fa41cade8370
Issue:
When you write partner_id = False on a lead
it erase all the values computed based on the res.partner
this lead to data loss during the conversion to opportunies
by the lead assignation process
Solution:
Revert to v13.0 behavior, don't erase the value
of the address, phone, email when the partner is set to
False
+ Fix typo in method name
X-original-commit: 21db6cf93fea7d07ec4a8655fc6030a177abc36f
Purpose of this task is to prevent merging of opportunities when
a regular (non super) user selects more than five records.
This commit limits total number of recorrds to be merged, up to maximum
five leads / opportunities for non superuser environment, and raises a
UserError otherwise explaining the threshold limit.
closesodoo/odoo#55024
Task-id: 2256126
X-original-commit: c25d7654f250c888cea84c20af16b2a32cc5b365
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the lead, we compute the phone number to make it formatted to match
with the international phone number format.
Before this commit, this formatted number was used for comparison with
partner's phone (which is not formatted), and so, even if both the
numbers are same, the warning ribbon appears due to different formats
which is not correct behavior.
This commit fixes the issue by comparing both the formatted number to
remove the false positive warning ribbon and thus making sure that it
appears only when there actually is a difference between lead's phone
and the phone number set on partner.
Task Id-2274752
closesodoo/odoo#54942
X-original-commit: d29862c1de6208f7fdb7c8104afe0d35241d130b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1. set a Sales team and add an alias
2. create a contact (customer) with an email and grant them portal
access (under the action)
3. Odoo creates a portal user
4. use the email of the contact to send an email to the alias set under
the sales team
An opportunity is created but the sales person assign to that
opportunity is the customer.
This will revert user if the user has no access to crm.lead
opw-2288442
closesodoo/odoo#54217
X-original-commit: a3fdff3dd9cc38b432b93a7cd4387cb7c38b8d06
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
General Purpose : Introduce a new "My Activities" view so that CRM
users can easily overview and process their To-Do list
- new button in "My Activities" tree view : Send Email
Purpose: allow users to send email in one click to the client
- new button in "My Activities" tree view : Send SMS
Purpose: allow user to send sms in one click to the client
- new button in "My Activities" tree view : Snooze
Purpose: easily Snoozes the activity for 7 days
--> today + 7d if deadline < today
--> deadline + 7d if deadline >= today
- New view crm_case_tree_view_my_activities to show "My Activities"
Purpose: Use this view so that CRM users can have a "To Do List"
Domain of this action is : crm.lead, type = opportunity
Filter is : My Activities (at least an activity assigned to me)
- Rename filter "assigned_to_me" to "My Activities"
- Change crm_case_tree_view_oppor to be clearer for the user.
Purpose: allow the user to have an good idea of what he has to do in
a view.
Remove all decorations set on the CRM tree views
Add the widget remaining_days to the field activity_date_deadline
Add the field activity_ids with the widget list_activity
- New menu item and corresponding act_window to display the new views
Task ID 2243124
Community PR odoo#51537
closesodoo/odoo#53376
X-original-commit: 2382c01956feda617b7d207d1bc4d69de1e8b6b3
Related: odoo/enterprise#11314
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
RATIONALE
Activities are a way to organize our daily pipe. Notably in a sales pipeline
salesmen may have multiple leads with activities to perform in the next few
days. We would like to be able to have a list view displaying a list of leads
with "my" deadline, and to order leads based on this field.
PURPOSE
As activities are linked to records through a one2many and as my activities
are only a subset of those activities, it is impossible to store a field
on lead model. Indeed it would depend on the current user which makes storing
it impossible.
However ordering on a column in list view asks for a stored field. As it is
not possible, this commit proposes to hijack the web client and search of lead
model in order to allow it.
SPECIFICATIONS
Introduce a activity_date_deadline_my field, computed and searchable that
behaves like activity_date_deadline. It is filtered on current user activities
instead of being global to the record activities. "My" deadline is the earliest
deadline of my activities, even in the past.
Ordering through web client calls search_read with an order parameter set.
Search_read then calls search. In this commit we therefore override search
to intercept a search without count with an order on activity_date_deadline_my.
In that case we do the search in two steps.
First step: fill with deadline-based results
* Perform a read_group on my activities to get a mapping lead_id / deadline
Remember date_deadline is required, we always have a value for it. Only
the earliest deadline per lead is kept.
* Search leads linked to those activities that also match the asked domain
and order from the original search request.
* Results of that search will be at the top of returned results. Use limit
None because we have to search all leads linked to activities as ordering
on deadline is done in post processing.
* Reorder them according to deadline asc or desc depending on original
search ordering. Finally take only a subset of those leads to fill with
results matching asked offset / limit.
Second step: fill with other results. If first step does not gives results
enough to match offset and limit parameters we fill with a search on other
leads. We keep the asked domain and ordering while filtering out already
scanned leads to keep a coherent results.
All other search and search_read are left untouched by this commit to avoid
side effects. Search_count is not affected by this commit.
As web client order availability is simply based on field being stored we
have to allow hijacking its value. A new option 'allow_order' is added that
display the order icon in list view column headers. It allows calling
search_read with an order based on the column but nothing more. Using it
on a not-stored field will give a warning log and ORM ignores it by default.
LIMITATIONS
At least following limitations apply
* search on "my activities" gives a list of ids that is used for searching
and ordering. It means that having too much activities on a given user can
result in poor performances.
-> we consider that activities assigned to a given user should be kept
under control. Leads with activities for a given user should be a small
subset of leads without activities.
* ordering on activity_date_deadline_my always put those records on the top
(deadline asc or desc) whatever the actual ordering of order items given
to search. This is done to avoid complex implementation where deadline
would be used to order records within groups ordered by another field.
-> for example: order = 'priority DESC, activity_date_deadline_my ASC'
actually behaves like 'activity_date_deadline_my ASC, priority DESC'.
WARNING
This implementation is a hack. It has been done by professionals. Do not try
to do it at home.
More seriously this is hackish and should be avoided. IN our case we consider
that the use of activities in sales pipeline is mainly driven by "my activities
deadline", which is not necessarily the case with longer processes like tasks.
Moreover user tests tend to show that this feature could be interesting. It
will improve quality of Odoo CRM and its adoption by improving its daily
use. A framework solution has to be found. Until this is done we keep this
hack and hope it is not duplicated in other applications.
LINKS
Task ID 2276011
Prepares Task ID 2243124 (My activities in CRM)
PR #52232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add an autocomplete for opportunity name. If no name is set when a customer is
selected set the name partner_id.name's Opportunity
Change help title and subtitle to be more explicit. Change title from "Create
an opportunity in your pipeline" to "Create opportunities to keep an eye on
all your ongoing sales talks." Concerning subtitle, if a valid
and active email alias is found : Emails sent to ALIAS@address automatically
create opportunities.
Improve crm onboarding tour text messages and display.
Change menuitem from Teams to Team Pipelines to be more explicit. Update
the corresponding act_window name in the sales_team module.
Make the "schedule an activity" button bigger (100% of the div) and highlight
the entire Schedule button box.
Update test tours accordingly. Since quick create opportunity form is updated
the tests were failing. Reason is a trigger on input:first trying to detect
the field "name". This is not the case after this commit's changes.
Task ID 2226563
Community PR #51587
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Digest now use qweb views instead of a standard mail.template record for
rendering as
* template is very custom;
* probability of breaking it while edition the mail template is high;
it is easier to maintain and extend in qweb;
* only body was really used, other mail-related fields were not used;
We therefore remove the mail template data and the field used for it on
the digest model. Template is now forced to a Qweb view.
We can also remove the template_id field. Indeed we think that having
different templates for digests is a really advanced use case we do not
want to support.
Finally kpis and action computation is rewritten. It now returns an unique
structure containing all information in a more neutral way, holding values
for 3 columns. Purpose is to be less date-oriented in data construct and
allow people to use digest qweb template to display a 3-columns KPIs content
even if not related to yesterday / last 7 days / last 30 days.
LINKS
Task ID 2197417
Community PR odoo/odoo#51619
Upgrade PR odoo/upgrade#1256
- Create a lead and set a language
- Convert to opportunity and choose 'Create a new customer'
The new customer created doesn't have the language of the lead set.
This is more logical to set the same language to the new customer.
opw-2270321
closesodoo/odoo#52376
X-original-commit: 1999c68ff4eb382019c92064d9285411314a39be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Get rid of email / phone behavior on lead that is hard to understand: if
and contact is set fields are readonly, if not they are editable.
SPECIFICATIONS
We want to be able to edit them if a partner is set. If we write on the
email/phone of the lead, it should write on the partner (and vice-versa).
Even a Falsy value is propagated to the customer. Reason is that if you update
a contact information, it should be available for all other records. Setting
a void value probably means you want to stop contacting this contact. This is
now also propagated.
SIDE NOTE: MOBILE FIELD
Mobile field is a bit different. Main phone contact field is phone, and is
placed in the main contact section of the lead view. Mobile is under a more
technical / detailled tab and is not completely synchronized with the partner.
Like zip, city or country, changing partner updates lead information but
changing lead values does not propagate those to the customer. Those fields
can be used for deal-specific information if needed.
Statistics: 5k crm.lead use mobile for 80k active records which means it is
a "lesser field".
LINKS
Task ID 2207636
PR odoo/odoo#48395
Upgrade PR odoo/upgrade#1025
Purpose
=======
Update Lead Probability CRON is currently running in a single transaction
and is locking lead table for too long.
This task aim to improve the performance of the cron by:
- reducing the number of update (instead of updating one by one the leads,
update all lead with same value to update)
- Making it multi-transactional (to avoid locking table during
the whole process)
Spec
====
- compute probability and automated probability values with only 2 decimals
(needed to compare new and old probability + to avoid too many values
in the group by probability)
- Group the leads to update by Probability value (rounded by 2 decimals)
Note : This commit doesn't change the field definition to avoid migration.
- Update leads by batch of limited number (=step), to avoid transaction to take
too long. After each batch execution, commit to unlock the table before
continuing with next batch.
Task ID: 2224677
closesodoo/odoo#51310
X-original-commit: ee346936efc6cabce14cb73223ecd2e6a0cc1e3f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-Configure alias on sales team;
-Send email, opportunity is created for sales team;
-Enable leads on CRM settings and enable leads for sales team;
-Send email to alias, lead is created for sales team;
-Disable leads in CRM settings;
-Send email to sales team alias;
Before this commit a lead is created even those these have been disabled
in CRM settings and you cannot access this menu anymore.
Now, an opportunity is created for sales team.
opw-2244379
closesodoo/odoo#50943
X-original-commit: 3e9f07e8fe2f31b66087db4b0fc274df2e6253c8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Editable stored fields are copy by default if their base field
allow it (char, integer, ...). Purpose of this commit is to remove
unnecessary copy=True statements added when using stored editable
fields.
PR #49464
Task 2225253
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Step to reproduce:
- Go to CRM app
- Create a new opportunity and edit it
- Alter the website field under "Contact Information" tab
with "www.anywebsite.com"
- Save and click on the website field value.
Without this fix, the field redirect as it's local:
"http://www.myodoo.com/www.anywebsite.com"
porting 726fad8
opw-2247853
closesodoo/odoo#50942
X-original-commit: 072400ad12ea17438a0175d94eb887f51172e461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Step to reproduce : Import from Excel a list of Opportunities.
The problem is that in _compute_day_open, the abs of the extraction
date_open - create_date is set as the lead's day_open.
As the date_open has no milliseconds, all those records which
create date is the same second have a date_open that is before their create_date.
Fixed it by comparing the date_create and date_open without microsecond.
Task ID 2222251
closesodoo/odoo#50599
X-original-commit: f7d1277080a91903342bbb4be44ce3a6ca814a38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements.
Purpose is to improve lead_count performance. Some people claim to gain a lot
of queries: from 90 to 30 SQL queries to read 39 partners. Hard to reproduce.
LINKS
Task ID 2196182
PR odoo/odoo#44662
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Or, in other words, set auto probability to 0 if no statistics yet.
Before this commit, if the automated probability could not be computed,
the automated_probability field on crm.lead was not modified.
That led to having leads stuck at 100% once won, even if going back to another
stage.
This happened only :
- in an empty DB (no demo data) or
- in a DB where the PLS cron had never ran and the PLS threshold was
inactivated (=0).
Because, if the frequency table has never been built, we cannot compute the
automated probability.
After this commit, if the automated probability cannot be computed, we set
it by default to 0. If the probability and the automated probability was
aligned, probability is also set to 0.
Note: this could be an issue if both probabilities were aligned, then
someone deactivate the PLS cron and set the threshold to 0 (if not yet the
case), and clear the frequency table. (unlikely to happen but still..)
When updating updating a lead, we would lose the probability
-> auto proba set to 0 + proba set to 0 as they were aligned.
Task ID: 2232036
closesodoo/odoo#49766
X-original-commit: b43ecf73958273a126135966422112b90f9f12cc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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 of this commit is to clean manual alias creation by correctly giving
field values instead of relying on magic from model_name to model_id. Code
is more understandable now.
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
Some fields of a calendar event are private.
The previous implementation was deleted while refactoring recurring events.
This commit cleanly re-implements the feature.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
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 of this commit is to make use of toggle_active to implement business
behavior linked to active field being changed. In CRM notably
* when archiving: it is considered as lost, and therefore probability is
set to 0;
* when reactivating: void the lost reason and update probabilities for PLS;
In this commit we also update tracking subtype to more clearly track
lost / restored subtypes
* lost: writing a lost reason (resetting it is not lost), archiving
it if no other subtype;
* restored: activating it again;
Task ID 2170708
Community PR odoo/odoo#46563
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
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>
SPECIFICATIONS
Improve heuristic used to find lead to convert duplicates
* check email_normalized instead of email_from, as it may contain formatted
emails. Normalized email are sanitized and normalized version of emails
and ease comparisons;
* use lead email if its customer has no email;
* if no email is available but a customer is set, use it anyway;
This notably reverts 2917b38f28 . Indeed no reason has been found why
this fix is necessary.
LINKS
Task ID 2088565 (crm: from onchange to compute)
SPECIFICATIONS 1: FORCE_ASSIGNATION
Move and rename force_assignation in convert wizard. Purpose is to move the
force_assignation field from mass convert wizard to its base convert wizard
used through _inherit. It allows to avoid relying on context propagation in
some methods. This field is also renamed as assignation as other meaning in
English.
SPECIFICATIONS 2: OPPORTUNITY_IDS
Improve search of duplicate by always ensuring duplicated are computed using
active_test. Also add the active_test on the field as otherwise computed
results are actually not visible to the user.
Generic opportunity_ids field is also renamed to better indicated it is used
to store duplicates and avoid thinking it holds data related to batch convert
or merge.
LINKS
Task ID 2088565 (crm: from onchange to compute)
Upgrade PR odoo/upgrade#781
PURPOSE
As CRM is going to be updated (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving code is a necessary first
step.
SPECIFICATIONS
Purpose of this commit is to rewrite code located and/or used in convert or
merge wizards. Indeed it holds unnecessary variables, dictionaries manipulation
that hides the real business flow, badly named variables, unclear methods, ...
Logic of those wizards seem quite simple but is hidden behind a wall of
bloated code.
Notably for wizards
* try to set explicit arguments in methods;
* less use of context values, replaced by arguments when possible;
* try to make better use of lead2opportunity wizard in its mass wizard that
inherit from it, notably by correctly calling super;
Notably for tools
* ``get_duplicated_leads`` was just a shortcut to ``_get_duplicated_leads_by
_emails``;
* ``_get_duplicated_leads_by_emails`` is renamed to ``_get_lead_duplicates``
because email is not the only way of finding duplicates;
* try to make better use of record sets instead of propagating ids, notably
for partner. For example input of ``_get_lead_duplicates`` or output of
``_find_matching_partner``;
* ``_create_lead_partner`` rename to ``_create_customer``, and its sub
method ``_create_lead_partner_data`` to ``_prepare_customer_values``;
* ``handle_partner_assignation`` was difficult as its use is not documented
and its docstring was not updated. Parameter have been renamed to be more
explicit about what it does. Method is renamed to ``handle_partner_
assignment`` as assignation has other meaning in English;
* ``allocate_salesman`` is renamed to ``handle_salesmen_assignment`` to match
the partner assignement and code is slightly cleaned;
No functional change should occur with this commit. Tests have been gradually
added to try to ensure behavior does not change.
LINKS
Task ID 2088565 (crm: from onchange to compute)
As the crm.lead.tags model shall be used in CRM and/or Sales apps,
it has been moved to the sales_team module, which is a depedency
of the CRM and Sales apps.
As these tags becomes more generic than just "lead tags", the model
has been renamed from crm.lead.tags to crm.tags.
Tags on sale orders were already present but not visible. They are
now visible in the "Other Info" section, and optionally in sale order
tree views.
When a quotation is created from an opportunity (CRM app), existing tags
are populated from the opportunity to the sale order (Sales app).
Views and demo data of several modules have been updated accordingly.
Task ID 2191276
Purpose
=======
The main definition of 'assignation' is the following:
"an appointment to meet someone in secret, typically one made by lovers"
The correct word we should be using is 'assignment':
"the allocation of someone or something as belonging to a particular group or category"
So in this commit change every iteration of the word
'assignation' to 'assignment', across all modules.
closes odoo/odoo#45041
Taskid: 1966215
Closes: #45041
Related: odoo/enterprise#8375
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Portal user that have opportunities in their portal
may change the stage of the opportunity
Changing the stage on the portal trigger
direcly the method write.
With the pls, write on the stage
trigger the recompute of the probabilities
that read on crm.lead.scoring.frequency
which portal user don't have acess
closesodoo/odoo#46551
Solution: compute probabilities in sudo mode
X-original-commit: 9cd7fe0ff3ce07618635b4d13ca564bd2f326980
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
This refactoring commit removes the crm.partner.binding mixin. Indeed it
defines a mixin for unnecessary fields, generally either redefined in
inheriting models, either not used at all. It also holds an utility method
we moved directly on crm.lead model.
SPECIFICATIONS
Code move
* move _find_matching_partner to crm.lead model;
* move action field into inheriting models, except crm.lead.convert2ticket
that does not use it;
* move partner_id to inheriting models;
* remove crm.partner.binding model and inheritance;
Improve behavior
* correctly store lead and partner many2one fields on all inheriting
models. It allows to support a default_lead_id instead of always
relying on active_model / active_id, making the wizards more generic;
* update default_get accordingly in various inheriting models in order to
correctly compute lead / partner values;
LINKS
Part of Task ID 2056759 (remove crm.partner.binding mixin)
Part of Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
Upgrade PR odoo/upgrade#750
Related: odoo/enterprise#8307
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Martin Trigaux