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

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

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

http://www.blogjava.net/ronghao 荣浩原创,转载请注明出处:)
posted on 2008-03-08 16:31 ronghao 阅读(1436) 评论(0)  编辑  收藏 所属分类: SOA、BPM

只有注册用户登录后才能发表评论。


网站导航:
 
<2008年3月>
2425262728291
2345678
9101112131415
16171819202122
23242526272829
303112345

关注工作流和企业业务流程改进。现就职于ThoughtWorks。新浪微博:http://weibo.com/ronghao100

常用链接

留言簿(38)

随笔分类

随笔档案

文章分类

文章档案

常去的网站

搜索

  •  

最新评论

阅读排行榜

评论排行榜