Currently when converting leads we may end up with False being compared to
a void partner recordset. Due to the use of != this leads to unnecessary
update of leads when no partner is involved in lead convert.
By comparing recordsets everytime we save queries and performance each
time a convert on a lead without customer is done. This leads to about
saving 150 queries in heavy duty tests.
Task-2722512 (Lead: performance in convert without customer)
Task-2722513 (Lead: performance master task)
closesodoo/odoo#81028
Related: odoo/enterprise#23094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Right now, if you click on 'Geolocate' button on partner form view, and if
partner has no address, it gives no feedback and user doesn't know what
happend.
With this commit, if the geolocating does not work, user will get a toast
notification telling him that 'No address found' to avoid confusion.
- When we click on 'Automatic Assignment' button from crm form view,
if there is no country set on lead, odoo skips the process, but we get the tag
that 'no partner available' which is not correct. It should be
there only when odoo actually tries to find the partner based on
lead's country.
This commit fixes the behavior by showing a toast notification to
user in this case, saying 'There is no country set in address'.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Currently the 'Opportunities' stat button on partner form view does not show
the opportunities where current partner is assigned one, it only shows the
ones that have current partner(and it's children) set as a customer.
This commit includes such opportunities (where current partner is set as
assigned parter) in the count of stat button and on the view we get when
clicking this button.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- This commit removes `selection` widget given on 'Partner Level'
and 'Activation' fields on contact form view to allow users to
create records for them on the fly (with 'no_open' option).
- This commit moves geo-location related fields below the parter assignment
related fields in the 'Partner Assignment' page of contact form view.
- This commit adds default lowest 'Partner Level' and 'Activation' (based on
sequence) while creating assigned partner on the fly from opportunity form
view. The purpose is to allow user to select the created partner again in
'Assigned Partner' m2o, which displays only partners having 'Partner Level'
(grade_id) set.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- For sake of having basic config for 'Partner Level' and 'Activation'
in contact form view (until user discovers the dedicated menus under
CRM > Configuration > Resellers) in blank db, this commit moves the
demo data related to 'Partner Level' to data, and adds new data for
'Activation', in following sequence:
- Fully-Operation
- Ramp-up
- First Contact
Also, higher ranks for partner level and activation are considered
better, and so the tree views for them now display the records in
the order of their rank (highest on top).
Note that with this commit, we remove 'Platinum' partner level and
it's references that were available in demo data.
- Apart from that in this commit we have also done these changes,
- Renames the menu 'Partner Level' to 'Partner Levels' and adds
action helper for the same.
- Adds action helper for the 'Partner Activations' menu.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Bug
===
1. Login as "Portal"
2. Go to "/my/opportunity"
3. Create an opportunity
4. Edit this opportunity from the frontend and set the probability empty
=> Save, an error is raised
Technical
=========
The probability is set to "None" and not to "False", therefor the
verification "probability >= 100" in the write method of the lead will
raise an error.
By using False instead of None, this verification will work.
Task-2613208
closesodoo/odoo#75100
X-original-commit: e58048350b670b88c31c88cc57cdf6cc38b22f80
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install 'addons/website_crm_partner_assign' module
- Create a partner X without a phone number (edit only name).
- Save and click on "Opportnuties" stat button
- Create an opportunity Y and set X as customer
- Edit it and set "Joekl Willis" as assigned partner
- Logout then login with portal user (Joel Willis)
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit "Contact"
- Change phone number then save
Access error message:
(not allowed to access 'Contact' (res.partner) records)
Cause
When editing the opportunity (OPP) phone (or email_from) field,
if a partner is linked to the OPP and the phone is different,
we will update also the phone of the partner.
User portal is not allowed to edit partner.
Solution
If user has write access on lead, use sudo() to update lead.
Raise an error if a user want to update a non allowed field
from portal through the contact lead form.
opw-2530744
closesodoo/odoo#72453
X-original-commit: 7d41ab05e5b3d78df5f60848ad440988cd98b6e0
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Bug
===
If 2 partners have the same weight, the first partner will
have 2 times more chance to be chosen.
Task 2246367
closesodoo/odoo#67992
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to make clearer how final opportunity value are
computed or chosen when merging leads. Functionally nothing should change
with this commit.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Before this commit:
- The precision on geolocalisation fields were set to (16,5) which
caused rounding when data was comming from Goolge.
After this commit:
- The precision on geolocalisation fields are set to (10,7) which is
aligned with what Google does.
This precision of (10,7) is actually already used in the Sign App.
task-2426985
closesodoo/odoo#64401
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Prepare sales team membership and lead assignment improvements by
reorganizing and cleaning some code bits.
SPECIFICATIONS
Tools methods should be private by default to indicate those are not part of
official convert or merge API for leads. In this commit we make convert and
merge tool methods private, keeping only main API methods public.
LINKS
Task ID-2428882
Prepares Task ID-2086889
COM PR odoo/odoo#64196
ENT PT odoo/enterprise#15610
The first stage has not always its sequence equal to 1. So if the
probability was for example equal to 0, then the salesman will not
be set to the new lead.
Since when we create a lead, the default stage is the first one in
the sequence. We only need to check if the lead is not already won
when we create a lead and try to assign the salesman to it.
task-2329327
closesodoo/odoo#61816
X-original-commit: c5059aa151430eebd62e9f000fe43e87bdd89ff3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- CRM--> Configuration --> Tags
- Delete the tag "No more partner available"
- CRM --> Lead --> Automatic Assignment
Bug:
It will raise Traceback
`AttributeError: 'NoneType' object has no attribute 'id'`
as Tag is not Present.
With this Commit:
It will add Tag if it exists on database.
closesodoo/odoo#61470
X-original-commit: 631030ae179c65ae0d99603046b5a09ffe00c408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem:
Now that date_partner_assign is a computed field, a
value should be set each time there is a value
set for partner_assigned_id. Still, it was not the case
Solution:
Use the proper decorator: depends instead of onchange.
closesodoo/odoo#55950
X-original-commit: 56d859d85f1e00029a601e9b1daa6bbcbdb7dc43
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
In portal an user can say he is interested by a lead and take it. He can also
post a comment. However this comment was not escaped, leading to possible
html injection.
As this comment is used to post a message no real issue occurs. It is sanitized
and behaves like every html content used in message_post. However we do not
want to support html here and therefore escape the content given to message
post.
Task ID 2228921
closesodoo/odoo#50537
X-original-commit: df5345618c4abbe8766a012b08ed90f1706c919a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Some apps, once installed, automatically create a menuitem in website.
What complexify the UI and create useless menu withtout plusvalue.
It is not because you install livechat to make support online, that you want
a link in your menu to show stats e.g.
Now we remove the default menu created, and help user to find it when he create
a link. The autocomplete suggest most of the main App's controllers
task-2189613
closesodoo/odoo#49081
Related: odoo/enterprise#9733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit attempts to add the option to order partner levels by sequence.
In this commit, the following changes have been made :
1- Add a handle widget to the sequence field to reorder partner levels (in view_partner_grade_tree).
2- Update default order field in "res.partner.grade" to order records by sequance.
3- Update partners order in 'website_crm_partner_assign' controller to keep the same order in website.
Task ID 2241632
closesodoo/odoo#49882
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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 coputation.
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.
SPECIFICATIONS: FIELDS RENAMING
In this commit we also rename ``date_assign`` to ``date_partner_assign``. There
are already ``date_open`` (crm_lead) and ``assign_date`` (website scoring)
fields available. It may be confusing. The field is therefore renamed to better
indicate it is linked to partner assignment.
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)
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>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*website_crm_partner_assign, website_customer
Before this commit, some models would create their own `website_published`
field rather than using the `website.published.mixin` mixin which should be
used instead.
That was done to be able to override the default value of the boolean.
This commit simply adds the possibility to override the default value of the
mixin field.
Also, help and string could simply be added on xml views rather than overriding
the field.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
This commit prepares the next Predictive Lead Scoring (aka PLS) ones.
With the new PLS implementation, stage based probablility is not relevant anymore
as the probability will be computed based on multiple criteria
following the Naive Bayes probabilist theorem.
To determine if the stage is a won stage, a new 'won_stage' boolean field replaces
the old probability field that is now removed.
won_stage = True is equivalent to stage.probability = 100.
Task ID : 1925439
PR #33589
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
With a portal user, receive an email that says "Go to lead/opportunity"
and click on the link
The link's url is /mail/view which is the generic access controller
Before this commit, the user is redirected to the backend,
with fireworks of access errors
After this commit, the portal url is opened
As a side note, in master crm.lead should implement portal.mixin
OPW 193509
closesodoo/odoo#30762
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Change API provider to prevent invalid API calls
- Move geo_find methods into base.geocoder object to ease inheritance
- Add system parameter to allow use of another provider
fixes #x26924
fixes #x6929
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose: improve understanding of partner and product models as well as their
daily use. This is done by improving tooltips and labels of some fields
according to business logic.
This commit is related to task ID 1880696 and closes PR #27133 .
Thanks to @xmo-odoo for its in-depth review.
Google Important Updated: API keys are now required
We began enforcing the use of API keys, effective June 11th 2018.
Keyless usage will result in a degraded experience, or an error.
https://developers.google.com/maps/billing/important-updates
In crm,website_crm_partner_assign and website_crm_score there were fields with
almost the same label, which was confusing, we change those names so it
reflects better what the field is used for.
| field | module | old label | new label |
------------------------------------------------------------------------------------------
| date_open | crm | Assigned | Assignation Date |
| date_assign | website_crm_partner_assign | Assignation Date | Partner Assignation Date |
| assign_date | website_crm_score | Assign Date | Auto Assign Date |
------------------------------------------------------------------------------------------
- As admin, create an opportunity
- Under the tab Assigned partner set the portal user
- As portal user go to My account > My opportunities > Edit opportunity
- Change something
Confirm button doesn't work. In fact, an access error is raised silently
in the JS console.
The issue is raised in `update_lead_portal`, at `lead.activity_ids...`.
This is because the field `activity_ids` has
`groups="base.group_user"`.
opw-1817935
opw-1818629
Thibault Delavallée