本文主要是介绍一些工作流管理权限的分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
既然是与用户相关的权限，那么权限的表现则一定与UI紧密相连。工作流管理系统里，用户与工作流的交互界面有四种：1、流程设计器
流程设计器的功能比较单一：定义或更新流程定义。里面涉及到包、模板和版本的概念。资源即流程模板（例如发文模板、收文模板），权限可以细分为：维护、只读以及不可见。
2、流程管理控制台
对流程实例（包括活动实例和工作项实例）进行管理。这里对资源的划分有两种方式：操作和数据。从操作来分比较琐碎，例如：流程实例的挂起、终止、恢复、跳转，活动实例的挂起、终止、恢复等等，当然可以做一种集合，例如：对流程实例的管理、对活动实例的管理、对工作项实例的管理、时间服务的管理等等。从数据划分则很好理解，例如：发文的流程实例、收文的活动实例等等。两种方式的组合构成最终的权限。
3、工作项列表
这个似乎没什么好说的，工作项直接分配到用户、部门和岗位。
4、与流程相关的业务数据
用户对业务自身的权限以及不同流程节点对业务的权限。看问题的两种方式。业务数据处于流程中时由流程决定权限，例如拟稿时可以操作哪些字段，审批时是否可以上传附件等等。流程结束后，业务数据归档，此时的权限由业务权限+流程权限组合。简单的一个例子：普通用户A可以在发文模块里看到自己参与过的所有发文文件，发文管理员B则可以看到发文模块里所有的发文文件。
结合具体的业务需求：
1、主控岗位的提出。例如发文管理，存在主控岗位，可以对所有的发文流程进行管理，催办、督办等等。
2、大集中模式下对数据的再划分。还是以发文管理为例，北京公司的发文管理员对北京的发文数据进行管理，上海公司的发文管理员则只能对上海的发文数据进行管理。
最终的权限分类：
1、流程设计器里流程模板的可见与不可见。可见即可维护。
2、流程管理按操作来分显得没有实际的意义，用户关注的是业务数据即操作的范围。流程实例（活动实例）的可见与不可见。可见即可操作。更进一步说，用户甚至根本都不会登录到流程管理控制台，他会倾向于在业务菜单里有自己相应的流程管理功能，例如在发文管理里增加发文催办、督办等等。
3、不用
4、往业务权限表里增加流程参与者的权限信息。
总结：总是感觉工作流管理部分的权限不是那么的必要，流程定义的复杂度让最终用户很难直接使用，流程实例的管理更多的是契合到业务中去，而这种契合表现则是流程数据按业务进行划分后的管理。
这篇关于一些工作流管理权限的分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
