审批流程的设计与实现和OA系统权限设计
一、审批流程的设计与实现

在审批过程中可能多个部门审批一个文件,同时还有些约束,比如金额的限制,数量的限制等等.
用"采购申请单"来说明:
申请人填制完申请单后,由部门主管审核,再由部门经理批准,然后再由采购批准,"采购申请单"才
算是批准完成,
但其中的问题是:"申请人"是多个部门的,每个部门有自己的主管和经理,在审批过程中,
只有自己部门的主管和经理才能收到相关的申请.
如何实现这样的流程设计呢?
以前曾做出过类似的,但由于没有加入模块限制,不是很灵活,不知大家有什么好的做法,
可以设计为每个模块通用的?

二、OA系统权限设计

在系统权限设计中，我现在采用的是模块权限设计，比如有一个组织结构的模块，分别会有查看、添加、删除、修改以及其他权限多种不同权限，如果页面是分开的好办，如果同一个页面中包含有修改、添加，我怎么来实现这个权限设计，还有如果我想网站前台给模块添加权限，怎么在后台预留权限呢！

第一个问题前面有人提到过，但是没有说怎么实现的，就这两个问题我再次请教大家，谢谢各位的指教！
------解决方案--------------------
1、审批流程的设计与实现，解答：既然你申请审批的过程会涉及到多部门 多人审批，那可以在选择审批人员的时候读取所有人员，从中去选择拥有此单审批权限的人，在发送审批操作，对应的审批人全部审批通过的话，此单才算审批完成，中间有一个人审批不通过，此单就得被返回到“审批退回”的状态。


2、OA系统权限涉及，解答：可以分角色权限去控制菜单和模块功能；






------解决方案--------------------

引用:

但其中的问题是:"申请人"是多个部门的,每个部门有自己的主管和经理,在审批过程中,

你的意思是不是指的申请人有多种身份，必须余责成要同时向吴敬中和药店掌柜的申请是吗？那你的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
------解决方案--------------------