When we go to the simple user view, no need to show "Create Employee"
option unless we are inviting a new user. Also, to standardize the
behavior, we remove the context that conditionally used to hide the option.
Moreover, we add smartbutton leading to the related employees' view to the
simple user form view.
task-3334739
closesodoo/odoo#122870
Related: odoo/enterprise#41646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Draw attention to the monthly assigned lead count when
it is exceeding the limit by changing the text color
to orange.
Task-3204763
Part-of: odoo/odoo#115326
*: sale,sales_team
Improve UI of the CRM app:
- Add placeholders and underline m2o fields in the CRM quick create
- In the lead generation form, underline the industries field, add
the avatar widget on the user_id field, add the color attributes on
the tag field, add a placeholder for the states field and set a
longer selection field to avoid the caret from overlapping the content.
- In the opportunity form, align the expected revenue and probability
headers, set a longer width for the expected revenue field,
change the recurring plan placeholder.
- In the contact opportunities page, change the "Open Opportunities"
filter to exclude lost opportunities.
- In the Sales team page, add a groupby on the company_id.
- In the Sales team form, change the assigned lead count to be
a muted text, the pipeline checkbox should be visible only when leads
has been activated, the quotations/pipeline/leads options should be
aligned.
- In the lost lead modal, change the title from "Lost Reason"
to "Lost Lead" and the validate button from "Submit" to
"Mark as lost".
- In the Sales team member form, align the fields on the left and hide
the Create Employee field as it should not be displayed there because
this is not an hr module.
- In the lead analysis tree view, add the lost reason field with optional
hide.
- Align the enrichment company not found message to the left of the chatter.
- Update the crm iap lead role "Search More" list to display human
readable names instead of the technical names.
Task-3204763
Part-of: odoo/odoo#115326
Steps to reproduce:
- Install Sales.
- Go to any quotation and toggle mobile device mode in the browser.
- Go to Other Info > click in Sales Team field.
Issue:
We stop supporting the 'kanban_view_ref' in newer versions of odoo. So
we won't be able to get proper view.
Solution:
Changed the way we ref the kanban view to use context to get the
referenced kanban view.
Related to #39499
opw-3152174
closesodoo/odoo#116031
Related: odoo/enterprise#39499
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the `res.partner` form:
- the field `user_id` is set in base,
and is directly within the base res.partner.form form view,
within the `Sales & Purchase` notebook page
(which is in the base module despite what the tab name could make think)
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/odoo/addons/base/views/res_partner_views.xml#L343
- the field `team_id` is set in the module `sales_team`, and added
in the res.partner.form form view from this `sales_team` module
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/addons/sales_team/views/res_partner_views.xml#L9
Therefore, there isn't any obvious reason why the context `default_`
keys for `user_id` and `team_id` are set
only once the `crm` module installed,
neither why it only applies if you are a salesperson
(to the group `sales_team.group_sale_salesman`, sets in the view
`groups_id`).
If we have a look to the commit
f0b7600314
The goal described in the commit description is still achieved
by moving these default context keys in their respective module.
Besides, having a closer look in this commit,
`default_user_id` is directly added in the simplified partner form
within the base module, but is added through the crm module
for the regular form. Which doesn't make really sense.
Part-of: odoo/odoo#98551
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Currently no chatter is added on team member form views. Indeed this model is
mainly technical and accessed through a dedicated menu in configuration.
However some fields are tracked and being able to see tracking information is
important in day to day dealing of team members. This is why we add chatter
on team members form view.
We also add context key to avoid autofollow when creating team members. As
chatter is mainly present for tracking and information no need to add extra
followers automatically. This causes unnecessary notifications.
Task-2679897
closesodoo/odoo#79356
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- 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
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>
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Before commit:
In the sales_team -> search view of team members, if we try to seach
by name of a team member(sales person), the result do not match with
the search string, because it tries to search using `name` field which
is a non-stored related field.
After commit:
Instead of `name` field, we search the team member(sales person) using
`user_id` field, giving the expected result.
TaskID-2460697
closesodoo/odoo#66989
X-original-commit: c38584f6e89a8e94288d90f1e004038927fd6de2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* 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
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 cleaned.
SPECIFICATIONS
Make final integration of members management by taking into consideration
both multi-membership and automatic lead assignment features.
Correctly hide assignment options and fields if auto assign is not activated.
This means that
* when being in mono membership mode without automatic assign: display
users on team form view;
* when being in multi membership mode or with automatic assign: display
members o2m records, as configuration is done on this model;
* hide the whole right column in sales team form view about assignment when
assignment is not activated in settings;
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
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 cleaned.
SPECIFICATIONS
Move sales team automatic lead assignment from website_crm_score (enterprise)
directly into sales_team. Some cleaning and renaming is performed while moving
the code as it is old fashioned.
Scoring feature is removed completely from lead assignment. Indeed we consider
PLS is a better feature and provides more accurate results.
Minimal scoring specific field on team is removed. Indeed it can also be
integrated directly into domains linked to a sales team as this is a field
directly available on lead using ``probability``. It allows to reduce fields
of team model and move all logic in the team's domain itself.
Overall behavior as been kept as close as possible from the original one.
Purpose is to avoid too much undesired changes between versions.
In this commit we also add tests for automatic lead assignment.
ASSIGNMENT PROCESS DESCRIPTION
1- LEAD TO TEAM ALLOCATION
Allocate leads to teams given by self. This method sets ``team_id`` field
on lead records that are unassigned (no team and no responsible). No
salesperson is assigned in this process. Its purpose is simply to allocate
leads within teams.
Heuristic of this method is the following:
* first we randomize all teams;
* then for each team
* find unassigned leads, aka leads being
* without team, without user -> not assigned;
* not in a won stage, and not having False/0 (lost) or 100 (won)
probability) -> live leads;
* if set, a delay after creation can be applied (see BUNDLE_HOURS_DELAY)
parameter explanations here below;
* keep only leads matching the team's assignment domain (empty means
everything);
* assign maximum BUNDLE_SIZE leads to the team, then move to the next team.
This is done to ensure every team will have leads enough to fill its
capacity based on its domain;
* when setting a team on leads, leads belonging to the current batch
are also merged. Purpose is to clean database and avoid assigning
duplicates to same or different teams;
* for all teams that still have capacity (aka: a search on unassigned
available leads with team domain still give results), do another
assignment round. Each round teams are randomized so that team order
is not always the same;
Note that leads are assigned in batch meaning a team could receive leads that
could better fit another team. However this heuristics is based on hypothesis
that team domains do not overlap. Indeed if a company has several teams they
will probably target separate market segments: country-based, customer type or
size, ... Having several teams using same assignment domain could lead to less
fairness in assignment process but this should not be the target use case of this
heuristic.
Leads are allocated by batch. This can be configured using a config parameter.
Batch size depends on cron frequency, lead pipeline size and members assignment
maximum. Finding an optimal heuristic for this parameter is not easy as it
depends on internal processes and organization. Higher batch size leads to
better performances when running automatic assignment. It can also give unfair
results if teams domain overlap or if pipeline is not big enough to fill all
teams capacity.
2- LEAD TO MEMBER ASSIGN
Main processing method to assign leads to sales team members. It also converts
them into opportunities. Its main purpose is therefore to distribute team
workload on its members based on their capacity.
Preparation
* prepare lead domain for each member. It is done using a logical AND with
team's domain and member's domain. Member domains further restricts team
domain;
* prepare a set of available leads for each member by searching for leads
matching domain with a sufficient limit to ensure all members will receive
leads;
* prepare a weighted population sample. Population are members that should
receive leads. Initial weight is the number of leads to assign to that
specific member. This is minimum value between
* remaining this month: assignment_max - number of lead already assigned
this month;
* days-based assignment: assignment_max with a ratio based on ``work_days``
* e.g. Michel Poilvache (max: 30 - currently assigned: 15) limit
for 2 work days: min(30-15, 30/15) -> 2 leads assigned
* e.g. Michel Tartopoil (max: 30 - currently assigned: 26) limit
for 10 work days: min(30-26, 30/3) -> 4 leads assigned
Assign process then follows the following heuristic
* take a weighted random choice in population;
* find first available (not yet assigned) lead in its lead set;
* if found:
* convert it into an opportunity and assign member as salesperson;
* lessen member's weight so that other members have an higher
probability of being picked up next;
* if not found: consider this member is out of assignment process,
remove it from population so that it is not picked up anymore;
Assignment is performed one lead at a time for fairness purpose. Indeed members
may have overlapping domains within a given team. To ensure some fairness in
process once a member receives a lead, a new choice is performed with updated
weights. This is not optimal from performance point of view but increases
probability leads are correctly distributed within the team.
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
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 cleaned.
SPECIFICATIONS: COMPANY-BASED DOMAINS
Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.
When using mono membership mode
* members are res.users records;
* a domain is added on users to belong either to the team company, either
to all available teams if team has no company;
When using multi membership mode
* members are crm.team.member records;
* a domain is added on user_id field of membership records so that they
belong either to the team company, either to all available teams if team
has no company;
Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.
SPECIFCIATIONS: CHECK_COMPANY
``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.
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#9966
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 cleaned.
SPECIFICATIONS
Purpose of this commit is to allow to use either mono salesteam mode, either
multi salesteams mode. Basic CRM use mono membership: a salesperson belongs
to a single sales team. It is however possible to choose to work using multiple
memberships. This is configured through a configuration parameter available in
CRM configuration settings.
Mono salesteam behavior
* a given user can be member of a single sales team at a time;
* when moving an user from team to team, its existing memberships are
archived to keep history of what has been done within this team;
* display an alert when creating a new team member that would archive
existing memberships;
* displayed members on team form view are directly res.users records to
avoid displaying unnecessary layer when using a simple CRM;
Multi salesteam behavior
* a given user can be member of several sales team at a time;
* unicity contraint (user_id, crm_team_id) is still enforced;
* displayed members on team form view are crm.team.member records as
advanced configuration can be done directly at that level;
In all cases when adding a new member check for archived membership before
creating it. If an archived version of the member exists it is unlinked in
order to avoid breaking the unicity constraint.
Archived memberships can be managed in its dedicated menu for advanced sales
team use.
SPECIFICATIONS: SETTINGS VIEW
Move Multi Teams checkbox below Recurring Revenues / Leads checkboxes. On its
right alias configuration should appear if Leads is checked.
PLS take third configuration line. On its right future commits will gradually
add automatic assignment configuration.
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
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 cleaned.
SPECIFICATIONS: MODEL CLEANING
In this commit we improve team member model to make it more usable and
aligned with current Odoo views and usability.
This commit contains notably
* add some related fields on the user: phone, mobile, company, email;
* rename "team_user_domain" to "assignment_domain";
* rename "maximum_user_leads" to "assignment_max";
* improve member views globally;
We also introduce dynamic domain computation for users and teams when seeing
team members. This allows to limit selection of users or teams depending
on already existing configuration. Purpose is to avoid having people trying
to create wrong configuration (duplicates, ...) and receiving error messages.
Also
* clean some data and demo about teams and members;
* fix some views glitches;
* improve views: add some fields in search views, improve wording of
fields or actions, ... globally improve usability and US as well as
feedback given to users;
* group sales team members by team by default as it help getting an
overview of team members distribution;
* update tests to create team members instead of writing directly on m2m
towards users;
SPECIFICATIONS: SALE_TEAM_ID FIELD ON RES.USERS
In this commit we also rewrite sale_team_id field of res.users. Previously in
crm it was simply a many2one field linking to a crm.team. It was used to compute
team membership as a standard many2one / one2many relationship. In enterprise
module ``website_crm_score`` this field was set as a related on first user
teams. Indeed scoring changed relationship between users and teams to a
many2many.
This field is now directly a computed many2one field that links to the
"main" team of the user even in multi memberships mode. As memberships can
now be de-activated we changed this field to a computed stored field. It is
based on oldest active membership of user. That way default team of documents
will be the user's oldest team considered as its "main team".
SPECIFICATIONS: LEAD_ALL_ASSIGNED_MONTH_COUNT
Improve crm_team ``lead_all_assigned_month_count`` field computation. It is
now simply the sum of assigned leads of team members. Differences may
happen if a lead in teamA is assigned to an user working in teamB. This should
not happen if team / user is correctly set at lead level which is generally
the case. However if that happens, old field counted it. New field will not
count it as it is not directly linked to a team's member.
SPECIFICATIONS: DEMO DATA
Make crm.lead demo data coherent with user_id / team_id . As demo data should
be using a mono-membership behavior for users and teams, we have to ensure
user_id and team_id effectively matches. It allows to have coherent reporting
and assignment demo flows.
Also avoid having Odoobot responsible of leads. Instead of undefined user_id
and team_id leading to Odoobot being responsible of some leads, force it
to be False. Those demo data allow to test automatic assignment of lead
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
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 cleaned.
SPECIFICIATIONS
Move sales team membership model from website_crm_score (enterprise) directly
into sales_team. It allows to have the base requirements to correctly handle
mono and multi sales team for salesperson.
Membership is modeled using a decorated many2many relationship. Members of
a sales team are res.users. Subscriptions are crm.team.member linking a team
and an user. It is a rename of team.user model coming from website_crm_score
as well as some other relational fields renaming.
Part of old team.user model is moved directly to sales team, part of it to
crm module (notably assignment limits). Its support will be improved in the
upcoming commits. Assignment related fields will be cleaned and used when
moving assignment directly into CRM.
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#996996
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 cleaned.
SPECIFICATIONS
Rename views according to guidelines in order to better understand what
they are. As there are few views let us take a few minutes naming them
correctly.
Also prepare sales team enhancements and ease migration scripts addition by
bumping version numbers.
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
Behavior prior to the commit:
- when setting the customer (partner) on a sales order, the sales team
is set based on the partner's sales person. If there is no sales person
on the partner then the team defaults to the first team in sequence for
the company.
- the team set on the partner is not used (by default, this field is not
visible, but it can be set from server action or added via studio). In
Odoo 12.0 the team set on the partner was used as a fallback, but this
was removed in commit 242be00429
Behavior after the commit:
- the partner's team is used as fallback when the partner is updated
- when the salesperson is updated on the quote, we also use the current
team as fallback (since presumably this was set either from the partner,
or using the existing default rule, there is no reason to change it)
- in debug mode, the field `team_id` is shown on the partner view (under
the `Sales & Purchases` tab)
Note:
- Change in existing installation is expected to be minimal since it only
affects the customers who are making use of the partner.team_id field, not
populated or displayed by default, but there is a risk for a customer who:
1. has that field populated on existing partners (maybe upgraded from
an old install where it was displayed?)
2. is relying on the new (as of v13.0) behavior of assigning the default
sales team based on the sequence
opw-2351868
closesodoo/odoo#61827
X-original-commit: 7683e1907f6eb1fde4626927957df4eede49b8ca
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.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>
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>
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
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>
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
=========================
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
The color picker help the user to choose a color instead of picking it
by id.
The title and arial-label "no-color" default value are removed from the
picker_preview because they are not accurate. Instead name of currently set
color is used.
Task ID 2128166
closesodoo/odoo#47474
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Prepare enhancements of sales team membership.
SPECIFICATIONS
Linting containing
* reorder fields according to their use;
* order methods according to guidelines (compute, CRUD, actions, tools);
* fix some docstrings and typos;
* remove unused imports and dead code;
* rename files according to guidelines;
* move views in their own file for mail.activity and assets;
* correctly name data and demo files;
* rename some inner methods to ease understanding;
LINKS
Task ID 2086889 (sales team enhancements)
Task ID 2234698 (preparation lint)
Community PR odoo/odoo#49520
As the crm.lead.tags model shall be used in CRM and/or Sales apps,
it has been moved to the sales_team module, which is a depedency
of the CRM and Sales apps.
As these tags becomes more generic than just "lead tags", the model
has been renamed from crm.lead.tags to crm.tags.
Tags on sale orders were already present but not visible. They are
now visible in the "Other Info" section, and optionally in sale order
tree views.
When a quotation is created from an opportunity (CRM app), existing tags
are populated from the opportunity to the sale order (Sales app).
Views and demo data of several modules have been updated accordingly.
Task ID 2191276
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
Next to 883c96b781 and recent ribbon widget update some form views
have to be updated. It is best displayed following those rules
* after oe_button_box in order to fix overlapping;
* before image to overlap it cleanly;
LINKS
Task ID : 2032621
PR : #34662
Task
If we use a kanban view to select a record we want to hide those elements:
dropdown boxes, buttons, anchors, some widgets, kanban color.
When it was too much change and used the new attribute
"kanban_view_ref" to explicitly define which view to open in selection_mode.
When also had to create previously unexisting kanban for
fleet.vehicle.model to show name and brand.
Task ID : 1924779
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
This commit changes the method _get_default_team_id so that it removes
the xmlid reference to the default team. Instead, we will now use
the team sequence (with default team's sequence being set as 1)
and falling back to the next team with the highest sequence if the
default team got deleted.
Therefore, teams will now be ordered by sequence instead of name,
allowing the users to reorder their teams as they see fit
This commit also removes useless sudo when searching teams
Task: #1962182
PR: #32372
wip
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
sofiagvaladze