审批流程的设计与实现和OA系统权限设计
一、审批流程的设计与实现
在审批过程中可能多个部门审批一个文件,同时还有些约束,比如金额的限制,数量的限制等等.
用"采购申请单"来说明:
申请人填制完申请单后,由部门主管审核,再由部门经理批准,然后再由采购批准,"采购申请单"才
算是批准完成,
但其中的问题是:"申请人"是多个部门的,每个部门有自己的主管和经理,在审批过程中,
只有自己部门的主管和经理才能收到相关的申请.
如何实现这样的流程设计呢?
以前曾做出过类似的,但由于没有加入模块限制,不是很灵活,不知大家有什么好的做法,
可以设计为每个模块通用的?
二、OA系统权限设计
在系统权限设计中,我现在采用的是模块权限设计,比如有一个组织结构的模块,分别会有查看、添加、删除、修改以及其他权限多种不同权限,如果页面是分开的好办,如果同一个页面中包含有修改、添加,我怎么来实现这个权限设计,还有如果我想网站前台给模块添加权限,怎么在后台预留权限呢!
第一个问题前面有人提到过,但是没有说怎么实现的,就这两个问题我再次请教大家,谢谢各位的指教!
------解决方案--------------------1、审批流程的设计与实现,解答:既然你申请审批的过程会涉及到多部门 多人审批,那可以在选择审批人员的时候读取所有人员,从中去选择拥有此单审批权限的人,在发送审批操作,对应的审批人全部审批通过的话,此单才算审批完成,中间有一个人审批不通过,此单就得被返回到“审批退回”的状态。
2、OA系统权限涉及,解答:可以分角色权限去控制菜单和模块功能;
------解决方案--------------------
------解决方案--------------------这个比较复杂,我们刚好有类似的工作流系统,属于比较核心的东西
------解决方案--------------------[Quote=引用:]
引用:
1.你那个申请人兼顾多个部门角色对吧,我想问下,你的那个申请审批的过程是自选审批人发送审批呢?还是说程序设定部门审批人,不需要申请人选择由谁审批就直接发送审批呢?如果是自选审批人,那你的问题就很简单,都不用管申请人的多角色问题造成审批信息泄露。但如果是不需选择审批人那种,那你可以根据申请人角色的不同,应该有模块权限的划分,比如他是市场采购人员的角色时,他可以做采购申请的操作,自然审批人事采购部主管和经理,如果她还作为行政人员角色时,他肯定只能做一些信息流转审批类的操作,自然审批人的话就是行政主管或经理,再不行的话,你可以在填单申请时加多一个部门选择项,那样根据部门就知道是该由谁审批啦?
------解决方案--------------------审批加入提交对象
在提交对象上做筛选
------解决方案--------------------这个审核得控制好审批顺序,这个顺序可以通过一个字段来决定,部分级别高的也不能审批级别低的;
权限可以添加一个权限表,这个里边存放着不能的用户权限,这些权限对应着角色;角色下又有用户;
即:
先对角色进行分配权限;
再对用户分配角色;
页面展示时会去判断一下有没有这个权限,没有就做没有处理,有则把页面元素展示出来;
------解决方案--------------------工作流部分
1.请阅读《编译原理》搞明白啥是文本解析和语法树
2.请了解如何把 if---else ,while 解析成语法树
3.请了解如何把语法树解析成对象
4.请了解如何把语法树对象保存为xml
5.请了解BPM,BPMN,BPML相关xml定义
知道上面这些东西,其实就可以做工作流了。了解前4项基本就可以做一个不太通用的工作流引擎,而第5项则是做通用工作流引擎的基础
==============================================
权限部分
1.了解撒是AOP和动态代理
2.了解如何使用MEF做AOP编程
3.了解如何进行切面注入和方法拦截
权限本质上包含两部分
一权限树(包括树状表示,分组继承,特例权限)
二AOP代码切面注入,方法拦截
其中第一部分是很常见的东西,本质上他和一般B2C软件的商品属性是一个故事
但是与商品属性不同的是,商品属性只用数据结构即可描述清楚,而权限必须在数据结构的基础上加入硬编码控制,这方面可以使用AOP编程进行动态植入和配置
ps:我所回答的是做标准产品化的思维和步骤。如果就事论事不考虑后续开发,其实可以直接硬编码
------解决方案--------------------楼上一说把人家孩子都吓着了,以后笔都不敢落了,科班研究的东西就是牛,那产品不是拿来用的,是用来欣赏的。其实如果你不想做通用产品也很简单,很多土办法可用。偏方治大病嘛。
就权限管理而言,分为两个范畴:
1)功能操作权限-比如谁有权设计流程、谁有权修改用户等,
这些权限直接与界面的按钮相关的,一个土办法就是把功能编上号,存到数据库里,功能还可以分组,与用户或角色关联上就可以,在点击按钮后就会进入功能的入口,这时对每个功能入口硬编码,判断编号与权限是否匹配即可。
2) 业务流转权限,比如谁有权查看业务记录、谁应该操作某个步骤等等。
这里也有两种类型:
- 业务操作权(查看记录、设置权限等),这可以设计的非常复杂,以解决动态的权限定义问题,也可以设计的非常简单,只有管理员可以做业务操作就行了呗。
- 步骤操作权: 对于步骤操作权,可以看看某个帖子:http://blog.csdn.net/comsci/article/details/6642856
------解决方案--------------------就大型企业的权限管理,你考虑的过于简单了,企业的部门设计是非常复杂易变的,现有的所有设计思路都有问题,导致用户处理起来很“别扭”,有个土办法可以供你参考一下:
http://blog.csdn.net/etudiant6666/article/details/6260502
------解决方案--------------------一种通用的做法:工作流+电子表单+人事系统;不过开发这套东西非常的复杂,属于一些软件公司的核心价值所在。
------解决方案--------------------1.你的系统没有人员组织结构表吗?
2.另外新建一张表,保存每个页面需要控制权限的按钮,给一个唯一id,设置parentid为页面id
------解决方案--------------------