系统管理之权限设计

    系统管理模块是每个系统的必备点,而其中的权限管理部分是其核心所在。因此,如何设计出一个足够灵活的权限管理功能是系统管理模块设计成功与否的关键所在。而笔者根据近年来自己所开发过的系统管理,对权限部分设计时所遇到的一些关键点进行梳理,一是对自己的工作进行记录,另一个是可以给大家提供一种思路,欢迎大家一起沟通讨论。

   权限管理部分设计到了几个比较重要的概念,分别是菜单管理、按钮管理、角色管理以及权限配置几个核心部分,此外,如果涉及到人员所在的多部门情况(集团级架构),则还会涉及到人员管理和部门管理的部分。如下图所示

其中权限管理可分为操作权限和数据权限两种,将分别展开。

   操作权限

      所谓的操作权限,通过给角色配置菜单和按钮,从而根据用户所属角色的不同,会展示给用户不同的页面,以及同一个页面显示不同的操作按钮。此过程中,菜单和按钮是一对多的关系,而角色和菜单也是一个一对多的关系,除此之外,还需要有一个权限表,是角色、菜单和按钮的中间表,以保存不同的权限关系。

数据权限

    所谓的数据权限,则是不同的用户通过配置,对于同一个页面可以查看到不同的数据。一般的数据级别会设置为本人可见、本部门可见以及所有可见三种情况,有些细分的情况,可能还包括可选部门或者可选人员的可见,但该种情况不再本文的讨论范文,本文只讨论常见的三种情况,即本人、本部门以及所有。

数据库设计

        针对以上所述的权限说明,其对应的数据库表也就明了了,即包含菜单表、按钮表、角色表、人员表、机构表以及相应的中间表。

1. 菜单和按钮表的设计

        菜单和按钮是由系统开发人员进行设置和管理的,其操作页面是对用户不可见的,且由于页面的按钮是具有点击事件的,是前后台的一种约定,故不可随影更改,所以按钮表是有一个code字段来唯一标识一个按钮,不可随意更改。

其表结构如下所示:

        

其中,菜单表中的名称是唯一的,且菜单是由上下级关系的,处于非叶子节点的菜单可能不需要调整页面,此时可将url设置为#;而按钮表中的code是唯一的且不可随意修改。此外,还需要一个菜单和按钮的中间表,存放菜单和按钮的对应管理,表结构是由两个表的主键id组合而成,不再赘述。

2. 角色表的设计

        角色是整个权限设计的核心,所有的权限都是基于角色进行设置和展示的,角色需要和菜单按钮做关联关系,还需要和人员进行关联,因此,属于承上启下的关系,一般表结构如下:

如上所示,是角色的关键信息,有些公司可能需要角色也分为上下级的结构,且每个角色的权限可继承上级的权限的集合,此处为了简化,将去掉角色的上下级,但其实现方式是一致的。

3. 操作权限表的设计

        操作权限上位已有描述,此表结构如下:

        

如上图所示,可发现操作权限的表结构也是比较简单的,即三个表的主键id组合而成,据此,可以将角色所对应的权限保存起来。此外,还有一种情况,即权限只有页面,没有操作按钮,即该角色只有页面浏览的权限,上述表是无法满足的,因此,还需要另一张角色和菜单的中间表,用于处理该种情况。

        以上便是权限设计的核心数据库设计,通过改数据库,已可以实现基于角色的访问控制,其控制级别为页面上的按钮级别,如不需要数据权限的控制,基本可满足大部分场景了。 

        而对于数据权限的设计,则需要在角色表上进行修改,以标识不同角色所对应的数据权限,由于篇幅限制,不再展开,后续将进行详细论述。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
针对 OA 系统的特点,权限说明: 权限 在系统中,权限通过模块 +动作来产生,模块就是整个系统中的一个子模块,可能对应一个 菜单,动作也就是整个模块中(在B/S 系统中也就是一个页面的所有操作,比如“ 浏览、添 加、修改、删除” 等)。将模块与之组合可以产生此模块下的所有权限权限组 为了更方便的权限管理,另将一个模块下的所有权限组合一起,组成一个“ 权限组” ,也就 是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的 浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限权限组添加到一个角色中, 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使 一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按 职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4 种方式( 参考飞思办公系统) A . 通过职位 a) 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继 承。 b) 实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤 查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不 设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限, 而对于项目组长,他对项目有全权,对下级项目也一样。 b) 实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项 目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目 文档的上传权和查看文档权即可。 c) 对于组长,因为可以赋予组长一个组长权(组长权是个特殊的权限,它包含其他各种权 限的一个权限包),所有组长对于本项目有全权,则项目组长可以对于项目文档查看,审批, 删除,恢复等,这些权限对于本项目的下级项目依然有效。 C. 通过角色 a) 角色中的成员继承角色的权限,角色与角色没有上下级关系,他们是平行的。通过角色 赋予权限,是指没办法按职位或项目的分类来赋予权限的另一种方式,如:系统管理员,资 料备份员… b) 实例中:对于本系统中,全体人员应该默认都有的模块,如我的邮件,我的文档,我的 日志,我的考勤……,这些模块系统成员都应该有的,我们建立一个角色为系统默认角色, 把所有默认访问的模块的浏览权加入到里面去,则系统成员都能访问这些模块。 D. 直接指定 a) 直接指定是通过对某个人具体指定一项权限,使其有使用这个权限的能力。直接指定是 角色指定的一个简化版,为了是在建立像某个项目的组长这种角色时,省略创建角色这一个 步骤,使角色不至于过多。 b) 实例中:指定某个项目的组长,把组长权指定给某个人。 针对职位、项目组: 如果用添加新员工,员工调换职位、项目组,满足了员工会自动继承所在职位、项目组的权 限,不需要重新分配权限的功能。 用户管理 用户可以属于某一个或多个用户组,可以通过对用户组授权,来对组中的所有用户进行权限 的授予。一个用户可以属于多个项目组,或担任多个职位。 授权管理 将一个基本权限或角色授予用户用户组,使用户用户组拥有授予权限的字符串,如果角 色、职位、项目中存在相同的基本权限,则取其中的一 个;如脱离角色、职位、项目组, 只是取消用户用户组的中此角色、职位、项目组所授予的权限用户所拥有的权限是所有 途径授予权限的集合。管理用户可以 查看每个用户的最终权限列表。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

面朝大海,春不暖,花不开

您的鼓励是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值