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
closesodoo/odoo#54217
X-original-commit: a3fdff3dd9cc38b432b93a7cd4387cb7c38b8d06
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Some fields are duplicated in the crm.lead for views. Those having
their label manually generated must define a unique id, to be used
by the associated label. That way, all labels are associated with
the correct occurrence of their field.
Part of task 2261697
closesodoo/odoo#53950
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
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
closesodoo/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.
Steps to reproduce:
- install crm
- go to crm > configuration > settings > activate leads
- go to a contact > click the "opportunity" smart button >
create an opportunity > select the newly created opportunity > click
the "meetings" smart button
Previous behavior:
meetings are filtered with 'search_default_opportunity_id' set to active_id.
active_id is referring to the partner_id in this case. this leads to
a cache miss error.
Current behavior:
meetings are filtered by the right opportunity (current id).
opw-2272325
closesodoo/odoo#53013
X-original-commit: b9abc757da3034209b083c4ba862edd3865f7637
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
Purpose
=======
Rename "Follow-up" tab into "Extra Information" in the lead form view
Remove the create option on the language field in the lead form view.
Align vertically the expected revenue with the PLS in the lead form view.
Add the "Planned revenue" label in the quick create form.
Improve the pipeline activities default filter.
Improve the sale team form view.
Task-2277242
closesodoo/odoo#52965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
Improve existing tips to be more inlined with new digest styling.
Add new tips, notably
* use lead enrichment;
* use lead mining;
LINKS
Task ID 2197417
PR odoo/odoo#51619
Co-Authored-By: Elisabeth Dickinson <edi@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
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
- Create a lead and set a language
- Convert to opportunity and choose 'Create a new customer'
The new customer created doesn't have the language of the lead set.
This is more logical to set the same language to the new customer.
opw-2270321
closesodoo/odoo#52376
X-original-commit: 1999c68ff4eb382019c92064d9285411314a39be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Actuin `relate_partner_opportunities` and its window views is not used anymore
in codebase. It can be removed, allowing some cleaning.
closesodoo/odoo#46676
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Get rid of email / phone behavior on lead that is hard to understand: if
and contact is set fields are readonly, if not they are editable.
SPECIFICATIONS
We want to be able to edit them if a partner is set. If we write on the
email/phone of the lead, it should write on the partner (and vice-versa).
Even a Falsy value is propagated to the customer. Reason is that if you update
a contact information, it should be available for all other records. Setting
a void value probably means you want to stop contacting this contact. This is
now also propagated.
SIDE NOTE: MOBILE FIELD
Mobile field is a bit different. Main phone contact field is phone, and is
placed in the main contact section of the lead view. Mobile is under a more
technical / detailled tab and is not completely synchronized with the partner.
Like zip, city or country, changing partner updates lead information but
changing lead values does not propagate those to the customer. Those fields
can be used for deal-specific information if needed.
Statistics: 5k crm.lead use mobile for 80k active records which means it is
a "lesser field".
LINKS
Task ID 2207636
PR odoo/odoo#48395
Upgrade PR odoo/upgrade#1025
Purpose of the task is to remove the needaction message counter from
kanban view due to below reason:
- The user has access to unread messages on records from the discuss
item in the systray.
- It is irrelevant for user handling notifications through their mail
client
- It is only less UI item to worry about on the kanban views (as
features increase, we need to be careful not to clutter the views)
- The user can still use the message_needaction filter to get records
with unread messages
So in this commit we removed the need action counter from all the
kanban view.
closes odoo/odoo#51299
Taskid: 2257624
Closes: #51299
Related: odoo/enterprise#10613
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
Purpose
=======
The following task implemented new widgets/features in the listview for better UI.
https://www.odoo.com/web#id=2195254&action=327&model=project.task&view_type=form&cids=1&menu_id=4720
The goal of the current task is to use those to upgrade our listviews
Specification
=============
Below are change requests on various listviews.
Remove decoration-bf="message_needaction==True" from every listview in every module.
PRODUCT - stock.view_stock_product_template_tree (product template)
remove all decorations from <tree>
set the following decorations on 'virtual_available' and 'qty_available'
decoration-danger="virtual_available<0"
decoration-warning="virtual_available==0"
also set decoration-bf on 'virtual_available'
apply the same modifications on stock.view_stock_product_tree for product variants
SUBSCRIPTION - sale_subscription.sale_subscription_view_list
remove all decorations from <tree>
'stage_id' field
set <field name="stage_id" widget="badge" decoration-info="stage_category == 'draft'" decoration-success="stage_category == 'progress'"/>
'recurring_next_date' field
set <field name="recurring_next_date" string="Next Invoice" widget="remaining_days" attrs="{'invisible': [('stage_category', '!=', 'progress')]}"/>
set decoration-bf on 'code' and 'recurring_total_incl'
move 'percentage_satisfaction' before 'recurring_total_incl'
set widget="many2one_avatar_user" on 'user_id'
add <field name="activity_ids" widget="list_activity"/> after 'user_id'
ELEARNING - website_slides.slide_channel_view_tree
set widget="many2one_avatar_user" on 'user_id'
'enroll' field
set <field name="enroll" widget="badge" decoration-success="enroll == 'public'" decoration-info="enroll == 'invite'" decoration-warning="enroll == 'payment'"/>
POS - point_of_sale.view_pos_order_tree
remove all decorations from <tree>
'state' field
make visible and move it at the end of the view
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state not in ('draft','cancel')"/>
set decoration-bf on 'name'
APPRAISAL - hr_appraisal.view_hr_appraisal_tree
'state' field
set <field name="state" widget="badge" decoration-info="state in ('new','pending')" decoration-success="state == 'done'"/>
'date_close' field
set <field name="date_close" widget="remaining_days" attrs="{'invisible': ['|',('state','=','done'),('state','=','cancel')]}"/>
PAYMENT - account.view_account_payment_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state == 'posted'"/>
move 'company_id' before 'amount'
CONTRACT - hr_contract.hr_contract_view_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state == 'close'" decoration-success="state == 'open'"/>
set widget="many2one_avatar_employee" on 'employee_id'
PAYSLIPS - hr_payroll.view_hr_payslip_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state == 'verify'" decoration-success="state in ('done','paid')"/>
set decoration-bf on 'number' and 'net_wage'
move 'company_id' before 'basic_wage'
set widget="many2one_avatar_employee" on 'employee_id'
SURVEY - survey.survey_tree
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state == 'open'"/>
APPLICATION - hr_recruitment.crm_case_tree_view_job
set widget="date' on 'create_date'
set widget="priority' on 'priority'
set widget="many2one_avatar_user" on 'user_id'
TIME OFF - hr_holidays.hr_leave_view_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state in ('confirm','validate1')" decoration-success="state == 'validate'"/>
apply the same changes in hr_holidays.hr_leave_allocation_view_tree
closesodoo/odoo#51305
Taskid: 2256589
Related: odoo/enterprise#10614
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Update Lead Probability CRON is currently running in a single transaction
and is locking lead table for too long.
This task aim to improve the performance of the cron by:
- reducing the number of update (instead of updating one by one the leads,
update all lead with same value to update)
- Making it multi-transactional (to avoid locking table during
the whole process)
Spec
====
- compute probability and automated probability values with only 2 decimals
(needed to compare new and old probability + to avoid too many values
in the group by probability)
- Group the leads to update by Probability value (rounded by 2 decimals)
Note : This commit doesn't change the field definition to avoid migration.
- Update leads by batch of limited number (=step), to avoid transaction to take
too long. After each batch execution, commit to unlock the table before
continuing with next batch.
Task ID: 2224677
closesodoo/odoo#51310
X-original-commit: ee346936efc6cabce14cb73223ecd2e6a0cc1e3f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-Configure alias on sales team;
-Send email, opportunity is created for sales team;
-Enable leads on CRM settings and enable leads for sales team;
-Send email to alias, lead is created for sales team;
-Disable leads in CRM settings;
-Send email to sales team alias;
Before this commit a lead is created even those these have been disabled
in CRM settings and you cannot access this menu anymore.
Now, an opportunity is created for sales team.
opw-2244379
closesodoo/odoo#50943
X-original-commit: 3e9f07e8fe2f31b66087db4b0fc274df2e6253c8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit displays the currency of the `Expected Revenue` field of
lead in the list view.
Known drawback : the sum is not correct if multiple currencies are involved.
Task-ID 2238661
Closes#49954
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Editable stored fields are copy by default if their base field
allow it (char, integer, ...). Purpose of this commit is to remove
unnecessary copy=True statements added when using stored editable
fields.
PR #49464
Task 2225253
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose of task is to update the 'user/employee avatar' to the new
widget in all the kanban view across all modules.
The below new widget are introduced for avatar:
- many2one_avatar_user (for user_id fields)
- many2one_avatar_employee (for employee_id fields)
which displays the avatar (i.e. picture) of a user/employee in front
of his name and clicking on the avatar will open a chatbox to message
that specific user/employee.
So in this commit, For each kanban view with a user or employee avatar,
replaced it by the field with the new 'many2one_avatar' widget.
TaskID: 2244928
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10420
closes odoo/odoo#50789
Closes: #50789
Related: odoo/enterprise#10420
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Step to reproduce:
- Go to CRM app
- Create a new opportunity and edit it
- Alter the website field under "Contact Information" tab
with "www.anywebsite.com"
- Save and click on the website field value.
Without this fix, the field redirect as it's local:
"http://www.myodoo.com/www.anywebsite.com"
porting 726fad8
opw-2247853
closesodoo/odoo#50942
X-original-commit: 072400ad12ea17438a0175d94eb887f51172e461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Use the new Many2OneAvatarUser field widget in some kanban views,
which allows to open a DM chat window with the corresponding user
by clicking on the avatar.
Part of task 2195254
Step to reproduce : Import from Excel a list of Opportunities.
The problem is that in _compute_day_open, the abs of the extraction
date_open - create_date is set as the lead's day_open.
As the date_open has no milliseconds, all those records which
create date is the same second have a date_open that is before their create_date.
Fixed it by comparing the date_create and date_open without microsecond.
Task ID 2222251
closesodoo/odoo#50599
X-original-commit: f7d1277080a91903342bbb4be44ce3a6ca814a38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this commit is to allow customization of view types available when
using the activity menu. By default only kanban, list and form are available
as before.
Calendar, pivot, graph and activity have been added for leads, allowing
better user experience in their use of activities.
Task ID: 2228451
Community PR odoo/odoo#50042
Enterprise PR odoo/enterprise#10145
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the crm.lead form view to always display UTM information when
the lead is of type "opportunity".
Before this change, the UTM information (as well as the 'referred' field) were
only displayed for members of the 'base.group_multi_company', which did not
make sense on a functional point of view.
The 'company_id' field however, that is in the same form group, is still
correctly displayed only for members of the 'base.group_multi_company' group.
Task 2237318
closesodoo/odoo#50337
X-original-commit: d5b07b7c16cf7129f3231985ef607f02fb0c6475
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Impacted modules: account_analytic_default, crm, event,
hr_recruitment, maintenance, mass_mailing, project,
purchase_requisition, stock_picking_batch, website_slides
The default image displayed when the record is unassigned is
confusing, so we are removing it.
FP request
Task 2234524
closesodoo/odoo#49333
Related: odoo/enterprise#9834
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit will put more emphasis on both the revenue and the contact
attached to the opportunity.
Task ID 2240258
closesodoo/odoo#49773
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements.
Purpose is to improve lead_count performance. Some people claim to gain a lot
of queries: from 90 to 30 SQL queries to read 39 partners. Hard to reproduce.
LINKS
Task ID 2196182
PR odoo/odoo#44662
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Or, in other words, set auto probability to 0 if no statistics yet.
Before this commit, if the automated probability could not be computed,
the automated_probability field on crm.lead was not modified.
That led to having leads stuck at 100% once won, even if going back to another
stage.
This happened only :
- in an empty DB (no demo data) or
- in a DB where the PLS cron had never ran and the PLS threshold was
inactivated (=0).
Because, if the frequency table has never been built, we cannot compute the
automated probability.
After this commit, if the automated probability cannot be computed, we set
it by default to 0. If the probability and the automated probability was
aligned, probability is also set to 0.
Note: this could be an issue if both probabilities were aligned, then
someone deactivate the PLS cron and set the threshold to 0 (if not yet the
case), and clear the frequency table. (unlikely to happen but still..)
When updating updating a lead, we would lose the probability
-> auto proba set to 0 + proba set to 0 as they were aligned.
Task ID: 2232036
closesodoo/odoo#49766
X-original-commit: b43ecf73958273a126135966422112b90f9f12cc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to clean manual alias creation by correctly giving
field values instead of relying on magic from model_name to model_id. Code
is more understandable now.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Prepare enhancements of sales team membership.
SPECIFICATIONS
Purpose of this commit is to prepare modifications in sales team management
notably by cleaning sales team tests. We also move some data preparation in
sales team. It allows to rely on some common data while doing sales team
then crm tests.
LINKS
Task ID 2086889 (sales team enhancements)
Task ID 2234698 (preparation lint)
Community PR odoo/odoo#49520
PURPOSE
Prepare enhancements of sales team membership.
SPECIFICATIONS
Lint crm data and demo, notably about sales team and file organization.
Also move crm menu entries declaration in a single file and remove some
menu entries not imported anymore.
LINKS
Task ID 2086889 (sales team enhancements)
Task ID 2234698 (preparation lint)
Community PR odoo/odoo#49520
Some fields of a calendar event are private.
The previous implementation was deleted while refactoring recurring events.
This commit cleanly re-implements the feature.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
When `_synchronize_alias` was introduced into crm.team.write, the write
method become incompatible with batch writes because
`_synchronize_alias` assumes `self` is a recordset of length 1 and
performs attribute accesses directly on self, this makes the __get__
crash because it performs a `self.ensure_one()`
With this commit, crm.team.write will iterate over the self recordset
and call `_synchronize_alias` on every record of the recordset.
This also solves a uninstallation problem in sale_crm because a write is
performed on crm.team in an uninstall_hook.
closesodoo/odoo#49088
X-original-commit: a9511cd42be365e58371d717b8197aac644eaf33
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Purpose of this commit is to make use of toggle_active to implement business
behavior linked to active field being changed. In CRM notably
* when archiving: it is considered as lost, and therefore probability is
set to 0;
* when reactivating: void the lost reason and update probabilities for PLS;
In this commit we also update tracking subtype to more clearly track
lost / restored subtypes
* lost: writing a lost reason (resetting it is not lost), archiving
it if no other subtype;
* restored: activating it again;
Task ID 2170708
Community PR odoo/odoo#46563
activity_type_id is a related field on the first activity to do and should
probably not be reset / forced to a value. It is probably some code coming
from previous implementations of activities that were linked to crm only.
Coming notably from 87e457158e and 42226de46e .
Community PR odoo/odoo#48946closesodoo/odoo#48960
X-original-commit: de2e682824a636062fbb2c47b1bf5d7c7cef18db
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently there is two ways in view to have a phone number displayed in
LTR in a RTL language:
- have `widget="phone"` on a field
- have a class o_force_ltr on the field
But this is currently done very rarely and fail in list view because the
direction of data cells is used, eg.:
```
<div style="direction:rtl">
<table><tr><td style="direction:ltr">
<span>+1 2 3</span>
</td></tr><tr><td>
<span style="direction:ltr">+4 5 6</span>
</td>/tr></table>
</div>
```
will be displayed as:
+1 2 3
6 5 4+
In this commit, we use unicode-bidi* to optionally add an additional
level of embedding so direction is taken into account by the
bidirectional algorithm.
This commit also adds o_force_ltr class or phone widget on phone fields
where it is not already defined.
*: https://drafts.csswg.org/css-writing-modes-3/#propdef-unicode-bidi
opw-2224828
closes#48425closesodoo/odoo#48588
X-original-commit: ab067218e069f0a92610c3f0d4137e563e47755c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
Andrea Grazioso (agr-odoo)