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.
- Add an option in the General Settings : Use product variant.
- If this option is disabled : don't show any reference to variants
- When going on the product template view, and clinking on the stat button under the tab Variants,
the form view should display only the information related to the variant
- Fields moves from product_template to product_product : weight, volume, cost price,
- DO NOT display these fields on the product_template if there are more than 1 variants.
- In product variant view, set some fields readonly and add a link to edit it from Template.
The rules 'base.res_partner_rule' and 'product.product_comp_rule' are now inactive by default. This will make these models visible for all companies defined in the database, ignoring the configuration of companies set on product and partners.
Granting read-only access to Sales/Accounting Users is useless
as all employees already have it - removed. On the other hand
Sales Managers need write access to it in order to create
products, and they need it even when `sale` is not installed,
e.g. with `account` only.
Moved this access right to `product` module. The Sales
Manager group is defined in `base`, so that works.
In new API, selection field value is checked (against the selection's possible
values) at both read and write. For pricelist.type this requires read access
to product.pricelist.type.
behavior for product variant. Users are either in group_product_mono or
group_product_variant, allowing to tune the form view according to the
group the user belongs to.
product: added group_product_mono group
sale: added set_group_product_variant method that adds or remove the
group_product_mono according to the group_product_variant being unchecked
or checked.
product: updated form view accordingly
bzr revid: tde@openerp.com-20140121105046-zkbs778upjg0lpyr
ir.rule records are in noupdate data blocks to let the admin
alter them without fear of them being reset at next update.
Other records such as groups are in normal mode, so they
can be updated whenever necessary
bzr revid: odo@openerp.com-20121218232001-t425t4hi7qbmsip2
mdi-odoo