一些工作流管理权限的分析

既然是与用户相关的权限，那么权限的表现则一定与UI紧密相连。工作流管理系统里，用户与工作流的交互界面有四种：
1、流程设计器
流程设计器的功能比较单一：定义或更新流程定义。里面涉及到包、模板和版本的概念。资源即流程模板（例如发文模板、收文模板），权限可以细分为：维护、只读以及不可见。
2、流程管理控制台
对流程实例（包括活动实例和工作项实例）进行管理。这里对资源的划分有两种方式：操作和数据。从操作来分比较琐碎，例如：流程实例的挂起、终止、恢复、跳转，活动实例的挂起、终止、恢复等等，当然可以做一种集合，例如：对流程实例的管理、对活动实例的管理、对工作项实例的管理、时间服务的管理等等。从数据划分则很好理解，例如：发文的流程实例、收文的活动实例等等。两种方式的组合构成最终的权限。
3、工作项列表
这个似乎没什么好说的，工作项直接分配到用户、部门和岗位。
4、与流程相关的业务数据
用户对业务自身的权限以及不同流程节点对业务的权限。看问题的两种方式。业务数据处于流程中时由流程决定权限，例如拟稿时可以操作哪些字段，审批时是否可以上传附件等等。流程结束后，业务数据归档，此时的权限由业务权限+流程权限组合。简单的一个例子：普通用户A可以在发文模块里看到自己参与过的所有发文文件，发文管理员B则可以看到发文模块里所有的发文文件。

结合具体的业务需求：
1、主控岗位的提出。例如发文管理，存在主控岗位，可以对所有的发文流程进行管理，催办、督办等等。
2、大集中模式下对数据的再划分。还是以发文管理为例，北京公司的发文管理员对北京的发文数据进行管理，上海公司的发文管理员则只能对上海的发文数据进行管理。

最终的权限分类：
1、流程设计器里流程模板的可见与不可见。可见即可维护。
2、流程管理按操作来分显得没有实际的意义，用户关注的是业务数据即操作的范围。流程实例（活动实例）的可见与不可见。可见即可操作。更进一步说，用户甚至根本都不会登录到流程管理控制台，他会倾向于在业务菜单里有自己相应的流程管理功能，例如在发文管理里增加发文催办、督办等等。
3、不用
4、往业务权限表里增加流程参与者的权限信息。

总结：总是感觉工作流管理部分的权限不是那么的必要，流程定义的复杂度让最终用户很难直接使用，流程实例的管理更多的是契合到业务中去，而这种契合表现则是流程数据按业务进行划分后的管理。

 

评论

1 楼 ronghao 2008-03-11  

恩，其实有一部分没有贴出来。其实用户自己的动态维护授权是很简单的，管理员授出最初的权限，用户即可对自己拥有的资源进行再授权，这个需要对授权的资源做一次过滤就好。另外我在想的是资源的粒度问题。

至于“业务数据处于流程中时由流程决定权限”，这个虽然有些简单，但是还是基本满足业务需要的。你的情况可能是这样：同样是审批节点（同一个节点），不同用户对业务表单的权限还存在差异。这个就涉及到权限按一定规则的叠加。这是最好的方式，但是也会增加系统的复杂度