oa工作总结范文（十九篇）

oa工作总结范文（十九篇）第一篇范文：OA项目总结组织机构管理模块请描述一下你做的组织机构管理模块描述思路：1、组织机构模块的基本需求a)本模块主要管理公司、子公司、部门、岗位、员工的信息b)公司下面可以创建子公司、部门c)部门下面可以创建子部门、岗位或员工d)岗位下面可以创建员工（即员工可以属于某个岗位）e)公司、部门、岗位、员工形成一棵组织机构树，要求使用树型方式来展现和管理2、组织机构的总体设计思路a)公司、部门、岗位、员工可以看成同一种类型：Partyb)在Party上实现树型结构（父子关系）c)其它类型：公司、部门、岗位、员工均继承Party（请画出类图）3、组织机构的实现技巧a)利用jQuery的jsTree实现组织机构树b)利用jQuery的treeTable实现列表（AJAX、查询、分页）c)在组织机构树中显示公司、部门、岗位的信息，点击公司、部门、岗位，则可以显示其详细信息，及其下面的所有员工（利用hibernatefilter避免在树上显示员工信息）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），我们定义资源的时候，把这个资源对应的操作映射到某一位上，规定在这一位上取1表示允许执行那个操作，而取0表示不允许执行那个操作。e)这样，在授权的时候，我们直接改变相应操作的状态位的取值即可；在认证的时候，直接判断相应操作状态位的取值3、权限管理的实现技巧a)在实现上，对于授权，我们界面上用jQuery和jQuery的插件jsTree来呈现菜单树，在菜单树的前面显示一个CheckBox框，打勾表示允许，打叉表示拒绝；同时也做了一些右键点击显示上下文菜单，方便客户执行各种功能b)jsTree没有打叉这种显示方式，为了满足我们的要求，所以对jsTree插件做了一些扩展（主要是修改它的js文件和c文件、图片等），以便能支持更强大的显示方式。c)因为我们把系统中的各种Action类及其方法，看成是各种资源及其操作，为了方便管理，我们利用Spring提供的API搜索具备某些特征的Action类及其方法（特定的命名及特定的注解），将这些信息插入数据库，这样便可以将其用于授权和认证。d)在认证的时候，我们实现了两种方式的认证：i.第一是根据授权，能够把没有授权的菜单项屏蔽，也能够把没有授权的功能按钮屏蔽；ii.第二，因为第一种认证方式会有一些安全性问题，比如客户可以绕过功能按钮，直接在浏览器输入某个功能的地址，为了避免这种问题，我们在后台也做了认证，根据当前请求的是哪个类的哪个方法，编写拦截器，判断当前登录用户是否具备这个权限，如果没有这个权限，就不允许执行这个操作！e)InitService和XMLf)自定义注解，利用Springde的API扫描类（大概说出一两个类名）4、我们这个设计的优点在哪里a)因为抽象出了主体和资源这两个概念，核心的授权和认证代码依赖于这两个概念，而不是具体的哪个主体或资源。所以，能够更灵活的支持主体和资源的扩展，比如假设以后客户还想要给用户分组，按照分组来给用户授权，那么只需要实现一个新的主体类型即可，核心的授权和认证的代码无需变化。b)权限控制的粒度更细，因为我们用一个int来表示操作的允许状态，这就意味着，我们能支持在某个资源上的至多32种操作，在设计上无需做变化。一个资源上的操作一般不会超过32种操作，一般来说也就是添加、更新、删除、查询，以及在这个基础上更加细分的一些操作而已，很少会超过32种操作。即使是极端情况，超过了32种操作，那么我们的核心设计也无需变动，无非就是把int换成一个long类型即可（支持64种操作）。c)我们还能支持细粒度的操作权限继承关系：i.比如针对“公司管理”这种资源，假设它有六种操作：添加公司信息、删除公司信息、更新公司信息、查询公司信息、添加子公司、删除子公司；我们可以把这些权限授予比如“张三”这个用户。在授权的时候，我们可以细化到这种程度：1.明确规定：允许张三查询公司信息、更新公司信息2.明确规定：不允许张三添加公司信息、删除公司信息3.至于张三是否能执行添加子公司和删除子公司这些操作，我们可以不做明确规定，而是由其所拥有的角色，或其所属的部门、岗位的权限来决定，这称为“权限的继承关系”，针对这种需求，在ACL中，我们设计了一个额外的属性：aclTriState，用来表示某种操作的权限是否是继承下来的。5、我们这个设计的缺点在哪里a)角色之间没有考虑父子关系，如果考虑父子关系的话，会更加便于授权，比如假设有一个角色为“普通员工”，另外一个角色是“档案管理员”，如果把普通员工看成是档案管理员的父角色，则意味着档案管理员这个角色的权限将可以继承普通员工中的权限（为什么没有实现这个设计呢，客户认为没有必要，因为系统中的角色数量比较少，如果这样设计的话，反而会增加客户操作的难度，无需过度设计）b)我们还没有实现更细粒度的数据级的权限控制，比如，我们目前通过权限控制系统无法实现如下需求：规定张三可以查看所有部门的员工信息，但只能对本部门的员工信息执行添加、删除和修改操作。没有实现的原因是：客户目前这方面的需求还不是很多，因此，没有必要在权限控制系统中实现。实现上述需求，我们是将这些逻辑写到了具体的代码中，而没有通过权限控制系统进行统一的定义。这也是大部分权限控制系统的实现策略。工作流模块请描述一下你做的工作流模块描述思路：1、工作流模块的基本需求a)请描述2、工作流模块的总体设计思路a)把JBPM嵌入OA系统（如何实施的？具体过程？大概有哪些配置？）b)表单管理、流程管理、WorkEntity、WorkApprove、EntityProperty（动态表单）3、工作流模块的实现技巧a)引入jbpmeditor之后，对它做了一些定制开发（支持中文，动态表单的关联）b)其它？4、我们这个设计的优点在哪里a)对JBPM的扩展i.自定义JBPM变量解释器ii.可以给角色、部门、岗位分配任务，抛弃了JBPM中简单的User-Group这种组织结构模型，使用了OA中的组织结构模型iii.实现了自由流（如何实现的？）iv.利用自定义节点实现了会签的决策（如何实现的？）b)动态表单设计方案5、我们这个设计的缺点在哪里a)在流程定义的界面上，没有实现会签节点的定义b)在动态表单设计界面上，无法直接添加一些动态的组件（比如无法通过拖拽的方式添加一个人员列表等等）c)没有实现流程的监控第二篇范文：OA工作流程OA使用流程一、法务1、OA申请用印审核法务服务流程：选择《用印审核类-法务审批》，内容包括：（①集团及子公司公章、合同章、法人章、；法人签字章；法人及股东签字；④董事会章）填写申请原因，上传电子版附件，设置集团法务部为第一审批人，原则上三日内完成初审，下属子公司的设置总经理办公会成员（院长、副院长、财务主任）为第二审批人，集团公司的设置总裁办公会成员（董秘、财务总监、副总裁、总裁、董事长）为第二审批人，原则上均二日内完成终审，知会办公室、财务部存档或文件流转。法务部定期每周三办公，原则上提交三日内完成回复，特殊情况另行沟通，特事特办。2、OA申请运营规划法务服务流程：选择《运营规划类-法务审批》，内容包括（参与决策，为公司的经营、管理决策提供法律上的可行性、合法性分析和法律风险分析；②按照集团发展战略和目标，拟订、建立、检查和改善集团及下属子公司法务组织架构；）填写申请原因，上传电子版附件，设置法务部为第一审批人，原则上三日内完成初审，设置总裁办公会成员（董秘、财务总监、副总裁、总裁、董事长）为第二审批人，原则上二日内完成终审，知会总裁办存档。法务部定期每周三办公，原则上提交三日内完成回复，特殊情况另行沟通，特事特办。3、OA申请风险管理法务服务流程：选择《风险管理类-法务审批》，内容包括（①参与集团及下属子公司重大经济活动的谈判工作，提出减少或避免法律风险的措施和法律意见；②审查、修改、会签经济合同、协议，协助和督促集团对重大经济合同、协议的履行；③协助集团公司及各下属公司建立、完善各项规章制度，对集团及各下属公司中容易出现漏洞和滋生腐败现象的部门加强管理，逐步建立完善的监督约束机制；④在集团整体层面，把握集团项目运营以及公司经营中的整体法律状况，控制集团整体法律风险，建立法律风险防范和预警机制；⑤加强常规性环节法律风险的控制，同时为集团的内控体系提供法律支持；⑥修订和完善合同管理制度，指导下属公司及其他业务部门制订合同管理实施办法；制订公司自用合同的格式文本；会同相关部门对重大、重要合同进行评审并出具审查意见；⑦监督、检查各部门合同签订、履行、管理情况；⑧参与合同纠纷的调查处理，制定解决方案。就经营、管理等业务方面提供法律建议和法律风险提示；⑨企业工商登记以及商标、专利、