系统权限管理设计方案(.).docxVIP

OA 系统权限管理设计方案 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 可以对 “组 ”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。 就像是组件一样的可以被不断的重用， 而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权 限的管理，而另外一种则是资源权限的管理， 在不同系统之间， 功能权限是可以重用的，而资源权限则不能。 针对 OA 系统的特点，权限说明： 权限 在系统中，权限通过 模块 + 动作来产生，模块就是整个系统中的一个子模块，可能对应 一个菜单，动作也就是整个模块中 （在 B/S 系统中也就是一个页面的所有操作， 比如 “浏览、添加、修改、删除 ”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个 “权限组 ”， 也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 1 / 8word. 角色 权限的集合， 角色与角色之间属于平级关系， 可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快 速使一类人具有相同的权限， 来简化对用户授予权限的繁琐性、 耗时性。用户组的划分，可以按 职位、项目 或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有 4 种方式 ( 参考飞思办公系统 ) 通过职位 在职位中，职位成员的权限 继承当前所在职位的权限，对于下级职位拥有的权限不可继承。 实例中 ：如前台这个职位，对于考勤查询有权限，则可以通过对前台这个职位设置考勤查询的浏览权，使他们有使用这个对象的权限，然后再设置个，考勤查询权（当然 也可以不设置， 默认能进此模块的就能查询） ，则所有前台人员都拥有考勤查询的权利。 通过项目 在项目中，项目成员的权限来自于所在项目的权限，他们同样不能继承下级项目的权限，而对于项目组长，他对项目有全权，对下级项目也一样。 b) 实例中 ：在项目中，项目成员可以对项目中上传文档，查看本项目的文档 , 可以通过 对项目设置一个对于本项目的浏览权来实现进口， 这样每个成员能访问这个项目了，再 加上项目文档的上传权和查看文档权即可。 2 / 8word. 于 ，因 可以 予 一个 （ 是个特殊的 限，它包含其他各种 限的一个 限包），所有 于本 目有全 ， 目 可以 于 目文档 看， 批， 除，恢复等， 些 限 于本 目的下 目依然有效。 通 角色 角色中的成 承角色的 限，角色与角色没有上下 关系，他 是平行的。通 角色 予 限，是指没 法按 位或 目的分 来 予 限的另一种方式，如：系 管理 ， 料 份 ? 例中 ： 于本系 中，全体人 默 都有的模 ，如我的 件，我的文档，我的日志，我的考勤 ??， 些模 系 成 都 有的，我 建立一个角色 系 默 角色，把所有默 的模 的 加入到里面去， 系 成 都能 些模 。 直接指定 直接指定是通 某个人具体指定一 限，使其有使用 个 限的能力。直接指 定是角色指定的一个 化版， 了是在建立像某个 目的 种角色 ， 省略 建角色 一个步 ，使角色不至于 多。 例中 ：指定某个 目的 ，把 指定 某个人。 位、 目 ： 如果用添加新 工， 工 位、 目 ， 足了 工会自 承所在 位、 目 的 限，不需要重新分配 限的功能。 用 管理 用 可以属于某一个或多个用 ，可以通 用 授 ，来 中的所有用 行 限的授予。一个用 可以属于多个 目 ，或担任多个 位。 3 / 8word. 授权管理 将一个基本权限或角色授予用户或用户组，使用户或用户组拥有授予权限的字符串，如果角色、职位、项目中存在相同的基本权限，则取其中的一个；如脱离角色、职位、项目组，只是取消用户或用户组的中此角色、职位、项目组所授予的权限。用户所拥有的权限是所有途径授予权限的集合。管理员用户可以查看每个用户的最终权限列表。 权限管理 基本操作权限与权限组（基本操作权限的集合）的管理。 OA 权限管理设计的实现 物理数据模型图如下： 4 / 8word. 物理