共计 1870 个字符，预计需要花费 5 分钟才能阅读完成。
1. 背景需要
某连锁酒店团体应用.NET 开发了一套报表剖析平台，随着治理及业务倒退的须要，原平台开发报表的难度较大、易用性低和数据权限治理较弱，现管理层级上需减少大区总监角色及其它数据权限管制，原平台权限体系批改工作量微小，为了加强报表剖析平台的易维护性和易开发性，团体高层决定废除原零碎，引入 Smartbi 作为其报表剖析平台。
其中，权限治理想要达到的成果是酒店经理、店长、大区总监、经营总监和团体总部人员等不同角色的人员看到不同的数据和报表。
2. 权限设计
Smartbi 具备十分欠缺的平安管理体系，它能够管制用户操作性能权限、数据拜访权限、资源拜访权限。反对按用户、用户组、角色进行治理；反对多套利用零碎共用同一套用户管理系统；反对多级用户管理体系。权限管制的粒度十分细，最小可管制到报表按钮，数据字段等权限。
不同人员查看不同的报表和数据对应的是 Smartbi 零碎中的资源权限和数据权限管制，所以应用 Smartbi 进行开发和治理是非常容易实现的。
新建用户
新建角色
将角色受权给相应的用户，对应关系如下
2.1. 资源权限
编辑分店角色，关上资源受权治理页面：
将 F_分店报表受权给分店角色：
应用店长用户登录 Smartbi 零碎后，店长会获取到分店角色的权限，成果如下，店长只能看到已受权的 F_分店报表
相似的编辑大区总监角色和团体治理角色，受权后的成果如下：
大区总监角色，所能看到的报表比分店角色多
团体治理角色，所能看到的报表是最多的
2.2. 数据权限
以其中一个报表为例，有以下 5 个参数：分店类型，区域，省份，城市，分店，参数之间互相关联，分店的值由前 4 个参数决定，城市的值由前 3 个参数决定，省份的值由前 2 个参数决定，区域的值由分店类型决定。
1. 分店信息表 Store_info
2. 建设用户和分店的权限管制表 User_store：
3. 建设用户属性
零碎自带函数 CurrentUserName 的作用是获取以后登录用户的名称
新建用户属性的作用是当用户登录零碎后即可获取以后用户所能查看哪几家酒店数据
4. 由权限管制表 User_store 和用户分店属性建设参数
a) 分店类型参数由用户分店属性决定
b)区域参数由用户分店属性和分店类型参数决定
c)省份参数由用户分店属性、分店类型和区域参数决定
d)城市参数由用户分店属性、分店类型、区域和省份参数决定
e)分店参数由用户分店属性、分店类型、区域、省份和城市决定
3. 案例实际效果
理论用户：分店角色用户 4000 人、总监角色用户 200 人和团体治理角色用户 15 人，只需简略操作受权即实现权限治理。除此之外，用户还可随便依据本身需要减少角色，如按部门治理，极大的减少了权限治理的自由度和可扩展性。
店长用户登录后的成果如下，只能查看到北京大成店的数据。
大区总监用户登录后的成果如下，只能查看到深圳宝安新安地铁站店，深圳东门湖贝地铁站店和深圳蛇口工业七路四海公园店这 3 个酒店的数据。
最终团体总部人员登录后的成果如下，能够查看 6 家曾经受权的酒店数据。
4.Smartbi 权限体系
Smartbi 具备欠缺的平安管理体系，它能够管制用户性能权限、数据拜访权限、资源拜访权限。反对按用户、用户组、角色进行治理；反对多套利用零碎共用同一套用户管理系统；反对多级用户管理体系。权限分类如下。
操作权限次要是从更高层面对用户权限进行划分，决定被受权用户能够应用零碎的哪些性能，能够执行哪些操作。如：管理员能够查看并设置数据源、用户等信息，普通用户只有查看报表的权限，IT 人员有设计和开发报表的权限等等；其原理是在生成 sql 语句时增加响应的过滤条件，对于各类资源设置数据权限，应该是对其依赖的资源进行设置，比方组合分析如来源于业务主题，则应该对其业务主题进行数据权限设置。
资源权限是对平台具体资源的管制，能够限度被受权用户到具体的某一张报表或某一个图形资源，如：创立的某张报表只容许本部门的所有人查看，本部门以外的人不容许看到；或者某些报表只能被被领导查看，普通员工不容许查看等等。
在零碎中，咱们能够利用数据权限性能实现不同区域的用户登录 Smartbi 后只能看到其所属区域及子区域的数据，如：北京分行和广州分行只能看到本分行本人的数据，而总行能够看到所有分行的数据和总行数据等等。
相关联的，这些权限的授予对象为角色、用户及用户组，关系如下：
用户为最终的受权者，所有的权限最终会体现在用户身上；受权对象之间存在着肯定关系，从用户角度剖析看，一个用户能够有多个角色，能够同时属于多个用户组，并且一个用户组也能够有多个角色，如此角色和用户组的权限最终都将传递到用户下面。
