oa工作总结（共19篇汇总）.docVIP

　　第1篇OA项目总结 　　组织机构管理模块 　　请描述一下你做的组织机构管理模块 　　描述思路 　　1、组织机构模块的基本需求 　　a) 本模块主要管理公司、子公司、部门、岗位、员工的信息 b) 公司下面可以创建子公司、部门 　　c) 部门下面可以创建子部门、岗位或员工 　　d) 岗位下面可以创建员工（即员工可以属于某个岗位） 　　e) 公司、部门、岗位、员工形成一棵组织机构树，要求使用树型方式来展现和管理 　　2、组织机构的总体设计思路 　　a) 公司、部门、岗位、员工可以看成同一种类型Party b) 在Party上实现树型结构（父子关系） 　　c) 其它类型公司、部门、岗位、员工均继承Party（请画出类图） 　　3、组织机构的实现技巧 　　a) 利用jQuery的jsTree实现组织机构树 　　b) 利用jQuery的treeTable实现列表（AJAX、查询、分页） 　　c) 在组织机构树中显示公司、部门、岗位的信息，点击公司、部门、岗位，则可以显示其详细信息，及其下面的所有员工（利用hibernate filter避免在树上显示员工信息） 　　d) 为了显示某个公司或部门（包括其下级机构）下面的所有员工，我们设计了一个sn，这个sn根据组织机构的树型结构来取值，通过它便可以方便实现查询需求。 e) 利用TreadLocal实现分页参数的传输 　　f) 利用VO设计模式适应客户端对数据格式的特殊要求 　　4、我们这个设计的优点在哪里 　　a) 通过树的方式来管理，一目了然，层次清楚 　　b) TheadLocal设计模式的运用大大降低了分页查询逻辑的封装处理 　　c) 抽象出Party来，便于对所有的组织机构实体进行统一的管理（比如方便我们后面的权限管理模块把所有Party统一对待） 　　5、我们这个设计的缺点在哪里 　　a) 没有实现员工的调动管理（从一个部门调到另外一个部门），此功能在项目二期实现！ 　　b) 员工不允许跨部门（即一个员工只能属于一个部门，而不能同时属于多个部门） c) 在模型上没有规定哪些类型的Party只能放在哪些类型的Party下面，比如，在一般的需求中，岗位下面肯定是不能挂一个公司的。我们针对这种需求，是通过具体的代码逻辑来实现的，而没有办法在一个地方去统一定义这种规则。 i.如果要实现这些逻辑的统一定义，可以参考“责任模式”！ 　　权限管理模块 　　请描述一下你做的权限管理模块 　　描述思路 　　1、权限管理的基本需求 　　a) 系统后台有很多菜单项，同时各个页面上也有很多功能按钮，客户要求我们的系统要能够控制这些菜单项的访问权限，也可以控制到具体每个功能按钮的访问权限 b) 客户要求建立角色的概念（参考RBAC），能够自由定制不同的角色，角色和用户之间是多对多的。 　　c) 权限可以授予角色，然后把角色分配给用户，这样用户就拥有了角色的权限 d) 权限也可以授予某个部门、某个岗位，这样在这些部门或岗位下面的用户就拥有了这些部门和岗位的权限 　　e) 客户还要求权限也能直接授予用户，这样即使拥有相同的角色、相同的部门、相同的岗位，用户的权限也可以是不同的 　　f) 这样，用户自身被授予的权限、用户拥有的角色的权限、用户所属部门或岗位的权限这些要素联合起来判断，才能最终决定用户的权限。 　　g) 因为用户的权限可能从多个角色或部门、岗位中继承下来，而这些角色、部门或岗位的授权极有可能会有冲突，比如一个角色的授权是允许访问，而另外一个角色的授权是拒绝访问，客户要求，如果出现这种情况，就以拒绝为准，即不允许访问。 　　2、权限管理的总体设计思路 　　a) 因为权限可以被授予用户、角色、部门、岗位等等，我们称之为权限控制的“主体”，我们定义了一个接口Principal用来表示主体的概念，用户、角色、部门、岗位等均实现这个接口 　　b) 我们要控制菜单项以及各种功能按钮的访问，我们称这些菜单项和各种功能按钮为权限控制的“资源”，定义了一个SysResource接口来表示资源的概念。 　　c) 菜单项是一种资源；而各种功能按钮最终其实是要访问后台的某个类的某个方法，因此我们把Action类看成是一种资源（称为“操作资源”），各种功能按钮则对应了这个类里面的各种方法，我们把这些方法看成是这种资源的各种操作。 d) 我们定义了一个ACL用来表示哪些资源的哪些操作被授予了哪些主体，ACL中的主要属性包括主体类型（principalType）、主体ID(principalId)、资源类型(resourceType)、资源ID(resourceId)、操作状态(aclState)，其中操作状态是int类型，在Java中，一个int有32位（bit），我们定义资源的时候，把这个资源对应的操作映射到某一位上，规