CN112035861A - 在线文档处理方法、装置和电子设备 - Google Patents

Abstract

本公开提供了一种在线文档处理方法、装置和电子设备，可用于金融领域或其他领域，该方法包括：接收文档处理请求，文档处理请求包括用户标识和文档标识；响应于文档处理请求，确定与用户标识对应的用户属性，并且确定文档标识所标识的在线文档的当前文档阶段；以及基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限，以便给与用户标识对应的用户分配处理权限。

Description

在线文档处理方法、装置和电子设备

技术领域

本公开涉及云计算领域，更具体地，涉及一种在线文档处理方法、装置和电子设备。

背景技术

在过程、方法与系统(Development Operations，简称DevOps)持续交付流水线被业界普遍认同的情况下，开发到运维紧密协作版本持续交付是版本管理的大趋势。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题。相关技术中，与文档相关的多方对文档管理方式存在管理效率、权限准确性以及文档准确性等方面的不足。

发明内容

有鉴于此，本公开提供了一种用于提升多方对文档管理方式的管理效率、权限准确性以及文档准确性等的在线文档处理方法、装置和电子设备。

本公开的一个方面提供了一种在线文档处理方法，在线文档包括至少一个文档阶段，该方法包括：首先，接收文档处理请求，文档处理请求包括用户标识和文档标识。然后，响应于文档处理请求，确定与用户标识对应的用户属性，并且确定文档标识所标识的在线文档的当前文档阶段。接着，基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限，以便给与用户标识对应的用户分配处理权限。

本公开的一个方面提供了一种在线文档处理装置，包括处理请求接收模块、处理请求响应模块和处理权限确定模块。其中，处理请求接收模块用于接收文档处理请求，文档处理请求包括用户标识和文档标识。处理请求响应模块用于响应于文档处理请求，确定与用户标识对应的用户属性，并且确定文档标识所标识的在线文档的当前文档阶段，在线文档包括至少一个文档阶段。处理权限确定模块用于基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限，以便给与用户标识对应的用户分配处理权限。

本公开的另一方面提供了一种电子设备，包括一个或多个处理器以及存储装置，其中，存储装置用于存储可执行指令，可执行指令在被处理器执行时，实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，计算机程序包括计算机可执行指令，指令在被执行时用于实现如上所述的方法。

本公开实施例提供的在线文档处理方法、装置和电子设备，将在线文档分为多个文档阶段，同一个用户针对不同的文档阶段具有不同的处理权限，这样就形成在线可流转的文档，使得可以基于用户属性和在线文档的当前文档阶段确定当前用户针对该在线文档的处理权限，实现了流水线式的、多方可见的、多方共同参与的维护方式，实现对在线文档在各阶段准确性的把控，并通过对在线文档即验证即确认的方式，实现如版本文档发布投产的灵活性和高效性。

本公开实施例提供的在线文档处理方法、装置和电子设备，提供统一的线上模板，提升版本文档的编写规范性，提高版本文档的质量，从文档创建编辑直到投产实施完成，全部通过统一系统进行操作，替代线上线下交替的文档维护方式，版本文档问题不再需要其他系统流程反馈，减少人工操作，降低版本文档维护成本。

本公开实施例提供的在线文档处理方法、装置和电子设备，对各角色人员进行权限控制，对所有角色放开版本文档查看权限，使版本文档全生命周期所有人员可见，文档维护过程中透明化，可以实现提前对环境进行准备，提高测试及投产的效率。

本公开实施例提供的在线文档处理方法、装置和电子设备，多个合作方在文档流水线过程中各自在各文档阶段的处理权限不同，以保证文档权限准确性，又共同对同一份文档进行维护确认，保证文档的准确性，实现文档即确认即投产，打破三方工作壁垒，使版本文档问题能够快速得到响应，提升开发到运维的协助性，确保与文档对应的产品的投产安全。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了现有技术中在线文档处理方法的逻辑示意图；

图2示意性示出了根据本公开实施例的在线文档处理方法、装置和电子设备的应用场景；

图3示意性示出了根据本公开实施例的可以应用在线文档处理方法、装置和电子设备的示例性系统架构；

图4示意性示出了根据本公开实施例的在线文档处理方法的流程图；

图5示意性示出了根据本公开实施例的第一映射关系的示意图；

图6示意性示出了根据本公开实施例的文档标识的示意图；

图7示意性示出了根据本公开实施例的文档流水线的示意图；

图8示意性示出了根据本公开实施例的文档阶段关联信息的示意图；

图9示意性示出了根据本公开实施例的在线文档处理装置的框图；以及

图10示意性示出了根据本公开实施例的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。

图1示意性示出了现有技术中在线文档处理方法的逻辑示意图。

如图1所示，现有技术中在线对文档进行处理时，为了保证不同用户处理的在线文档是最新的、内容是连续的，通常需要用户先下载文档，在本地进行编辑，然后将编辑后的文档进行上传，以供其它用户进行下载和编辑。

然而现有技术的文档处理方式无法满足一些场景下的特殊需求。例如，在DevOps持续交付流水线被业界普遍认同的情况下，开发到运维紧密协作版本持续交付是版本管理的大趋势。传统的开发、测试和运维三方对版本文档分阶段的管理方式存在效率和权限准确性以及文档准确性等方面的不足。例如，在日常的版本管理过程中，经常会遇到以下问题。

一方面，版本文档由研发人员编写完成后，随版本交付给测试人员，以及在测试完成后版本最终发布给运维人员之前，测试人员和运维人员都不清楚具体需要做哪些环境准备，对版本文档内容掌握不及时，版本部署时效性差。

一方面，由于版本文档随测试补丁通过版本传输系统发出，测试人员需要从版本传输系统下载版本文档到本地执行验证，在最终需要将版本发布给运维人员时，要人工编写最终投产的版本文档后上传至版本传输系统交接给运维，准确性和时效性都极需提高。

一方面，在测试过程中发现版本文档有问题时，需要通过问题管理系统提交问题，需要在问题管理系统中对版本文档信息、问题方位和问题详情进行描述，问题需要经过问题管理系统中相关的审批流程才可以流转到研发人员手中，操作流程复杂，不能及时有效的将问题反馈给研发人员，重新修改的版本文档需要随下一个补丁版本发出，如需要在第二天发出，版本文档问题响应速度受到限制。

图2示意性示出了根据本公开实施例的在线文档处理方法、装置和电子设备的应用场景。需要说明的是，本公开实施例提供的在线文档处理方法、装置和电子设备可用于云计算在文档管理相关方面，也可用于除云计算领域之外的多种领域，本公开实施例提供的在线文档处理方法、装置和电子设备的应用领域不做限定。

如图2所示，用户1(如研发人员)发起一个在线文档后，用户2(如测试人员)、用户3(如运维人员)等无需下载该文档即可根据自身的处理权限，在线对该文档进行诸如查看、编辑、审批等操作。其中，不同阶段拥有编辑和审批处理权限的用户不同，处理权限是根据用户的属性和在线文档的当前阶段(如阶段1、阶段2中任意一个阶段)而定的。当一个文档阶段被审批通过之后，则在线文档进入到下一个阶段，用户对在线文档的处理权限会发生改变。通过如上方式，降低了不相关人员对在线文档进行编辑而导致的意外风险，有助于改善上述相关技术中遇到的多种问题。

本公开的实施例提供了一种在线文档处理方法、装置和电子设备。该在线文档处理方法包括信息确定过程和处理权限确定过程。在信息确定过程中，首先，接收文档处理请求，文档处理请求包括用户标识和文档标识，然后，响应于文档处理请求，确定与用户标识对应的用户属性，并且确定文档标识所标识的在线文档的当前文档阶段。在完成信息确定过程之后，进入处理权限确定过程，基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限，以便给与用户标识对应的用户分配处理权限。

本公开实施例提供的在线文档处理方法、装置和电子设备，通过流水线式的、多方可见的、多方共同参与的文档处理方式，实现对诸如版本文档最终准确性的把控，并通过对版本文档即验证即确认的方式，实现版本文档发布投产的灵活性和高效性。

图3示意性示出了根据本公开实施例的可以应用在线文档处理方法、装置和电子设备的示例性系统架构。需要注意的是，图3所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图3所示，根据该实施例的系统架构300可以包括终端设备301、302、303，网络304和服务器305。网络304可以包括多个路由器、网线等，用以在终端设备301、302、303和服务器305之间提供通信链路的介质。网络304可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备301、302、303通过网络304与其他终端设备和服务器305进行交互，以接收或发送信息等，如发送文档创建请求、用户角色录入请求、文档关联信息查询请求、编辑在线文档、审批在线文档和接收处理结果等。终端设备301、302、303可以安装有各种通讯用户端应用，例如银行类应用、运维类应用、网页浏览器应用、办公类应用、搜索类应用、即时通信工具、邮箱用户端、社交平台软件等应用(仅为示例)。

终端设备301、302、303包括但不限于智能手机、虚拟现实设备、增强现实设备、平板电脑、膝上型便携计算机等等。

服务器305可以接收请求，并对请求进行处理。例如，服务器305可以为后台管理服务器、服务器集群等。后台管理服务器可以对接收到的文档创建请求、用户角色录入请求、文档关联信息查询请求等进行分析处理，并将处理结果(如文档创建成功提示、角色录入成功等)反馈给终端设备。

需要说明的是，本公开实施例所提供的在线文档处理方法一般可以由服务器305执行。相应地，本公开实施例所提供的在线文档处理装置一般可以设置于服务器305中。本公开实施例所提供的在线文档处理方法也可以由不同于服务器305且能够与终端设备301、302、303和/或服务器305通信的服务器或服务器集群执行。

应该理解，终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图4示意性示出了根据本公开实施例的在线文档处理方法的流程图。

如图4所示，该方法可以包括操作S401～操作S405。

在操作S401，接收文档处理请求，文档处理请求包括用户标识和文档标识。

在本实施例中，在线文档可以包括至少一个文档阶段，如在线文档可以包括研发阶段、测试阶段和运维阶段，每个阶段可以和与该在线文档对应的产品的生命周期中各产品阶段相对应。如研发人员在研发一个新产品时，创建一个针对该产品的技术文档，则该文档阶段可以是处于研发阶段，后续随着产品交付测试部门进行测试时，文档阶段可以处于测试阶段。需要说明的是，为了实现精细化管理，每个文档阶段还可以细分为多个子文档阶段，一个用户针对一个文档阶段内的多个子文档阶段的处理权限可以相同或不同。

当用户通过用户标识等登录文档处理系统之后，可以得到用户标识。此外，也可以是由用户在文档处理系统中输入用户标识。用户标识用于唯一地标识一个用户，其可以是由系统分配给用户的，也可以是用户向系统申请的，在此不做限定。

文档标识可以是在线文档被创建时自动生成的标识，以唯一地标识一个文档。此外，为了便于直观地确定与一个文档对应的产品，该文档标识可以是基于一定规则，利用产品名、版本等信息生成的。该文档标识可以被修改或禁止被修改。此外，当一个文档需要被重新创建时，则可以在文档标识中添加文档版本信息等以便进行区别。

在操作S403，响应于文档处理请求，确定与用户标识对应的用户属性，并且确定文档标识所标识的在线文档的当前文档阶段。

在本实施例中，可以为处于不同文档阶段的在线文档，针对不同的用户设置不同的处理权限，例如，研发人员可以对处于研发阶段的文档进行诸如编辑、审批等处理，但是不可以对处于测试阶段的文档进行编辑或审批等处理。测试人员可以对处于测试阶段的文档进行诸如编辑和审批等处理，但是不可以对处于研发阶段的文档进行编辑、审批等处理。需要说明的是，与当前文档阶段不对应的用户属性的用户也可以具有一定的处理权限，如查看权限，这样使得与在线文档对应的产品相关工作人员(如研发、测试和运维人员等)，都可以查看文档，这样便于相关工作人员可以及时了解产品进度、为了承接该产品需要进行的准备工作等。

具体地，可以根据用户标识在诸如人力资源数据库中等确定与该用户标识对应的用户属性，如该用户标识表征的用户是否在职，其岗位是否什么，其所属的部门是什么，该部门是属于研发类、测试类还是运维类等，用户在公司的职级等。在线文档的当前文档阶段可以是从数据库中查询得到的。

在操作S405，基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限，以便给与用户标识对应的用户分配处理权限。

在本实施例中，可以通过匹配、查询等方式确定当前用户针对该在线文档的处理权限。

图5示意性示出了根据本公开实施例的第一映射关系的示意图。

如图5所示，用户属性和文档阶段的组合与处理权限之间存在映射关系。例如，研发人员对处于研发阶段的文档具有查看、编辑和审批的处理权限，测试人员对处于运维阶段的文档具有查看的处理权限。这样使得可以通过查询或匹配的方式确定当前用户的处理权限。需要说明的是图5所示的第一映射关系仅为示例性说明，除了使用用户属性和文档阶段的组合之外，还可以采用多种其他组合，例如，员工职级和文档阶段的组合，用户所属部门、用户年龄段、用户职级、用户性别、用户所在产品组等中至少一种与文档阶段的组合等。这样便于根据用户需求预先设定各组合与处理权限之间的映射关系。

在一个实施例中，基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限可以包括如下操作。通过查询权限表确定与用户属性和当前文档阶段对应的处理权限，权限表的变量包括用户属性、文档阶段和处理权限。

例如，以DevOps持续交付流水线的场景为例，一个应用的版本文档流水线可以设置三种角色：研发人员、测试人员、运维人员(角色可以属于用户属性的一种)。在一个版本的在线文档中各个文档阶段，所有角色赋查看文档权限，文档内容全程可见。研发人员角色赋文档编辑和开发阶段的文档审批权限。测试人员角色赋测试过程中的文档审批权限。运维人员角色赋投产过程阶段的文档审批权限。表1为版本文档各阶段各角色人员权限表。

需要说明的是，表1所示的权限表仅为示例性说明，除了使用用户属性和文档阶段的组合之外，还可以采用多种其他组合方式。此外，权限除了查看、编辑和审批之外还可以包括其他权限，如分享、打印、退回上一文档阶段等。

表1

本公开实施例提供的在线文档处理方法，实现版本文档从开发创建编辑直到运维实施投产全生命周期的全程共享可见，通过线上对文档状态的转换以及对相关人员的权限设置以保证权限准确性，并且实现对同一产品(如应用)唯一一份文档的维护，确保版本文档的准确性。用户可以通过统一的全球广域网(World Wide Web，简称WEB)界面进行文档的编辑和展示，使文档更加规范，开发交付后，测试过程持续完善，生产可以提前介入文档质量控制，最后交接审批，直接形成投产文档，无需线下编辑文档再线上传输，避免手工整合文档，实现文档编写规范化，文档操作流程标准化。

在一个实施例中，该方法还可以包括如下操作。

首先，接收文档创建请求，文档处理请求包括文档标识，文档标识包括产品名称、产品版本信息、产品关联日期信息和文档版本信息中至少一种。其中，产品名称可以为应用名称、应用简称、应用代号等。产品关联日期可以包括：产品的立项日期、产品研发启动时间、产品投产日期及其代码等。文档版本信息可以被包含在文档创建请求中，也可以是由系统默认生成的，如首次生成的针对该产品的文档的版本可以为0、1、a等，第二次生成的针对该产品的文档的版本可以为1、2、b等，在此不再详述。

然后，响应于文档创建请求，调用文档模板以生成在线文档，其中，至少一个文档阶段各自与产品生命周期中各产品阶段之间存在对应关系。其中，文档模板可以是统一格式的，如包括：文档标题、副标题、目录、版块等。此外，文档模板可以包括多个版本，如针对金融类应用具有统一的模板，针对政务类应用具有统一的模板等，这样使得用户可以根据自身的需求从模板库中选取所需的模板。

例如，系统数据库录入统一的版本文档模板，当文档名称生成后，点击页面展示的文档名称(可以为文档标识或与文档标识存在映射关系)，触发调用文档模板，显示出文档各章节供研发人员填写，获取编写的文档内容后保存至服务器，发起后续流程。

图6示意性示出了根据本公开实施例的文档标识的示意图。

如图6所示，该文档标识可以包括：产品名称部分信息(XXXX)、产品版本部分信息(YYYY)、关联日期部分信息(ZZZZ)和文档版本部分信息(PPPP)。需要说明的是，文档标识中各部分及其位数、字符等仅为示例，不能理解为对本公开的限定。

在一个实施例中，至少一个文档阶段按照产品生命周期中各产品阶段的排列顺序依序排列，形成文档流水线。

图7示意性示出了根据本公开实施例的文档流水线的示意图。

如图7所示，该文档流水线可以包括：创建编辑阶段、内部测试阶段、交付阶段、测试阶段、交接阶段、生产投产阶段和结束阶段等。每个在前的文档阶段被审批通过后，则会自动进入下一个文档阶段。同一个用户针对文档流水线中各文档阶段的处理权限不同。此外，不同用户针对文档流水线中相同文档阶段的处理权限也不同。

例如，在研发人员创建版本文档流水线时确定，文档名称由三要素组成：应用名称、版本号、投产日期。由三个要素确定一份版本文档，形成一个文档流水线。系统提供入口创建文档，系统获取页面录入的三要素后根据规则合并生成出一份文档的名称写入数据库，同时页面展示该文档名称。

在一个实施例中，处理权限包括审核权限。相应地，还可以包括如下操作。

首先，接收审核通过指令，审核通过指令表征针对在线文档的审核结果是通过。然后，响应于审核通过指令，将当前文档阶段更新至文档流水线中下一个文档阶段。

例如，研发人员审批通过后的在线文档进入测试阶段，测试人员对该在线文档进行审批，如果测试人员针对该在线文档的审批结果是审批通过，则会进入到下一个文档阶段，如运维阶段等。

在一个实施例中，处理权限包括审核权限。相应地，还可以包括如下操作。

首先，接收审核失败指令，审核失败指令表征针对在线文档的审核结果是拒绝通过。然后，响应于审核失败指令，将当前文档阶段更新至文档流水线的首个文档阶段，并且更新文档版本信息。

例如，研发人员审批通过后的在线文档进入测试阶段，测试人员对该在线文档进行审批，如果测试人员针对该在线文档的审批结果是审批不通过，则会进入到文档创建阶段，以便研发人员再次进行文档创建等。需要说明的是，重新创建的在线文档仍然是针对同一个产品(同一产品版本)的，因此，文档标识的主体可以不发生变化，仅更新在线文档的文档标识中的文档版本信息即可。

此外，创建文档的用户的权限可以高于其余具有审批权限的用户。例如，当测试人员审批在线文档通过之后，则仅具有查看功能，不能使得文档阶段改变为首个文档阶段(如文档创建阶段)，但是，如果测试人员在将某个在线文档审批通过后，发现该在线文档存在缺陷，需要重新进行审批或编辑时，则可以告知文档创建的用户，如研发人员将该在线文档的文档阶段修改为文档创建阶段。此外也可以通知对当前文档阶段具有审批权限的用户将文档阶段修改为文档创建阶段。

以下对用户属性申请方式进行示例性说明。

在一个实施例中，还可以包括如下操作。

首先，接收用户属性申请请求，用户属性申请请求包括用户角色、以及以下至少一种：用户标识、所在组织、产品名称、申请理由。一方面，如果用户角色和所在组织相匹配，则将用户属性申请请求中与权限表的变量相关信息录入权限表中。另一方面，如果用户角色和所在组织不匹配，则至少将申请理由发送给审核用户的客户端，以便审核用户基于客户端展示的申请理由进行处理权限审核。

例如，系统提供入口以便用户进行角色申请，系统通过交互界面(如交互界面中交互组件)获取用户在申请页面中录入的信息。其中，录入的信息包括但不限于：“所属单位部门”、“应用名称”、“角色”、“申请理由”中至少一种。研发部分研发人员申请研发人员角色，测试部门测试人员申请测试人员角色，生产部门运维人员申请运维人员角色，若所申请角色与其所属单位部门相匹配时，则系统对用户的角色申请予以授权，并将获取到的录入信息保存到数据库的权限表中(参考表1所示)，权限表中信息决定各用户针对各文档阶段的在线文档的处理权限。如果用户所申请的角色与所属部门不匹配，在一个实施例中，如果申请理由不充分，则先拒绝申请并反馈拒绝原因，同时邮件通知申请人该申请不成功，录入信息不写入权限表，无论权限申请是否成功，申请记录录入权限申请记录表(包括信息：人员ID、应用名称、角色、申请理由、是否授权、拒绝理由)。其中，申请理由是否充分可以由人工进行审核，也可以基于一定的规则进行自动审核。例如，理由中填写：XXX于YY年AA月BB日被从研发借调到测试部门，而其申请的角色是测试角色，如果“XXX于YY年AA月BB日被从研发借调到测试部门”与人力资源等数据库中记载的信息是相适配的，则可以自动批准该角色申请。

在另一个实施例中，如果申请理由不充分，则将申请理由发送给所申请的部门的审批人的终端上，以便所申请的部门的审批人对该申请进行审批。

在一个实施例中，为了便于用户确定当前申请是否成功，上述方法还可以包括如下操作。如果用户角色和所在组织相匹配，则利用用户标识在认证系统中进行匹配以确定与用户标识对应的通讯地址，以基于通讯地址输出权限申请成功提示信息。例如，权限表中可以记录了人员首次登陆系统时获取到的人员标识(ID，作为键值，如登陆用户名)以及通过人员ID从统一认证系统获取到的人员姓名和邮箱信息，通过匹配表中的“人员ID”属性进行对应信息写入，并邮件通知申请人权限申请成功。

在一个实施例中，上述方法还可以为用户提供查询接口以便用户查询文档阶段等相关信息。例如，上述方法还可以包括如下操作。首先，接收文档阶段信息请求。然后，输出与文档阶段信息请求对应的文档阶段关联信息，其中，文档阶段关联信息包括文档阶段的状态信息和与状态信息对应的颜色信息。

例如，版本文档通过WEB页面展示，同时每个流水线提供流水线环节图，展示文档目前所到状态，已过环节显示为第一种状态(如显示绿色或第一种填充)，当前环节显示为第二种状态(如显示蓝色或第二种填充)，未到环节为第三种状态(如显示为灰色等或第三种填充)。版本文档展示页面提供“审批通过”和“审批驳回”按钮，在各环节具有权限的人员通过点击页面显示可以进行相应环节的审批。通过对文档状态的转换，实现版本文档的流水线传输。

图8示意性示出了根据本公开实施例的文档阶段关联信息的示意图。

如图8所示，文档流水线可以包括：创建编辑阶段、内部测试阶段、交付阶段、测试阶段、交接阶段、生产投产阶段和结束阶段共7个阶段。其中，创建编辑阶段、内部测试阶段、交付阶段是已完成阶段，可以显示格子填充图案。测试阶段是当前文档阶段，可以显示竖条填充图案。交接阶段、生产投产阶段和结束阶段是还未进行的文档阶段，则可以不进行图案填充。这样使得与该产品相关的用户都可以直接地查看与该产品相关的在线文档当前所处的文档阶段。

以下以一个具体实施例对应用的版本文档的文档处理流程进行示例性说明。

应用的版本文档可以由研发人员创建编写完成后，文档内容上传至服务器数据库，文档状态置为“内部测试”，页面流水线的内部测试节点置为蓝色。此时根据人员权限配置，研发人员具有审批权限，在内部测试阶段进行审批操作，获取页面回写的审批结果，若审批通过，则文档状态置为“交付”，页面流水线的内部测试节点置为绿色，交付节点置为蓝色。在交付阶段进行审批操作，获取页面回写的审批结果，若审批通过，则文档状态置为“测试”状态，页面流水线的交付节点置为绿色，测试节点置为蓝色。此时根据人员权限配置，测试人员开始具有审批权限，在测试阶段进行审批操作，获取页面回写的审批结果，若审批通过，则文档状态置为“交接”，测试节点置为绿色，交接节点置为蓝色。在交接阶段进行审批操作，获取页面回写的审批结果，若审批通过，则文档状态置为“生产投产”，页面流水线交接节点置为绿色，生产投产节点置为蓝色。此时根据人员权限配置，运维人员开始具有审批权限，在生产投产阶段进行审批操作，若审批通过，文档状态置为结束，页面流水线生产投产节点置为绿色，结束节点置为绿色，流水线结束。

版本文档到任何文档阶段时，根据权限表中对应的邮箱信息，发送邮件通知该应用该环节对应的处理人员及时处理，各阶段若获取审批结果为不通过，则文档置为“创建编辑”状态，获取录入的审批不通过原因保存至数据库，通知研发人员重新进行编辑，审批不通过的节点置为红色，流水线停止，新编辑文档重新发起流水线。

用户可以通过在WEB页面上点击蓝色的文档阶段，触发文档在页面显示。已审批不通过的红色环节同时展示审批不通过原因。

本公开提供的文档处理方法，基于流水线形式的版本文档维护方法，一方面，通过对版本文档线上流水线管理，提供统一的线上模板，提升版本文档的编写规范性，提高版本文档的质量，从文档创建编辑直到投产实施完成，全部通过统一系统进行操作，替代线上线下交替的文档维护方式，版本文档问题不再需要其他系统流程反馈，减少人工操作，降低版本文档维护成本。

另一方面，本公开通过对各用户属性的人员进行权限控制，对所有用户属性的用户放开版本文档查看权限，使版本文档全生命周期可被所有人员查看，文档维护过程中透明化，便于实现相关用户提前对产品所需环境进行准备，提高测试及投产的效率。

另一方面，本公开使开发、测试及运维三方在流水线过程中既各司其职以保证权限准确性，又共同对同一份文档进行维护确认，保证版本文档的准确性，实现版本文档即确认即投产，打破三方工作壁垒，使版本文档问题能够快速得到响应，提升开发到运维的协助性，确保版本投产安全。

本公开的一个方面提供了一种在线文档处理装置。

图9示意性示出了根据本公开实施例的在线文档处理装置的框图。

如图9所示，该在线文档处理装置900包括：处理请求接收模块910、处理请求响应模块920和处理权限确定模块930。

处理请求接收模块910用于接收文档处理请求，文档处理请求包括用户标识和文档标识。

处理请求响应模块920用于响应于文档处理请求，确定与用户标识对应的用户属性，并且确定文档标识所标识的在线文档的当前文档阶段，在线文档包括至少一个文档阶段。

处理权限确定模块930用于基于第一映射关系、用户属性和当前文档阶段确定用户标识针对在线文档的处理权限，以便给与用户标识对应的用户分配处理权限。

需要说明的是，装置部分实施例中各模块/单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再一一赘述。

根据本公开的实施例的模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，处理请求接收模块910、处理请求响应模块920和处理权限确定模块930中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，处理请求接收模块910、处理请求响应模块920和处理权限确定模块930中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，处理请求接收模块910、处理请求响应模块920和处理权限确定模块930中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

本公开的一个方面提供了一种电子设备。图10示意性示出了根据本公开实施例的电子设备的方框图。图10示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，根据本公开实施例的电子设备1000包括处理器1001，其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。处理器1001例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1001还可以包括用于缓存用途的板载存储器。处理器1001可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1003中，存储有电子设备1000操作所需的各种程序和数据。处理器1001、ROM 1002以及RAM 1003通过总线1004彼此通讯连接。处理器1001通过执行ROM 1002和/或RAM 1003中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除ROM 1002和RAM 1003以外的一个或多个存储器中。处理器1001也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备1000还可以包括输入/输出(I/O)接口1005，输入/输出(I/O)接口1005也连接至总线1004。电子设备1000还可以包括连接至I/O接口1005的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被处理器1001执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1002和/或RAM 1003和/或ROM 1002和RAM 1003以外的一个或多个存储器。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (12)

1.一种在线文档处理方法，所述在线文档包括至少一个文档阶段，所述方法包括：

接收文档处理请求，所述文档处理请求包括用户标识和文档标识；

响应于所述文档处理请求，确定与所述用户标识对应的用户属性，并且确定所述文档标识所标识的在线文档的当前文档阶段；以及

基于第一映射关系、所述用户属性和所述当前文档阶段确定所述用户标识针对所述在线文档的处理权限，以便给与所述用户标识对应的用户分配所述处理权限。

2.根据权利要求1所述的方法，还包括：

接收文档创建请求，所述文档处理请求包括文档标识，所述文档标识包括产品名称、产品版本信息、产品关联日期信息和文档版本信息中至少一种；

响应于所述文档创建请求，调用文档模板以生成在线文档，其中，至少一个所述文档阶段各自与产品生命周期中各产品阶段之间存在对应关系。

3.根据权利要求2所述的方法，其中，至少一个所述文档阶段按照产品生命周期中各产品阶段的排列顺序依序排列，形成文档流水线。

4.根据权利要求3所述的方法，其中，所述处理权限包括审核权限；

所述方法还包括：

接收审核通过指令，所述审核通过指令表征针对所述在线文档的审核结果是通过；以及

响应于所述审核通过指令，将当前文档阶段更新至所述文档流水线中下一个文档阶段。

5.根据权利要求3所述的方法，其中，所述处理权限包括审核权限；

所述方法还包括：

接收审核失败指令，所述审核失败指令表征针对所述在线文档的审核结果是拒绝通过；以及

响应于所述审核失败指令，将当前文档阶段更新至所述文档流水线的首个文档阶段，并且更新文档版本信息。

6.根据权利要求1所述的方法，其中，所述基于第一映射关系、所述用户属性和所述当前文档阶段确定所述用户标识针对所述在线文档的处理权限包括：

通过查询权限表确定与所述用户属性和所述当前文档阶段对应的处理权限，所述权限表的变量包括用户属性、文档阶段和处理权限。

7.根据权利要求6所述的方法，还包括：

接收用户属性申请请求，所述用户属性申请请求包括用户角色、以及以下至少一种：用户标识、所在组织、产品名称、申请理由；

如果所述用户角色和所述所在组织相匹配，则将所述用户属性申请请求中与所述权限表的变量相关信息录入所述权限表中；以及

如果所述用户角色和所述所在组织不匹配，则至少将所述申请理由发送给审核用户的客户端，以便审核用户基于客户端展示的申请理由进行处理权限审核。

8.根据权利要求7所述的方法，还包括：

如果所述用户角色和所述所在组织相匹配，则利用用户标识在认证系统中进行匹配以确定与所述用户标识对应的通讯地址，以基于所述通讯地址发送权限申请成功提示信息。

9.根据权利要求1至8任一项所述的方法，还包括：

接收文档阶段信息请求；

输出与所述文档阶段信息请求对应的文档阶段关联信息，其中，所述文档阶段关联信息包括文档阶段的状态信息和与所述状态信息对应的颜色信息。

10.一种在线文档处理装置，包括：

处理请求接收模块，用于接收文档处理请求，所述文档处理请求包括用户标识和文档标识；

处理请求响应模块，用于响应于所述文档处理请求，确定与所述用户标识对应的用户属性，并且确定所述文档标识所标识的在线文档的当前文档阶段，所述在线文档包括至少一个文档阶段；以及

处理权限确定模块，用于基于第一映射关系、所述用户属性和所述当前文档阶段确定所述用户标识针对所述在线文档的处理权限，以便给与所述用户标识对应的用户分配所述处理权限。

11.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现根据权利要求1～9任一项所述的方法。

12.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时实现根据权利要求1～9中任一项所述的方法。

Images