| Age | Commit message (Collapse) | Author |
|---|
|
Currently phone_sanitized computation on lead model works only if crm_sms
is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
dependency hides the issue as those modules are auto-install. However if
``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.
Task ID-2528169
Oversight of odoo/odoo#45315
|
|
When the user searches a phone number, the search function will generate
a pattern by removing the "+" sign as well as well as the prefix "00" from
the input string.
Problem:
If the input string starts with "+", it means that the phone number will
be prefixed by something different than "00". As the function will
systematically remove the first occurrence of "00" from the input string,
the function can remove part of the input string that does not correspond
to a prefix. The search results can hence be incorrect.
Example:
If the user types "+32485001122", the function will remove the "+" sign
and the first occurrence of "00" from the input string. In the provided
example, the function will search phone numbers matching with the pattern
"324851122" which is incorrect.
Solution:
The function should remove the first occurrence of "00" iff the phone
starts with "00".
Task id: 2479277
COM PR: odoo/odoo#69729
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Purpose of this commit is to fix computation of access link. In some cases
msg_vals modification leads to invalid URL computation, notably for frontend
or backend differentiation for target recipients.
Followup of odoo/odoo#63292 .
Task ID-2513724
COM PR odoo/odoo#69607
ENT PR odoo/enterprise#17849
X-Original-Commit: odoo/odoo@2015ef463c9ac7c7f89d543745c02a2d1528acf2
|
|
Before this commit:
If there is no subject for message, it effectively displays "False" in case of
void subject.
After this commit:
If there is no subject for message, it will not display "False" in case of void
subject.
Tasks-2156170
closes odoo/odoo#68232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Before this commit when we update the email_from field on lead with only
formatting differing from partner a warning ribbon was displayed. It
considered email had changed and had to be propagated. Moreover unnecessary
update on partner was done to propagate the new email onto the customer.
In this commit we propagate email only if normalized versions are different.
It means that if lead email_from is "Hermes Conrad <email@example.com>" and
partner email is "Jonathan Conrad <email@example.com"> no update from lead
to partner is performed. Indeed normalized versions are the same.
Task ID-2461308
PR odoo/odoo#66890
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Right now, if someone changes the `crm.pls_start_date` system parameter
to something that is not valid, opening a settings gives you traceback.
This commit improves the behavior by making sure that the compute field on
settings page `predictive_lead_scoring_start_date` always contains a valid
date. For doing so, if the system parameter is not a valid date(or not set
or deleted), we set the above field to the date 8 days prior to current
date, and thus, when saving the settings, the system parameter is again
set with a valid date.
closes odoo/odoo#65985
Taskid: 2448248
X-original-commit: ead10c7e0a22ce65a88558cdfaa99198ac27e524
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
RATIONALE
Stored editable fields receive their values either from compute either from
user input. If a user input is given to create / write compute method is not
called. If multiple fields are computed through the same method giving one
field value discard call to compute method and other fields are not called.
SPECIFICATIONS
Split ``_compute_partner_id_values`` compute method so that partner related
fields are independent :
* have a method for address fields as those are computed in group. Indeed
either we take all from partner either none. Otherwise it would create mixed
addresses that make no sense;
* have a specific computation for partner_name and contact_name coming
from ``_prepare_partner_values``;
* have other fields separated (function, title, ...) acting like related on partner
if not set by user;
LINKS
COM PR odoo/odoo#65381
Task ID-2451339
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545
Closes odoo/odoo#63292
Closes odoo/enterprise#15585
closes odoo/odoo#64170
X-original-commit: 2b6d2b71f6c60bcf64db440473c88d1dc335acbf
Related: odoo/enterprise#15588
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
|
|
Fix typo preventing a correct management of won/lost when creating
multiple leads in a row.
closes odoo/odoo#64140
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
With a recent commit[1], we fixed the issue of false warning while changing
the partner on lead. But that fix ignored the fact that the lead has an
automatic formatting that may lead to false warning.
Right way to detect a phone number change is
* lead phone is different from partner phone;
* lead formatted phone is different from partner formatted phone;
If those two conditions are met we are quite sure numbers are different and
not only differs in their formatting.
In this commit we also fix inverse of phone number. When updating lead phone
value we have to use the same heuristic to update partner phone value. That
was we avoid unnecessary partner update when only formatting differs.
Tests are added to ensure new behavior and that ribbon message is effectively
trig erred with correct content.
LINKS
Task ID-2390287
[1] - https://github.com/odoo/odoo/commit/d29862c1de6208f7fdb7c8104afe0d35241d130b
closes odoo/odoo#62397
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Ijas Ahammed <ija@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
|
|
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closes odoo/odoo#62420
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
This commit changes the default crm alias prefix from 'info' to 'contact'.
As the alias of the default sales team is configured to 'info', also having
'info' for the "crm_alias_prefix" setting was leading to an alias collision.
This change allows an easier configuration by the end user and avoids confusion
when first playing with your CRM settings.
Task 2373095
closes odoo/odoo#61025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
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 #61490
closes odoo/odoo#61497
X-original-commit: 7ff3e9abf08f7f896f31119247157cce5764b431
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.
closes odoo/odoo#61365
Related: odoo/enterprise#14682
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
|
|
config parameter
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
closes odoo/odoo#61290
X-original-commit: d04cc4df4ec28816aeb6d1d7c7fc0e547fd13fa5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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
|
|
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
Co-authored-by: nim-odoo <nim@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
closes odoo/odoo#59976
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 #59084
closes odoo/odoo#59100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
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.
closes odoo/odoo#59144
X-original-commit: 291db77cf09c6ee76373fd168f575fda28270467
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
|
|
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
closes odoo/odoo#58163
X-original-commit: e95afbedc18d198454c7f66b523c4cafb19a4066
Signed-off-by: Raphael Collet (rco) <rco@openerp.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
|
|
- 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
closes odoo/odoo#57632
X-original-commit: a84dcfb9475051082c6103f81bfa231ea50ed157
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.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
closes odoo/odoo#56601
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
- 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
closes odoo/odoo#56750
X-original-commit: 70f441a7ee3d46f6ba25cf56529a972b9e7ab29e
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.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
closes odoo/odoo#56666
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.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
|
|
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.
closes odoo/odoo#56336
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.
closes odoo/odoo#44936
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.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.*
|
|
PURPOSE
Make sure the Rainbowman animation is rightly triggered whichever way the user
marks the opportunity as won. Especially relevant for the onboarding as we want
to show the first rainbowman to users completing the tour.
SPECIFICATIONS
Now the rainbowman and its finely-tuned message are displayed to the user when
he uses the statusbar, mark lead as won using action buttons or drag and drop
a lead in the won stage in kanban view.
LINKS
Task ID-2287758
PR #54553
|
|
This commit adds a few minor improvements to crm views:
- Add the crm.team currency on opportunity amounts on the crm.team kanban view
- Slightly reorganize "My Activities" view for increased usability
- Remove the "alias_user_id" field in the crm.team form view because it's a
related technical field that is not supposed to be modified there.
Task #2314894
closes odoo/odoo#55940
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
|
|
PURPOSE
Allow users to configure contract recurrences and Monthly Recurring Revenues
on Opportunities they're trying to close. One short revenues are not sufficient
to cover real life use cases of CRM revenu analysis.
SPECIFICATIONS
Adds an option in the settings to activate the recurring revenue feature.
This feature is set on an opportunity to indicate a revenue that could be
perceived over time. This time indicator is set by the crm.recurring.plan
model in which the number of months is determined.
By default some plans are added in data. When using plans, revenues are
computed across the plan months.
LINKS
Task ID-2283052
odoo/odoo#54194
odoo/enterprise#12423
odoo/upgrade#1463
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
PURPOSE
Link field name with their content.
SPECIFICATIONS
This commit changes the field name "expected_revenue" into "prorated_revenue"
and the field name "planned_revenue" into "expected_revenue".
Indeed content of those fields evolved since their first naming. Their content
is not what the field name indicates. Better rename those fields to understand
code flow inside CRM.
LINKS
Task ID-2283052
odoo/odoo#54194
odoo/enterprise#12423
odoo/upgrade#1463
|
|
PURPOSE
Avoid automatic partner finding and update on lead to erase too much data.
RATIONALE
On crm.lead, the address fields, email_from and phone, are computed field
since saas-13.3 based on the partner_id. Previously they were synchronized
with an onchange on partner_id which was never triggered during automatic
flows on the lead.
Now computed field are triggered each time the partner_id is written.
Problems
- If someone uses the mass conversion with the action "Use existing partner
or create", the partner is found for each lead with the method
_find_matching_partner. This method can find any partner with a name that
contains the lead name, the lead contact_name or partner name. It can find
wrong partner. Previously, only the partner was changed and the contact
information remained on the lead. Now, all the information are erased with
the wrong partner information.
- If at creation all the address information are set and the partner_id
as well, the address field from the partner won't be synchronized.
The lead will end up with the address information we forced.
During the conversion to opportunity, the partner_id defined on the
lead, will be written again. It will trigger the synchronization
of the address field on the lead. Those info can be incomplete or wrong
You will end up with a data loss.
SPECIFICATIONS
Tell _find_matching_partner to match partner only based on exact email address
in the case of mass convert. Avoid fuzzy matching based on name likeliness.
During opportunity conversion, don't write the partner_id if the partner is
already the one set on the lead.
LINKS
Task ID-2316828
PR #55825
X-original-commit eed0a31e1e2c428c94dae4703c9575534a49ec1d
X-original-PR #55194
closes odoo/odoo#55838
X-original-commit: e82b5a92f44709592b25fa66d9555d64abef1ec9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
PURPOSE
Distinguish synchronization of partner values on lead: address fields (all
or none), classic fields (propagate if set) and special cases (names-alike).
SPECIFICATIONS
Follow up of https://github.com/odoo/odoo/commit/f8179007f9aa662be7318edeb18426ea1c906c15
Context: many fields are now synchronized from the partner_id: address fields
as well as other contact fields. A first commit 9c9f477f04e8f4ee9b18092fe894890c2ab31b58 kept the value
from the lead if the value from the partner was empty. This lead to mixed
address fields.
A second commit fixed that behavior f8179007f9aa662be7318edeb18426ea1c906c15 by taking the value from
the partner only when it was set.
Problem: This erases too much information.
```
>>> lead.partner_name
'testtest'
>>> partner_id.name
'testtest@mailinator.com'
>>> partner_id.parent_id
res.partner()
>>> partner_id.is_company
False
>>> lead.write({'partner_id': partner_id.id})
>>> lead.partner_name
False
```
We indeed need a consistent address but for the other fields we want to keep
the maximum of data.
SOLUTION
For the address fields, take all the values from the partner if one of the
address fields is defined, otherwise keep the information defined on the lead.
For all the other fields keep the lead information if the partner information
is empty.
LINKS
Task ID-2316828
PR #55825
X-original-commit https://github.com/odoo/odoo/pull/55194/commits/f53fba6663a34e8e6b13354dde3dc225f5814de3
X-original-PR #55194
X-original-commit: b136df8530279a54c9be96beeea9bdda01643000
|
|
PURPOSE
Improve user experience by improving copy writing of tour steps and first
encountered screens.
SPECIFIFCATIONS
Improve Pipeline empty list help to be more catchy and help users doing their
first opportunity related steps.
Improve tour copy writing.
LINKS
Task ID-2316699
PR #55604
|
|
Followup of 9c9f477f04e8f4ee9b18092fe894890c2ab31b58 and f8179007f9aa662be7318edeb18426ea1c906c15
In some cases (notably event_crm addon in 13.4) a country record is propagated
instead of a country ID; converting as write values ensure we always deal with
IDs in all cases.
Also add some tests to cover more test cases. Notably phone and email behavior
in 13.3 compared to other fields. For example phone is kept is partner's phone
is void. It may leads to inconsistencies (partner US, Belgian phone number).
We think it is better to keep values and let salesmen change them than
voiding values customer gave.
PR #55390
Task ID-2311981
closes odoo/odoo#55412
X-original-commit: a26735f516e48acb77e234862e17e29be71d7d1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Consider a lead with valid email and/or phone. Some process assign a partner
to it, like mass convert. This partner has no email and/or phone. We should
not void lead values for email and/or phone, as this is information loss.
This is a followup of 89ca89ca9269aea9ce2850db28ef6a7477e1ef18 . Test cases are added to try to
avoid future regressions.
Task ID 2311981
PR #54619
X-original-commit: 0b69d98cf4cbd2c99d7c3fb510e324f49652eea5
|
|
FIXUP of 9c9f477f04e8f4ee9b18092fe894890c2ab31b58
[FIX] crm_lead: do not erase computed field based on partner
Don't erase the field on the lead if you emptied the field partner_id
but erase them if you select a partner_id that have empty value
for the corresponding field
otherwise you end up with mixed address field.
Make an exception for the phone and the email_from
Keep the value from the lead if the partner_id has no value
for those field
X-original-commit: ed3979f84e65ebfa9534f12196a8fa41cade8370
|
|
Issue:
When you write partner_id = False on a lead
it erase all the values computed based on the res.partner
this lead to data loss during the conversion to opportunies
by the lead assignation process
Solution:
Revert to v13.0 behavior, don't erase the value
of the address, phone, email when the partner is set to
False
+ Fix typo in method name
X-original-commit: 21db6cf93fea7d07ec4a8655fc6030a177abc36f
|
|
Purpose of this task is to prevent merging of opportunities when
a regular (non super) user selects more than five records.
This commit limits total number of recorrds to be merged, up to maximum
five leads / opportunities for non superuser environment, and raises a
UserError otherwise explaining the threshold limit.
closes odoo/odoo#55024
Task-id: 2256126
X-original-commit: c25d7654f250c888cea84c20af16b2a32cc5b365
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
In the lead, we compute the phone number to make it formatted to match
with the international phone number format.
Before this commit, this formatted number was used for comparison with
partner's phone (which is not formatted), and so, even if both the
numbers are same, the warning ribbon appears due to different formats
which is not correct behavior.
This commit fixes the issue by comparing both the formatted number to
remove the false positive warning ribbon and thus making sure that it
appears only when there actually is a difference between lead's phone
and the phone number set on partner.
Task Id-2274752
closes odoo/odoo#54942
X-original-commit: d29862c1de6208f7fdb7c8104afe0d35241d130b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
1. set a Sales team and add an alias
2. create a contact (customer) with an email and grant them portal
access (under the action)
3. Odoo creates a portal user
4. use the email of the contact to send an email to the alias set under
the sales team
An opportunity is created but the sales person assign to that
opportunity is the customer.
This will revert user if the user has no access to crm.lead
opw-2288442
closes odoo/odoo#54217
X-original-commit: a3fdff3dd9cc38b432b93a7cd4387cb7c38b8d06
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
General Purpose : Introduce a new "My Activities" view so that CRM
users can easily overview and process their To-Do list
- new button in "My Activities" tree view : Send Email
Purpose: allow users to send email in one click to the client
- new button in "My Activities" tree view : Send SMS
Purpose: allow user to send sms in one click to the client
- new button in "My Activities" tree view : Snooze
Purpose: easily Snoozes the activity for 7 days
--> today + 7d if deadline < today
--> deadline + 7d if deadline >= today
- New view crm_case_tree_view_my_activities to show "My Activities"
Purpose: Use this view so that CRM users can have a "To Do List"
Domain of this action is : crm.lead, type = opportunity
Filter is : My Activities (at least an activity assigned to me)
- Rename filter "assigned_to_me" to "My Activities"
- Change crm_case_tree_view_oppor to be clearer for the user.
Purpose: allow the user to have an good idea of what he has to do in
a view.
Remove all decorations set on the CRM tree views
Add the widget remaining_days to the field activity_date_deadline
Add the field activity_ids with the widget list_activity
- New menu item and corresponding act_window to display the new views
Task ID 2243124
Community PR odoo#51537
closes odoo/odoo#53376
X-original-commit: 2382c01956feda617b7d207d1bc4d69de1e8b6b3
Related: odoo/enterprise#11314
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
|
|
RATIONALE
Activities are a way to organize our daily pipe. Notably in a sales pipeline
salesmen may have multiple leads with activities to perform in the next few
days. We would like to be able to have a list view displaying a list of leads
with "my" deadline, and to order leads based on this field.
PURPOSE
As activities are linked to records through a one2many and as my activities
are only a subset of those activities, it is impossible to store a field
on lead model. Indeed it would depend on the current user which makes storing
it impossible.
However ordering on a column in list view asks for a stored field. As it is
not possible, this commit proposes to hijack the web client and search of lead
model in order to allow it.
SPECIFICATIONS
Introduce a activity_date_deadline_my field, computed and searchable that
behaves like activity_date_deadline. It is filtered on current user activities
instead of being global to the record activities. "My" deadline is the earliest
deadline of my activities, even in the past.
Ordering through web client calls search_read with an order parameter set.
Search_read then calls search. In this commit we therefore override search
to intercept a search without count with an order on activity_date_deadline_my.
In that case we do the search in two steps.
First step: fill with deadline-based results
* Perform a read_group on my activities to get a mapping lead_id / deadline
Remember date_deadline is required, we always have a value for it. Only
the earliest deadline per lead is kept.
* Search leads linked to those activities that also match the asked domain
and order from the original search request.
* Results of that search will be at the top of returned results. Use limit
None because we have to search all leads linked to activities as ordering
on deadline is done in post processing.
* Reorder them according to deadline asc or desc depending on original
search ordering. Finally take only a subset of those leads to fill with
results matching asked offset / limit.
Second step: fill with other results. If first step does not gives results
enough to match offset and limit parameters we fill with a search on other
leads. We keep the asked domain and ordering while filtering out already
scanned leads to keep a coherent results.
All other search and search_read are left untouched by this commit to avoid
side effects. Search_count is not affected by this commit.
As web client order availability is simply based on field being stored we
have to allow hijacking its value. A new option 'allow_order' is added that
display the order icon in list view column headers. It allows calling
search_read with an order based on the column but nothing more. Using it
on a not-stored field will give a warning log and ORM ignores it by default.
LIMITATIONS
At least following limitations apply
* search on "my activities" gives a list of ids that is used for searching
and ordering. It means that having too much activities on a given user can
result in poor performances.
-> we consider that activities assigned to a given user should be kept
under control. Leads with activities for a given user should be a small
subset of leads without activities.
* ordering on activity_date_deadline_my always put those records on the top
(deadline asc or desc) whatever the actual ordering of order items given
to search. This is done to avoid complex implementation where deadline
would be used to order records within groups ordered by another field.
-> for example: order = 'priority DESC, activity_date_deadline_my ASC'
actually behaves like 'activity_date_deadline_my ASC, priority DESC'.
WARNING
This implementation is a hack. It has been done by professionals. Do not try
to do it at home.
More seriously this is hackish and should be avoided. IN our case we consider
that the use of activities in sales pipeline is mainly driven by "my activities
deadline", which is not necessarily the case with longer processes like tasks.
Moreover user tests tend to show that this feature could be interesting. It
will improve quality of Odoo CRM and its adoption by improving its daily
use. A framework solution has to be found. Until this is done we keep this
hack and hope it is not duplicated in other applications.
LINKS
Task ID 2276011
Prepares Task ID 2243124 (My activities in CRM)
PR #52232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Add an autocomplete for opportunity name. If no name is set when a customer is
selected set the name partner_id.name's Opportunity
Change help title and subtitle to be more explicit. Change title from "Create
an opportunity in your pipeline" to "Create opportunities to keep an eye on
all your ongoing sales talks." Concerning subtitle, if a valid
and active email alias is found : Emails sent to ALIAS@address automatically
create opportunities.
Improve crm onboarding tour text messages and display.
Change menuitem from Teams to Team Pipelines to be more explicit. Update
the corresponding act_window name in the sales_team module.
Make the "schedule an activity" button bigger (100% of the div) and highlight
the entire Schedule button box.
Update test tours accordingly. Since quick create opportunity form is updated
the tests were failing. Reason is a trigger on input:first trying to detect
the field "name". This is not the case after this commit's changes.
Task ID 2226563
Community PR #51587
|
|
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Digest now use qweb views instead of a standard mail.template record for
rendering as
* template is very custom;
* probability of breaking it while edition the mail template is high;
it is easier to maintain and extend in qweb;
* only body was really used, other mail-related fields were not used;
We therefore remove the mail template data and the field used for it on
the digest model. Template is now forced to a Qweb view.
We can also remove the template_id field. Indeed we think that having
different templates for digests is a really advanced use case we do not
want to support.
Finally kpis and action computation is rewritten. It now returns an unique
structure containing all information in a more neutral way, holding values
for 3 columns. Purpose is to be less date-oriented in data construct and
allow people to use digest qweb template to display a 3-columns KPIs content
even if not related to yesterday / last 7 days / last 30 days.
LINKS
Task ID 2197417
Community PR odoo/odoo#51619
Upgrade PR odoo/upgrade#1256
|
