一二三文档管理系统设计——2.文档管理系统中权限控制实现方案

整体思路

文档管理的权限控制与常规的功能权限和数据权限都不同,有其自己的特色,异常复杂。

1.权限项相对固化,对于文件夹,有创建、删除、更名、查看、复制、移动等操作项;对于文件,则通常有上传、下载、删除、更名、预览、复制、移动、分享等操作项。
2.需要对组织机构进行授权,通常企业内部部门内文档共享,部门外需控制授权。
3.需考虑权限继承,两个层面,一是对某一文件夹授权,则对该文件夹的子文件夹及文件也应自动拥有权限;二是对某一组织机构授权,则该组织机构的子组织机构也应自动拥有权限
4.文件夹及文件均属于动态变化,因此不能在权限配置环节将资源项(文件夹或文件)的权限项持久化到库表,而只能保存权限设置信息,动态计算是否拥有权限,这种方式同时考虑了人员调动问题,例如某人员从A部门调动到了B部门,如固化资源权限,则会出现依旧能访问A部门文档,而无权访问B部门文档的情况。

从业务和管理角度考虑,控制到文档的权限并没有多少意义,并会造成权限初始化和权限维护的复杂性和工作量,基于该角度,将文件夹作为权限控制的单元,文档权限则来源于所属的文件夹权限,无需单独配置和维护,高效易用。

设计方案

文件夹规划

1.文件夹规划要合理规范,根目录下设置以下三个主目录:
a)公共文档:公司内部共享,所有成员默认具备查看、下载权限,管理员具备上传和删除功能,可按内容进一步划分子目录,如规章制度、人力政策等
b)部门文档:部门内部共享,所有该部门成员默认具备所有权限;若希望精细化管理,则以模块为维度进行文件夹的划分和权限控制的最小颗粒度
c)小团队文档:团队内共享,如以项目或小组为单位的文档,团队内共享。
d)个人文档,职责为个人专有,相当于分配给个人的私人网盘,只允许相应人员自己管理。个人专属文档实际意义不大,放到个人办公电脑即可,放到远程主要起的作用的是容灾备份,该功能优先级降低,暂不实现。

权限设置模式

1.部门文档需对组织机构授权,如使用用户组管理,则部门人员变动时,需要同步调整人员从属的用户组,及时性和一致性难以保证。

2.公共文档需要按用户组授权,只需要两类用户组,一是普通员工,可以查看和下载,二是管理员,可以上传、修改和删除。

对于普通人员,系统建一个普通员工用户组,所有人员均放到该用户组下(新员工入职,将该员工加入该用户组也作为权限初始化工作的一部分),同时该用户组分配系统菜单权限。
对于管理员,则视实际情况考虑建1个或多个,若公司规模较小,共享文档均由同一部分人维护,则建1个用户组即可;如需要进一步分类,如规章制度、人力政策等,需要分派不同管理员,则需要建多个用户组。

3.小团队文档,可能有保密需求,不想开放给团队外人员,并且团队成员可能跨越多个组织机构,因此采用按用户组授权模式。

综上,权限的配置实际有两种模式,一是按组织机构;二是按用户组。

按组织机构授权

因为存在进一步的权限项(如创建文件夹、下载文件)设置,因此不能直接弹出组织机构多选控件,需要单独实现一个页面,同时,对同一文件夹,不同组织机构可能存在不同权限,因此组织机构树不适合采用多选方式。

此外,权限维护人员还需要查看当前文件夹的权限情况。

综上,最终设计界面是左边为单选模式的组织机构树(不显示复选框),右侧显示权限项和保存按钮。

难点:因存在继承关系,右侧权限项是直接显示权限配置表中存储的权限关系,还是动态计算?
方案:按照规划,考虑到权限维护人员的维护工作量,推荐优先按大范围的文件夹授权,因此不建议权限维护人员直接为一个文件夹设置一个很小的组织机构,否则将会给系统运维带来压力,并且给系统权限计算带来性能问题。

注意,这里不进行动态计算的是组织机构层级继承权限,但文件夹不能只取当前标识,而是取所有父节点标识,计算动态权限。

这种方式,如查看某文件夹整体授权情况,需要用户从顶层组织机构向下查看,如只查看某一特定组织机构是否有权限,可以从组织机构这一层级逐级往上找。

对于上面规划的以组织机构作为权限分配的主要方式,实际上对应关系非常简单,用户组树与文件夹树,都参照组织结构创建对应的节点,一一对应即可,需要注意的是从最初规划阶段即确定以哪一级组织机构间作为权限的最小单位,如公司级别、部门级别、模块级别……

按用户组授权

该模式无需考虑用户组的继承关系,因此技术实现比按组织机构实现简单,方案与实现与组织机构类似。

权限持久化

权限配置有两种方式,按组织机构和按用户组,持久化有两种方案,一是新建一张表,增加一个字段区分是哪种模式,二是分别创建一张表

经评估采用方案1,简便实用,以后扩展按人员授权,无需再增加库表(但从软件设计角度而言,增加新的授权类型,需要对原代码修改,违背开闭原则)

设计方案(已废弃)

新建一张库表,为文档权限配置表
资源标识:这是存放的是文件夹标识
授权类型:按组织机构、按用户组
对象标识:这是存放的是组织机构标识或用户组标识
以下权限项各对应1个字段
创建文件夹
更名文件夹
删除文件夹
查看文件夹
上传文件
更名文件
下载文件
删除文件
预览文件

问题:权限项是否考虑使用单字段,每个位1代表有权限,0代表无权限,通过位运算提升性能?
解决:性能需要测试才能评估出来,不过该方案已废弃,采用下面方案位运算方式不再适用。

优化后设计方案

以上方案,当扩展新的权限项,如打印文件时,需要更改库表结构,程序变动也比较大,改变存储结构
将权限项独立出来(不建库表,作为数据字典管理),权限配置表简化为

资源标识:这是存放的是文件夹标识
授权类型:按组织机构、按用户组
对象标识:这是存放的是组织机构标识或用户组标识
权限项:取值为以下编码
创建文件夹
更名文件夹
删除文件夹
查看文件夹
按角色授权
按组织机构授权
上传文件
更名文件
下载文件
删除文件
预览文件

非正常操作考虑

虽然系统对使用方式做了规划,但要考虑用户未完全按照规范操作下,系统的健壮性,以下两种情况评估:
1.对部门文档按用户组授权,该方式可以一定程度上实现跨部门共享文档的目的。
2.对公司文档按部门授权,这么做没什么意义,因为默认所有员工均对公司文件夹下的文件具有查看权限,有一点风险在于按部门授权且允许上传、编辑、删除等,将造成权限扩大,该点可以从管理上规避。
3.对小团队文档按组织机构授权,基本无影响,通常来说,对组织机构授权相当于所有组织成员可以访问这些文档,将该目录放到规划中的部门文档里更好。
有一种情况例外,即整体规划时确定将部门作为部门文档权限划分的最小单元,这时候如果部门内部的模块,需要对部分文档内部成员可访问,部门内其他成员不可访问,则可以放到小团队文档中,其实也相当于将整个模块作为1个小团队,这么做反而是一种解决上述需求的可行的变通方案。

权限处理

应用场景1

用户打开我的文档菜单,显示文档结构树
处理逻辑:
根据权限控制整体思路,文件夹的可见性不进行权限控制,因此正常加载即可。

应用场景2

用户执行某一操作,后端验证是否具备相应权限
a)创建文件夹、删除文件夹、更名文件夹、上传文件,都是对文件夹操作,直接获取该文件夹标识
b)文件更名、下载、预览,先找到归属的直接上级文件夹标识

处理逻辑:
既然权限配置有按组织机构和按用户组两套模式,则获取当前用户的权限项,需要分别处理,然后取并集
a)按用户组,根据人员,找到所有用户组,根据用户组找权限项
b) 按组织机构,根据人员,找到所有组织机构(从直接从属组织结构找到根组织结构),根据组织机构找权限项
c)合并以上两步找到的权限项
d)判断当前文件夹标识及操作项是否包含在权限项列表中,如在,则运行执行,否则提示无权限。

应用场景3

文件夹和文件移动与复制对授权的影响

权限设置当前配置的文件夹标识,文件的权限由其所属的文件夹决定,因此,移动和复制文件无需权限做处理。
文件夹的复制,会产生新的标识,默认情况下,也会跟随父文件夹,同样无需权限处理。
文件夹的剪贴,标识不变,如不处理原权限配置,则会产生问题,例如:
A->B是父子文件夹关系,用户组甲原本对B文件夹有权限,对A文件夹无权限,但若通过移动,将父子关系对调,则会造成权限扩大,从安全角度,应在移动后将其直接的权限配置信息清除。

但是一些文件夹的移动,只是内部重新组织,不希望调整权限,例如按用户组分配权限的某项目A,从华东地区调整到华北地区文件夹下,但团队成员并没有变化,这种情况下清空权限反而需要额外再赋权。

以上两种情况,系统无法识别,需要人工判断,因此附加一个复选框,含义是保留权限配置,默认勾选,由权限维护人员自行决定是否要重新授权。

开源资料

系统名称:一二三文档管理系统
简介: 企事业单位一站式文档管理系统,让组织内文档管理有序,协作高效、安全可控
资料:csdn专栏
开源地址:Gitee
开源协议:MIT
欢迎收藏、点赞、评论,你的支持是我前行的动力。

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

学海无涯,行者无疆

你的鼓励将是我创作的最大动力

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

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

打赏作者

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

抵扣说明:

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

余额充值