模块管理常规功能自定义系统的设计与实现(32--权限设计[2])

权限设计(2)

二、模块记录的可视权限。通俗的讲哪些记录你能看,哪些记录你不能看,说起来简单,做起来不简单。

先从一个简单的需求说起。对于前面搭建的销售系统如果由一个内勤来处理所有的合同,那么就没有权限设计的问题,把内勤的部门加在“销售部”就可以看到销售一、二、三部的所有合同。但是如果每个销售部有单独的内勤来处理自己部门的销售订单,并且互不干扰,就要设计记录的可视权限了。现在系统里内置了部门的权限。例子中的部门结构如下:

部门编码 部门名称 操作所有记录 操作本级 其他
00 公司      
0001 办公室 true  
0002 财务部 true    
0010 销售部      
001001 销售一部   true  
001002 销售二部      
001003 销售三部      

在上面的结构中,操作员根据其所属部门来设置其记录可视权限。00部门下的人可以查看所有数据,0001,0002,由于设置了 操作所有记录 的选项,这二个部门的人也可以查看所有记录。0010可以查看001001,001002,001003的所有数据,而001002,001003只能查看自己部门下面的数据。001001设置了一个操作本级的值,表示他可以查看到0010的权限,也就和本级平级的数据都可以看到。

对应权限设置,其实就是将条件加进sql的过程。对于业务员,我们来看一下查找销售二部的业务员的sql

    select
       _t6020.tf_salesmanId as tf_salesmanId ,
        _t6020.tf_name as tf_name ,
        _t6020.tf_sex as tf_sex ,
        _t6020.tf_birthday as tf_birthday ,
        _t6020.tf_age as tf_age ,
        _t6020.tf_telnumber as tf_telnumber ,
        _t6020.tf_phonenumber as tf_phonenumber ,
        _t6020.tf_eMail as tf_eMail ,
        _t6020.tf_remark as tf_remark ,
        _t9011.tf_departmentId as _t9011___tf_departmentId ,
        _t9011.tf_name as _t9011___tf_name
    from
        Salesman _t6020
    left outer join
        _Department _t9011
            on _t9011.tf_departmentId = _t6020.tf_departmentId
    where
        (
            (
                _t9011.tf_departmentId like ‘001020%‘
            )
        )

查找业务二部的所有订单的sql

    select
        _t6040.tf_ordersId as tf_ordersId ,
        _t6040.tf_ordersNumber as tf_ordersNumber ,
        _t6040.tf_date as tf_date ,
        _t6040.tf_finished as tf_finished ,
        _t6040.tf_remark as tf_remark ,
        _t6010.tf_customerId as _t6010___tf_customerId ,
        _t6010.tf_name as _t6010___tf_name ,
        _t6020.tf_salesmanId as _t6020___tf_salesmanId ,
        _t6020.tf_name as _t6020___tf_name ,
        _t9011.tf_departmentId as _t9011___tf_departmentId ,
        _t9011.tf_name as _t9011___tf_name ,
    from
        Orders _t6040 						//订单
    left outer join
        Salesman _t6020 					//业务员
            on _t6020.tf_salesmanId = _t6040.tf_salesmanId
    left outer join
        _Department _t9011 				//部门
            on _t9011.tf_departmentId = _t6020.tf_departmentId  

    where
        _t9011.tf_departmentId like ‘001020%‘

可以看到所有部门的子模块,不管离部门有多远,在查找数据的时候,都必须一级级的关联,最终关联到部门,并加入部门的限定条件值。对于系统结构图,可以看到的是部门的子模块有:业务员、订单、订单明细、订单收款。

不止是上面直接取得各子模块数据的时候要加入部门的限定值,在这些模块的字段作为聚合字段计数或求和时也要限定部门的值,所有的部门及其子模块作为导航值统计记录数的时候也都要加入部门的限定值。总之一句话,销售二部的人看到的和统计到的都是他部门的数据。而不管这个模块和部门的距离有多少级。如果你的系统设计到了层次10级以上,可能会考虑效率问题,但这个应该不是你应该考虑的,这是oracle,sybase,microsoft公司应该考虑的了。

对于有分层结构的模块,其where子句是象上面的这样加入的

where
        _t9011.tf_departmentId like ‘001020%‘

这个还得优化一下,因为是最末一级了,可以使用

_t9011.tf_departmentId = ‘001020‘

而如果是 0010权限,才用

_t9011.tf_departmentId like ‘0010%‘

这是单个一个部门的权限,当然也可以设计成这样的权限

_t9011.tf_departmentId like ‘001020%‘ or
_t9011.tf_departmentId like ‘001030%‘

这个操作员就可以查看销售二部和销售三部的所有数据。


以上就是单个模块设计记录权限的方法。现在引申一下,可以对任何一个模块的记录加上这个限定的权限,比如说有个统计专员,专门统计“金牌客户”的订单,我们就可以在 “客户等级”这个模块上加一个权限,然后将此权限赋予此统计专员,其就只能看到金牌客户的所有数据,而其他数据就看不到了。

如果有一个行业订单分析师,那么就在行业模块上加上权限,可以选择一个行业,或几个行业,使此行业分析师只能看到这些行业下面的所有客户和所有订单。

以上这些权限是可以叠加的:比如说销售二部有一个金牌分析师,那么在查客户单位的时候是限定金牌单位,查业务员的时候限定销售二部,在查销售订单的时候要同时满意是销售二部的金牌客户的订单。

这些权限的设计也都是全部在前台设计好后立即生效的。

继续引申,比如有一个大订单分析师,只要看到10万元以上的订单,那么也应该可以设计一个权限,放置于订单金额总金额之上。这个功能现在没做的,只是我刚想出来的一个点子而己,要做进去的话,估计1,2天时间就可以了。

以上即为模块记录的可视权限的简单设计介绍,如果还有更好的办法,请跟贴指点或交流 [email protected]。

模块管理常规功能自定义系统的设计与实现(32--权限设计[2]),布布扣,bubuko.com

时间: 2024-10-22 12:52:38

模块管理常规功能自定义系统的设计与实现(32--权限设计[2])的相关文章

模块管理常规功能自定义系统的设计与实现(36--终级阶段 综合查询[3])

综合查询(3)--查询条件的设置2 不仅仅对于模块才有这样方便的条件选择方式,对模块的字段也可以设置.例如对于"省份"中有个字段是"所属区域",这个字段不是一个manyToOne字段,而是一个字符串字段,里面就是存着"东北地区"."华北地区"等等这样的具体的字符串值.对于这样的字段也很容易将其放在toolbar上供选择.在模块字段中找到"所属区域"这个字段,修改字段的属性,让这个字段可以加到综合查询的too

模块管理常规功能自定义系统的设计与实现(33--权限设计[3])

权限设计(3) 三.字段的只读权限.对于可以修改记录的操作员,可以进一步限制哪些字段对于他是不可修改的.这个功能很少用到,是用户提出来的,我就顺便加了进去.实现这个功能也很简单建立只读字段角色,然后加入模块的字段,最后再将角色加到操作员上即可.前台在解释生成edit form 的时候,将这个字段的只读属性置为true即可.后台Hibernate在新增或保存的时候,可以把只读字段过滤掉,不能保存或不能修改即可. 四.字段的可视权限.有时候某些字段你不希望被某些群组的操作员看到,那么就设置一个隐藏字

模块管理常规功能自定义系统的设计与实现(28--多个模块之间的关联[4])

多个模块之间的关联(4) 前面搭建了客户以及客户父模块的一个分支,另一个分支是产品线,还有一个是业务员,然后这三条线归并到订单之上. 前面我贴了我要搭建系统的一张图,现在贴一下数据库的表和其之间的关系情况. 上图中表和我设计的简易销售管理系统是完全一致的.再看一下的模块图,稍微记下下其中的关系,对于看懂下面的内容很有必要. 对于业务员,产品,订单三条分支我建立的过程就不介绍了.现在来看看架构好的菜单: 再看看加好的各个模块的页面: 1.部门和业务员: 2.商品类别 3.商品 4?订单 订单明细

模块管理常规功能自定义系统的设计与实现(52--功能更新[2] 对百分比字段的操作)

功能更新(2)  对百分比字段的操作 百分比数据,或者是比率数据是一个比较难处理的字段,难点并不在于单条记录之中,而是在于汇总和分类汇总的时候. 先来看看我系统中的一个模块中的一个比率字段: 上图中的  已支付比例,这个字段是  已支付金额 / 结算金额,这个字段在此合同模块中可以作为一个计算字段来保存在数据库中,甚至可以不保存在数据库中,直接在bean里作为一个计算的属性. 现在问题就来了,如果要计算所有合同的已支付比例,那么就不是简单加起来的问题了,要把分子和分母分别加起来再除才会得到总计的

模块管理常规功能自定义系统的设计与实现(29--多个模块之间的关联[5])

多个模块之间的关联(5) 系统全部架构好了,下面来看看一个很远的关系,"省份","订单"之间的关联.在省份模块里显示该省的订单的个数以及金额和收款情况.跟前面的设计一样,给省份增加"附加字段". 然后把选入的字段加入到 grid 当中. 再来看看子模块市下面的菜单: 下面显示一下选择了订单菜单项的界面. 其他导航 以上为模块间关系的一个例子.上面有个缺点就是,我要看某个省份2013年度的订单汇总,在省份模块里就没有办法做到,这个问题放到以后去解决

模块管理常规功能自定义系统的设计与实现(23--二个模块之间的关联[1])

"省"."市"二个模块之间的关联的操作(1) 一. "市"模块定义好了,我们先来新增1个市,看看和"省"的关联操作. 上面显示了"市"的模块界面,在导航栏中为省份的导航,我们看到只有"江苏省"一个,其他的在哪里呢. 一个模块的父模块的导航有一个选项,叫"显示无记录的项目",此选项默认不选中,也就是说省里面还没有市的话,那个省将不放在导航列表中,看下图. 二.记录拖放操

模块管理常规功能自定义系统的设计与实现(22--第二个模块的加入)

模块"市"的设计与加入 现在重复加入"省"模块的过程,来加入市的模块. 1.建立数据表City CREATE TABLE [dbo].[City]( [tf_cityId] [nvarchar](4) COLLATE Chinese_PRC_CI_AS NOT NULL, [tf_provinceId] [nvarchar](2) COLLATE Chinese_PRC_CI_AS NOT NULL, [tf_name] [nvarchar](50) COLLATE

模块管理常规功能自定义系统的设计与实现(37--终级阶段 综合查询[4])

综合查询(4)--查询条件的设置3 这节来看看日期字段如何设置查询条件.我对日期字段做了一个分类,使其可以按年,年季,年月,年月日的几种方式来设置条件.另外每一个模块可以设置一个日期字段,当该模块作为查询的基准模块时,在条件设置toolbar 上第一个菜单即是日期选择菜单,选择的值将会作为该日期字段的条件.例如对于"订单"模块,为其设置了日期字段为"tf_date". 在综合查询的模块中显示为以下: 上图是选中了基准模块为"订单"时,查询期间选择

模块管理常规功能自定义系统的设计与实现(24--二个模块之间的关联[2])

父子模块之间关联操作(2) 上一节介绍了子模块中对父模块的一些相关操作.这一节来看看父模块中对子模块可以进行什么样的操作. 一.进入子模块的时候,限定父模块值.选择一个"省"记录,查看省下面的所有市的记录. 在选择了"江苏省"记录之后,按toolbar上面的"市",会进入市模块的界面.(在前一节的基础上,我又给河北省和浙江省增加了市,在下面的界面中将会看不到) 二.加入子模块的记录和聚合字段.上节中介绍了可以将父模块中的字段加入到子模块的grid

模块管理常规功能自定义系统的设计与实现(21--第二阶段设计目标)

第二阶段设计目标 前面的章节讲了建立单个模块的各种功能,从现在开始要加入若干个具有关联的模块,使其协同工作.我设计了一个简易的销售管理系统,系统的结构如下图所示,从本节开始将逐步的搭建此系统. 在上图中,各模块之间都能通过一定的路径产生联系,而具有关联的二个模块具有直接的关系,例如省是市的父模块,市是省的子模块:客户单位是市的子模块也是省的子模块.这种上下级关系将会是处理的重点.各模块间的关系要明确,不能出现关系不明确或者循环引用的模块,那样权限的设置将会有问题. 例如有如下模块结构: 在上图中