Use a template for merge post messages and clean how fields are displayed,
notably by fixing the display format, and the field order.
Indeed, previously posted lead merge message contained all fields in an
alphabetical order, even ones that had empty values, which is not very user
friendly in terms of display.
Now, the displayed fields are determined and ordered by sections, which greatly
improves understanding the various information.
Please note however, that it has the downside of not including all fields
anymore.
The merged leads information are included in a "read more/read less" enabled
block using the "data-o-mail-quote" feature to get a nice rendering and avoid
cluttering the Odoo chatter UI.
Within the sent mail however, the full text is directly visible when viewing
through a mail client.
Task-2451164
closesodoo/odoo#75946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
After the conversion of the graph and pivot views done in https://github.com/odoo/odoo/pull/73311,
it was no more possible to open the forecast_graph and forecast_pivot views.
This is due to the fact that the new View component cannot manage a legacy
view: every extension of a converted view must be converted. We thus
convert forecast_graph and forecast_pivot.
closesodoo/odoo#76793
X-original-commit: ff28db335fa77dadc3198e754f1e0649811fba7b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some tests in this test class are leading to uncertain results and fails
randomly.
With this commit, the whole test class is deactivated until a fix is found.
closesodoo/odoo#76743
X-original-commit: 39545ba5b3c080ae3e651c4f9d25aa190582429a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, in some of the important business objects' form views,
few header buttons are missing the title, and so the command palette
displays the button string which is not very clear/useful.
This commit improves the behavior by adding titles to the buttons. Below
are the model wise actions/methods linked with updated buttons:
- preview_invoice (account.move)
- action_sale_quotations_new (crm.lead)
- action_set_lost (crm.lead)
- action_set_won_rainbowman (crm.lead)
- crm_lead_lost_action (crm.lead)
- iap_enrich (crm.lead)
Task-2622266
closesodoo/odoo#75935
Related: odoo/enterprise#20680
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If for some reason we cannot compute lead probability, we should simply
continue to the next value without causing a division by zero.
For example, this can happen if all stages are team specific, as there is
a current limitation regarding the first stage (used to know how many lost
and won there is) that requires to have no team assigned to it. This is a
side effect of the commit https://github.com/odoo/odoo/commit/cd291b79eb2d2df80899867263ec71438ab8fe87 introduced in V14, and we should add
a test to ensure we do not crash in that case.
closesodoo/odoo#76379
X-original-commit: 9793bb29fe6c4d0d59905b2fcfe78ebe51e17579
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Purpose of this commit is to clean field definitions by
* doing compute in batch: especially when the loop can be reduced to a single
computation / batch assignment (based on groups or config parameter for
example);
* remove default when having a compute as computes should completely define
the field value at any time;
Some side dish code cleaning is performed at the same time: unnecessary
import or dead code removal.
Task-2638444
PR odoo/odoo#76005
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
Usually, the actions are defined before the menu items. So with this
commit, we load the 'crm_menu_views.xml' file at the last.
TaskID-2582208
Part-of: odoo/odoo#73530
- If we only install sales_team, on the footer of sale team kanban view
there's empty grey border which looks ugly. Also, if the data are
not available, the empty graphs don't look so beautifull.
This commit improves the kanban view to avoid this empty grey border
when there's no content within it, and in case of lack of the data,
we now display sample data in graph with grey color. Note that the
actual data now has colors, green for the future / present data range
and pink for the past ones.
- When opening the configuration menu of team kanban from CRM, we observe
three columns: View, New and Reporting. However, those columns are not
consistent. For example, when leads are activated, we don't see 'Leads'
action under 'New' column. Also the order for the actions are not
consistent for 'View' and 'Reporting' columns.
This commit re-organizes the sequence of the actions for these columns
and thus makes them consistent. Note that we want to always show the
'Activites' at the last, which is being added from crm with 'Leads' and
'Opportunities' actions. So an empty seperator is introduced to keep
them seperate, and push the sales related actions on the top of
'Activities'.
- Right now, the alias on sales team's kanban view is being shown
with `<small>` tag, but it is hard to read. Apart from that, in
the list view, only the alias name is displayed even if the alias
domain is configured.
This commit makes the alias more easy to read by displaying it
with `<span>` tag on the kanban view, and by showing the full
alias along with the domain on list view. Note that on the kanban view,
alias will now be displayed always, which previously was displayed only
when 'leads' were enabled.
- This commit also changes of the action 'crm_activity_report_action' from
'Pipeline Activities' to simply 'Activities' to avoid confusion.
- Apart from that, this commit also adds currency symbol in the form
view and kanban view (while configuring the target), with the suffix
' / month' after the input. Adds the alias name in the
team list view, and it adds 'many2one_avatar_user' widget on user_id
field for both list and form view.
TaskID-2582208
Part-of: odoo/odoo#73530
- if the alias is configured for the team, the action helper
with the link of that email will be displayed. Otherwise, it will
simply indicate user to either create lead manually, or to configure
email alias.
- This commit improves action helper for the tags and adds
sample data for better onboarding.
- This commit adds action helper on action 'sale.action_invoice_salesteams'
for better onboarding.
- This commit updates the action helper for 'CRM > Customers'
and 'Contacts' actions and make the helper message consistent.
TaskID-2582208
Part-of: odoo/odoo#73530
Before this commit, editing a mail.activity with the "meeting" category would
open a modal form for the mail.activity, which did not make much sense.
When editing a mail.activity that is linked to a calendar.event, you will now
jump on the calendar view to edit the related event, which is much more
convenient.
In addition, when scheduling such an activity, the "Edit" button in the chatter
is renamed to "Reschedule", to show the user that he will land on the calendar
view.
Furthermore, trying to delete an activity that is linked to a meeting will now
prompt a confirmation dialog warning the user that the meeting will be deleted
as well.
Finally, we moved the 'phonecall' activity category from the 'voip' module
(enterprise) to the base 'mail' module.
Scheduling a phonecall activity will let the user choose if he wants to:
- Simply save the activity, which will schedule a regular mail.activity
- Open the calendar to create a related calendar.event
Used typically when you want your colleagues to see that you are busy in your
calendar during this call.
Task-2486126
ENT PR odoo/enterprise#20431
UPG PR odoo/upgrade#2775closesodoo/odoo#75530
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Check if the attendees are correctly present. We replace
assertEqual by assertIn to be sure that the order of the
attendee doesn't have an impact on the test
task-2287846
COM PR: odoo/odoo#69484
ENT PR: odoo/enterprise#17792
Related: odoo/upgrade#2401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, 'My Activities' menu (under CRM > Sales) is accessible only
by the sales manager. However, this menu should be accessible to the
sales user also. The existing records rules make sure that the menu
will display salespersons' own documents only and so there seems no
data leak in this case.
So with this commit, we make the 'CRM > Sales > My Activities' menu
available for the salesperson as well.
Task-2624721
closesodoo/odoo#75521
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, it was not possible to create events with defined attendee state. The default value was always set.
This was a limitation when the events were part of a recurrence and all events attendee needed to be created with a known state.
To reproduce, one would create a recurrent event, sync it with Google and in Google, 'decline' this event and the following.
The attendee state was not properly set.
closesodoo/odoo#68700
Taskid: 2484335
Related: odoo/upgrade#2537
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Rename ``crm_iap_lead_website`` to ``website_crm_iap_reveal``. This module
is an addition to ``website_crm``, notably using visitor based information
to generate leads based on rules.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Rename ``crm_iap_lead`` to ``crm_iap_mine`` . Indeed it adds lead mining
feature on top of crm.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Rename ``crm_iap_lead_enrich`` to ``crm_iap_enrich`` . Lead naming is not
really required as it is a bridge build on ``crm``.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
As mail grows and will continue to grow, ordering views and having right
files is important to understand module organization and content.
Split main.py controller file into two files, one for mail related controllers
(redirections) and one for discuss.
Rename files according to guidelines for wizards and views.
No functional change comes with this commit. This is only code move.
Task-2631873
PR odoo/odoo#75571
Following the removal of read access on ir.model (odoo/odoo#69120),
the mail.activity.type model was not accessible to non-admin users due
to the res_model_id many2one field.
Before this commit, a project user could not access the Activity Type
menu.
Convert it to a selection field with the selection values being
computed in sudo.
closesodoo/odoo#74981
Related: odoo/enterprise#20214
Related: odoo/upgrade#2734
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Revert "[FIX] crm: allow regular salesman to convert and merge opportunities"
This reverts commit 24db93c0e6b88f89fdf03d63afee05fc858ed977.
Indeed adding a sudo at the end of merge process is a strange way to fix
an unexplained issue about "similar emails". CRM code has been cleaned
since v14+ and flows should not gain random sudo trying to solve an
undefined problem.
closesodoo/odoo#75385
X-original-commit: b4fa19376eb50bf07b5753b4664fcad4d637bcec
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Go to CRM and create a team.
- Create 2 Opportunities and assign them to the created team
- Put a date in the past for 'Expected Closing'
- Mark one of the opportunities as won
- Go to CRM > Sales > Teams
- You will see that the number of overdue opportunities is 1 but when clicking on it, it shows 2
Problem:
As an opportunity is in a stage with "is_won= True" so it was won (Probability 100%).
It should not be displayed with the overdue opportunities
Lost opportunities should not be displayed also.
Solution:
Opportunities won or lost have a closing date, so we can use this field to filter them:
https://github.com/odoo/odoo/blob/14.0/addons/crm/models/crm_lead.py#L590-L591
opw-2590471
closesodoo/odoo#75376
X-original-commit: b699c3e28c4cf745a91eb29bf5c85c429d152335
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When creating a meeting from a partner/lead, the invitations won't be
created/sent
To reproduce the error:
1. Open a lead
2. Click on Meeting
3. Create a meeting
- On meeting creation, directly click on "Create", not "Edit"
Error: No invitation has been sent. When editing the created event,
there isn't any invitation on Invitations tab. Same error will happen
when opening the form of a customer instead of a lead (step 1)
For an attendee to be created, the partners associated with the meeting
must be explicitly listed in the creation values:
https://github.com/odoo/odoo/blob/3e20e68f0790a0b0f3b5c4d43f59f235b7d20fef/addons/calendar/models/calendar_event.py#L710-L713
However, in the above use case, the partners identifiers are given
through the context. This explains why the attendees are not created.
OPW-2531496
closesodoo/odoo#75353
X-original-commit: a8b4f8f6c009d8abd7210973005fd755ac3bc573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
If an internal user does not belong to Sales / Administrator group, and wants
to convert a lead into an opportunity, he will face an access rights error if
another lead exists with the same email because we are trying to merge them.
We should allow him to convert and merge them without error.
closesodoo/odoo#75283
X-original-commit: 24db93c0e6b88f89fdf03d63afee05fc858ed977
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Update query counters according to last runbot state. This helps spotting
query counters change linked to this PR.
Task ID-2377974
Community PR odoo/odoo#61467
Currently,when merging opportunities, they are sorted by "confidence level",
which has following criterion for sorting:
- type (active opportunity is best, inactive opportunity is better)
- stage sequence (higher is better)
- ID (older is better)
For better sorting, this commit improves the confidence level by adding
probability as a third criterion, and so now criterion for sorting is:
- type (active opportunity is best, inactive opportunity is better)
- stage sequence (higher is better)
- probability (higher is better)
- ID (older is better)
This commit also adapts the test cases accordingly which now considers
probability as a factor for calculating confidence level.
Task-2198562
PR odoo/odoo#51893
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this merge is to force some probabilities on leads used as data
in various tests. That way when dealing with probabilities changes in tests
are easier to spot and understand.
Also fix some docstrings about stage sequence which were incorrect.
No tests has been changed, purpose was to set probabilities that do not
change any test output.
Task-2198562
PR odoo/odoo#51893
Currently, there are many useful pivot views on reporting models but most
of them lacks the dedicated list view. Dedicated list views will allow users
to see useful information when one directly drill down to the records from
the pivot table in odoo spreadsheet [1].
With this commit
1. we remove 'disabled_linking' attribute from the very important pivot
and graph views (see the full list on task pad);
2. we added dedicated list views for the following reporting models
- account.invoice.report
- fleet.vehicle.cost.report
- hr.timesheet.attendance.report
- purchase.report
- project.profitability.report
- report.membership
- report.pos.order
- report.project.task.user
- sale.report
Task-2547881
[1] See task-2506116
closesodoo/odoo#72394
Related: odoo/enterprise#19122
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Use Case
========
The cron run perfectly well when there is no concurrent transaction.
But in real life users may interact with leads modified in the cron.
This cause two issue:
Concurrent update
-----------------
If a lead is modified in another transaction during a the transaction
where the lead is modified. The parameter crm.assignment.commit.bundle
allow to reduce the size of the transaction but before this commit
the first transaction was always way longer because it took the time
to handle the bundle + the fetching of all the data at the begining of
the cron.
The solution: start a new transaction after the preparation
of the data is done
Missing record
--------------
If the a lead is deleted in another transaction before
the transaction that modified the lead starts.
The code will then try to access a record which does not
exist anymore in the database causing a Cache Miss and Missing record
error.
The solution: Make sure a record exists in the current transaction
before using it. It reduce a little bit the performance of the cron
but avoiding the crashes is at this price.
Discussion
----------
This commit does not remove completely the risk of crash
due to concurrent update but reduce its probability a lot.
To remove the risk of crash, a proper exception management should be
implement in a further commit
closesodoo/odoo#74166
X-original-commit: 4a70f7539ec53b9c3419f83d584ad99111d2e172
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Requires markup every markup-using tip content as Markup. Would be a
nice occasion to migrate everything to a markup-safe markdown I think,
especially if we could migrate the translations so we don't lose them.
Use correct label. This link leads to opportunities, not to "Favorites"
whatever that means.
closesodoo/odoo#60036
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, activity view does not support many2one_avatar_user widget due to
which clicking on image do not open chat window, with this commit, we add
support of many2one_avatar_user widget in activity_view so that user can click
on avatar image and open chat window.
task-2554466
closesodoo/odoo#71804
Related: odoo/enterprise#18803
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Taking advantage of the new action_opportunity_forecast for crm leads to
create a dedicated ir_actions.xml file to store all server/client actions.
Task-ID: 2243913
PR odoo/odoo#69380
Add a new submenu "Forecast" in "Reporting" for CRM
The Forecast shows 4 views:
1. Kanban
2. Graph
3. Pivot
4. List
Objective
Shows the short term forecast for opportunities (crm_lead) based on their
expected closing (date_deadline) and have an overview of the prorated
revenues for each period (defaults to month).
Implementation
1. Kanban
- the progressbar is using the prorated_revenue
- the forecast_field is date_deadline
- the default groupby is date_deadline
2.3. Graph, Pivot
- the measure defaults to the prorated_revenue
- the row defaults to date_deadline
4. List
- shows the prorated_revenue
The special filter "Forecast" is defined to be used by the
forecastModelExtension (JS). (define the forecast_filter context key)
The forecast_field context key is defined in the action to be used by the
forecastModelExtension and the forecastService (JS).
The demo data for opportunities is updated to spread date_deadline over 4 months
Enable drag&drop and quickCreate features for the kanban view with the use of
the allow_group_range_value <field> xml attribute
Add a "Won" flag for the forecast view to better distinguish opportunities that
need to be worked on
Test tour
Task-ID: 2243913
PR odoo/odoo#69380
ENT PR odoo/enterprise#18547
* Currently located in CRM as it is its only use. After Owl-ification of Web
Client it will probably be added as a core feature.
* Objectives:
- Kanban view:
- Kanban groups on a specific date/time field should be contiguous and show
a short term vision. Empty groups should be shown
-> FillTemporalService
-> ForecastKanbanModel
-> context.forecast_field
- Add the next period (i.e. month) with one click in the kanban view
-> ForecastKanbanRenderer
-> ForecastKanbanController
-> ForecastColumnQuickCreate
- Store specific time ranges for each granularity (year, month, ...), so
that when the user switches back to one his progress will be recovered.
(reset on page refresh)
-> FillTemporalService
- Graph, Kanban, List, Pivot views:
- Filter out data from the past (previous periods), while keeping every
records from the current period even if we are in the middle of it
-> ForecastModelExtension
-> context.forecast_filter
-> context.forecast_field
* context key `forecast_field`:
- Used to set the date/time field name, on which the forecast logic should be
applied
- This key will be used by :
a js model (for a view) / ForecastModelExtension / FillTemporalService
* ForecastModelExtension and context key `forecast_filter`:
This extension will use a filter, the groupBy value, and the
context.forecast_field to apply a custom domain constraint.
This domain constraint can also be applied by default with the
FillTemporalService, but it was decided to extract it to a filter for the user
to be able to disable it, to see "old forgotten records" and update them if
necessary. In other words, this filter enables or disables the first bound of
the domain for the read group.
- Filter "Forecast":
This filter should set the context key `forecast_filter:1`, in order
to only get future records starting from the start of the period
containing "now".
example:
now: 2021-04-26
groupBy: month
=> all records starting from 2021-04-01 match the filter
- If none of the groupBy values are the forecast_field, filters the records
on the forecast_field starting from "now"
* FillTemporalService:
This service will be used to generate or recover `FillTemporalPeriod`.
Depending on the configuration, it will return an instance handling a
certain `forecast_field`, with a certain `granularity` (hour, day, week,
month, quarter, year), for a certain `modelName`. This can be used in
multiple views to always get the same object, if it concerns the same model,
the same field and the same granularity.
The generated `FillTemporalPeriod` object is used to compute the final domain
and context to be provided to the backend `read_group`.
The objective was to limit the amount of desired groups regarding a specific
time period (cycle). Here are the cycles depending on the granularity:
granularity - cycle
-------------------------------
hour - one day
day - one week
week - one week
month - one year
quarter - one year
year - one year
In order to get a minimal amount of groups after a read_group, we can provide
an integer in the configuration : `min_groups`, which will guarantee this
amount of groups, regardless of the rest of the configuration
The default maximum amount of groups returned depends on the end of the
specific cycle reached after guaranteeing `min_groups`
We can always alter the result by directly modifying the `start` and `end`
properties of the `FillTemporalPeriod`, using the dedicated methods to do so.
Configuration of the domain with the keys `force[Start|End]Bound`
- true: applies a lower|upper bound for the domain, which means that
the subsequent read_group will search for groups [from the
start|until the end] of the FillTemporalPeriod
- false: no domain constraint applied, which means that at least every
groups with records in the database will be returned
Configuration of the context with the keys `forceFilling[From|To]`
- true: set fill_temporal.fill_[from|to], which means that at least
every groups [from the start|until the end] of the
`FillTemporalPeriod` will be returned as contiguous groups
by a read_group
- false: does not set fill_temporal.fill_[from|to], which means that
read_group will only return groups from|until the first|last
one with at least one record
The `expand` method can be used to add one interval to the end of the
`FillTemporalPeriod` depending on the granularity (add one group)
* any "forecast" view :
- should define a `forecast_field` in the context
- should use the `forecast_model_extension` with the searchModel to be able to
filter "future" records correctly
- could make use of the `FillTemporalService` to maintain a consistent domain
and context when grouping by the desired date field. The domain and
context are to be applied on __load and __reload calls in the MODEL, on the
provided domain and context, to further filter the groups returned by a
read_group.
* forecast views: graph, kanban, list, pivot
* kanban
uses: forecast_model_extension, fill_temporal_service
has a custom `column_quick_create` limited to the forecast_field which
allows to add the next group (period depends on granularity)
works with the sample_server even thought the domain and the context are
modified during the __load/__reload processes.
* graph, pivot, list
use: forecast_model_extension
Task-ID: 2243913
PR odoo/odoo#69380
PURPOSE
Purpose is to avoid loosing frequencies and also avoid rebuilding the whole
frequency table. We choose to merge frequencies from team about to be unlinked
with "no team" frequencies.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case
LINKS
Task ID-2507750
COM PR odoo#70645
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
Next to the addition of a generic field adding a compute to find
my next activity deadline there is no need to keep a custom field
on crm.lead model.
Task ID-2438822
COM PR odoo/odoo#72219
Related: odoo/upgrade#2566
Related: odoo/enterprise#19044
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, suppose we have a scenario like below
Task-A:
Activity-1:
name: Email ( Today )
Assigned to: User-1
Task-B:
Activity-1:
name: Email ( Today )
assigned to: User-2
Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
When User-1 goes through the systray 'Today' filter shortcut he gets both
Task-A and Task-B in the list instead of only Task-A. Indeed currently
activities are not filtered based on current user with its deadlines.
However purpose of systray is to indicate activities current user has to
perform instead of global activities.
After this commit activities will be filtered based on deadlines as well as the
current user. In order to achieve this behavior we needed to pass a domain like
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that purpose we introduced a non-stored compute field with a search
method.
Task ID-2438822
COM PR odoo/odoo#72219
X-original-commit: f4eaf4d8fb2f97240201104dcd4fc7e2674bce02
Bug
===
1. Create a new database from the database selector
2. Do not select a country for your company
3. Install CRM
4. Create a new opportunity and select your company
5. The sync "warning" will be displayed, and it should not
The reason for that is the phone of the company is an empty string and the
phone of the lead is False. So we try to sync them and we show the warning
message even if for the user, nothing will happen.
This commit fixes that behavior by correctly checking that False / empty
strings are considered as equal.
UPDATE
In this commit we also display warnings about update only in edit mode to
avoid displaying irrelevant information to the user. Indeed email and phone
will be propagated at save, aka in edit mode.
TaskID-2499659
closesodoo/odoo#72286
X-original-commit: efea8fce6c7cb6e40b590cd827fe22e134cc3d13
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
-----
When a lead with an automated probability is merged with other leads and
if its probability is 0, it will be considered as null value and will be
erased by the value of the next lead with a probability > 0
The final lead gets a probability != automated_probability and is now
considered is_automated_probability = False. Therefore automated probability
computation will not be triggered anymore.
Expected behavior
-----------------
Possible use cases
* if the probability is auto on the master keep the auto probability;
* if the probability is manual on the master keep that manual value even if
it is 0 as sales people know their pipe and gave an accurate probability;
In other words: never take the probability from the merged records and always
keep the master one.
Task-2526926
PR odoo#70270
X-Original-Commit: odoo/odoo@4e14997f92closesodoo/odoo#70270closesodoo/odoo#72073
X-original-commit: 8fa6c154b196ec5bebb37293e70f9009a56e7974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, leads without any team_id set had their automated
proabbility computed based on the subset of all leads without team id.
Unless wrongly configured or strange pipeline use, all leads end up with
a team_id set. Therefore subset of leads without team is not really a
good set used to estimate probability of new leads.
After this commit, a lead with no team_id set yet will have its
automated probability computed based on the entire lead set.
Task-2526926
PR odoo/odoo#70270
X-original-commit: be1a55b305057803a67ec2b016e51325c992586f
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault François <tfr@odoo.com>
