OE权限设置文档
-
[quote author=jerry_hao link=topic=16629.msg29053#msg29053 date=1411722972]
共享组是啥意识啊？
[/quote]
目前没用到过，据说是内部用户共享文档给外部用户的，我看了下代码，不知道为何在代码里把checkbox设置为readonly了，google了一下也没找到满意的答案。
参见： https://www.odoo.com/forum/help-1/question/what-is-use-of-share-group-and-portal-under-groups-in-openerp-v7-23769
@校长 @Jushua 过来解答下吧 -
细节描述很到位，但总体理解有些偏颇。摘抄一段我的论文
二、 权限子系统的设计和实现
在上ERP系统之前，企业的订单数据是在excel里进行管理的，无法很好地区分权限。只能实现表级别的权限控制，要实现记录级别的权限控制只能复制部分行出来临时拆分成另外一个excel文件，要实现字段级别的权限控制还要手工删除某些列。
(一) 基于角色的权限控制
ERP系统中权限控制的对象是数据库表，权限控制的主体是用户。但是考虑到企业员工的流动性，针对具体的雇员指定职责繁琐且容易出错，企业常见的做法是划分岗位，首先确定每个岗位的职责，然后为员工分配岗位。这既能覆盖小企业一人多岗的需求，又能覆盖大企业一岗多人的需求。我们的ERP系统也迎合这个设计，在系统中设置角色这个概念，针对角色设置每个数据表的读写插删权限，然后系统管理员只需要简单地给新用户指定角色即可。
图-1 数据库表、角色、用户三者之间的关系
需要注意的两点是：
1、 有些角色是为一些特定的需求而定义的，并不能在企业里找到对应的岗位名称与其对应。
2、 角色之间可以有继承关系，实现“部门经理有部门里其他人所有权限”的常见需求
(二) 表级别的权限控制
适用场景：销售部门的所有人都可以创建或修改订单，但客户和产品由于关系到财务记账，需要由财务统一创建并分配编号，销售人员可以修改客户信息以完善地址，但不能修改产品信息。
实现：我们用一个独立的表来存储这些控制规则，表中只需包含6个字段，即表名、角色名、允许读取、允许修改、允许新建、允许删除。当用户在界面上点击对应按钮的时候，我们先取得用户所属的所有角色（这个可以在用户登录时缓存，以提高运行速度），再根据这些角色的名称、当前界面的表名和按钮对应的操作这三个条件到这个权限表里取得一条数据进行比对验证，如果验证失败则报错。
表1 – 表级别的权限控制
表 角色 允许读 允许写 允许新建 允许删除
Sale.order Salesman yes yes yes yes
Product.product Salesman yes no no no
(三) 记录级别的权限控制
适用场景：销售部门的各个销售人员之间的客户信息是保密的，不能看到其他销售人员的订单和客户。
实现：我们在定义另一张表来存储这些规则，表中有7个字段，即表名、角色名、适用条件、允许读取、允许修改、允许新建、允许删除。当用户在界面上点击对应按钮时，我们先取得用户所属的所有角色（这个可以在用户登录时缓存，以提高运行速度），再根据这些角色的名称、当前界面的表名和按钮对应的操作这三个条件到这个权限表里取得数据。如果有规则数据并且当前操作的记录不满足这个过滤条件，则报错。
表2 – 记录级别的权限控制
表 角色 适用条件 允许读 允许写 允许新建 允许删除
Sale.order Salesman Creator = user.id yes yes yes Yes
Sale.order Salesmanager 1 = 1 yes yes yes Yes
注意这里根据需要要给销售经理特别设置一个反规则。
(四) 界面级别的权限控制
我们在系统架构设计的时候，采用基于界面定义文件动态生成用户界面的技术。所以在界面定义文件中指定字段时，可以用 groups 属性指定此字段对哪些角色可见（如未指定则无限制）。在界面生成的时候，根据当前用户所有的角色，决定哪些字段在界面上是隐藏的。同样的技术适用于菜单、按钮、标签页等界面元素。
这样设计则无法像前面两个级别的控制一样可以有管理员进行配置，只能通过修改程序来实现。好处是无需配置，弊端是不够灵活。
表3 - 界面级别的权限控制
界面元素 角色
成本价字段 Salesmanager
产品菜单 Accountant，Salesmanager
