因工作需要，做了个工作流系统，用于本部门对其他部门提供服务的接口。做之前在网上找了些资料，也研究了django的一个工作流框架：django-workflow。但感觉很不好用，不是很灵活。于是按照自己的理解自己做了。思路如下：
术语定义如下：
工单：具体的待处理事项，用户新建的是工单，工单按照工作流的设计来实现不同状态不同处理人之间的流转
工作流：即工作流的设计，定义了工单的审批链、各状态的处理人、各状态可以执行的操作（提交、保存，处理完成，退回，关闭等等）、每个状态下显示哪些字段、哪些字段可以在哪些编辑。
工作流处理过程可以理解为工单状态的变化，如一个工作流处理过程中可以有：发起人新建中、发起人编辑中、部门经理审核中、技术人员处理中、发起人验证中、结束等状态，每个状态对应相应的处理人（如部门经理审核中这个状态下只有部门经理才可以处理该工单）。如用户在新建工单的时候处于“发起人新建中”，（用户）提交后工单处于“部门经理审核中”， 部门经理（即“部门经理审核中”状态的处理人）审批通过后，工单的状态变更为“技术人员处理中”。
于是可以设计表结构如下：
1、工单表(myworkflowjob)：字段可以包括 标题、创建人、当前处理人，创建时间、详细信息、等， 然后与设计的工作流关联："工作流"字段
2、工作流表(myworkflow):字段包括工作流名称、描述、流程图、提醒方式（短信、邮件、短信+邮件、不提醒等等）、初始状态
3、工作流状态表(myworkflowsstate)：字段包括状态名称、该状态下的处理人类型（如部门、个人，角色，职位等等）、具体的处理人（如类型为部门，那么就可以为财务部，行政部等等。如为个人那就是具体的人名字），工单接单方式（主动接单、系统随机分配）、是否为最终状态、关联的工作流
4、工单流转表(myworkflowtran)： 字段包括名称（即操作名称：如提交、保存、退回、关闭等）、初始状态、目标状态
5、日志表(myworkflowdisposelog)：用于记录处理人各种操作，字段可包括：操作名称、时间、处理意见。
6、工单查看页面表单的展现表(myworkflowdisplayfield)：用于定义工单查看时表单中显示哪些字段，字段包括：工作流(myworkflow_id)、字段名
7、工单处理页面状态字段表(myworkflowstatefield)：用于用户处理工单时候页面总显示那些字段。字段包括：状态(myworkflowsstate_id)、字段名、读写权限（只读、可编辑）
8、工单类型与工作流关联表(myworkflowtype)：用于不同工单类型与工作流的关联。达到用户选择不同类型的工单后系统对其使用相应的工作流及相应的表单。字段包括名称、上级类型、工作流(myworkflow_id)
本项目组多工作流使用一个工单表。所以初始化需要将必要的字段都写到该表中
新建（配置）工作流思路：
新建工作流名称(表myworkflow)-->添加状态、该状态下的处理表单要显示的字段及是否可以编辑（表myworkflowsstate）--->设置初始状态（表myworkflow）---->设置工单流转（即工单流转表myworkflowtran）
设置工单类型（请假、监控处理、权限申请等等）与工作流之间的关联即表myworkflowtype
工单处理逻辑:
1、在新建工单的页面中，用户选择工单类型，后台根据“工单类型与工作流关联”的表来确定使用的工作流
2、根据确定的工作流弹出工单信息输入界面（内容包括标题、详细信息、附件等等，具体表单字段通过改工作流的初始状态来确定），根据工作流的初始状态查找状态表来确定可以执行的操作（提交、保存，处理完成，退回，关闭等），将这些操作作为该界面的按钮，用户填写完工单基本信息后点击相应的操作按钮，来实现状态的流转。后台结合前端提交的数据并生成工单必备的字段信息（工单创建时间、创建人、流水号等），将这些信息写到工单表里。其中当前状态、当前处理人通过工单流转表和状态表来确定 用户执行相应操作后导致的属性变化
3、通过步骤2中插入到工单表中的数据“处理人类型”、“当前处理人”来确定哪些人有权限处理这些工单。 如果处理人类型不是“个人”,那就根据这条数据中的“当前状态“来确定接单方式，主动接单（有权限的人先执行接单操作将当前处理人变更为自己再处理），系统随机分配（后台在执行状态流转时随机设置工单当前处理人为符合条件的某一个人）
3、查看工单的界面通过 “工单查看页面表单的展现表”来确定 显示哪些字段
4、处理工单的界面通过“工单处理页面表单的展现表” 来确定显示哪些字段，以及哪些字段可以在处理过程中再次修改
效果图:
