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.
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.
Stages are now sales team dependant, and not shared anymore. This comes
with a sales-team way of working :
- sales team is the entrance point, click on the big Pipeline button to
see the opportunities pipeline of this specific sales team
- no more opportunities menu entry, as you should come from a sales team
- leads are still sales-team agnostic
The stage management has been updated :
- Won is still a stage (probability=100, onchange=1).
- Lost is not a stage anymore. Lost is equivalent to archiving. Archiving
uses the active field. Setting a lead or an opportunity as lost set them
as unactive.
Downside of the no more share policy: multi sales team opportunities
management can quickly become complicated. Indeed you may have stages
with the same name, not being the same stage, therefore not displayed
in the same column. Grouping on the stage name leads to other issues
(sequencing incoherence, impossible to drag n drop), so this is not
an option.
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
- sales_team: remove field note, usability improvement in kanban and form views
- crm: in crm.stage remove default_case, sequence and legend_priority fields and remove default stage_ids + some fields in technical group
- sale: add field use_invoices on sales_team and display links in dashboard according to this new field
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).
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Models renamings:
- crm.case.stage becomes crm.stage
- crm.case.section becomes crm.team
Model split:
crm.case.categ has been splitted into:
- crm.phonecall.tag
- crm.lead tag
- crm.claim.tag
- crm.helpdesk.tag
Models removal:
- crm.payment.mode
- crm.segmentation
- report.crm.case
Removal of the crm_profiling module
(all these refactorings have been done in order to ease new API
migrations)
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
- improved behavior of schedule a meeting, for both opportunities and partner, with correct
attendees and options;
- removed wizard to schedule a cal, jumping to the list view with correct default values
is sufficient;
- scheduled calls is now accessible using a group, accessible through sales configuration;
bzr revid: tde@openerp.com-20140417145645-cpohfrfpqnskpok6
Yannick Tivisse