When clicking on the stat button "Meetings" on a contact:
- before dac91bc18 (November 2019): only meetings with participant
matching contact name are shown
- after dac91bc18 (November 2019): all meetings are shown => this was
because the view was used to create new meeting, so it makes sense to
see other meetings and not have a conflict.
- after 16206d72 (August 2020): only meeting of the contact are shown
- after 7449c8a6 and d11fb611 (November 2020): more complicated logic
that will also show partner events, and child partner events.
Since August 2020, when you create a new event, since we are showing a
list of IDs at the time the button was clicked, the new event will not
appear unless you go back to the contact, then click on "Meetings" anew.
With this changeset, we still show a list of IDs, but add an alternative
to also show the events of the current partner (that should be in the
list of IDs, but will match new events).
opw-2374021
closes#61490closesodoo/odoo#61690
X-original-commit: eb6e03908bfb6ed8bbe231da2a4422ec2e149834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Pupose of the task is, to set up a dedicated 'dashboard' reporting menu
item, and make the graph view the default the other 'leads' and
'opportunities' reporting menus.
So in this commit, change the default view graph in normal report
(except dashbaord menu) and each menu should be submenu of reporting
menu Also apply default filter for lead reporting menu
TaskID: 2311392
Related Enterprise: https://github.com/odoo/enterprise/pull/12419
closes odoo/odoo#55598
Closes: #55598
Related: odoo/enterprise#12419
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Make the "activity_state" searchable on the "mail.activity" mixin.
This field is not stored as it depends on the current time.
Technical
=========
To make the search, we perform a SQL query.
The "activity_state" depends on the state of each activities on the
record. And this state also depends on the timezone of the user of
the activity. That's what made things tricky and we need to make the
conversion in SQL for performance purpose (we can not fetch all records
and compute them in python).
There's a special case, where there's less than 24 hours between the
deadline and the current time but one day of difference. In that case
the state should be "planned" and not "today". This case is handle by
the function "DATE_TRUNC" (e.g. 23h 01/01/2020 & 1h 02/02/2020).
Also for performance purpose, we compute the delay only once and we use
the function "SIGN" so we can use a switch/case instead of duplicating
3 times the expressions.
Task 2354754
closesodoo/odoo#60074
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose is to ease the onboarding for the default CRM settings.
Now, we do not include any field by default and tags become an option
in the choice of fields apply to the computation.
task-2196200
closesodoo/odoo#48124
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, in multiple modules, long names would result in an overflow of text.
With this commit long texts should appear like this: [aaaaa...] instead of
going out of their boxes.
Various views are updated, depending on which fields we wanted to prevent
from overflowing and the probability they do so.
Task ID-2325219
PR odoo/odoo#57713
PR odoo/enterprise#13226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When we clear the configuration parameter crm.pls_fields unlink method is
called. In order to have a correct dynamic compute based on this parameter
we need to re-evaluate the depends. This is done by overriding unlink of
ir.config_parameter, like already done at create and write.
Task-2196200
closesodoo/odoo#61293
X-original-commit: d04cc4df4ec28816aeb6d1d7c7fc0e547fd13fa5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
WHAT: apply 93a7695f65baf00d1f82481d6a2a97e6c11940a8 for all res.config.settings
menus
WHY: the same reason as in 93a7695f65baf00d1f82481d6a2a97e6c11940a8:
When saving, a read is called. By default, read has
bin_size to true to avoid performances issues.
It will return the image size instead of the content
it may lead to image dissapearing or "Incorrect padding" error
HOW:
find . -iname "*.xml"|xargs grep "\"context\".*'module'" -l | xargs sed -i "s/\(\"context\".*'module'.*\)\}/\1, 'bin_size': False}/"
git checkout -- addons/base_setup/views/res_config_settings_views.xml
---
PR for General Settings: https://github.com/odoo/odoo/pull/47297
opw-2346644
closesodoo/odoo#61215
X-original-commit: 7c55efa88b72bd1f3f0f32f7f738e2fda5aa4abd
Related: odoo/enterprise#14547
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create an opportunity for CH1 and a subscription for CH2
Bug:
The count of opportunities in C was displaying 0 instead of 2
opw:237344
X-original-commit: d11fb611fed3a8541d03b7d3e49973ae7c16a768
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create a meeting for CH1 and a meeting for CH2
Bug:
The count of meetings in C was displaying 0 instead of 2
PS: set() is used to avoid to count several times the same event for a partner.
If for example CH1 and CH2 attend to the same event, only one event must be counted for the
parent C
opw:2360155
X-original-commit: 7449c8a6643477742616bf236f2f2c90aec68581
Co-authored-by: nim-odoo <nim@odoo.com>
The 'Mark as lost' server action raises an AccessError when executed by
a non administrator.
Due to de4213b771
opw-2371490
closesodoo/odoo#60866
X-original-commit: b80e44bac5de3ccffad42917307bb5f049a7bec6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Improve ui in CRM settings to ease user understanding and using settings.
SPECIFICATIONS
This commit re-organizes some crm related settings groups for better
usability by interchanging their positions and by putting related
groups together.
Crm PLS warning improvement: https://tinyurl.com/y67ug3fr
* Reword PLS explanation and button (followup of 9a57a7edfb)
Settings cleanup: https://tinyurl.com/y5lwqwe6
* Move "Leads" option on the right, next to Recurring revenues;
* Move "Incoming Emails" below "Leads";
* Switch "Visits to Leads" and "Outlook CRM Extension";
LINKS
TaskID - 2351582
closesodoo/odoo#60264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes few of the strings / layout for the settings related
to CRM and makes it less technical and thus more understandable and
also updates the required translation strings.
TaskID - 2351582
closesodoo/odoo#60790
X-original-commit: 55b05ed5e2cf083ac1e6d807d59e5533f4fb94b6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit:
When accessing activities from the systray, any existing breadcrumb-item should
be clearer.
After this commit:
Clear breadcrumb-item when access activities from the systray.
Task-2342246
closesodoo/odoo#60018
X-original-commit: a9b32448c4a6227ef8e729436cb793ea9c24c289
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Whenever when change the 'Leads' of 'Pipeline' boolean field on sales team,
it should also update the linked alias. Mainly, if 'Lead' is checked, the
'Default Values' on the alias should also be updated.
It used to work before a recent refactoring (see commit [1] and [2] for more
information).
This commit adapts the changes done in refacotring and updates the alias values
while updating the sales team.
[1] - https://github.com/odoo/odoo/commit/7cfd364db54e88970ef51c798df3bd4df44222b3
[2] - https://github.com/odoo/odoo/commit/186cfb5ebd35d572d0f635cd7975de7cff0d1055
TaskId - 2357573
closesodoo/odoo#60008
X-original-commit: 0669ee36e195e8e0f98131219b59fcc5cba4cea7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem
-------
Sales people can have restriction on partner they can see
Private addresses, multi company, ....
When they convert a lead to opportunity, it's currently possible
that the wizard will find and link a partner that the current user
cannot see.
Solution
--------
Field that are now computed store field, that were previously
normal field with onchange, should not be computed as sudo
to respect the record rule
closesodoo/odoo#59957
X-original-commit: 182fa38d7f28a92e7171c4ee3a42c8f73217b765
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To investigate a bit. Sometimes a few extra queries are generated.
Task ID-2359847
closesodoo/odoo#59869
X-original-commit: 36bb56a5e9704c76e84960ec84588524b52406f8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The URL to the mail extension module documentation in the settings view is
currently wrong.
It only works temporarily because of a redirect we setup on our website.
This commit updates the URL to the proper location of the documentation.
When we later support Gmail, the view will have to be updated to contain two
documentation links: one to Outlook and one to Gmail.
Task 2356910
closesodoo/odoo#59503
X-original-commit: 3968cfebfabcf34f800203d880c4a719c0f1174c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Handle salesmen allows to assign responsible to leads using a round robin like
algorithm. Currently a write on each lead is done to update its team and
responsible, even if number of leads is far greater than number of available
users to assign.
Current implementation can be simplified by doing one write per sales person
to assign on its batch of leads, or a single write if no salesmen has to be
assigned.
Performance counter on a mass convert wizard on 50 leads show that we gain
about 9% of queries (125 on 1471) with this simple optimization.
Task ID-2351604
PR #59084closesodoo/odoo#59324
X-original-commit: 973a2998666813ca4fbe90f1b486c1b18091c4e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to
* move tests about mass management of leads (mass assignment + mass convert
wizards) in its own file to ease writing of tests;
* add some performance tests :
* performance for assignment;
* performance for convert wizard in mass mode;
Task ID-2351604
PR #59084
X-original-commit: 950dd491bc4b680e0bcfab83815313e909a3c282
Currently when trying to find duplicates of a lead with an email that
cannot be normalized and without partner, a crash appears as there is
no domain part to form a valid domain.
Fix it by returning a void set if no valid email and no valid partner
is set on the lead as we cannot determine any duplicate based on void
information.
closesodoo/odoo#59147
X-original-commit: 291db77cf09c6ee76373fd168f575fda28270467
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
While running 'crm_tour' in test mode and quick creating record on
crm kanban, adding a partner and moving to another field from
tour opens a confirmation dialog asking whther or not you want to
create a new record. This dialog remains open sometimes, breaking
the further flow of tour.
This commit fixes the issue by selecting or creating the record from
drop-down after adding a partner (and before going to further steps),
thus avoiding the confirmation dialog.
Note:
- Because we create/select the partner, the 'name' field is auto filled
and we don't have to set anything in there. So this step is not needed
anymore in the tour.
TaskID - 2323196
closesodoo/odoo#58823
X-original-commit: a592ba14f82028487cee0b060a86881f0175aeda
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds sequence to CRM tour so that it can be prioritized over other
apps.
Task ID-2302572
closesodoo/odoo#58799
X-original-commit: 7372d9995aaad2fd8a259cbdea6e176bac6017b0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the salesperson(user_id) field with many2one_avatar_user
widget that will display avatar before user name.
Task Id : 2302572
PR #565013closesodoo/odoo#58781
X-original-commit: ec05118e85d7e3d4611c5688f3c4a572c86d0afa
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: D J <dja@odoo.com>
Fix the redundancy of "Send email" menu on the crm.lead model. We now correctly
have a form action in comment mode, and a list action in mass mail mode.
We also update the use of those actions according to the business flow: form
based from a single record, mass mail from a batch of records.
Task ID-2310462
Somehow forward-port of X-Original-Commit: odoo/odoo@9ded57d87fclosesodoo/odoo#58774
X-original-commit: ad7d28ab1abe484102cd3ec18ee6ce9c9ac7b5bb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes a missing default_partner_id in context of 'Opportunities'
stat button on contact form. It allows to immediately link a new opportunity
to the contact we came from.
Task ID-2343221
closesodoo/odoo#58722
X-original-commit: 77d4ba222630fa0f97351186782d09d2ec59a42a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit we remove the warning logger when not being able to format
a phone number. Indeed this does not indicate there was a real issue.
It simply indicates that either the phone number is not parsable or not
matching given country format.
It happens in a lot of situation that phone numbers are not valid: bad
encoding, country mismatch due to {lead, task, ticket} / partner not always
being the same, ... This should not raise a server warning.
When using frontend SMS composer for phone number, a warning is displayed
to the user telling the number is probably incorrect. This is considered
as sufficient from UX point of view as it warns users. We do not think
we should warn admins that some data is incoherent in database.
This commit also
* Revert "[FIX] crm: avoid linking demo leads with an unrelated partner"
This reverts commit 2c94c4c81ffa171158586cd64828d27c537cd1d6
-> having "invalid" data should be a valid use case of real life
* Revert "[FIX] crm: get correct country for phone validation"
This reverts commit a58f9fc154c038d72031b281e2bec2c0fc2915ba
-> country of a lead comes from its partner if set but can be different.
Same for phone numbers. Values on a lead after a compute are considered
as complete. Sales persons could effectively have incoherent data on their
form view but that is the result of what has been encoded.
Task ID-2325228
X-original-commit: cecc4ca6f02e599e193c3fa688bfcbd02ac0580b
Using this partner will copy his phone number on the lead.
However, the lead and the partner don't have the same country, which
will lead to ad invalid phone number (for the lead country).
It avoids a warning emitted by the `phone_validator` module, while
browsing the lead.
closesodoo/odoo#58352
X-original-commit: 2c94c4c81ffa171158586cd64828d27c537cd1d6
Signed-off-by: Christophe Simonis <chs@odoo.com>
The method _compute_probability has a dynamic depends, that depends on the
crm.pls_fields config parameter. When installing the DB, the depends is
evaluated. If the config parameter is modified afterwards, the depends is not
re-evaluated as the registry is not rebuilt.
The result is that when modifying the config parameter, if an optional
pls_field's value is modified on a record, the compute won't be triggered, as
that pls_field is not in the compute's depends.
This commit force to re-setup the registry after a modification (or the
creation) of the crm.pls_fields config parameter, in order to force the
depends of the _compute_probability method to be updated.
Task ID: 2341829
closesodoo/odoo#58165
X-original-commit: e95afbedc18d198454c7f66b523c4cafb19a4066
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
Setting a lead to won or lost should not impact others leads' probability
until they are modified.
Tests have been added to ensure that.
Task ID: 2254543
closesodoo/odoo#57681
X-original-commit: 7edc12e366659d226d56197e09bd65d17c80bd2f
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
Purpose
=======
Get rid of the cron.
Always have an up to date frequency table to compute lead probability.
Clean PLS code and ensure to remove unnecessary code
Specifications
==============
Disable the cron:
- Increment won and lost count for lead PLS params from frequency table at
each won/lost
- The complete set of leads won't be recomputed anymore every day
- A lead probability will only be recomputed if one of the PLS parameter will
be modified (stage_id, team_id + the ones checked in settings)
- No more onboarding phase : as frequency table is always up to date and only
the modified leads are recomputed, we can drop this. (So even on onboarding,
winning or losing a lead won't impact other leads, except the ones we modify
manually afterwards)
- Add an button to force the recompute of all the lead probabilities
(kind of reset) in the settings.
The cron has been disabled by default.
Users can know choose to reactivate it if they want to continue updating their
lead probabilities on a daily basis.
Code have been reorganised for better structure and understanding.
Some code parts have been factorised to be usable in both Live Increment and
Full Rebuild mode.
In this commit, we also update probabilities using only computes
Before this commit, _update_probability was called during write and create,
to ensure both probability and automated_probability were correct. That was
necessary because of onchanges and readonly field (automated_probability
was not given to the write method while saving after a change on the lead).
After this commit, we use the force_save tag on the readonly field
automated_probability. So we ensure that write always receives the new
automated_probability value and everything can be handled directly by the
compute. Also, we force the lead to start in automated probability mode.
So when creating a new lead, both probability and automated probability are
computed and aligned.
Finally, when winning a lead, we ensure that both probabilities are aligned
(=100), so that if user take the lead back to a previous stage, the
probabilities are correctly recomputed, and the lead will not be stuck to
100%.
Also, this commit applies some fix and minor changes listed here under:
- Ensure to have always positive frequencies
- Fix lost counts for team not set in pls computation
- optimise set_won : write only once per values
Finally, include tag in frequency table even if less than 50 occurences:
Due to refactoring in which we increment frequency table at each won/lost
instead of rebuilding the frequency table each day, the tags are never added
in frequency table.
This is due to the 50 occurence conditions that avoid to create the frequency
if we have less than 50 won or lost for a tag.
After this commit, we include the tag_ids in the frequency table, no matter
the number of occurences. But, during the PLS computation, we skip the tag
frequencies if the number of occurences for this tag is under 50.
This allows to have a complete vision on the tag frequencies, even for
small number of occurences.
Task ID : 2254543
X-original-commit: cd291b79eb2d2df80899867263ec71438ab8fe87
- Go to CRM > Settings and activate Leads
- Go to CRM > Leads and create 2 Leads with a different phone number
- Select the 2 created Leads and in Action menu, select Send email
- Make sure that "Lead/Opportunity: Mass Mail" is selected as template
- Send it
- Go to Contacts
2 Contacts have been created from the Leads, but both have the same phone number.
The issue comes from the override `default_get` of `res.partner` in crm module.
It is using `active_id` from context to fetch the Lead to populate Partner data.
This cannot work when several Leads are selected as the same `active_id` is used
for all of them.
opw-2333819
closesodoo/odoo#57638
X-original-commit: a84dcfb9475051082c6103f81bfa231ea50ed157
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
For the graph views based on reporting models (e.g sale.report), click
on a group in the chart redirects the user to an "empty" list view. Here
we use the attribute disable_linking to avoid that redirection for those
views.
Task ID: 2336960
closesodoo/odoo#57622
X-original-commit: 0b0ae92b6bdac25843ba24d767dbcab3b75703e5
Related: odoo/enterprise#13192
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before when we tried to duplicate a lead without the mrr option
active, a traceback was raised.
If the MMR option was not activated, then the user was not be able to write
on some field because he was lacking the corresponding group. In this case,
the recurring_revenue and recurring_plan fields.
Now, when copying a lead, we purposefully set those fields to 0/False to
avoid a crash if the option is not enabled.
task-2325629
closesodoo/odoo#56927
X-original-commit: 1a5cc55dfeb03ad7d4a63a0286d5d33eaca3cbe2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Now, compute's methods are executed on default, which leads to a crash
when these methods try to use the actual records but there isn't one
yet (e.g. at the creation of a record).
- Fix the traceback raised when creating a lead because of the
visitor_page_count method when self.ids is empty on default compute.
- Since the default_get() and the first_onchange() are also now combined,
we need to adapt the syntax of the default get for the field opportunity_ids,
replacing the array of ids by the command syntax '[(6, 0, ids)]'.
task-2325629
X-original-commit: acbc97bfe290ef3c7b8f7a1160266e49485099ae
- Create a Meeting for Contact X
- Go to Contacts and open Contact X
The Meetings smart button shows 1, but when clicking on it,
all user & partner meetings are displayed.
opw-2320299
closesodoo/odoo#56753
X-original-commit: 70f441a7ee3d46f6ba25cf56529a972b9e7ab29e
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Right now on few business objects (like leads, invoices, tasks, helpdesk
tickets etc) creation message contains
* subtype description;
* generic creation message;
This looks like multiple creation message on chatter after creation of the
record as you generally have "Task Created - Task created" (subtype description
then generic message).
This happens when we provide custom subtype on creation by by overriding
`_creation_subtype` method.
This commit fixes the issue by only using provided creation subtype and
removing default body. If creation subtype is not provided default creation
message is posted as before.
In this commit we also fix subtype for Lead/Opportunity creation and make
it generic ('Lead/Opportunity created') to avoid inconsistent behavior.
Finally some cleaning is made in method naming. Semi followup of 92e9e84b63
LINKS
Task ID-2288458
PR odoo/odoo#56631
PR odoo/enterprise#12707closesodoo/odoo#56688
X-original-commit: 2ebbeb4b5443c6405dd9a3b202a1eee9c5c67ebb
Related: odoo/enterprise#12728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create a Contact named "Alpha"
- Create another Contact named "Mister X" with "misterx@alpha.com" as email
- Go to CRM and create an Opportunity for Mister X
- Go to Contacts and open Alpha
The Opportunities smart button shows 0, but when clicking on it,
Mister X's Opportunity is displayed.
The Opportunity smart button displays a "crm.lead" view with a filter on partner_id.
The filter applies an "ilike" with the Contact's name on several fields of "crm.lead",
including "email_from".
As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved.
opw-2320299
closesodoo/odoo#56667
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
In this commit we set tree view of leads (both as leads and opportunities)
as multi edit enabled. Onchanges has been removed in CRM application. We
can therefore allow multi edit as computed fields work as intended.
Add domain on user_id fields to prevent selecting portal users as Salesperson
or Team leader from list views.
In crm.lead, onchange is only used to get formatted phone numbers when their
values changed or when country_id & company_id updated. This behavior will
only work in form views. It is not blocking so multi edit is not an issue.
Do not allow multi edit on name as it makes no sense.
Specifications: Contact (res.partner): base.view_partner_tree
phone
email
company_id
city
state_id
country_id
category_id
date_review_next
grade_id
user_id (+ add a limitation to not share users)
Specifications: Opportunities (crm.lead) : crm.crm_case_tree_view_oppo
partner_id
email_from
phone
city
state_id
country_id
stage_id
probability
partner_assigned_id
user_id
team_id
planned_revenue
company_id
campaign_id
medium_id
source_id
tag_ids
priority
Specifications: Opportunities (crm.lead) : crm.crm_case_tree_view_leads
contact_name
partner_name
email_from
phone
city
state_id
country_id
partner_assigned_id
user_id
team_id
company_id
probability
campaign_id
medium_id
source_id
tag_ids
priority
Specifications: Sales Teams (crm.team) : crm.team.tree
user_id
company_id
Specifications: Stages (crm.stage) View : crm.crm_stage_tree
is_won
team_id
Task ID-2200674
PR #56378closesodoo/odoo#56533
X-original-commit: 369375a69adc20a92075a89ef9557bf6b46cd605
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Improve performances of various Odoo code bits.
SPECIFICATIONS
Use a read_group to compute the opportunities_count & opportunities_amount,
like the other compute methods for statistics fields.
Do the same improvement in pos_sale when computing pos_order_amount_total.
LINKS
Task ID-2281297
PR odoo/odoo#53053
PR odoo/enterprise#11299
X-original-commit: 3e30b1e5c1aa25463848d82492f25002bcbf9154
Phone validation of crm_leads was using crm.lead country instead of partner
country code. This was leading to phone number of crm_case_16 coming from
an us partner validated as a uk phone number. (same problem applies for crm_case_14)
The problem was discovered in pre/post upgrade crawler test.
closesodoo/odoo#56348
X-original-commit: a58f9fc154c038d72031b281e2bec2c0fc2915ba
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This module provide routes to manage people, companies, and
leads from the outlook add-on. It could eventually be accessed by
add-ons for other mail clients.
closesodoo/odoo#44936
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Two things have been introduced in this commit:
The first is a change in the way the tour tip widgets are updated when
a DOM mutation is triggered: before this commit, each active tip would
evaluate its current anchor to elements matching its "trigger" selector.
If the element was not the anchor, it was set as the new anchor and
would be bound to the tip event handlers. Now, the unbinding/rebinding
of event handlers is done regardless of the new element.
This is helpful when the anchor is on a field monetary for example,
which keeps the same input element while internally unbinding and
rebinding the widget event listeners to it on each rendering. This
process does not include external event listeners such as those of the
tip and they were lost until now, breaking the tour step.
The second change is a modification of the CRM tour: the "Expected
revenue" field being an input, the according step trigger has been set
to target the input element instead of its parent. This means that the
step will await an "input" event instead of a click to be consumed,
making the tour step feasible with a keyboard.
Task: 2314864
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
PURPOSE
Adapt CRM views now that some measures can be set invisible.
SPECIFICATIONS
Adapt the views and implementing the new invisible attribute on some fields.
It allows to hide unnecessary measures.
In this commit we remove some measures in inheriting CRM apps
* crm: do not use color as measure;
* crm_iap_lead_website: do not use reveal_iap_credits as measure;
* website_crm_partner_assign: do not use partner_latitude and partner
longitude as measures;
LINKS
Task ID-2288381
Community PR #54774
Enterprise PR odoo/enterprise#11970
Upgrade PR odoo/upgrade#1519
This commit simply removes the default filter on the calendar.events when
clicking on the crm.lead stat button to access "Meetings".
The filtering was not handy because the user could not easily see when a slot
was available to schedule a new meeting.
The events that are related to that crm.lead are highlighted anyway (current
behavior), which should be sufficiently clear.
Task ID 2289295
closesodoo/odoo#55050
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Nicolas Lempereur