*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
This index allows to improve performances of learch searching based on phone
and mobile fields. We currently use those fields are phone_sanitized is
based on both fields, which could lead to information loss and/not not
accurate results, notably when used to find duplicates.
Task-3007714
closesodoo/odoo#105873
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Accelerate duplicate lead detection by adding indexes on field involved in the
search.
In this commit we add trigram indexes on email_normalized, partner_name and
contact_name that are used a lot for searching and finding leads.
Task-3007714
Part-of: odoo/odoo#105873
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Some cases require usage of Markup in order to correctly display HTML content
and avoid escaped or invalid statements.
Fix: in hr_recruitment, support default_job_id from context, easing display
of job's alias in empty list helper.
Task-3074357
closesodoo/odoo#106061
Related: odoo/enterprise#34139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
Purpose:
In the Forecast view of the CRM module, when recurring revenues are activated,
they are not shown in the progress bar of each stage of the kanban view. Only
the prorated expected revenue (non-recurring) are shown. In the regular
kanban view, they are shown.
To display them, we extended the CrmKanban view, which already possesses this
behavior, since behaviors relevant to the CrmKanban view are also relevant
to the ForecastKanban view.
As for the forecast kanban cards, when recurring revenues are activated,
they show "regular" recurring revenues instead of "prorated" recurring
revenues. Expected revenues are prorated. This is misleading for users.
The goal is to show prorated recurring revenues instead of just
recurring revenues.
Task-2994146
Task-3006404
closesodoo/odoo#102037
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The same override of `_get_view` was done in `res.partner` and `crm.lead`
in order to call `_view_get_address`, to change the address format
of the partner and lead form.
The definition of `_view_get_address` was already shared between these
two models through the `format.address.mixin` mixin.
So, why not share the override of `_get_view` also in this mixin,
so only one override needs to be written, instead of two.
In addition to merge the code of the `_get_view` override
in `format.address.mixin`, also set the `_get_view_cache_key`,
so the partner and lead form are correctly cached by company,
in case multiple companies in a same db use different address views.
Before this revision, this wasn't the case for `crm.lead`,
which therefore leaded to a bug when two companies where
using different address view, and one company accessed the lead
form before the other, therefore caching its own view version
in the cache, re-used later by the second company when fetching
its own lead form.
This revision takes the opportunity to add a unit test for crm.lead,
to assert the expected form according to the company address.
There was already a test for res.partner, but not for crm.lead.
To avoid copy/pasting the unit for both models,
a common test class is created, re-used to test both res.partner
and crm.lead.
closesodoo/odoo#103438
X-original-commit: 7e4a8b77024af663c5555c6d56557e2c6136b24b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The code removed by this revision was initally introduced in
odoo/odoo@126ba0a9a8
The `_get_view` override introduced relied
on the context key `opportunity_id`,
which was set in the crm.phonecall form view with
```xml
<field name="opportunity_id" on_change="on_change_opportunity(opportunity_id)" context="{'opportunity_id': opportunity_id}"/>
```
as you can see in the above mentioned revision.
This above node was removed 7 years ago in revision
https://github.com/odoo/odoo/commit/ff2b14d4c3c5aaa62418b527585d0a19e98a23de#diff-892062d6151c1e1c1cb5f6c09035df1d5ae6d5a71f7558aacfdc8cf62627bf5fL138
Therefore making pointless the code about it in the `_get_view`
override.
In addition to this clue to make sure the override is pointless,
checking the code, we can see it relies on `get_formview_action`
to set a different view according to the result of `get_formview_action`.
Since revision
https://github.com/odoo/odoo/commit/e28d3aa4d3851d72deba08c236072d002f83216a#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2L1224
the override of `get_formview_id` is removed,
therefore making `get_formview_action` of `crm.lead` completely default
(as there is no override of `get_formview_action` either in crm.lead,
nor any dependent method)
We can therefore assume this code was useless,
at least in standard odoo,
and can therefore be removed.
X-original-commit: 82c2f4b13034c16ca5546afd777150ecb4d8ad9b
Part-of: odoo/odoo#103438
Purpose
=======
To be able to customize the working flow on the lead, based on their
team, we add a properties field on leads, whose definition is stored
on their team.
Include the properties value in the merge message to keep the history
of the properties value if they have been overwritten during the merge
process.
Task-2965523
X-original-commit: 4722cc4b1fb027b7b9d731c3b206656588071360
Part-of: odoo/odoo#101487
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
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>
Julien Castiaux