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>
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider a sales team ST in C1
- Let's consider that the partner of your current user is in ST
- Log your user in C2
- Go to CRM > Sales > My pipeline
- Create a lead
Bug:
An access error was raised.
opw:2191517
closesodoo/odoo#45234
X-original-commit: 42cdf368bdec41918b9f4b131b838cb1c76928b4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit improves overall usability for lost reason wizard in CRM with
following improvements
* prevent deletion of reason if any lead is still referencing it;
* remove obsolete filter 'Include archived' for lost reason;
* add new stat button for lost reason, to see the leads that were lost
due to that particular reason;
* add margin on the reason title to avoid ribbon glitch;
TaskID 2176323
PR #43541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Probably coming from a conflict / rebase / forward port. Or several of those
keywords.
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this commit, two fields were used for lead and opportunities
count.
As both of these fields were set with the same values and only existed
for labelling purposes, this commit replaces them by a single field
and handles the the labels in the xml.
LINKS:
TaskID: 2086863
PR: #38707
Try to understand a bit this code with comments. Some unnecessary code is
removed, and some parameters are added to try to understand the various flows,
but main purpose is to understand that mighty spaghetti, not destroy it.
LINKS
Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterpreise#7656
Related: odoo/enterprise#7656
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes 9ac5f42cd0c381bdddfd196721983057bab7028b by correctly calling the probabilities
computation method. It was a backport of a master fix and methods names are
slightly different.
closesodoo/odoo#42643
X-original-commit: 2e41f129ee39786c8259af792635e3b0f3dbfa3d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
SPECIFICATIONS
Fixes following issue: when a lead is marked as lost, the probability is
correctly set to 0 but not the automatic one. If one clicks on the "Set to
automatic", the probability is updated, which un-archives it without really
restoring it, meaning we get in a very strange state outside the expected flow
(no Won/Lost buttons, ...).
With this commit the automated probability is set to 0 when setting as lost.
Moreover restoring a lead recomputes its probabilities.
LINKS
Task ID 2092799
Manual backport of PR odoo/odoo#42015 done in master
PR odoo/odoo#42045closesodoo/odoo#42057
X-original-commit: 9ac5f42cd0c381bdddfd196721983057bab7028b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit we perform some small code move in order to better understand
the huge crm_lead.py file. Notably
* add some code sections headers (actions, PLS, opp/leads merge);
* move crm.lead.tag and crm.lost.reason in their own file;
* reorganize fields by main category because it is a mess;
* remove some unnecessary help messages on fields;
* merge two _auto_init methods definitions;
No functional change occur with this commit as it contains only some code
move.
It prepares some further technical cleaning in CRM application, notably
onchange -> compute move.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
CRM still holds code dead since more than 2 years about sales / crm dashboard.
Custom ugly un-onboarding not-wow headers have been removed at ea66192276.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
SPECIFICATIONS
Fixes following issue: when a lead is marked as lost, the probability is
correctly set to 0 but not the automatic one. If one clicks on the "Set to
automatic", the probability is updated, which un-archives it without really
restoring it, meaning we get in a very strange state outside the expected flow
(no Won/Lost buttons, ...).
With this commit the automated probability is set to 0 when setting as lost.
Moreover restoring a lead recomputes its probabilities.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
PURPOSE
Purpose of this commit is to allow users to look for leads and opportunities
by using the phone/mobile number fields. For example this allows salesmen
working in call centers to quickly retrieve all open opportunities of a
specific caller.
SPECIFICATIONS
Add a phone_search field allowing to implement a search on both phone and
mobile fields.
Allow searching independently from local format used to store the phone number.
Imagine we have leads with phone or mobile number that looks like ``+32 485 11
22 33``. We want to find this lead even when typing ``485112233``.
A custom search method is therefore implemented. It uses only the digits in the
phone or mobile number to perform the search.
A limitation is added on search having to contain at last 3 digits. Indeed
as it returns a domain whose leaf is ``[('id', 'in', ids)]`` it may be huge
for production databases.
LINKS
Task 2122873
PR #40131
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Andrea Grazioso (agr-odoo)