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>
Now, compute's methods are executed on default, which leads to a crash
when these methods try to use the actual records but there isn't one
yet (e.g. at the creation of a record).
- Fix the traceback raised when creating a lead because of the
visitor_page_count method when self.ids is empty on default compute.
- Since the default_get() and the first_onchange() are also now combined,
we need to adapt the syntax of the default get for the field opportunity_ids,
replacing the array of ids by the command syntax '[(6, 0, ids)]'.
task-2325629
X-original-commit: acbc97bfe290ef3c7b8f7a1160266e49485099ae
- Create a Meeting for Contact X
- Go to Contacts and open Contact X
The Meetings smart button shows 1, but when clicking on it,
all user & partner meetings are displayed.
opw-2320299
closesodoo/odoo#56753
X-original-commit: 70f441a7ee3d46f6ba25cf56529a972b9e7ab29e
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Right now on few business objects (like leads, invoices, tasks, helpdesk
tickets etc) creation message contains
* subtype description;
* generic creation message;
This looks like multiple creation message on chatter after creation of the
record as you generally have "Task Created - Task created" (subtype description
then generic message).
This happens when we provide custom subtype on creation by by overriding
`_creation_subtype` method.
This commit fixes the issue by only using provided creation subtype and
removing default body. If creation subtype is not provided default creation
message is posted as before.
In this commit we also fix subtype for Lead/Opportunity creation and make
it generic ('Lead/Opportunity created') to avoid inconsistent behavior.
Finally some cleaning is made in method naming. Semi followup of 92e9e84b63
LINKS
Task ID-2288458
PR odoo/odoo#56631
PR odoo/enterprise#12707closesodoo/odoo#56688
X-original-commit: 2ebbeb4b5443c6405dd9a3b202a1eee9c5c67ebb
Related: odoo/enterprise#12728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create a Contact named "Alpha"
- Create another Contact named "Mister X" with "misterx@alpha.com" as email
- Go to CRM and create an Opportunity for Mister X
- Go to Contacts and open Alpha
The Opportunities smart button shows 0, but when clicking on it,
Mister X's Opportunity is displayed.
The Opportunity smart button displays a "crm.lead" view with a filter on partner_id.
The filter applies an "ilike" with the Contact's name on several fields of "crm.lead",
including "email_from".
As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved.
opw-2320299
closesodoo/odoo#56667
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
In this commit we set tree view of leads (both as leads and opportunities)
as multi edit enabled. Onchanges has been removed in CRM application. We
can therefore allow multi edit as computed fields work as intended.
Add domain on user_id fields to prevent selecting portal users as Salesperson
or Team leader from list views.
In crm.lead, onchange is only used to get formatted phone numbers when their
values changed or when country_id & company_id updated. This behavior will
only work in form views. It is not blocking so multi edit is not an issue.
Do not allow multi edit on name as it makes no sense.
Specifications: Contact (res.partner): base.view_partner_tree
phone
email
company_id
city
state_id
country_id
category_id
date_review_next
grade_id
user_id (+ add a limitation to not share users)
Specifications: Opportunities (crm.lead) : crm.crm_case_tree_view_oppo
partner_id
email_from
phone
city
state_id
country_id
stage_id
probability
partner_assigned_id
user_id
team_id
planned_revenue
company_id
campaign_id
medium_id
source_id
tag_ids
priority
Specifications: Opportunities (crm.lead) : crm.crm_case_tree_view_leads
contact_name
partner_name
email_from
phone
city
state_id
country_id
partner_assigned_id
user_id
team_id
company_id
probability
campaign_id
medium_id
source_id
tag_ids
priority
Specifications: Sales Teams (crm.team) : crm.team.tree
user_id
company_id
Specifications: Stages (crm.stage) View : crm.crm_stage_tree
is_won
team_id
Task ID-2200674
PR #56378closesodoo/odoo#56533
X-original-commit: 369375a69adc20a92075a89ef9557bf6b46cd605
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Improve performances of various Odoo code bits.
SPECIFICATIONS
Use a read_group to compute the opportunities_count & opportunities_amount,
like the other compute methods for statistics fields.
Do the same improvement in pos_sale when computing pos_order_amount_total.
LINKS
Task ID-2281297
PR odoo/odoo#53053
PR odoo/enterprise#11299
X-original-commit: 3e30b1e5c1aa25463848d82492f25002bcbf9154
Phone validation of crm_leads was using crm.lead country instead of partner
country code. This was leading to phone number of crm_case_16 coming from
an us partner validated as a uk phone number. (same problem applies for crm_case_14)
The problem was discovered in pre/post upgrade crawler test.
closesodoo/odoo#56348
X-original-commit: a58f9fc154c038d72031b281e2bec2c0fc2915ba
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This module provide routes to manage people, companies, and
leads from the outlook add-on. It could eventually be accessed by
add-ons for other mail clients.
closesodoo/odoo#44936
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Two things have been introduced in this commit:
The first is a change in the way the tour tip widgets are updated when
a DOM mutation is triggered: before this commit, each active tip would
evaluate its current anchor to elements matching its "trigger" selector.
If the element was not the anchor, it was set as the new anchor and
would be bound to the tip event handlers. Now, the unbinding/rebinding
of event handlers is done regardless of the new element.
This is helpful when the anchor is on a field monetary for example,
which keeps the same input element while internally unbinding and
rebinding the widget event listeners to it on each rendering. This
process does not include external event listeners such as those of the
tip and they were lost until now, breaking the tour step.
The second change is a modification of the CRM tour: the "Expected
revenue" field being an input, the according step trigger has been set
to target the input element instead of its parent. This means that the
step will await an "input" event instead of a click to be consumed,
making the tour step feasible with a keyboard.
Task: 2314864
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
PURPOSE
Adapt CRM views now that some measures can be set invisible.
SPECIFICATIONS
Adapt the views and implementing the new invisible attribute on some fields.
It allows to hide unnecessary measures.
In this commit we remove some measures in inheriting CRM apps
* crm: do not use color as measure;
* crm_iap_lead_website: do not use reveal_iap_credits as measure;
* website_crm_partner_assign: do not use partner_latitude and partner
longitude as measures;
LINKS
Task ID-2288381
Community PR #54774
Enterprise PR odoo/enterprise#11970
Upgrade PR odoo/upgrade#1519
This commit simply removes the default filter on the calendar.events when
clicking on the crm.lead stat button to access "Meetings".
The filtering was not handy because the user could not easily see when a slot
was available to schedule a new meeting.
The events that are related to that crm.lead are highlighted anyway (current
behavior), which should be sufficiently clear.
Task ID 2289295
closesodoo/odoo#55050
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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.*
To trigger a run of a server action, one must have a group specified
or a write access on the model.
CRM: only access lead, crm.team is readable by employees
Website: all users can access, action_dashboard_redirect takes care of the group
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>
The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
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
Review the tips and digest layout design to make sure they have a WOW effect
and increase trial conversion/retention.
SPECIFICATIONS
“Did you know Odoo has built-in lead mining?”
“Opportunity win rate is predicted with AI”
“Manage your pipeline”
“Do not waste time recording user's data”
“Turn a selection of opportunities into a map”
See code for specifications.
LINKS
Task ID-2274264
COM PR: odoo/odoo#53580
ENT PR: odoo/enterprise#1139
X-original-commit: 93c7aa19397ae7a25e88e760f44d24a0b4f0dd9a
Nicolas Martinelli