* = base_geolocalize, calendar, website_crm_partner_assign
Oversight of discuss refactoring. Code is restored into bus module as it
does not depend on any mail or discuss feature.
closesodoo/odoo#119243
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
On an heavy database searching for company leads or assigned leads can be
costly. Having an OR does not necessarily triggers index usage and query plan
uses an index scan.
It is less costly to do two searches: one for the base domain (based on
commercial entity) and one for the assign domain (based on partner assigned).
Task-2770994
closesodoo/odoo#88538
X-original-commit: 6957d7a57cb3bf25d552d3f8f2760db46ace5e3a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Two lines have been inverted in ``_get_access_action`` override, leading
to access rights not being correctly checked. This currently leads customers
with token to land on portal without token, which is not the expected
behavior.
Followup of odoo/odoo@a018735closesodoo/odoo#86646
X-original-commit: dd7d60aca8718763aaa211e138f684d8797f5d8c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Recently with commit[1], we changed the sequence for partner grades and
partner activations at db level (from asc to desc) to see the records
created with data files in our chosen order (for example Gold, Silver,
Bronze instead of Bronze, Silver and Gold).
However, there are several drawbacks with this approach. For example
during db upgrade, all the existing records needs to be adapted to
keep up the order of records created by data files.
This commit reverts change of order at db level, and instead adapts the
sequence of the records being created with the data files in a way that
they are still in the same order we wanted. And it will also maintain the
order of the records manually created by users after db upgradation.
commit[1] - https://github.com/odoo/odoo/commit/b28aae2
taskID-2765577
closesodoo/odoo#85235
X-original-commit: 5cc309744de5c2d5713d6bd95d02a66c21aaf11e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, for the better first user experience, few partner activation
levels are available by default (added in data files). Since there is no
way to archive it, the only way to not use them in your production is to
delete it. But it means that on each migration, it will be restored.
To improve that, this commit introduces 'active' field in the activation
levels so that one can easily archive them if they are of no use, and
this way they won't be again created every time when db is migrated.
This commit also adds a search view with 'Archived' filter to see the
archived activation levels easily.
taskID-2753985
closesodoo/odoo#84401
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
The module website_crm_partner_assign has its own partner_longitude
and partner_latitude values that are resolved independently, when the
linked partner doesn't exist yet.
So when a lead is turned into an opportunity and a partner is created,
the address info is copied to the new partner, but not the geolocation.
In case these partners are supposed to be geolocalized (for example
on the FSM application), the geolocation will be recomputed despite
the fact that this information was already available at the convertion
time.
closesodoo/odoo#84890
Related: odoo/enterprise#24517
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Improve performance in often used views and fields in a normal Odoo usage.
SPECIFICATIONS
On res.partner model in website_crm_partner_assign, convert the computed field
``_compute_implemented_partner_count`` to use read_group. Performance test
have shown it could be costly.
Also rename ``implemented_count`` to ``implemented_partner_count`` to better
match ``implemented_partner_ids`` naming.
Task-2752043
Part-of: odoo/odoo#83806
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
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
Sébastien Theys