Non total order can lead to randomized order in some case, making some
test behaviour random and/or difficult to debug.
Adding some fallback 'id' order shouldn't hurt
closesodoo/odoo#99324
X-original-commit: 6e40e5fe775273a2d3a968ac113cbeb578318dd1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Currently, the 'similar lead detection' mechanism only considers email,
contact name, and partner name while finding duplicate leads in CRM.
After this commit, it will also consider the mobile/phone number for
the same. Note that the mobile numbers and phone numbers both will be
matched with each other while finding duplicate leads.
Task-2817884
closesodoo/odoo#88372
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 0edc854a84 introduces a company check on the salesperson, partner
& team on the lead model.
However 184334a97d1ccd19b9a7266a13ff51531d22cff4 was not able to find the expected company on a lead
created by email when the team did not have a company set. Which is the case by
default for the following crm.team:
- Sales (3ad1867ea4)
- Pre-Sales
- Website (3ad1867ea4)
- PoS
Having added the company check introduce an unexpected error:
"Incompatible companies on records:\n-
'[header subject of email]'
belongs to company False and 'Customer'
(partner_id: '[name in header from of email]')
belongs to another company."
Error was hard to spot as the db logs are reporting that the routing of the
email was correctly done. But script to send eml using xmlrpc showed the error.
In this commit we fix the issue by removing the custom code trying to set
a company in ``message_new`` method of crm.lead. Indeed as it is a computed
field with a complete heuristic it is easier to let the ORM do its job and
remove that wrong value. It is now correctly computed as with any other
lead.
opw-2862509
opw-2783249
opw-2832435
opw-2881841
closesodoo/odoo#98746
X-original-commit: 2fec9c53314ef3f7c7e3305a6ee2417018d70ce5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Xavier Alt <alt@odoo.com>
# Purpose
Take into account the current company when creating a new lead if not defined
earlier.
# Specifications
If there is no company provided by the sales team and the user belongs
to several companies and several companies are allowed by context,
we preferentially take the current company over the user's company if allowed.
# Additional considerations
This commit
* builds on the multi-company fix brought by e5f35a60 avoiding the restricted
access error when setting to the user's base company if not allowed by context,
but will also allow to first preferentially use the current company instead of None.
* Complete tests
Task-2824913
X-original-commit: ce62780153183545ba423a7a8d945d9665cdc50e
Part-of: odoo/odoo#97136
Co-authored-by: Florian Charlier <flch@odoo.com>
Co-authored-by: Fabio Barbero <faba@odoo.com>
With Calendar and CRM installed:
- Create a lead and a meeting related to that lead.
- Delete the lead.
- Go to the meeting form view from the calendar App.
- Click the Document action button and nothing will take place.
After this commit if you delete the lead, you will no longer be able to the
see the button as document information is correctly reset.
Task-2917174
Closesodoo/odoo#42450Closesodoo/odoo#47497closesodoo/odoo#96190
X-original-commit: 71ccb7dae43a13521f2a290ce76cafd8fb5b963f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Probability is not always given to write, hence date_closed is currently not
always reset. Indeed as it is a computed field it can be updated after stage
update, without being explicitly in values.
In this fix we consider that going out of won stage without any other hints
on probability is like being not won anymore, therefore resetting date closed.
Task-2917116
Closesodoo/odoo#93704Closesodoo/odoo#93704
X-original-commit: 1cf1b572b10bfbd02581c12f89824a028c4f23e6
Part-of: odoo/odoo#96190
Onchange could also populate the lang field of the lead when updating the
customer.
Partial backport of odoo/odoo@65bb3a5710
Task-2917174
Closesodoo/odoo#78715
X-original-commit: e0e1e402a6c40ed89bc5a11671e364a67e93a176
Part-of: odoo/odoo#96190
The field `company_currency` is indirectly used by portal users, and
does not seem to be a security concern in that context. But as portal
users cannot read companies, the field should be computed in superuser
mode. This apparently used to work by accident in the past...
closesodoo/odoo#95325
Signed-off-by: Raphael Collet <rco@odoo.com>
To reproduce
============
Have two companies with different currencies,
Create a lead in the first compnay => the expected revenue has the company's currency
Create a lead in the second company => the expected revenue doesn't have the currency
Purpose
=======
in v15 the `company_id` has became computed, but the compute method in some scenarios
doesn't set the `company_id`.
`company_currency` is related to `company_id`, so when `company_id` is not set `company_currency`
is also not set which occures this issue.
Specification
=============
To solve the issue, the field `company_currency` is computed now, and we give it the value of the active
company if `company_id` is not set.
opw-2862410
closesodoo/odoo#95484
X-original-commit: de59391caede72624fddcb01ba3565884c4e5574
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does below improvements:
1/ If salesperson and sales team are set on an individual partner, we propagate
those to parent company being created from m2o of the form view.
2/ If the existing parent company is manually linked to an individual partner
being created, and salesperson and sales team are not set on the individual,
we set those values from the linked parent (if set on the parent).
Task-2636290
closesodoo/odoo#78696
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In a multi-company environment, when we transform a lead (which has no
salesperson) into an opportunity, we get an error if the customer has
a company set.
To reproduce the issue
1) Create a new company
2) Create a Lead for a customer with the Company set
3) Remove the Sales Team
4) Set the company on the Lead
5) Convert to an opportunity and you will see an error showing up
Solution
A previous commit (1fad826743de9c8f916ef083e8de453212df6959) adapted the `_compute_company_id`
computation in which a case was forgotten (the case described here-above).
The fix was to force the `company_id` to the one of the `partner_id` if it
has one.
OPW-2805181
Task-2888330
closesodoo/odoo#88108closesodoo/odoo#94493
X-original-commit: fc3bb66a863cd3ff8c92d70dd43146a5610a4a43
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when creating a new stage, even if there are sales team(s)
available, the `team_count` always displays zero, because it is a
computed field but is not dependent on any other field.
This commit improves the behavior by small hack, which makes the
compute method dependent on `team_id` field so that it can be
triggered while creating a record.
taskID-2819559
closesodoo/odoo#88738
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the helper string for 'My Pipleline' a bit in case
the logged in user has not joined any sales team yet. Also, if user is
having enough rights to access 'Configuration >Sales Team' menu, the
helper string will now contain a link to this menu as well.
task-2846401
closesodoo/odoo#91304
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
install crm and change a lead between two won
stages
Expected behavior:
The date_closed does not change
Current behavior:
The date_closed changes
opw-2839298
closesodoo/odoo#92534
X-original-commit: 0c55c0d31021abe966c453c4827d5873a7af485c
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The performances tests in TestLeadAssignPerf have a margin for queries
because of some randomness in query counts.
Those margins avoid random failures but will hide small increments,
making the query count fail randomly in future build. This margin also
makes the update of query counts difficult.
This commit tries to identify the source of this randomness and proposes
some fixes.
Sources of randomness
=====================
Comparing different executions, the query can differ on two point:
1. During the flush, while updating the lead
1.1 the written user_id can vary (~1 additional query)
1.2 the written convert_date can changes (~4 additional queries)
1.3 the written date_last_stage_update can change (~1 additional query)
2. during _handle_salesmen_assignment
2.1 write/_message_auto_subscribe can change? (~1 additional query)
the point 1.2 and 1.3 can be easily reproduced, adding sleep,
especially a 0.1 sleep in convert_opportunity
Writing different values for date will lead to multiple execute
when flushing the records:
the orm cannot group records with different values
Proposed fixes
==============
A. Use `cr.now` instead of `fields.datetime.now`
Using the transaction time will avoid randomness linked to the change of
second during the transaction. This will fix 1.2 and 1.3
B. Sorting members
The members comes from a o2m and the order is not deterministic.
During the test with a subset of lead (10 instead of 100),
the two last members ('Martin Sales Manager' and 'Orteil Sales Own')
can come in different orders, leading to different user_id set on lead.
Instead of 4 different users, the lead where sometimes dispatch on
5 different users with this setup. (5 queries in flush() instead of 4)
This is fixed by adding a complete order (adding id) on crm.team.members
This will solve 1.1
C. The leads are also ordered by id if they have the same probability,
since it shouldn't hurt and make the search more deterministic.
2.1 was fixed by B or C or is not fixed, not sure anymore.
task-2796579
Part-of: odoo/odoo#85525
Instead of displaying the float duration in the log, we display it
with this format:
1.5 => 1 hour 30 minutes
0.5 => 30 minutes
task-2665863
closesodoo/odoo#87057
Related: odoo/enterprise#21799
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The test `test_assign_count` may fail randomly leading to the error:
```
self.assertEqual(self.sales_team_1_m3.lead_month_count, 14)
AssertionError: 12 != 14
```
Since BUNDLE_HOURS_DELAY is 0 (during tests), the domain becomes
`[('create_date', '<', fields.Datetime.now()]`
Depending of the time when the transaction starts, and the tests is
executed, the domain could match more or less records when executed one
second earlier or later. This is especially True for single module build
where there is less logic and the execution is faster. The domain may be
tested earlier and match less records.
This error can be reproduced deterministically by setting
`BUNDLE_HOURS_DELAY = 1/3600`
A fix could be to ignore ignore the create_date domain if the
BUNDLE_HOURS_DELAY is 0, we want to match all records in theory
(except if some of them are created in the future...)
The chosen solution is to use cr.now and use a <= instead.
Some assertions where also added to the test in order to identify why
the count was different and give a more precise message when it fails.
```
AssertionError: Lists differ: [] != ['TestLeadInitial_0000', 'TestLeadInitial_[97 chars]006']
Second list contains 6 additional elements.
First extra element 0:
'TestLeadInitial_0000'
- []
+ ['TestLeadInitial_0000',
+ 'TestLeadInitial_0001',
+ 'TestLeadInitial_0002',
+ 'TestLeadInitial_0004',
+ 'TestLeadInitial_0005',
+ 'TestLeadInitial_0006']
```
task-2796579
closesodoo/odoo#87107
X-original-commit: 4a5b68f05c57ba36560d43733dfd04b67c3297a8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Purpose
=======
Add globe button next to language for leads and opportunities if the
database is in multi language mode and user has enough access rights.
User is also unable to edit language from view
PR: odoo/odoo/pull/78287
Task-2662548
Part-of: odoo/odoo#78287
Expected Behaviour
When creating a contact from a lead with an unactive language, Odoo should
replace this language with the parent's language or the DB language.
Observed Behaviour
Since saas-15.1, when you create a contact from a lead email adress,
the contact is created with the lead's language, even if it's not active,
which give an error.
Reproducibility
This bug can be reproduced following these steps:
1. Set an uninstalled language on a lead (two choices):
a. Select an uninstalled language on a lead (this is what happens with
the trial creation, and how to reproduce it via the interface)
- install 8 languages in order to activate the "Search More..." link in
the Language select field of a lead
- on a lead which doesn't have a Customer yet, in the Language, "Search
More...", filter with Active = False, and select an uninstalled language
b. Install a language, select it on a lead with no Customer, and uninstall
the language
2. On the lead, in its chatter, open the Send Message and check the checkbox
next to its email => it should open a popup
3. Validate the popup => there is an exception in saas-15.X, and not in 15.0.
Related Issues/PR
- opw-2745841
closesodoo/odoo#85992
X-original-commit: c9b6ec91a87a4ad007287d978adc34332a97f8da
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>
PURPOSE
Improve performance in often used views and fields in a normal Odoo usage.
SPECIFICATIONS
On crm.lead model
* remove field user_email and user_login fields. Those are related non stored
and used in kanban for no reason (or even not used). Those can be removed
completely;
Original commit seems to be odoo/odoo@ea2e8b64c4 which seems to show those
fields were added to add a gravtar based on user email, and its login was used
to display "responsible". Maybe an internal Odoo related spec, anyway not used
anymore.
Task-2752043
Part-of: odoo/odoo#83806
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Steps to follow
- Select only one company in the company selector but not the default one
from the current user;
- Go the the CRM app;
- Create a lead;
-> A multi company error appears !
Solution
- The default team is now restricted to the companies in the context
- When computing a lead's company_id when the team has no company, keep only
the ones within the allowed_company_ids;
opw-2713757
closesodoo/odoo#83764
X-original-commit: 58b9b3e839c7725fdcd66376564ce6554a4b82ac
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
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>
Purpose
=======
When creating an opportunity, set the language of the Lead/Opportunity
to the partner's language if it is set instead of leaving it blank.
Also update tests to correctly test lang propagation.
Update event_crm so that lang of lead from registration is directly set
to False when there is no partner. Indeed we have no clue which lang we
should set and we can skip the field computation that otherwise triggers
some additional queries.
Task-2709436
Part-of: odoo/odoo#81028
PURPOSE
After this commit when creating a partner the language will default
to the crm lead value.
LINKS
Task-2580065
Pr: odoo/odoo#76812
Related: odoo/enterprise#20689
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Currently no chatter is added on team member form views. Indeed this model is
mainly technical and accessed through a dedicated menu in configuration.
However some fields are tracked and being able to see tracking information is
important in day to day dealing of team members. This is why we add chatter
on team members form view.
We also add context key to avoid autofollow when creating team members. As
chatter is mainly present for tracking and information no need to add extra
followers automatically. This causes unnecessary notifications.
Task-2679897
closesodoo/odoo#79356
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit consolidates UTM usage across all applications.
Global purpose is to avoid having undesired side-effects, such as unlinking an
utm.source/utm.medium/utm.campaign and at the same time cascading the deletion
to various records without noticing.
SPECS
ALLOW MORE PEOPLE TO CLEAN UTM RECORDS
Currently, not even the system administrator can delete utm.mediums and
utm.sources (he can only delete campaigns).
These were considered as "technical records", but allowing some cleanup is
a good idea since these records are often automatically generated and can
create a lot of unnecessary noise in the database.
That's why we now allow the following groups to delete all UTM records
(sources, mediums and campaigns):
- group_system
- group_mass_mailing_user
- group_social_manager (enterprise)
PREVENT DELETION
For some use cases, removing an utm.source/utm.medium/utm.campaign would
cascade delete the related record, which was unintended / hidden side effect.
These combinations were secured by preventing to unlink:
- mailing.mailing source_id field
Trying to delete the utm.source will throw an error message
- mailing.mailing medium_id field
Trying to delete the utm.medium will throw an error message
- hr.recruitment.source source_id field
Trying to delete the utm.source will throw an error message
ADDING CLEAN ERROR MESSAGES
When trying to delete an UTM record that is linked with ondelete="restrict", we
improved the error message to give a clear explication to the user, e.g:
"You can't delete these UTM sources as they are linked to the following
mailings in the Mass Mailing APP, and deleting the source would break the
statistics: Newsletter"
SPECIFY 'ondelete' strategy
For a lot of uses of sources/mediums/campaigns, the 'ondelete' strategy was not
specified, leading to the confusion of "is this really how we want to handle
this?".
A lot of ondelete="set null" have been added in various field definitions to
ensure that this is the desired and logical strategy we want for that
specific model.
PREVENT REMOVING HARDCODED UTM RECORDS
In some functional flows, UTM records are hardcoded using their direct
record reference.
This is notably the case for the recruitment process and its creation of
aliases, and for the Email / SMS Marketing flows.
As deleting them would break these flows, we prevent their deletion in a
"api.ondelete" method.
ENFORCE NEW RULES WITH TESTS
A lot of python tests have been added to make sure we enforce the decisions
taken here above.
LINKS
ENT PR odoo/enterprise#19048
Task-2459480
closesodoo/odoo#72239
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As this is a many2one, it should end with an ``_id`` suffix. Otherwise we
may think this is a char field, which was probably the case at one point.
Task-2671709
Part-of: odoo/odoo#78648
Purpose
=======
Give the user a more organized view of the digest KPIs in the backend and
improve global wording of digest sections and KPIs.
Specifications
==============
Reorganize order of KPIs in digest view. Fix some typos, move buttons in
list and form views.
Task-2582128
closesodoo/odoo#77507
Related: odoo/enterprise#21340
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When an user clicks on the Meeting tab to open the calendar,
it should onyl display the events linked to the opportunity.
task-2665863
closesodoo/odoo#79860
X-original-commit: 5a6e6e9fdd5bc85e8c79c09ef17b63bf4b95dd39
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When lead is won/lost, 'date_closed' field should be updated. But since
recent commit[1], this field was not updated while marking lead as lost.
It used to work prior to commit because we used to set `active` and
`probability` together from `action_set_lost` method.
But now, won and lost action are handled with `toggle_active` method.
In case of the lost leads, it first sets the `active` field to False,
and the `date_closed` is correctly updated by write method. After that,
it sets the `probability` to 0, and during that the write method sets
the `date_closed` to False.
This commit fixes the issue by updating `date_closed` field from write
method, only if the `probability` is greater than zero, and thus not
discarding the already set value.
[1] - https://github.com/odoo/odoo/commit/9b76c6b7f1eec4057289de90d62b8a7a266b0aac
TaskID-2343223
closesodoo/odoo#79154
X-original-commit: 3b9db86b76a838c0ae6cc9d517d7a29bff2c0544
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Context
-------
Leads get assigned a different company than the one defined on the salesman
after being merged with another lead.
This happens because some leads assigned to a user_id have no company set. They
are merged with leads that receive self.env.company during assigment to the
to the team and then get merged with the lead without company. So the company
of the new lead is written on the old one.
Behavior before this PR
-----------------------
When the crm.team have the field company_id = False
With the following flow
1) Create a lead without a user_id and a team_id
2) Assign a team to the lead
3) Assign a user_id
The status of the company field on the lead is the following
1) set the company of the env.user
2) Keep the company of the lead
3) set the user company if the current company is not one of the allowed
company of the user
Behavior after this PR
----------------------
1) set the company of the env.user
2) set the company of the team even if it's False
(so erase the company if the team has no company set)
3) set the user company if the current company is not one of the allowed
company of the user
Other changes
-------------
When resetting team and user: void company to avoid having leads without
any information but a company set. It eases assignment.
Task-2520276
closesodoo/odoo#78860
X-original-commit: ff2a6949c3a59be98cd1849e7a2e38c6ccc3187e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Thibault François <tfr@odoo.com>
The validation error raise
"AttributeError: module 'odoo.exceptions' has no attribute 'ValidationEreror'"
Instead the the correct message
"Member assignment domain for user %(user)s and team %(team)s is incorrectly formatted
closesodoo/odoo#78943
X-original-commit: a7ae22d0206eb833d584755e55351c41a12fd274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When merging multiple leads, we want to move the followers to the
destination lead if they posted a message in the last 30 days.
A message will be added in the merge note to know which followers have
been added.
Task-2447721
PR odoo/odoo#75742
Purpose
=======
Add more fields when we merge multiple leads to be sure not lose
valuable information.
Specifications
==============
Those fields are propagated to the destination if the value on the
destination is Falsy
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
The "lost_reason" field is propagated to the destination only if it's
lost (otherwise, it makes no sense to have a lost reason on a non-lost
lead).
The field "iap_enrich_done" is set to True if at least one lead has been
enriched.
We also keep the sum of all the lead tags (and remove any potential
duplicates).
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple lead have the same amount
of non-empty fields).
Task-2447721
PR odoo/odoo#75742
Purpose
=======
This commit remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views. This group was used
only to turn on / off the feature, not for security reason. So it's
fine to move the group in the views.
It will help for the lead merge so we will not be forced to use SUDO
during the merge.
Task-2447721
PR odoo/odoo#75742
Xavier-Do