Commit Graph
10 Commits
Author SHA1 Message Date
Victor Feyens 066214b36b [IMP] *: remove duplicate ACL targeting same group/model.
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).

Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
2020-03-27 09:55:33 +01:00
Josse Colpaert 2ddc35a530 [REF][NEWPIE] mrp: new MRP
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :

 - Picking type not only for pickings but also for manufacturing orders
 - Properties replaced by picking type
 - BoM can only be produced with its routing (no other)
 - Either produce without routing with only production orders, or produce with
   routing
 - By default, there is an order in the work orders (serially), but you can
   override it to be able to work in parallel
 - Time clocking on work orders and block time on work centers with reporting
   on OEE, performance, losses, ...
 - Real-time adaptation of timings on operations
 - Lots/serial numbers can be inputted like in the pickings on manufacturing
   orders.  It is also possible to input them in the work orders.
 - Material availability independent of production order state (possibility to
   start production when only part of it is there)
 - Work sheets on work orders
 - Put messages on work orders to make your workers pay attention to something
 - Full traceability link to see for each produced piece of stock, the
   consumed pieces, ...
 - Separate scrap object (a scrap is not done based on an original move
   anymore)
 - Separate unbuild system (if you want to unbuild into its original
   components)

Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
2016-07-04 16:22:37 +02:00
Yannick Tivisse 9e57185449 [IMP] base,sales_team: Move res_groups and menuitems to sales_team
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.
2016-06-09 16:05:25 +02:00
Yannick Tivisse ccdb5cbfc0 Revert "[IMP] base,sales_team: Move res_groups and menuitems to sales_team"
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.
2016-06-06 17:26:30 +02:00
Yannick Tivisse fa6e415cdb [IMP] base,sales_team: Move res_groups and menuitems to sales_team
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.
2016-06-06 15:46:52 +02:00
ajay javiya (OpenERP) 4431d24355 [REM]Remove mrp_bom_revision
bzr revid: aja@tinyerp.com-20120831050028-aoprwoo3bq8x0f75
2012-08-31 10:30:28 +05:30
Dharti Ratani (OpenERP) 2cea76a982 [IMP]mrp related access for sales group
bzr revid: dhr@tinyerp.com-20120629100139-v94s5qhlxkh2vber
2012-06-29 15:31:39 +05:30
Fabien Pinckaers f27318c8af [IMP] Security Rule: removed duplicates due to inheritancies of groups
bzr revid: fp@tinyerp.com-20111212181113-mhnnbps3ip8ls6pp
2011-12-12 19:11:13 +01:00
Harry (OpenERP) 97f03cf5c2 [FIX] mrp,sale_mrp,stock_location: security
bzr revid: hmo@tinyerp.com-20101229120559-z1wxdm5r2nakfivg
2010-12-29 17:35:59 +05:30
aag (OpenERP) 05bee134f8 Security Added in sale_mrp
bzr revid: aag@tinyerp.co.in-20101028071548-so4ysxes4esg3m7j
2010-10-28 12:45:48 +05:30