OA权限设计问题？

好像不太好。扩展性也比较差。

一般是这样，User表，角色表，用户角色表（用户拥有哪些角色），菜单表

角色菜单表（角色拥有哪些菜单）。

这个结构是基于菜单的分配来控制权限。

如果还想控制到功能按钮级别，可以再增加其他的表做控制，比如菜单功能表(MenuFunction)等等。

另外我觉得你表名也起的不好，比如角色通常用Role这个单词

表分别为：User,Role,UserRole,Menu,RoleMenu,分别对应我上面列出的中文表名

－－－－－－－－－－－－－－－－－－

补充一下，上面的模型，是用户登录的时候，读取其对应的User信息，UserRole信息，然后读取UserRole中每一个Role对应的功能菜单，从而得到菜单集合，然后展示给界面。

这个模型也可以用于判断用户是否有访问某个功能的权限。

OA系统是服务组织的系统，而任何组织一定会涉及到权限；所以OA系统最关键的核心就是权限控制。OA系统中的权限管理要实现的效果是对“什么时间、什么地点、谁可以访问什么内容、可以进行哪些 *** 作”一系列权限的精细化控制。

权限管理是组织的必要因素，也是OA系统一切功能应用能够发挥其价值的基础所在。权限管理渗透在企业业务和运营的方方面面，如何做到权限的严谨与灵活，是OA系统权限落地中需要权衡的课题。以下几个方面供参考：

1.权限与性能的矛盾：越大的组织越需要对权限的细化控制，但同时细化的信息控制权限必然带来大量的运算，大量的运算一定是降低性能的

2.权限的灵活性：如何做到权限的随时调整

3.六维立体权限控制：时间、对象、 *** 作、内容、级别、地点

4.每一个功能模块都有自己的权限体系，整个软件有自己的权限体系：如何让整个软件的权限体系能够控制所有模块的权限；以及更为深层次是否能够控制异构系统的数据权限

5.随着社交化软件的发展，如何处理好权限控制和自由精神发扬的矛盾是目前OA系统软件的难题

6.OA系统软件的权限管理必须要细化到对每一个字段、每一个 *** 作的控制

7.OA系统软件的权限控制不只是功能信息的权限控制，更为重要的是对整个系统部署的分权管理模式的支撑

8.赋权和撤权如何在系统方便快速处理、批量处理，且不影响性能

9.一个组织的架构发生变化的时候，已有的信息控制和将来的信息权限控制如何方便快速调整

可以通过不同划分管理权限：分组进行权限管理，根据角色权限管理，根据用户权限管理。

权限中定义的是用户和事情之间的关系，并没有涉及到角色。所以，如果不使用角色也可以实现成员资格管理。但是，角色作为某些用户的集合，这样对制定规格是更为方便、合理，也更符合业务逻辑的客观存在形式。 即：通过角色对用户进行权限管理。

权限管理系统功能分为：授权与认证

4、授权，指将权限授予角色或用户

a) 如果用户A拥有角色B、角色C，那么，缺省的情况下，用户A将拥有被分配给角色A和角色C的所有权限（即默认情况下，用户A继承其拥有的角色所具有的所有权限）

b) 如果用户拥有多个角色，那么用户的权限是这些角色权限的合集

c) 如果用户拥有多个角色，而且角色之间的授权有冲突（比如对同一个资源的同一个 *** 作，一个角色为“允许”，另外一个角色为“不允许”），将以优先级别高的角色为准（所谓优先级别，也就是对于这个用户所拥有的角色而言，是有顺序的，同一个角色在不同的用户那里可能拥有不同的优先级）

5. 认证，指用户访问资源的某些 *** 作时，根据授权，判断是否允许用户的访问

a)在用户访问的时候，需要进行即时的判断（是否有权访问）

员工职位=角色-》设置权限。权限有树形结构

为角色分配权限-》分配子权限，角色也就有父权限。

一、权限有哪些功能：控制哪些用户可以使用哪些功能。

1，初始化权限：

向数据库插入所有的权限数据，这个 *** 作只在安装做一次。ps:权限没有增删改（因为功能已经开发完）

插入一个超级管理员用户，这个用户有所有的权限，并且他的权限不可以被修改与删除。

2，分配权限：

指定哪些用户有哪些权限（某权限就是使用某功能的许可，也就是某URL的访问许可）。

是给Role分配权限（用户的权限就是用户所有角色的权限的合集）。

3，使用权限：

1，用户登录后才能使用OA中的功能（登录、注销）。

2，左侧的菜单是根据权限显示的。

3，右侧页面中的链接是根据权限显示的。

4，验证每一个请求的权限，有权限才能访问。

权限= *** 作+资源

控制权限---》控制url

二、整体思路

某权限就是使用某功能的许可，

一个功能就是一个多个URL（在ItcastOA中有两种情况）：

1，一个功能对应1个URL，例：删除用户功能对应的URL是userAction_delete。

2，一个功能对应2个URL，例：添加用户功能对应的URL是userAction_addUI（添加页面的显示）与uesrAction_add。

功能的使用许可，也就是某URL的访问许可。

分配权限就是指定用户可以访问哪些URL（白名单）。

每个功能应对应一个唯一的名称，以便用户分配权限时看到的是名称，最终关联的还是URL。

--------- 举例 --------

资源：用户

*** 作：增、删、改、查、初始化密码

资源+ *** 作 = 权限

用户增userAction_addUI, userAction_add

用户删userAction_delete

用户改userAction_editUI, userAction_edit

用户查userAction_list

用户初始化密码userAction_initPassword

-----------------------

三、设计实体

权限分为三级：顶级菜单、二级菜单、右侧页面中的链接。

选中一个权限时，应同时选中所有直系上级的权限。

取消一个权限时，应同时取消他所有的下级权限（所有子孙权限）。

取消同级的所有权限时，就同时取消他们的上一级权限。

开发思路：

1）用户登录,登录成功后将登录用户放入Session，并将用户对应的角色和角色对应的权限立即查询

2）左侧菜单数据从数据库中获取

* 通过一个监听器，项目启动时加载权限数据，放入application作用域

* 用户登录成功之后，直接从application作用域中获取权限数据展示

3）左侧菜单按照登录人的权限展示

<s:if test="#session.loginUser.hasPrivilegeByName(name)">

4）在数据库中加入超级管理员，在程序中判断如果当前登录用户是超级管理员，就直接显示所有权限菜单

5）右侧连接和按钮按照权限显示

6）编写自定义拦截器，拦截用户的所有针对Action的请求

1，初始化权限：安装时：执行一次--》完成权限数据库的初始化，分配超级管理员

(用户通过批处理文件进行初始化权限数据表文件）

2，权限数据：即菜单栏的显示----》* 通过一个监听器，项目启动时加载所有权限数据，放入application作用域

* 用户登录成功之后，直接从application作用域中获取权限数据展示

监听器实现：

再web.xml中配置监听器

页面处理：从Session中获取登录用户，根据用户的角色最终获取对应的权限，判断用户的权限是否和当前循环出的权限是否一致，如果一致就显示

3，右侧连接和按钮按照权限显示

————————————————

版权声明：本文为CSDN博主「jongsuk_sun」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/jongsuk_sun/article/details/93081424

---