* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
With commit[1], we introduced a feature that from the sales team, we can
see the overdue opportunities for a particual teams. However, the filter
that we use for related action which is supposed to show overdue opportunities
is not not added, and the filtration is not working as expected, showing us
all the opportunites for a team.
This commit fixes the issue by adding the invisible filter with proper
domain set within opportunities' search view and thus enables us to
filter overdue opportunites.
commit[1] - https://github.com/odoo/odoo/commit/1da63f0ab0fb4212bee46f960c6bbe8ca9251cac
TaskID : 2323612
closesodoo/odoo#65258
X-original-commit: 68577d32c7fe0cb18ba4fb788cee65ec8b54b65b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and clean
SPECIFICATIONS
Set _check_company_auto on lead model to enable automatic company check when
updating company_id field.
Add a company check on user_id field to ensure user and lead company match.
Also add a company check on team_id to ensure team and lead company match.
Add a dynamic domain to be used in form view to limit available users to set
on leads to those matching domain.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
Some of the feature of the "My Activities" list view of the crm app were not
available on the regular crm tree view.
This commit aligns the 2 views by sharing these features, notably:
- You can "snooze" your next activity if there is one
- You can contact the lead by email with a direct button on the row/list header
- You can contact the lead by sms with a direct button on the row/list header
The "team_id" column is now optional="hide" since not required most of the time
when you go to check your own leads (and can be activated in a few clicks if
needed).
Finally, the "Email" action at the end of the tree row is now in "single" mode
to allow adding contacts on the fly. This implied re-introducing an action that
was recently removed in 8c65d7c5f7
Further demonstrating that R&D is just an eternal loop.
UPG PR odoo/upgrade#2064
Task-2390500
closesodoo/odoo#62289
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of the task, is to prevent users from inadvertently
creation/opening countries from country_id fields.
Countries should be managed from their dedicated menu item.
so in this commit, we have set both no_open and no_create to True
so user should not update and create a country from the many2X fields.
closesodoo/odoo#63773
Taskid: 2241677
Related: odoo/enterprise#15464
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds few missing default values for some of the partner
fields while we create partner on the fly with quick create kanban
card of lead. Below are the fields that we added
* name
* is_company
* company_name
* phone
* email
Task ID-2409462
closesodoo/odoo#63622
X-original-commit: 5b3290b0869e3954ff1606ad0ca0a35cfd948698
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Crm holds a blank template that adds no real value. Its purpose was to
give a base for salesmen to perform a mass mailing on leads. Using a template
and its action menu entry it was possible to launch a mail composer in
mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Purpose
=======
Make the "activity_state" searchable on the "mail.activity" mixin.
This field is not stored as it depends on the current time.
Technical
=========
To make the search, we perform a SQL query.
The "activity_state" depends on the state of each activities on the
record. And this state also depends on the timezone of the user of
the activity. That's what made things tricky and we need to make the
conversion in SQL for performance purpose (we can not fetch all records
and compute them in python).
There's a special case, where there's less than 24 hours between the
deadline and the current time but one day of difference. In that case
the state should be "planned" and not "today". This case is handle by
the function "DATE_TRUNC" (e.g. 23h 01/01/2020 & 1h 02/02/2020).
Also for performance purpose, we compute the delay only once and we use
the function "SIGN" so we can use a switch/case instead of duplicating
3 times the expressions.
Task 2354754
closesodoo/odoo#60074
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, in multiple modules, long names would result in an overflow of text.
With this commit long texts should appear like this: [aaaaa...] instead of
going out of their boxes.
Various views are updated, depending on which fields we wanted to prevent
from overflowing and the probability they do so.
Task ID-2325219
PR odoo/odoo#57713
PR odoo/enterprise#13226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The 'Mark as lost' server action raises an AccessError when executed by
a non administrator.
Due to de4213b771
opw-2371490
closesodoo/odoo#60866
X-original-commit: b80e44bac5de3ccffad42917307bb5f049a7bec6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit improves the salesperson(user_id) field with many2one_avatar_user
widget that will display avatar before user name.
Task Id : 2302572
PR #565013closesodoo/odoo#58781
X-original-commit: ec05118e85d7e3d4611c5688f3c4a572c86d0afa
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: D J <dja@odoo.com>
Fix the redundancy of "Send email" menu on the crm.lead model. We now correctly
have a form action in comment mode, and a list action in mass mail mode.
We also update the use of those actions according to the business flow: form
based from a single record, mass mail from a batch of records.
Task ID-2310462
Somehow forward-port of X-Original-Commit: odoo/odoo@9ded57d87fclosesodoo/odoo#58774
X-original-commit: ad7d28ab1abe484102cd3ec18ee6ce9c9ac7b5bb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Get rid of the cron.
Always have an up to date frequency table to compute lead probability.
Clean PLS code and ensure to remove unnecessary code
Specifications
==============
Disable the cron:
- Increment won and lost count for lead PLS params from frequency table at
each won/lost
- The complete set of leads won't be recomputed anymore every day
- A lead probability will only be recomputed if one of the PLS parameter will
be modified (stage_id, team_id + the ones checked in settings)
- No more onboarding phase : as frequency table is always up to date and only
the modified leads are recomputed, we can drop this. (So even on onboarding,
winning or losing a lead won't impact other leads, except the ones we modify
manually afterwards)
- Add an button to force the recompute of all the lead probabilities
(kind of reset) in the settings.
The cron has been disabled by default.
Users can know choose to reactivate it if they want to continue updating their
lead probabilities on a daily basis.
Code have been reorganised for better structure and understanding.
Some code parts have been factorised to be usable in both Live Increment and
Full Rebuild mode.
In this commit, we also update probabilities using only computes
Before this commit, _update_probability was called during write and create,
to ensure both probability and automated_probability were correct. That was
necessary because of onchanges and readonly field (automated_probability
was not given to the write method while saving after a change on the lead).
After this commit, we use the force_save tag on the readonly field
automated_probability. So we ensure that write always receives the new
automated_probability value and everything can be handled directly by the
compute. Also, we force the lead to start in automated probability mode.
So when creating a new lead, both probability and automated probability are
computed and aligned.
Finally, when winning a lead, we ensure that both probabilities are aligned
(=100), so that if user take the lead back to a previous stage, the
probabilities are correctly recomputed, and the lead will not be stuck to
100%.
Also, this commit applies some fix and minor changes listed here under:
- Ensure to have always positive frequencies
- Fix lost counts for team not set in pls computation
- optimise set_won : write only once per values
Finally, include tag in frequency table even if less than 50 occurences:
Due to refactoring in which we increment frequency table at each won/lost
instead of rebuilding the frequency table each day, the tags are never added
in frequency table.
This is due to the 50 occurence conditions that avoid to create the frequency
if we have less than 50 won or lost for a tag.
After this commit, we include the tag_ids in the frequency table, no matter
the number of occurences. But, during the PLS computation, we skip the tag
frequencies if the number of occurences for this tag is under 50.
This allows to have a complete vision on the tag frequencies, even for
small number of occurences.
Task ID : 2254543
X-original-commit: cd291b79eb2d2df80899867263ec71438ab8fe87
In this commit we set tree view of leads (both as leads and opportunities)
as multi edit enabled. Onchanges has been removed in CRM application. We
can therefore allow multi edit as computed fields work as intended.
Add domain on user_id fields to prevent selecting portal users as Salesperson
or Team leader from list views.
In crm.lead, onchange is only used to get formatted phone numbers when their
values changed or when country_id & company_id updated. This behavior will
only work in form views. It is not blocking so multi edit is not an issue.
Do not allow multi edit on name as it makes no sense.
Specifications: Contact (res.partner): base.view_partner_tree
phone
email
company_id
city
state_id
country_id
category_id
date_review_next
grade_id
user_id (+ add a limitation to not share users)
Specifications: Opportunities (crm.lead) : crm.crm_case_tree_view_oppo
partner_id
email_from
phone
city
state_id
country_id
stage_id
probability
partner_assigned_id
user_id
team_id
planned_revenue
company_id
campaign_id
medium_id
source_id
tag_ids
priority
Specifications: Opportunities (crm.lead) : crm.crm_case_tree_view_leads
contact_name
partner_name
email_from
phone
city
state_id
country_id
partner_assigned_id
user_id
team_id
company_id
probability
campaign_id
medium_id
source_id
tag_ids
priority
Specifications: Sales Teams (crm.team) : crm.team.tree
user_id
company_id
Specifications: Stages (crm.stage) View : crm.crm_stage_tree
is_won
team_id
Task ID-2200674
PR #56378closesodoo/odoo#56533
X-original-commit: 369375a69adc20a92075a89ef9557bf6b46cd605
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Adapt CRM views now that some measures can be set invisible.
SPECIFICATIONS
Adapt the views and implementing the new invisible attribute on some fields.
It allows to hide unnecessary measures.
In this commit we remove some measures in inheriting CRM apps
* crm: do not use color as measure;
* crm_iap_lead_website: do not use reveal_iap_credits as measure;
* website_crm_partner_assign: do not use partner_latitude and partner
longitude as measures;
LINKS
Task ID-2288381
Community PR #54774
Enterprise PR odoo/enterprise#11970
Upgrade PR odoo/upgrade#1519
This commit simply removes the default filter on the calendar.events when
clicking on the crm.lead stat button to access "Meetings".
The filtering was not handy because the user could not easily see when a slot
was available to schedule a new meeting.
The events that are related to that crm.lead are highlighted anyway (current
behavior), which should be sufficiently clear.
Task ID 2289295
closesodoo/odoo#55050
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To trigger a run of a server action, one must have a group specified
or a write access on the model.
CRM: only access lead, crm.team is readable by employees
Website: all users can access, action_dashboard_redirect takes care of the group
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 #2314894closesodoo/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#54194odoo/enterprise#12423odoo/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#54194odoo/enterprise#12423odoo/upgrade#1463
Purpose: Redirect to lead activity view when clicking
on activity systray for leads. The idea is to give the
user a quick overview of his "To Do List" activities.
Specification: The path from the systray (opportunity/leads)
should redirect to the view with the buttons instead of the
one from the pipeline.
On top of the existing filters/domain, it adds the time-based
filter : Today, Late, Future Activities, ...
Task ID-2281254
Community PR odoo#55383
closesodoo/odoo#55413
X-original-commit: 0cee7f48ce44cea6aa31fcace40206eaed5315ca
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: All action buttons were the same color.
Solution: Make the snooze button more visible by giving-it
a warning color
Closes Task#2295872
closesodoo/odoo#54508
X-original-commit: d4b7f8b44c8d0d5b07a85cd52ee1648f9068f7b2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
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
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 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>
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>
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>
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
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
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
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>
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
Michael Mattiello (mcm)