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.
Added a mail_template_field on project stage model (project.task.type). This
fields is used to automatically send an email when a task or issue comes in
this stage.
Recruitment code has been updated to use the mixin method.
In project, stages are shared between projects. However demo projects do not
have any stage by default but stages are assigned to some random stages. This
leads to columns disappearing from the kanban view when there are no more
tasks or issues in it.
Also fixed the addition of followers in a demo project. Instead of hardcoding
the followers use a message_subscribe instead. It was impossible to reload
the project module before that fix.
Major changes:
- New start and expiration dates
- Remove field Contract Status
- Simplified because use of sale_timesheet
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
concept of default / common stages.
However as the link between stages and projects is still a many2many
it is still possible to have shared columns. It is however not the
standard way of using stages.
Members were not used in project, except for the now removed faces library.
Statistics can still be computed based on task or issues responsibles
instead of adding all members of a project.
Indeed you could have members that did not actually work in the project
making it difficult to differentiate with followers. Now the concept
of members is removed. Followers is sufficient for communication.
code in resource and project.
This library was once used to perfom resource allocation: scheduling
tasks and things like that. However this feature cannot be accessed
through the interface since a long time.
The feature is now removed from the project code. The library has been
removed. Some code in resource used only in the project code
has also been removed, as well as a test linked to this code.
- remove unnecessary copy() method from project/res_partner.py
- remove old methods on project.project
- progress is not used anymore on project.project
- use clickable statusbar for project states
- remove _resolve_project_id_from_context
- rename project.category becomes project.tag to be more explicit
- remove old methods on tasks
- issues: remove option fetchmail_issue
- stage model (project.task.type): add fields holding the eventual specific
legends for kanban states and star (priority) management
- project: task now have labels; you may use project to hold trainings
instead of tasks.
- project form: use label field on tasks statinfo to use the label
- project.task form: use kanban state customization using states_legend option;
- project.task kanban: use kanban column and kanban state cuztomization
using group_by_tooltip and states_legend options
- project_issue: issues now have labels, like tasks.
- issue: same kanban custo as for tasks
- update data and demo data
[IMP] web: statinfo widget now take an optional label_field option allowing
to have strings coming from another field present in the form view
- project kanban view: dashboard-like view, add sparklines for open tasks
and closed issues
- project: cleaned demo data, less stages
- project: description is now an html field
Removed concept of state on project.task (and propagated report)
Removed python inheritance towards base_stage (specific code will be re-added)
bzr revid: tde@openerp.com-20130626132519-988nfq8pw8h8c8e8
Yannick Tivisse