Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Still having sometimes a test failing due to extra queries...
closesodoo/odoo#85929
X-original-commit: 34eebe66f12bf43dbf7c16800e177907fe39f2ba
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.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>
This commit orders the records coming from the mock server the same
way they are ordered by the ORM, while also allowing it to support
multiple levels of orderby.
This has been done to increase consistency in the test suite and provide
a more accurate representation of how records would be returned by the
actual server.
Some tests performed their assertions based on this previous
undeterministic system and have been adapted, either by altering
the base setup or the assertions themselves.
closesodoo/odoo#84718
Related: odoo/enterprise#24509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if we try to merge crm leads and few of the
details are not available, traceback was thrown. For ex-
- When lead does not have a company or the company does not have
currency set
- When the visitor name is not set
This commit fixes both of the tracebacks and thus allows users
to merge the leads in these cases.
taskID-2745017
closesodoo/odoo#84656
X-original-commit: eda3f43dde8122aa5f572f57bf2c3c0d94abe1f2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
If we
1. Open a lead with an email but without partner
2. Set a partner without email on the lead
3. The warning "The email will be propagated" is visible
4. When saving the form, the email is not propagated even if the
warning message was visible
Solution
========
The reason is that, as the email was not changed, the inverse method
of this field was not called and so the email was not propagated.
The best solution would be to use "force_save" on those fields. But
this feature only works on readonly fields.
So, we simulate a real "force_save" on the email / phone, directly in
JS. That way the inverse will be called, and if necessary, the email /
phone will be propagated.
Task-2704904
closesodoo/odoo#84618
X-original-commit: 1d548c7eadcd25b97856c4769759358f86e00640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: flch-odoo <flch@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
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
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
Purpose
=======
When we group the record based on a boolean fields, we want to show
"Yes/No" instead of "True/False".
This has been done for the list view, the pivot view and the kanban
view.
Task-2648390
Part-of: odoo/odoo#79911
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 is to add some tests involving unsync of env.companies and current
user's company. Tests are added trying to mimic notably assignment cron
using sudo().
Next commit will fix some side issues.
opw-2713757
X-original-commit: 70b9f3aaa86acc6d32bee21fbd6114541115d310
Part-of: odoo/odoo#83764
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
Better aligns the stars with the label when no expected deadline is set,
by styling the parent div to space out non-empty children.
Task-2709761
closesodoo/odoo#81358
X-original-commit: 61925f488557181ae691d222a142a242c939d3e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: base_address_city, base_address_extended, bus, crm, im_livechat,
l10n_ae_pos, lunch, pos_restaurant_adyen, test_assetsbundle,
test_converter, test_lint.
It is spelled `auto_install`, the `complexity` key is long gone, `qweb`
has been moved to `assets: {'web.assets_qweb': []}`. `js` and `css` are
long gone too, `maintainer` is redundant with `author` which is
"Odoo S.A." by default already, the `certificate` key is long gone.
closesodoo/odoo#80988
Related: odoo/enterprise#22766
Signed-off-by: Julien Castiaux <juc@odoo.com>
*mass_mailing_crm, mass_mailing_sale
Currently, the Mailing stat buttons have a few problems.
The business reporting smart buttons send the user to a list of linked records,
which doesn't provide much value (e.g. what is the user supposed to do with a
list of 12345 leads?). They also show wrong values depending on access rights.
The Mailing KPI smart buttons lead to a blank screen if there's no data to show.
In this commit, we add/adapt all action helpers to help users understand what is
going on. For the business reporting smart buttons we instead send users to
relevant reporting actions, so they can make sense of the data we showed before.
The values of the business reporting smart buttons are now calculated as a super
user.
We also change some domains from the whole UTM Sale Domain to only using
Source ID, which simplifies computation while staying accurate.
task-2604515
closesodoo/odoo#76798
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit simply re-organizes a few fields on the crm.lead form view to give
more visibility to the most important information and to give more space to the
"Notes" section.
Task-2677144
closesodoo/odoo#80591
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Purpose
=======
As a Lead Manager, I do not really care about what's in the "Lead Pipeline"
since this does not exist. Instead, I want to keep an eye on all the leads that
entered the CRM to see how well they are doing and how they are spread.
Specifications
==============
- Remove the group on the Reporting
> Leads menu item, this menu can be used with Opportunities only
- Move it below the Pipeline report
- By default, this menu shows all crm.lead :
- no matter the type (lead/opp) but with the filters in the search view
if needed
- no matter if won/active/lost (but again, filters allow me to change that
if needed)
- Default grouped by month creation date
- Filtered on records created this year to avoid displaying 10 years of CRM
usage - already done
=> The difference if I activate leads is that then I have the extra filters, ...
but this is already valid if I'm only working with opportunities
Also, on the report list view of the leads, this commit brings some small
modifications in order to have a better view of what kind of lead and 'where'
they are:
- Hide by default the "City" field
- Add "Type" field before "Probability" field (only if Leads are activated)
- Add "Stage_id" after "Type" field
Task-2671372
closesodoo/odoo#78748
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
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>
PURPOSE
Concatenate feedback message and tracking when marking a lead as lost. This
currently generates 2 consecutive message about the same change, having a
single one is better from an UI point of view.
SPECIFICATIONS
Allow to link a body to a value change tracking. Tracking is currently done
by accumulating changes in a structure (see ``env.cr.precommit.data`` usage
with ``mail.tracking.<name>`` key). In the end those values are used to
generate a message with tracking value and a subtype.
In this commit we allow to manually set a body used as a message for the
tracking message, adding a new ``mail.tracking.message.<name>`` key. It is
used when posting or logging the tracking message, simply propagated as body
to ``message_post`` or ``message_log``.
In crm we use this when losting a lead through the dedicated wizard. A bit
of custom html allows to have a nice display.
Task-2671709
Part-of: odoo/odoo#78648
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
Allow sales reps to add a closing note to their lead while it is being marked
as lost. This is currently already done by a lot of sales reps but manually
with the "Log a Note" button.
SPECIFICATIONS
In ``Lost Reason`` model: add a new html field allowing to log a note on the
lost leads. Below the m2o, add an Extra Comment field where users can add a
"closing note". When the wizard is submitted, log this message as a note on
selected records.
Add tests, allowing to test both the wizard and this new feature.
Task-2671709
Part-of: odoo/odoo#78648
Tracking is generated using commit hooks, meaning they are really sent when
the commit ends. This is done to ease values aggregation and accumulation
through various record updates. In some tests we therefore have to manually
flush the tracking, otherwise it is not created and posted. Notably tests about
lead lost wizard were not flushing and therefore not generated the tracking
messages. Those tests will be improved in future commits, cleaning them is
therefore a necessary step.
We also specifically add some tracking flush in mail performance tests. This
is to be sure we measure impact of a write and tracking separately from
previous transactions. Seems everything is working as intended as warmup and
query counters already perform flushes. Here we simply flush at the end
of the setup to be sure all base is clean before starting tests.
Task-2671709
Part-of: odoo/odoo#78648
In one week, this test failed about 4 times, seems mainly on nightly
enterprise. Let us update counter accordingly.
closesodoo/odoo#80164
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Seed is now fixed at beginning of each test to ensure random state is set
once for all and avoid random issues.
Task-2643740
X-original-commit: 85ebcaeaf909cd46743c20bf052360a65e60ea82
Part-of: odoo/odoo#79573
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>
This commit improve the pipeline analysis search for a better
usability. The changes includes:
- Rename 'My Opportunities' filter to 'My Pipeline'
- Move 'Opportunity' filter above 'Lead', rename it to
'Opportunities', and display only if leads are activated
- Rename 'Lead' filter to 'Leads', and display only if leads are
activated
- Remove the string from filter 'Creation Date', and use the
default field name (which is 'Created On').
Also updated some filter names to have a global convention
and avoid name clashing, updated filter names are listed below.
- `opportunity` to `filter_opportunity`
- `lead` to `filter_lead`
As we need to display same filters and groupby in both community and
enterprise pipeline report search view, we have removed the search
view `crm_opportunity_view_search` from enterprise so that we can use
the community view there and both becomes the same view.
So in this commit we have also added some filters and groupby to
community version(`crm.crm_opportunity_report_view_search`) which was
existed in enterprise search view (`crm_enterprise.crm_opportunity_view_search`)
so that we dont miss any filters used in enterprise.
The filter and groupby added are listed below:
Filter:
- inactive
Groupby:
- compaign
- medium
- source
Apart from this, we have added groups `crm.group_use_lead` to the
groupby filter `conversion_date`.
Enterprise: odoo/enterprise/pull/18797
Upgrade: odoo/upgrade/pull/2937
TaskID-2343223
closesodoo/odoo#71796
Related: odoo/enterprise#18797
Related: odoo/upgrade#2937
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.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>
Purpose of this commit is to highlight current behavior of multi company
in lead. Notably a company is set at creation even when no team or user
is set, leading to a lot of issues when dealing with lead merge or convert.
Task-2520276
X-original-commit: dc8d82bbe032cef2f732fdfb1ded3068edc37371
Part-of: odoo/odoo#78860
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>
Before this commit, those tests sometimes failed because we didn't
correctly wait for the load and reload promises.
X-original-commit: f62503a56c4ec5c3de6638c5fe2138330d217eac
Part-of: odoo/odoo#78698
Fabio Barbero