One of the behavioural divergences between "create or replace" view and
DROP; CREATE turns out to be that "create or replace" can only add
columns *at the end* of the view, and can not change the name or type of
the view during replacement, which can break migrations.
Reinstate the old drop;create as replacement is not necessary for this
specific view.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
- try to make better use of recordsets (and recordset APIs)
- remove pointless decorators
- remove redundant ensure_one
- make 'stage_find' a private method returning a recordset
- etc ...
Author: User who logged the activity in the chatter ----> Created By
Responsible: User assigned on the lead ----> Salesperson
Salesperson filer = Author. --> Same label : Created By
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
The two fields used in the filter Lost were not available on the
crm.activity.report model.
closes#11623
opw-673533
note: in 9.0..saas-10 the filter was removed with 70ba0e9
The two fields used in the filter are not available on the
crm.activity.report model.
It is not possible to do a Lost filter until the fields are added (and
this can only be done in master).
opw-673533
note: should not be forward-ported over saas-10
1/ Add a stat button with history of activities (count of activities) on
the Customer form view
2/ Activity reports: When clicking on the list view, there shouldn't have any
group by (remove the Salesperson/leads group by)
When counting the 'activities' on each opportunity/lead,
this view only considered messages with a subtype that
matched the subtype of a specific crm.activity.
This was not consistent with the crm.opportunity.report
which counted *all* messages on an opportunity as
"activitiy entries".
The latter is considered better because any entry,
(even automated one for tracking field value changes
or automated system responses) corresponds to an "action"
taken on that record.
This patch makes crm.activity.report consistent with
this decision: it will now count all messages.
+ also convert the incorrect `left join` to a plain
[inner] `join`, as we don't want deleted leads to
appear in case orphan messages were left around
(which should not happen anyway).
Using a subselect is more efficient than constructing
a complete temporary table of all messages, and then
joining them. This way only messages or relevant
opportunities are used, as most of the time the
report is accessed for a specific subset of opportunities
(by date, salesman, stage, etc.).
The query planner can then use the dedicated index
to quickly access the corresponding messages.
On a sample database with 1 million crm.lead
entries and 10 million mail.message entries
this brings the time for a typical read_group
call on crm.opportunity.report down from 300s to
500ms (600x faster)
From f255aa7,
the lost semantic is `probability = 0, active = False`
The existing filters "Lost" in the leads/opp search views
have not been updated with this change of semantic.
opw-666186
Stages are now shared by default between sales team. As the sales flow should
be quite the same whatever the sales team, stages are now shared and not
sales team dependant.
The possibility of customizing the flow by adding stages specific to a sales
team still exist. Stages have a team_id field that can be set in the stage
form, in configuration. However this is not the default behavior. A stage
is either common to all sales team, either specific to only one sales team.
This is why there is no team_ids field anymore, only team_id.
Moreover leads do not use stage anymore. A lead is either alive or archived.
The type field on stages is then removed, as all stages are now used in
opportunities only.
A small hack has been introduced in crm_stage default_get. Indeed when going
from the pipeline, creating a stage with a sales team in context should not
create a stage for the current sales team only. Therefore unless specified
in the context, default_team_id is discarded in the default get context.
- Remove _inherit = ['utm.mixin'] on some reports and models. It make no sense
to set campaign_id, source_id or medium_id on reports according to the
cookies.
- Add an inheritS on the source_id in the mass_mailing model. Naturally, the
source_id name is the mass_mailing name.
- The medium is hardcoded as beeing 'Email', which is rather easy to understand
- Remove the 'Tracking' tab on the mass_mailing view.
We do not want to set the medium,campaign or the source automatically
from the cookies on reports, or on mass_mailing creation.
The lost filter wasn't working:
- The domain syntax was not correct
- It tried to filter `active='f'` leads,
while, in the SQL view, they were already filtered out
with `active='t'`
We can safely remove the active=`t` from the SQL view, by default
`active='f'` records are filtered out except if explicitely set
otherwise.
opw-651746
Among various small fixes, some changes :
- correct computation of default sales team, located in sales_team with a
small code cleaning. Rely on this method everywhere it is necessary.
- add a configuration option to enable the use of leads in sales team;
otherwise it is hidden
- better display of alias in empty list help;
- add a menu for next activities, that are the opportunities with an action
whose deadline is near assigned to the current user;
- automatic update of aliases configuration on sales team, based on whether
they use leads and/or opportunities;
- add a wizard to log the lost reasong when deactivating a lead or an
opportunity
Fixes 4 actions where a whitespace was inserted in the view_mode, resulting in
an unknown view_mode (' graph') in the view_switcher.
Also updates the doc to prevent people to think they can insert whitespaces in
the view_mode definition.
[REM] crm: removed unused file crm_report_view.xml, containing
strange old views, probably some old reports. Those seems to be replaced by
the opportunities and activities analysis + the various dashboards and
graph views.
Using several sales team and the new dashboards is now the only
behavior about sales team. The unique sales team mode is therefore
removed, leading to some update in the various addons that hide
the team_id field when not in multi sales team mode.
[DEMO] cleaned demo data (removed marketing sales team because it should
not exist)
won: probability=100 (on lead)
loss: probability=0 and not active
Won / Loss Replaced most complex domains (merge leads wizard...) by active=True
[IMP] Code cleaning / removing:
unused report.crm.*
merged crm.lead.report and crm.opportunity.report (one report with domains)
[IMP] Cleaned demo data:
Won / Loss, Put back "New" stage
Removed "Marketing" sales team
[IMP] Removed Multiple salesteam setting (always multiple salesteam
Always display the dashboard (multiple salesteam)
No more option in settings
[FIX] misc fixes (bad domains), type not required
to define custom light workflows on opportunities.
Activities are linked to mail.message.subtype through inheritance.
This means that the follow mechanism works for activities. When
an activity is done, a message with the matching subtype is posted
on the opportunity.
Activities are internal by default. They are only visible by
employees.
A shortcut in the 'log a note' chatter option allows to post a
note linked to an activity (subtype).
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
- Several Modules have been splitted into several apps
Examples :
Human Resources : Splitted into Leaves, Recruitment, Expenses, Appraisals, Timesheets, Employees, Payroll
Marketing : Mass Mailing, Events, ...
Messaging : Chat, Agenda, Notes, Address Book, ...
- Generally, the related reports have been moved in the apps, as last menu
- Also, configuration menu (no_one group) have been moved into a config root menu
exception made for the warehouse and lunch modules
- Configuration for typical frontend modules have been moved into the website settings
Related modules : Ecommerce, blog, slides, forum
- When they are present, menus like 'product' or 'customers' have been moved
ex : Customers in Sales menu, Product in POS menu
- A lot of sequences and xmlids have been added or modified in this commit
- List of apps :
1 Chat : Inbox, Channels
2 Agenda : Calendar
3 Notes
4 Address Book : The view contact is still laying in the mail module (1 app => 2 icons)
5 eCommerce : Still to define : Config + Orders Analysis + Shipping + incoming Amazon module
6 Sales : Dashboard (Sales Team Kanban), CRM, Sales (note that they are splitted into 2 submenus)
Assignation, After-Sales (Invoicing and Services), Reports
7 Point of Sale : Dashboard (POS status), Orders, Reports
8 Project : Dashboard (Project Kanban), Search (all tasks, issues), Incoming Forecasts module, Reports
Project.issue.version feature has been removed completely
9 Members : Dashboard (Members Kanban), Report, Config
10 Timesheets : Time Tracking, Approvals, Reports
11 Purchase : Purchase, Control (Products and Bills)
12 Warehouse : Dashboard (Warehouse Kanban), Operations, Inventory Control, Schedulers, Configuration
13 Manufacturing : Same menu structure
14 Mass Mailing : Mailings, Campaigns, Reports
15 Events : Events, Reports
16 Lead Automation : Campaigns, Reports
17 Surveys : Surveys, Reports
18 Human Resources : Dashboard (Departments Kanban), Employees, Contracts, Engagement (Gamification)
19 Recruitment : Job Positions, Applications, Resumes & Letters, Reports
20 Expenses : Expenses, Approvals, Reports
21 Leaves : My Leaves, Approvals, Reports
22 Appraisals : Appraisals, Interview, Reports --> Will probably be modified by the incoming refactoring
23 Payroll : Current Menu
24 Lunch : My Lunch, Manager, Configuration
25 Accounting : Same menus currently, waiting the new accounting to be merged
26 Fleet : Current menu
27 Sign : Incoming docusign module
28 No root menuitem with this sequence
29 Attendance : Attendance, Reports
Sign in/out by project feature has been removed completely
30 Link Tracker (group_no_one) : Link Tracker, UTMs
New view added : URL Shortner, which is the frontend view embedded in backend
31 Versionning : Website domain, Versions, Experiments
32 Slides (group_no_one) : Channels, Categories, Slides, Tags
33 No root menu item with this sequence
34 Livechat : Channels, History, Reports
35 Dashboards : My Boards, Configuration
36 App Store : Local Modules, Apps, Updates
Last Settings : Incoming Dashboard Settings, Sales, ...., Website Settings
General Pattern for all modules' settings :
| Module_name
|-- Settings : General Config view (checkbox screen)
|-- Record setting 1
|-- ...
|-- Record setting n
Example for Sale module
| Sales
|-- Settings : Checkbox screen
|-- Quotations
|---- Quotation Templates
|---- Report Layout Categories
|---- Contract Template
|---- Invoice Type
|-- Contract
|---- Deduplicate Contacts
|-- Delivery
|---- Delivery Methods
|---- Delivery Pricelist
Xavier Morel