The user can delete teams created during the installation of the Sale
Team module, both CRM and Sale modify those teams but the way they
modify the teams doesn't take their deletion into account.
This reverts commit 30a848bffb to replace
post_init_hooks by `forcecreate=False` in the datas.
closesodoo/odoo#32742
Signed-off-by: Christophe Simonis <chs@odoo.com>
The user can delete teams created during the installation of the Sale
Team module, both CRM and Sale modify those teams but the way they
modify the teams doesn't take their deletion into account.
opw-1962297
closesodoo/odoo#32412
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
Purpose : Various relabelling and design improvements in crm:
- opportunity, lost reason, lead, team, tag forms
- hide "convert to opportunity" button for inactive/lost
leads (actually nothing happened when clicked anyway)
- Checkbox in crm.team to hide all alias related fields
- New many2one field appearing in crm.team form to select the user to
whom lead created by alias will be assigned.
- Set the admin as leader of the initial crm.team
closesodoo/odoo#28851
Use crm.lead instead of a the crm.opportunity.report object for
reporting. This allows to show more fields (e.g. tags_ids). The only
field not accessible in the report is #activities, but there is a
deicated report dedicated to activities.
Improved the default search. Example: when reporting on leads, you want
leads+opps by creation date (and not only leads) as an opportunity has
been a lead created too.
The new settings model loads by default all settings. In the case of
non-admin user having the 'Settings' access rights this can lead to
access errors.
This commit deals with the multi-company issues on a standard
installation. If the admin is in Company A and the other user in Company
B, accessing the settings is pretty much impossible because of records
rules.
This fixes the master or demo data to avoid setting a company by
default. Note that it only fixes a standard installation: if the
settings are later customized, there is no guarantee that it will still
work.
Problematic fields:
`auth_signup_template_user_id`
`crm_default_team_id`
`leave_timesheet_task_id`
opw-801210
rename values of selection field to actual model names.
this prevents the need of a separate function to get the sql table
and allows to get direct access to the model.
(needed for the next commit)
Currently there are several issues with this configuration box
* default_<field> does not generate automatically ir.values anymore.
Defining default_model does not work since it is not linked to an
existing <field> in current model sale.config.settings. Checkbox
value is therefore not saved and lost at reload;
* box label is not clear as user may understand unchecking it drops
all aliases or email support. This is not the case as it is only used
to define an alias creating unassigned leads. This is a rare use case
where leads assignation is done manually;
* checking / unchecking the 'Emails' box does not have any effect on
default info alias. This is counter-intuitive as user asks to remove
the feature but it still works in background;
This commit fixes those issues by
* correctly setting the checkbox value in an ir.config_parameter so that
it is not lost anymore at reload;
* inactivating info alias by default;
* adding onchanges so that values are reset when unchecking checkboxes;
* updating string and displayed label and helps for the 'Emails' section;
* putting that Emails checkbox in advanced mode as it is a rare use case;
Functional
==========
Sales teams become sales channels. Their dashboard cards now include a graph
displaying customizable data for managers (comparable to those in accounting).
By default, you now have the following sales channels (non-demo):
Direct Sales (with installation of crm or sale)
Sales Channel type: Sales
Works same as before, what's changed is:
- their cards display one big button directing to the start of their
workflow
- the links on the right-hand side have been reworked, and are only
displayed when there is at least one item requiring attention.
- 'More' tab remains unchanged.
Website (with installation of website_sale)
Sales Channel type: Website
Differences lies in the links displayed in the dashboard card:
- it displays abandoned carts, awaiting payments and payments to capture
Default Channel linked to all sales made from the eCommerce.
Point of Sale (with installation of sale and point_of_sale
-> auto-installs pos_sale)
Sales Channel type: Point of Sale
Linked to pos.configs and their pos.sessions and pos.orders.
- only links to their linked pos.config dashboard and open sessions
- can't use opportunities, lead or invoicing and can only display
pos.order data in the graph.
Default Channel linked to the default pos.config.
Technical
=========
- Add a channel type: sales, pos, website that have different actions/settings
- Add a graphs to the kanban cards in the sales/crm dashboard, configurable in
the form view in the new dashboard page.
- Rename sales teams to sales channels, rename and add default and demo sales
channels
- Change dashboard links depending on the channel type and add a related
computed fields on crm.team
- Rename strings and improve channel form view.
- Leads are now checked by default once activated for 'sales' type channels
- Disable checking "leads" without using "opportunities".
- Hide invoicing and invoicing target depending on channel type.
- Move currency_id to sales_team
Christophe Simonis