CN116980368A - 建立会话的方法、电子设备及存储介质 - Google Patents

Abstract

本申请涉及即时通讯技术领域，公开了一种建立会话的方法、电子设备及存储介质，应用于会话申请方所在的第一客户端，该方法包括包括：响应于触发的会话申请操作，发送会话申请，会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第二客户端是指会话接收方所在的客户端；显示通过提示信息，通过提示信息是在第三客户端审批通过会话申请后生成的，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话；本方案可以有效解决相关技术中用户被会话消息过渡打扰的问题。

Description

建立会话的方法、电子设备及存储介质

技术领域

本申请涉及即时通讯技术领域，更具体地，涉及一种建立会话的方法、电子设备及存储介质。

背景技术

在即时通讯应用中，用户之间可以随时随地相互发送和接收会话消息，为通讯带来便利的同时也存在一些问题。对于一些用于处理会话消息的时间较短的用户，由于其他用户可以随时随地向该用户发送会话消息，容易导致该用户被会话消息过渡打扰。

发明内容

鉴于上述问题，本申请实施例提出了一种建立会话的方法、电子设备及存储介质，以改善上述问题。

根据本申请实施例的一个方面，提供了一种建立会话的方法，应用于会话申请方所在的第一客户端，包括：响应于触发的会话申请操作，发送会话申请，所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第二客户端是指会话接收方所在的客户端；显示通过提示信息，所述通过提示信息是在第三客户端审批通过所述会话申请后生成的，所述第三客户端是指与所述会话接收方相关联且具有指定角色的用户所在的客户端；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

根据本申请实施例的一个方面，提供了一种建立会话的方法，应用于第三客户端，所述第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；所述方法包括：显示会话申请的信息；所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第一客户端是指会话申请方所在的客户端，所述第二客户端是指所述会话接收方所在的客户端；响应于对所述会话申请触发的审批通过操作，向服务端发送审批通过指令；所述服务端在接收到所述审批通过指令后，建立所述第一客户端与所述第二客户端之间的临时会话，并向所述第一客户端发送通过提示信息；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

根据本申请实施例的一个方面，提供了一种建立会话的方法，包括：接收第一客户端发送的会话申请，所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第一客户端是指会话申请方所在的客户端；所述第二客户端是指会话接收方所在的客户端；将所述会话申请转发至第三客户端，所述第三客户端是指与所述会话接收方相关联且具有指定角色的用户所在的客户端；接收所述第三客户端在审批通过所述会话申请后返回的审批通过指令；响应于所述审批通过指令，建立第一客户端与第二客户端之间的临时会话；向所述第一客户端发送通过提示信息；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

根据本申请实施例的一个方面，提供了一种建立会话的装置，应用于会话申请方所在的第一客户端，包括：会话申请发送模块，用于响应于触发的会话申请操作，发送会话申请，所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第二客户端是指会话接收方所在的客户端；通过提示信息显示模块，用于显示通过提示信息，所述通过提示信息是在第三客户端审批通过所述会话申请后生成的，所述第三客户端是指与所述会话接收方相关联且具有指定角色的用户所在的客户端；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

根据本申请实施例的一个方面，提供了一种建立会话的装置，应用于第三客户端，所述第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；所述装置包括：信息显示模块，用于显示会话申请的信息；所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第一客户端是指会话申请方所在的客户端，所述第二客户端是指所述会话接收方所在的客户端；审批通过指令发送模块，用于响应于对所述会话申请触发的审批通过操作，向服务端发送审批通过指令；所述服务端在接收到所述审批通过指令后，建立所述第一客户端与所述第二客户端之间的临时会话，并向所述第一客户端发送通过提示信息；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

根据本申请实施例的一个方面，提供了一种建立会话的装置，包括：会话申请接收模块，用于接收第一客户端发送的会话申请，所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第一客户端是指会话申请方所在的客户端；所述第二客户端是指会话接收方所在的客户端；转发模块，用于将所述会话申请转发至第三客户端，所述第三客户端是指与所述会话接收方相关联且具有指定角色的用户所在的客户端；审批通过指令接收模块，用于接收所述第三客户端在审批通过所述会话申请后返回的审批通过指令；临时会话建立模块，用于响应于所述审批通过指令，建立第一客户端与第二客户端之间的临时会话；通过提示信息发送模块，用于向所述第一客户端发送通过提示信息；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

根据本申请实施例的一个方面，提供了一种电子设备，包括：处理器；存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，实现如上所述建立会话的方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被处理器执行时，实现如上所述建立会话的方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品，包括计算机指令，所述计算机指令被处理器执行时实现如上所述建立会话的方法。

在本申请的方案中，若需要与会话接收方进行会话，需要针对会话接收方发起会话申请，并在会话申请被审批通过后建立会话申请发起方与会话接收方之间的临时会话，从而，可以解决相关技术中因用户可以随时随意向会话接收方发送会话消息，导致会话接收方被过渡打扰的问题。而且，在本申请的方案中，将针对会话接收方的会话申请转发到与会话接收方相关联且具有指定角色的用户所在的第三客户端来进行会话申请审批，从而，可以减少因需要对会话接收方进行会话申请导致会话接收方需要花费大量的时间审批会话申请的压力。由此，采用本申请的方案不仅可以避免会话接收方被过渡打扰，也可以避免因需要进行会话申请而额外增加会话接收方的会话申请的审批压力。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本申请一实施例示出的会话系统的示意图。

图2是根据本申请一实施例示出的建立会话的方法的时序图。

图3A是根据本申请一实施例示出的聊天管理页面的示意图。

图3B是根据本申请一实施例示出的代理人设置页面的示意图。

图4是根据本申请另一实施例示出的建立会话的方法的流程图。

图5A-图5E是根据本申请一实施例示出的第一客户端的用户界面的示意图。

图6是根据本申请另一实施例示出的建立会话的方法的流程图。

图7A-图7E是根据本申请一实施例示出的在第三客户端的用户界面的示意图。

图8是根据本申请一实施例示出的第二客户端的用户界面的示意图。

图9示出了基于角色的权限访问控制模型进行权限配置的示意图。

图10是根据本申请一实施例示出的建立会话的方法的流程图。

图11是根据本申请一实施例示出的经办方处理流程的示意图。

图12示出了相关技术中的沟通机制和采用本申请方案的沟通机制的对比示意图。

图13是根据本申请一实施例示出的建立会话的装置的框图。

图14是根据本申请另一实施例示出的建立会话的装置的框图。

图15是根据本申请另一实施例示出的建立会话的装置的框图。

图16示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

即时通讯(Instant Messaging，IM)：是指应用在计算机网络平台上，利用点对点(P2P)的协议，能够实现用户之间即时的文本、音频和视频交流的一种通信方式。

图1是根据本申请一实施例示出的会话系统的示意图，在本申请中的方案中，一次会话申请中至少涉及三方，即会话申请发起方、会话接收方和与会话接收方相关联且具有指定角色的用户。在本申请中，为便于区分，将会话申请发起方所在的终端称为第一终端111，将会话接收方所在的终端称为第二终端112，将与会话接收方相关联且具有指定角色的用户所在终端称为第三终端113。

如图1所示，该会话系统包括第一终端111、第二终端112、第三终端113和服务端120，其中，第一终端111、第二终端112和第三终端113分别与服务端120通信连接。该会话系统可以用于实现本申请所提供的建立会话的方法。

终端(第一终端111、第二终端112和第三终端113)可以是智能手机、平板电脑、笔记本电脑、台式电脑、车载终端、智能电视或者其他可以与用户进行交互的电子设备。终端中可以运行应用程序，该应用程序可以是即时通讯应用程序(例如企业即时通讯应用程序)，或者其他集成了即时通讯功能的应用程序。

由于终端中需要运行应用程序才能基于该应用程序与其他用户所在的终端发送即时的会话消息。为便于区分，将用会话申请发起方的用户标识所登录的客户端称为第一客户端、将用会话接收方的用户标识所登录的客户端称为第二客户端和将用与会话接收方相关联且具有指定角色的用户对应的用户标识所登录的客户端称为第三客户端。可以理解的是，第一客户端所在的终端即为第一终端111，第二客户端所在的终端即为第二终端112，第三客户端所在的终端即为第三客户端113。

在一些实施例中，与会话接收方相关联且具有指定角色的用户可以是一个，也可以是多个，在为多个的情况下，则第三终端113也对应为多个。

服务端120用于为终端(第一终端111、第二终端112和第三终端113)中所运行的即时通讯应用程序或者其他集成了即时通讯功能的应用程序提供服务，例如登录服务、消息转发服务、用户标识管理服务等。

服务端120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

以下先从服务端一侧对本申请的方法进行说明。

图2是根据本申请一实施例示出的建立会话的方法的时序图。在本申请中，在一次会话申请中，将会话申请方所在客户端称为第一客户端，将会话接收方所在的客户端称为第二客户端；将与会话接收方相关联且具有指定角色的用户所在的客户端称为第三客户端。图2所示的实施例可以应用于服务端，如图2所示，该方法包括：

步骤210，接收第一客户端发送的会话申请，会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第一客户端是指会话申请方所在的客户端；第二客户端是指会话接收方所在的客户端。

步骤220，将会话申请转发至第三客户端，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端。

在一些实施例中，步骤220之前，该方法还包括：获取第二客户端对应的角色配置信息；从角色配置信息中获取具有指定角色的用户的指定用户标识；指定用户标识用于确定第三客户端。

具体的，服务端可以根据会话申请所携带的第二用户标识，获取与第二用户标识对应的角色配置信息，即第二客户端对应的角色配置信息。该角色配置信息可以包括与会话接收方相关联且具有指定角色的用户的用户标识，即指定用户标识。

在一些实施例中，可以预先根据需要，将需要先申请才能进行会话的用户配置相关联且具有指定角色的用户。为便于描述，将需要先申请才能进行会话的用户称为第一指定用户，则第一指定用户所在的客户端为第二客户端。

在一些实施例中，可以根据角色来确定一用户是否为需要先申请才能进行会话的用户(即第一指定用户)，例如，若一用户的角色包括目标角色，则确定该用户为第一指定用户，反之，若一用户的角色不包括目标角色，则确定该用户不是第一指定用户。目标角色可根据实际需要进行设定，例如，在企业即时通讯应用中，目标角色可以是部门负责人、公司负责人等，在此不进行具体限定。其中，目标角色可以是一种，也可以是多种，在此不进行具体限定。并对应为第一指定用户预先设定相关联且具有指定角色的用户标识，即上文中的指定用户标识，该指定用户标识所指示用户所在的客户端即为第三客户端，在具体实施例中，指定用户标识所指示的用户可以是第一指定用户的秘书、助理等。

举例来说，若用户A为职员，用户B为部门负责人，用户C为用户B的秘书，则可以根据用户B的角色(即所在的岗位)将用户B确定为第一指定用户，将用户C设定为与用户B相关联且具有指定角色的用户，在此基础上，当用户A需要向用户B发送会话消息时，则用户A所在的客户端为第一客户端，用户B所在的客户端为第二客户端，用户C所在的客户端为第三客户端。用户A所在的客户端(第一客户端)先发送针对用户B的会话申请，该会话申请被服务端转发到用户C所在的客户端(第三客户端)，由用户C对会话申请进行审批，若服务端确定用户C审批通过该会话申请后，建立用户A所在客户端(第一客户端)与用户B所在客户端(第二客户端)之间的临时会话，并向用户A所在客户端发送通过提示信息，用户A所在客户端对应显示该通过提示信息。基于该通过提示信息，用户A可以向用户B所在客户端发送会话消息，服务端对应基于所建立的临时会话，将该会话消息转发到用户B所在的客户端。在一些实施例中，可以自动基于用户的职级来确定一用户是否为需要先申请才能进行会话的用户(即第一指定用户)。具体的，可以设定职级阈值，若一用户的职级不低于该职级阈值，则确定该用户为第一指定用户。并对应将该用户的秘书确定为与该第一指定用户相关联且具有指定角色的用户，即将该第一指定用户的秘书所在客户端确定为第三客户端。

在一些实施例中，还可以根据作为会话申请发起方的用户(假设为用户D1)的职级和作为会话接收方的用户(假设为用户D2)的职级来确定用户D2是否为需要先申请才能发起会话的第一指定用户。具体的，假设用户D1的职级为K1，用户D2职级为K2，若职级K2不低于职级阈值，且T不低于差值阈值，其中，T＝K2-K1，差值阈值为正整数，当用户D1所在客户端需要向用户D2所在客户端发送会话消息时，则用户D2可以确定为第一指定用户；反之，如果职级K2低于职级阈值，和/或，T低于差值阈值，则用户D2相对于用户D1不是第一指定用户。可以看出，在本实施例中，一用户是否为指定用户，是相对于会话发起方动态变化的，即若一用户D2相对于用户D1是第一指定用户，该用户D2相对于用户D3可能并不是第一指定用户，具体视用户D2的职级和用户D3的职级而定。

在一些实施例中，可以由作为管理员的用户在管理员客户端为第一指定用户进行用户指定，从而，并对应为所指定的用户添加指定角色，使所指定的用户作为与第一指定用户相关联且具有指定角色的用户；并对应将所指定的用户的用户标识(即下文中的指定用户标识)与第一指定用户的用户标识相关联，添加到第一指定用户的角色配置信息中。

在一些实施例中，还可以根据是否为用户设定相关联且具有指定角色的用户来确定一用户是否为第一指定用户，例如，若为一用户A设定了相关联且具有指定用户角色的用户B，则可以确定用户A为第一指定用户，反之，若没有为用户A设定相关联且具有指定角色的用户，则确定该用户A不是第一指定用户。在该种情况下，无论用户A的职级如何，当一用户(假设为用户D1)想要向用户A发送会话消息，若确定用户A不是第一指定用户，则用户D1可以直接与用户A进行会话；反之，若确定用户A是第一指定用户，则用户D1在会话申请通过后才能与用户A进行会话。

在一些实施例中，若确定会话接收方不是第一指定用户，则不需要先发起会话申请，即可与该会话接收方直接进行会话。

步骤230，接收第三客户端在审批通过会话申请后返回的审批通过指令。

在本申请中，具有指定角色的用户具有对会话申请进行审批的权限。而且，由于将具有指定角色的用户与另一用户(例如上文中的第一指定用户)进行关联，从而，由与该第一指定用户相关联且具有指定角色用户来审批针对该第一指定用户的会话申请，实现会话申请的分流。

步骤240，响应于审批通过指令，建立第一客户端与第二客户端之间的临时会话。

具体的，建立第一客户端与第二客户端之间的临时会话，相当于开放第一客户端与第二客户端进行会话的临时会话权限。

在一些实施例中，若限定了向第一指定用户发送会话消息的权限和限定了第一指定用户向其他客户端发送会话消息的权限(即在未建立建立第一客户端与第二客户端之间的临时会话的情况下，第一客户端无法接收到第二客户端发送的会话消息，而且，第二客户端也无法接收到第一客户端发送的会话消息)，则服务端响应于审批通过指令所开放的临时会话权限可以是第一客户端与第二客户端之间的双向会话权限。

在另一些实施例中，若仅限定了向第一指定用户发送会话消息的权限，而未限定第一指定用户向其他用户所在客户端发送会话消息到的权限(换言之，在服务端未建立第一客户端与第二客户端之间的临时会话的情况下，第二客户端向第一客户端所发送的会话消息可以被服务端转发到第一客户端段，但是第一客户端向第二客户端发送的会话消息，不会被服务端转发到第二客户端)，则服务端响应于审批通过指令所开放的临时会话权限可以是第一客户端向第二客户端发送会话消息的单向会话权限。

步骤250，向第一客户端发送通过提示信息；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话。

可以理解的是，所建立的临时会话是具有有效期的。在所建立的临时会话的有效期间内，第一客户端向第二客户端所发送的会话消息可以被服务端转发到第二客户端；进一步的，第二客户端向第一客户端发送的会话消息也可以被服务端转发到第一客户端。

反之，若超出临时会话的有效期，服务端即使接收到第一客户端向第二客户端发送的会话消息，也不将会话消息转发到第二客户端；进一步的，服务端还可以向第一客户端返回发送失败提示信息。

当然，在超出临时会话的有效期后，第一客户端若需要再次向第二客户端发送会话消息，则需要再次进行会话申请，以使服务端再次建立第一客户端与第二客户端之间的临时会话。

在本申请的方案中，若需要与会话接收方进行会话，需要针对会话接收方发起会话申请，并在会话申请被审批通过后建立会话申请发起方与会话接收方之间的临时会话，从而，可以解决相关技术中因用户可以随时随意向会话接收方发送会话消息，导致会话接收方被过渡打扰的问题。而且，在本申请的方案中，将针对会话接收方的会话申请转发到与会话接收方相关联且具有指定角色的用户所在的第三客户端来进行会话申请审批，从而，可以减少因需要对会话接收方进行会话申请导致会话接收方需要花费大量的时间审批会话申请的压力。由此，采用本申请的方案不仅可以避免会话接收方被过渡打扰，也可以避免因需要进行会话申请而额外增加会话接收方的会话申请的审批压力。

本申请的方案可以应用于对处理会话消息的时间较短的用户，例如作为企业、机构、或者组织的负责人的用户、作为部门负责人的用户等，当该处理会话消息的时间较短的用户作为本申请中的会话申请接收方，采用本申请的方法在会话申请被审批通过后才建立临时会话，并由于与会话接收方相关联的且具有指定角色的用户来进行会话审批，可以避免作为会话接收方的用户被过渡打扰。

在一些实施例中，还可以在客户端中设置针对会话申请的第一控制按钮，在该种情况下，若为第一指定用户设定了相关联且具有指定角色的用户，且第一指定用户所在客户端打开了该第一控制按钮，则若一用户(假设为用户A)需要向该第一指定用户进行会话，由于第一指定用户所在客户端(此时即为第二客户端)打开了该第一控制按钮，则确定需要先发起会话申请，并在建立与第二客户端的临时会话后，该用户A所在的第一客户端才能与第二客户端进行会话。反之，即使为第一指定用户设定了相关联且具有指定角色的用户，但是，第一指定用户所在客户端关闭了该第一控制按钮，则用户A不需要先进行会话申请即可与第二客户端进行会话，即此时，用户A所在客户端向第一指定用户所在客户端发送的会话消息会被服务端转发到第一指定用户所在的客户端。在本实施例中，由于在客户端中设置了第一控制按钮，由此，第一指定用户可以根据实际需要打开或者关闭该第一控制按钮，进而确定打开或者关闭会话申请。在该种情况下，第一指定用户可以根据自身的事务繁忙情况来灵活确定是否打开第一控制按钮，例如，在事务繁忙的时候，可以打开该第一控制按钮，基于会话申请且所关联的第三客户端审批通过后才建立临时会话，在事务不繁忙的时候，可以关闭该第一控制按钮，从而不需要进行会话申请即可与该第一指定用户进行会话。

在一些实施例中，还可以在客户端设置第二控制按钮，该第二控制按钮用于指示是否由第一指定用户所关联的具有指定角色的用户来代替第一指定用户处理会话消息。在该种情况下，若第一指定用户在客户端中打开了该第二控制按钮，则在服务端建立临时会话后，第一客户端向第二客户端发送的会话消息也同时被发送到第三客户端，在该种情况下，第二客户端或者第三客户端所在的用户中的任一一个均可处理该会话消息。当然，在该种情况下，若由第三客户端代为处理第二客户端与第一客户端之间的会话消息，该第三客户端代替第二客户端向第一客户端所发送的会话消息，也对应被服务端转发至第一客户端。在该种情况下，由于第一客户端向第二客户端发送的会话消息被发送到第三客户端和第二客户端，由此，即使不是第一指定用户亲自处理的会话消息，但是第一指定用户仍然可以根据所接收到的会话消息来知晓第三客户端与第一客户端之间的会话内容，从而，对第三客户端的用户进行监督，避免出现第三客户端的用户滥用第一指定用户的权限的情况。

反之，若第一指定用户在客户端关闭了该第二控制按钮，则在服务端建立临时会话后，第一客户端向第一客户端所发送的会话消息会被服务端转发到第一客户端，而不会被转发到第三客户端，从而，由第一指定用户在第二客户端处理与第一客户端之间的会话消息。

在本实施例，由于设定了控制是否由第一指定用户所关联的具有指定角色的用户来代为处理会话消息的第二控制按钮，从而，第一指定用户可以根据自身的实际需要灵活设定由自身处理与第一客户端之间的会话消息，还是选择由与第一指定用户所关联的具有指定角色的用户来代为处理与第一客户端之间的会话消息。

在一些实施例中，步骤210之后，该方法还包括：将会话申请转发至第二客户端；接收第二客户端在审批通过会话申请后返回的审批通过指令。在本实施例中，第一客户端发送的会话申请不仅被转发到第三客户端，也被转发到第二客户端，从而，会话接收方也可以在第二客户端对会话申请进行审批，可以进一步保证会话申请被及时审批。

在一些实施例中，将会话申请转发至第二客户端之后，该方法还包括：若接收到第三客户端在审批拒绝会话申请后返回的审批拒绝指令，或者接收到第二客户端在审批拒绝会话申请后返回的审批拒绝指令，向第一客户端发送拒绝提示信息。进而，会话申请发起方可以基于第一客户端所接收到的拒绝提示信息知晓会话申请被拒绝。

在一些实施例中，步骤240之后，该方法还包括：在临时会话的有效期间内，若接收到第一客户端向第二客户端发送的会话消息，将会话消息转发到第二客户端。

在一些实施例中，步骤240之前，该方法还包括：在未建立第一客户端与第二客户端之间的临时会话期间，或者在超出临时会话的有效期间后，若接收到第一客户端向第二客户端发送的会话消息，不向第二客户端转发会话消息，并向第一客户端返回发送失败提示信息。

在本实施例中，仅在所建立的临时会话的有效期限内，第一客户端才可以与第二客户端进行会话，从而，可以有效保证会话接收方被过渡打扰。

在一些实施例中，可以预先各用户的会话权限进行设置，从而，以设定需要基于会话申请才能进行会话的用户。进一步的，对于需要基于会话申请才能进行会话的用户，还可以进一步设定与该用户相关联且具有指定角色的用户。

图3A是根据本申请一实施例示出的聊天管理页面的示意图，如图3A所示，该聊天管理页面310包括多个设置选项，例如最大可发送文件、群成员人数上限、消息阅读状态、部门群、聊天申请、设置代理人、自定义聊天表情等，当然，在其他实施例中，聊天管理页面310中的设置选项可以包括图3A所示的更多或者更少的设置选项，图3A仅仅是一示例性举例，不能认为是对本申请使用范围的限定。

其中，聊天管理页面310中的“聊天申请”选项311用于指定需要基于会话申请才能进行会话的用户，在该“聊天申请”选项311可以添加用户标识，例如吐3A中添加的“李四”，则所添加的用户标识所指示用户是需要先进行会话申请才能进行会话的用户。

聊天管理页面310中的“设置代理人”选项312用于为所指定需要基于会话申请的用户设置代理人角色的用户，该代理人角色即为本申请中的指定角色，在“设置代理人”选项中设置完成后，对应为在该“设置代理人”选项312中添加的用户配置“代理人”这一角色。

当用户触发“设置代理人”选项312下的“添加”控件313，可以进入到图3B所示的代理人设置页面320，在该代理人设置页面320可以为“聊天申请”选项311下所指定的用户添加用户，使所添加的用户具有“代理人”这一角色，例如图3B所示的代理人设置页面320中，为“李四”这一用户添加作为代理人的用户。

该代理人设置页面320设有“添加代理人”控件321和“删除”控件322，其中，通过触发“添加代理人”控件321可以为选定的用户添加作为代理人的用户，使所添加的用户对应关联代理人这一指定角色；通过触发“删除”控件322，可以将已添加的作为代理人的用户进行删除。

在具体实施例中，为一用户所添加作为代理人的用户可以是一个也可以是多个，在此不进行具体限定。例如，在图3B中，所设定名为“邵XX”和名为“张XX”的用户均可以作为“李四”的代理人。

在完成图3A和图3B所示的设置后，将在“聊天申请”选项311下所指定的用户标识与在“设置代理人”选项312下所添加的用户标识进行关联，得到在“聊天申请”选项311下所指定的用户标识对应的角色配置信息，并将该角色配置信息发送到服务端，由服务端进行存储。

在具体实施例中，可以是由作为管理员的用户所在的客户端来按照图3A和图3B所示，来指定需要基于会话申请才能进行会话的用户，以及为需要基于会话申请才能进行会话的用户添加代理人。

以下从会话申请发起方所在的客户端(即第一客户端)一侧来对本申请的方法进行说明。

图4是根据本申请另一实施例示出的建立会话的方法的流程图，图4所示的实施例应用于会话申请方所在的第一客户端。如图4所示，该方法包括：

步骤410，响应于触发的会话申请操作，发送会话申请，会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第二客户端是指会话接收方所在的客户端。

会话申请指示了会话接收方的用户标识，当用户需要向某一用户(此时该用户对应作为会话接收方)发起会话时，若该会话接收方是需要基于会话申请才能进行会话的用户(例如上文中的具有目标角色的用户)，则对该会话接收方触发会话申请操作，从而发送会话申请。在本申请中，为便于区分，将需要先会话申请才能进行会话的用户称为第一指定用户。

在一些实施例中，为了便于用户知晓哪些用户是第一指定用户，可以在客户端中针对第一指定用户进行标记显示，或者在与第一指定用户的会话界面中显示会话申请提示信息，该会话申请提示信息用于指示需要先会话申请才能与该第一指定用户建立会话。其中，对第一指定用户进行标记显示可以是在第一指定用户的用户标识(例如用户头像、用户昵称等)等位置添加特定标记。

在一些实施例中，可以在与会话接收方的会话界面中显示用于触发会话申请操作的第一控件，从而，若检测对该第一控件触发的操作，则确定检测到会话申请操作。

在一些实施例中，若确定当前需要进行会话的会话接收方不是需要先会话申请才能进行会话的用户，则可以直接向该会话接收方发送会话信息，服务端对应会将该会话信息转发到会话接收方所在的客户端。

在一些实施例中，步骤410之前，该方法还包括：显示会话申请窗口，会话申请窗口用于输入会话申请信息；在本实施例中，步骤410，包括：响应于在会话申请窗口触发的会话申请操作，根据会话申请信息发送会话申请。

会话申请窗口用于输入会话申请信息，该会话申请信息可以是便于对会话申请进行审批的信息，例如，请求进行会话的理由、事项等，在此不进行具体限定。该会话申请窗口的显示形式不限，可以是以弹窗形式显示，或者显示于某一指定页面中的一区域。

在一些实施例中，会话申请窗口可以包括用于触发会话申请操作的第一控件，若检测到针对该第一控件的触发操作(例如点击、触摸、滑动等)，则确定检测到会话申请操作。

若用户在会话申请窗口中输入了会话申请信息，则会话申请除了携带会话接收方的用户标识外，还进一步携带该会话申请信息。

在一些实施例中，在显示会话申请窗口的步骤之前，该方法还包括：在与会话接收方的会话界面中显示会话申请提示信息，会话申请提示信息包括会话申请入口；在本实施例中，显示会话申请窗口，包括：响应于对会话申请入口触发的操作，显示会话申请窗口。

其中，会话申请提示信息用于指示需要先进行会话申请才能与该会话接收方进行会话。由于会话申请提示信息包括会话申请入口，从而，用户可以触发该会话申请入口，以在第一客户端的用户界面中显示会话申请窗口。

会话申请入口可以是进入会话申请窗口的链接，也可以是触发进入会话申请窗口的控件。在具体实施例中，可以将会话申请提示信息中的部分文本作为会话申请入口，从而，通过触发作为会话申请入口的文本，即可进入到会话申请窗口。例如，若会话申请提示信息为“你没有权限向对方发送聊天消息，申请聊天”，可以将“申请聊天”这一文本作为会话申请入口。

在一些实施例中，在与会话接收方的会话界面中显示会话申请提示信息，包括：响应于接收到发送失败提示信息，在与会话接收方的会话界面中显示会话申请提示信息，发送失败提示信息是服务端在接收到第一客户端向第二客户端发送的会话消息，且确定未建立第一客户端与第二客户端之间的临时会话后向第一客户端发送的。

在未建立第一客户端与第二客户端之间的临时会话的情况下，服务端若接收到第一客户端向第二客户端发送的会话消息，服务端不会将该会话消息转发到第二客户端，而是向第一客户端返回发送失败提示信息。第一客户端对应进行会话消息发送失败提示。进一步的，第一客户端接收到发送失败提示消息，可以对应确定需要与当前的会话接收方进行会话申请，从而，在与会话接收方的会话界面中显示会话申请提示信息，通过该会话申请提示信息提示用户先发起针对该会话接收方的会话申请。

步骤420，显示通过提示信息，通过提示信息是在第三客户端审批通过会话申请后生成的，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话。

第一客户端发送会话申请后，该会话申请会被服务端接收到，然后由服务端将该会话申请转发到第三客户端，由用户在第三客户端对该会话申请进行审批。

服务端将会话申请转发到第三客户端后，若在第三客户端检测到触发的审批通过操作，则第三客户端向服务端发送审批通过指令，从而，服务端可以根据该审批通过指令建立第一客户端与第二客户端之间的临时会话，并向第一客户端发送通过提示信息。从而，用户基于在第一客户端中所显示的通过提示信息，可以知晓当前以建立与第二客户端之间的临时会话。

在一些实施例中，该通过提示信息可以是显示在第一客户端与会话接收方的会话界面中。当然，在其他实施例中，也可以是显示的第一客户端的一个指定页面中，在此不进行具体限定。

在服务端建立第一客户端与第二客户端之间的临时会话后，在该临时会话的有效期间内，该第一客户端向第二客户端所发送的会话消息可以被服务端转发到第二客户端。

在一些实施例中，会话申请还被发送到第二客户端，在第二客户端通过会话申请后，生成通过提示信息。换言之，在该种情况下，服务端在接收到第二客户端发送的审批通过指令，或者接收到第三客户端发送的审批通过指令后，均可以向第一客户端发送通过提示信息。

在一些实施例中，服务端在接收到第一客户端发送的会话申请后，可以同步将会话申请发送的第二客户端和第三客户端。在另一些实施例中，服务端在接收到第一客户端发送的会话申请后，可以先将会话申请发送到第三客户端，若在第一设定时长内未接收到第三客户端针对会话申请的审批指令(例如审批通过指令或者审批拒绝指令)，则将该会话申请转发到第二客户端。以此保证会话申请可以被及时审批。

在一些实施例中，步骤410之后，该方法还包括：显示拒绝提示信息，拒绝提示信息是在第三客户端或者第二客户端审批拒绝会话申请后生成的。

若会话申请被转发到第三客户端，若服务端接收到第三客户端针对该会话申请返回的审批拒绝指令，则不建立第一客户端与第二客户端之间的临时会话，并向第一客户端发送拒绝提示信息，以在第一客户端中显示拒绝提示信息。

同理，若会话申请被转发到第二客户端和第三客户端，若服务端接收到第三客户端针对该会话申请返回的审批拒绝指令，或者接收到第二客户端针对该会话申请返回的审批拒绝指令，则不建立第一客户端与第二客户端之间的临时会话，并向第一客户端发送拒绝提示信息，以在第一客户端中显示拒绝提示信息。

在一些实施例中，可以是在与会话接收方的会话界面中显示拒绝提示信息。当然，也可以是在第一客户端的其他界面中显示该拒绝提示信息，在此不进行具体限定。

图5A是根据本申请一实施例示出的会话界面的示意图，在本实施例中，假设会话发起方为用户甲，会话接收方为用户乙，与会话接收方乙相关联且具有指定角色的用户为用户A。

如图5A所示，在与用户乙的会话界面510中显示发送失败提示信息511(即图5A中向用户乙所发送的会话消息旁的感叹号)和显示会话申请提示信息512，该会话申请提示信息512的内容为“你没有权限向对方发送聊天消息，申请聊天”，该会话申请提示信息512中的“申请聊天”为会话申请入口513。当用户点击该会话申请入口513，显示如图5B所示的界面图。

如图5B所示，在与用户乙的会话申请界面510中，以弹窗的形式显示会话申请窗口520，在会话申请窗口中设有信息编辑区521，该信息编辑区521可以显示用户输入的会话申请信息。进一步的，该会话申请窗口520中进一步设有“取消”控件522和“发送”控件523，若用户点击“发送”控件523，可以基于所输入的会话申请信息发送会话申请；反之，若用户点击“取消”控件522，则可以取消发送会话申请。

在会话申请被发送到第三客户端后，若用户在第三客户端审批通过该会话申请，则服务端可以向第一客户端发送通过提示信息，进而，可以在第一客户端中与用户乙的会话界面中显示通过提示信息530，如图5C所示，该通过提示信息530的内容为“对方已通过你的申请，并自动加入收藏通讯录，现在可以开始聊天了，查看详情”。

进一步的，由于第一客户端自动将用户乙添加到收藏通讯录，从而，在之后，若用户甲需要再次与用户乙进行会话，可以从收藏通讯录中触发用户乙的标识信息(例如用户乙的头像、昵称等)，进入到与用户乙的会话界面中。

进一步的，通过提示信息530中包括审批详情查看入口531，在本实施例中，审批详情查看入口531可以是通过提示信息530中的“查看详情”文本，当用户触发该审批详情查看入口531，可以进入到图5D所示的审批详情页面540。

如图5D所示，该审批详情页面540包括第一显示区541、第二显示区542和第三显示区543。其中，第一显示区541用于显示会话申请发起方的用户信息，例如会话申请发起方的用户名称“甲”和会话申请发起方的头像信息，以及会话申请发起方的所在机构信息，即“XX公司/XX部门/XX部”。第二显示区542用于显示会话申请信息，该会话申请信息例如图5D中的“因为XX事项需要与乙进行沟通，还请通过”。第三显示区543用于显示会话申请的审批流程，在图5D所示中，示出了会话申请发起方的用户名称、以及发起会话申请的时间，以及示出了审批会话申请一方的用户的用户名称、以及审批时间、审批意见和审批动作；其中，审批意见是指审批会话申请一方在审批会话申请过程中所输入的意见(例如审批拒绝会话申请的原因，审批通过会话申请的原因等)，审批动作是指审批通过或者审批拒绝的动作。

若用户在第三客户端审批拒绝该会话申请，服务端可以基于第三客户端发送的审批拒绝指令，向第一客户端发送拒绝提示信息。进而，在第一客户端中可以显示拒绝提示信息。

图5E是根据本申请一实施例示出的显示拒绝提示信息的示意图，如图5E所示，在与用户乙的会话界面中显示拒绝提示信息550，该拒绝提示信息550的内容为“对方拒绝了你的申请，查看详情”。进一步的，该拒绝提示信息550中包括审批详情查看入口531，该审批详情查看入口531可以是拒绝提示信息550中的“查看详情”。通过触发该审批详情查看入口531可以进入到审批详情页面540。审批详情页面540中的内容如图5D所示，可以理解的是，从拒绝提示信息550中的审批详情查看入口531所进入到审批详情页面540中所显示的审批动作为审批拒绝。

可以理解的是，如果会话申请还被转发到第二客户端，则审批详情页面540中所显示的审批会话申请一方的用户名称还可能是第二客户端所登录用户的用户名称。

下面，从第三客户端一侧对本申请的方法进行说明。

图6是根据本申请另一实施例示出的建立会话的方法的流程图，图6所示的实施例应用于第三客户端，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；如图6所示，该方法包括：

步骤610，显示会话申请的信息；会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第一客户端是指会话申请方所在的客户端，第二客户端是指会话接收方所在的客户端。

当第三客户端接收到会话申请后，显示针对该会话申请的信息，其中，该会话申请的信息可以是会话申请的摘要信息，或者是会话申请的详情信息。其中，会话申请的信息可以包括会话申请方的用户标识(例如用户名称(用户昵称)等)、会话申请的发起时间(或者第三客户端接收到会话申请的时间)。在一些实施例中，若在第一客户端是基于用户输入的会话申请信息发送的会话申请，该会话申请的信息还可以包括用户所输入的会话申请信息。

步骤620，响应于对会话申请触发的审批通过操作，向服务端发送审批通过指令；服务端在接收到审批通过指令后，建立第一客户端与第二客户端之间的临时会话，并向第一客户端发送通过提示信息；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话。

在一些实施例中，在客户端的用户界面中可以包括用于触发审批通过操作的第二控件，从而，若检测到针对第二控件的触发操作(例如点击、触摸、滑动等)，则确定检测到审批通过操作。

基于服务端所建立第一客户端与第二客户端之间的临时会话，在该临时会话的有效期间内，第一客户端与第二客户端可以进行会话。

在一些实施例中，步骤610之前，该方法还包括：若接收到会话申请，显示针对会话申请的提醒信息；在本实施例中，步骤610，包括：响应于对提醒信息触发的申请查看操作，显示会话申请的信息。

针对会话申请的提醒信息用于指示接收到会话申请。在一些实施例中，针对会话申请的提醒信息可以是红点提示信息，当然，还可以是其他提示收到会话申请的信息，在此不进行具体限定。

在一些实施例中，可以是在客户端的消息页面中显示针对会话申请的提醒信息，也可以是在与会话申请发起方的会话界面中显示针对会话申请的提醒信息，当然，该针对会话申请的提醒信息还可以是显示在其他页面，在此不进行具体限定，也不对提醒信息的显示形式形式进行限定。

对会话申请的提醒信息所触发的申请查看操作可以是对提醒信息的显示区域触发的点击、触摸、滑动等操作，在此不进行具体限定。

在一些实施例中，在会话申请查看页面中显示会话申请的信息，会话申请查看页面包括审批入口；在本实施例中，响应于对会话申请触发的审批通过操作，向服务端发送审批通过指令之前，该方法还包括：响应于对审批入口触发的操作，显示针对会话申请的审批页面；在本实施例中，步骤620，包括：响应于在审批页面触发的审批通过操作，向服务端发送审批通过指令。

会话申请页面可以显示客户端所接收到的多条会话申请的信息，包括已经办理的会话申请的信息和未办理的会话申请的信息。

审批入口可以是审批页面的链接，也可以是在会话申请页面中所设置用户进入审批页面的控件，在此不进行具体限定。

在一些实施例中，审批页面还可以显示会话申请的事项属性，其中，事项属性包括待办和已办。若一会话申请的事项属性为待办，则表明该会话申请是还未进行审批的会话申请；反之，若一会话申请的事项属性为已办，则表明该会话申请是还已经过审批的会话申请。

如上所描述，针对第一客户端所发送的会话申请，服务端可以将该会话申请转发至与会话接收方所关联的至少两个第三客户端，或者，将该会话申请转发至第二客户端和至少一个第三客户端，在此基础上，对于该会话申请而言，只要一个客户端(第二客户端或者一个第三客户端)对该会话申请进行了审批，则该会话申请的事项属性对应变化，因此，为了保证多个客户端中针对同一会话申请所显示的事项属性保持一致，服务端在首次接收到针对该会话申请的审批指令后，向接收到会话申请的各个客户端发送针对会话申请的审批信息，从而，便于各个客户端根据该审批信息来对该会话申请的事项属性进行更新，以及更新针对会话申请的当前所在的流程节点。其中，针对会话申请的审批信息可以包括服务端所接收到的审批指令(例如审批通过指令，或者审批拒绝指令)以及审批该会话申请的用户的用户信息、以及审批时间等，在此不进行具体限定。

在本实施例中，由于服务端在首次接收到针对该会话申请的审批指令后，向接收到会话申请的各个客户端发送针对会话申请的审批信息，从而，可以避免出现两个客户端(例如两个第三客户端、或者一个第三客户端和一个第二客户端)均对该会话申请进行审批的情况，造成对会话申请进行二次审批的情况。

在一些实施例中，步骤610之后，该方法还包括：响应于对会话申请触发的审批拒绝操作，向服务端发送审批拒绝指令，服务端在接收到审批拒绝指令后，向第一客户端发送拒绝提示信息。该拒绝提示信息用于指示会话申请被拒绝。

在一些实施例中，步骤610之后，该方法还包括：响应于对会话申请触发的申请转发操作，将会话申请转发至第四客户端；第四客户端是选取的用户标识所在的客户端。

一般而言，会话申请发起方是因某一事项来发起针对会话接收方的会话申请，但是，可能出现会话申请方对该事项的判断失误，错误认为该事项是由会话接收方来处理，而实际上该事项并不是由会话接收方处理，因此，该该种情况下，第三客户端所在的用户可以基于会话申请所携带的会话申请信息来判断是否需要将该会话申请进行转发，以此保证会话申请发起方对应的事项及时高效地处理，避免因会话申请发送错误导致事项处理时间过长。

在本申请中，将实际可处理会话申请中会话申请信息所指示事项的人员称为经办人。当确定该会话申请需要转发到实际的经办人时，用户可以在客户端的显示界面中选取一用户标识，所选取用户标识指示的用户即为经办人，对应的，所选取用户标识所在的客户端即为第四客户端。可以理解的是，登录第四客户端的用户与登录第二客户端的用户是不同的用户。

在一些实施例中，当本申请的方案应用于企业即时通讯应用中的情况下，当需要转发会话申请时，在客户端中提供企业通讯录，该企业通讯录中包括该企业中全部员工的用户标识，从而，便于在企业通讯录中选取经办人的用户标识，之后，对应将会话申请转发到经办人所在的客户端(即第四客户端)。

当把会话申请转发到第四客户端，在该第四客户端可以对应显示该会话申请的信息，例如会话申请发起方的用户标识(例如用户名称、用户昵称、所在的机构信息等)、以及发起会话申请的会话申请信息。

在一些实施例中，由于会话申请是被转发到第四客户端，该第四客户端并不是会话申请方实际所请求的会话接收方的第二客户端，可以设定客户端没有对通过转发所接收到的会话申请进行审批的权限，而用户可以基于通过转发所接收到的会话申请，主动与会话申请的发起方用户(即第一客户端所在用户)进行会话。

在一些实施例中，在将会话申请转发到第四客户端后，第三客户端可以向服务端发送转发信息，该转发信息可以用于指示会话申请已经被转发以及第四客户端对应的用户标识，在此基础上，服务端可以向第一客户端发送转发提示信息，该转发提示信息用于指示会话申请被转发到第四客户端。在此基础上，第一客户端所在的用户可以根据该转发提示信息知晓所要解决的事项实际是由第四客户端对应的用户处理，进而，第一客户端所在的用户也可以主动与第四客户端的用户发起会话。

在一些实施例中，当第一客户端所在用户基于转发提示信息想要与第四客户端所在用户发起会话时，可以按照上述请求与第二客户端进行会话的相似的流程进行。即，若确定第四客户端所在的用户不是需要基于会话申请才能进行会话的用户，则第一客户端可以直接向第四客户端发送会话消息，该服务端对应会将该会话消息转发到第四客户端；反之，若确定第四客户端所在的用户需要基于会话申请才能进行会话的用户，则需要先针对第四客户端发起会话申请，其会话申请的处理流程与上文中的流程类似，在此不在赘述。

图7A-7E是根据本申请一实施例示出的在第三客户端中的界面图。值得一提的是，在本实施例中，会话申请被称为聊天申请。图7A是根据本申请一实施例示出的消息查看页面的界面图，如图7A所示，该消息查看页面710用于显示提醒消息，其中，该提醒消息可以是接收到会话消息的提醒信息，和接收到聊天申请的提醒信息。

如图7A所示，若接收到聊天申请，则在消息查看页面710中的聊天申请提示项711中进行红点提醒，该红点提醒可以视为针对聊天申请的提醒信息。

当用户触发操作(例如点击、触摸操作)聊天申请提示项711，可以进入到图7B所示的聊天申请查看页面720。聊天申请查看页面720可以显示所接收到的各聊天申请的信息。图7B仅示出了在聊天申请查看页面720显示一条聊天申请的信息，可以理解的是，若客户端接收到多条聊天申请，则可以在该聊天申请查看页面720中显示多条聊天申请的信息。

该聊天申请查看页面720包括“待办”控件723和“已办”控件724，当用户触发“待办”控件723，可以筛选出未办理的聊天申请，从而，在聊天申请查看页面720中显示未办理的聊天申请的信息，而不显示已办理的聊天申请的信息。同理，若用户触发“已办”控件724，可以筛选出已办理的聊天申请，在聊天申请查看页面720中显示已办理的聊天申请的信息，而不显示未办理的聊天申请的信息。

该聊天申请查看页面720还包括聊天申请查看区721，在该聊天申请查看区721可以显示聊天申请的信息，例如图7B中的聊天申请查看区721所显示的信息包括聊天申请的发起方的用户名称(即，甲)和会话接收方的用户名称(即：乙)、以及甲在发起聊天申请时所输入的聊天申请信息(即：因为XX事项需要与乙进行沟通，还请通过)。

进一步的，在聊天申请查看区721还包括审批入口722，该审批入口722为审批页面的链接，用户触发该审批入口722，可以进入到图7C所示的针对聊天申请的审批页面730。

如图7C所示，在审批页面730中可以显示聊天申请的详情信息，例如聊天申请发起方的头像、用户昵称(或用户名称)、用户所在的机构信息(XX公司/XX部门/XX部)、聊天申请的发起时间、以及聊天申请的聊天申请信息。该审批页面730还包括审批意见编辑区732，该审批意见编辑区732可以显示用户所输入的针对聊天申请的审批意见。

该审批页面730还包括“拒绝”控件733和“同意”控件734，若检测到“同意”控件734被触发，则确定检测到针对该聊天申请的审批通过操作；若检测到“拒绝”控件733被触发，则确定检测到针对该聊天申请的审批拒绝操作。

审批页面730还包括事项属性显示区735，该事项属性显示区用于显示聊天申请的事项属性，其中，事项属性包括待办和已办。如果在聊天申请查看页面720触发针对待办理的聊天申请的审批入口722，则在审批页面730中所显示针对该聊天申请的事项属性为“待办”，同理，如果是触发针对已办理的聊天申请的审批入口722，则在审批页面730中所显示针对该聊天申请的事项属性为“已办”。

该审批页面730还包括审批流程查看入口731，即“查看审批流程”这一文本所在的区域，若用户点击审批流程查看入口731，可以进入到图7D所示的界面图中，图7D所示的界面图中包括审批流程查看区740，该审批流程查看区740可以显示聊天申请已经经过的流程节点和当前所在的流程节点，如图7D所示，当前所在的流程节点为“审批环节：代理人审批”。

进一步的，在图7D的界面中也可以审批聊天申请，图7D的界面中也包括“拒绝”控件733和“同意”控件734，用户通过触发“拒绝”控件733和“同意”控件734来审批该聊天申请。

进一步的，如果用户在图7C所示的审批页面730中，输入了审批意见，以及触发了审批控件(“拒绝”控件733和“同意”控件734)，若再次触发审批流程查看入口731，则该页面中的审批流程查看区740的内容对应进行更新，具体的，如图7E所示，在审批流程查看区740中显示用户A所触发的审批动作“同意”、以及所输入的审批意见“理由合理，可以通过”。

在一些实施例中，服务端还可以将第一客户端发起的会话申请转发到第二客户端和第三客户端，从而，会话接收方也可以在第二客户端对该会话申请进行审批。在该种情况下，第二客户端也可以按照第三客户端一侧相同的方式来对会话申请进行审批，具体审批的过程以及在第二客户端的针对会话申请的界面图与图7基本相似，在此不再赘述。

在一些实施例中，第二客户端也可以对所接收到来自第一客户端的会话申请进行转发。具体转发的过程也与第三客户端进行转发的过程相似，在此不再赘述。

图8是根据本申请一实施例示出的第二客户端的界面示意图。如图8A所示，若会话申请被发送到会话接收方所在的客户端(即第二客户端)，则审批流程查看区740中所显示的审批环节对应为“会话接收方”；同理，当第二客户端的用户对该会话申请进行审批后，审批流程查看区740中所显示的所指示的审批用户对应的会话接收方(即乙)。

下面结合一具体应用场景对本申请的方法进行说明。

本申请的方法可以应用于企业即时通讯应用中，在企业即时通讯应用中，可以通过作为管理员的用户来对设置企业中人员的角色和各角色对应的权限，并将企业中对应的人员与角色以及角色对应的权限进行关联。进一步的，作为管理员的用户可以来设置企业中需要基于会话申请才能进行会话的第一指定用户，并为各第一指定用户设定相关联的用户，使为第一指定用户所设定的相关联用户具有指定角色，该指定角色例如上文中代理人，当然，指定角色还可以是其他名称，在此不进行具体限定，该指定角色对应的权限至少包括对针对所关联用户的会话申请进行审批(或者审批和转发)的权限。

在具体实施例中，可以按照RBAC(Role-Based Access Control，基于角色的权限访问控制)模型来进行角色和权限设定。在RBAC模型中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

图9示出了基于角色的权限访问控制模型进行权限配置的示意图。如图9所示，可以结合岗位、机构来设定角色，并对应为各个角色设定菜单权限、操作权限、列表字段权限、以及权限组，其中权限组为数据权限的载体。由于机构对应有机构权限，从而，一用户的权限由该用户在对应岗位上所对应角色的权限和用户所在机构的机构权限共同确定。

在RBAC模型中，角色为权限的基本主体，功能权限、数据权限均依附在角色上，以角色为基础的授权主体，实现了对功能权限、数据权限的细颗粒度控制，对角色和权限进行统一维护，便于灵活地对角色进行增删改查。管理员可以定义领导和代理人两类角色。

菜单权限、操作权限、以及列表字段权限通过在所登录客户端中的界面元素来体现，因此，可以设定功能权限控制界面元素，来体现不同角色的菜单权限、操作权限、以及列表字段权限。

其中，功能权限主要是控制各种界面元素，包括菜单、页面、页面上的字段、按钮，标签页、列表中的字段等相关的界面元素，能够细颗粒度的管控领导和代理人对聊天申请权限、代理能力等界面元素的权限。

权限组为数据权限的载体，以主数据为依托，通过主数据作为数据权限过滤的条件，定义不同用户对不同主数据的权限，以此实现对各种业务数据的筛选。

岗位是角色的组合，一岗位可包含多个角色，实现同一个岗位拥有多个角色，以此来扩展某个岗位的权限。比如领导这个角色本身可以下发到多个岗位上的人员，这些人员也可以拥有领导/代理人的角色。

当用户有多个角色的权限时，无需进行角色切换，而是将角色权限进行叠加，显示该用户岗位下所有角色的权限。

进一步的，在RBAC模型中，关键的角色可以互斥，实现三员分立，使系统管理员、安全管理员、安全审计员三个关键管理员角色互斥，提高整个企业即时通讯系统的安全性。

基于如上的角色定义，进一步为具有领导人的角色设定相关联的用户，使所设定的相关联的用户具有代理人的角色，进而处理所关联具有领导角色的用户的会话申请。

图10是根据本申请一实施例示出的建立会话的方法的流程图。在图10的实施例中，假设会话申请发起方为甲，会话接收方为乙，为乙所设定的代理人为A，(A即为与乙相关联且具有指定角色(代理人)的用户)。

如图10所示，包括：步骤1001，给乙发送会话消息；若确定甲与乙会话不需要申请，则执行步骤1009；反之，若确定甲与乙会话需要申请，则执行执行步骤1002，收到消息发送失败提示；步骤1003，发起会话申请。

若确定乙有代理人，则可以将会话申请发送到A，或者可以将会话申请发送到A和乙。若确定乙没有代理人，则可以将会话申请发送到乙。当把会话申请发送到A和/或乙后，A或乙按照如下的步骤1004-1006来对会话申请进行审批。步骤1004，接收到会话申请；步骤1005，是否需要转给经办方；若需要转给经办人，则跳转到经办方处理流程；若不需要转给经办方，则执行步骤1006，是否审批通过会话申请；如果审批通过会话申请，则甲执行步骤1007，接收到通过提示信息；进一步的，可以基于该通过提示信息查看会话申请的审批流程。之后甲执行步骤1008，再次给乙发送会话消息；对应的，乙执行步骤1009，接收到甲发送的会话消息。

若未审批通过会话申请(即会话申请被拒绝)，则甲执行步骤1010，接收到拒绝提示信息；同理，也可以基于该拒绝提示信息查看会话申请的审批流程。其后，甲可以重新发起会话申请。

图11是根据本申请一实施例示出的经办方处理流程的示意图。图11中的步骤1001-1005的过程在此不再赘述。如图11所示，在确定需要将会话申请转给经办方后，经办方所在客户端对应执行如下的步骤1101-1104的过程：步骤1101，接收到卡片消息；该卡片消息用于指示接收到被转发的会话申请。步骤1102，向甲发送会话消息；步骤1103，经办方与甲会话是否需要申请；若确定经办方与甲会话不需要申请，则执行步骤1104，给甲发送会话消息；对应的，甲会接收到经办人发送的会话消息。若确定经办方与甲会话需要申请，则执行会话申请流程，其中，会话申请流程参见图10中的步骤1003-1007以及步骤1010的过程，在此不再赘述。

在相关技术的即时通讯应用中，会话申请仅发生会话申请发起方和会话接受方二者之间，点对点的发起会话申请→通过申请→发起会话、或者，点对点的发起会话→拒绝申请→拒绝会话。而在本申请的方案中，支持管理员将部分人员设置为指定角色(例如代理人)，具有指定角色的用户可替代所关联的用户(例如领导)处理聊天申请，从而，可以降低领导一方的会话申请处理压力，提高与领导一方的会话效率。

图12示出了相关技术中的沟通机制和采用本申请方案的沟通机制的对比示意图，相关技术中，在企业或者其他机构的企业即时通讯应用中，只能是逐层级发起会话申请，例如图12中左侧的沟通机制，若基层员工用户需要与公司负责人进行会话，则需要先向部分负责人发起会话申请，然后部分负责人通过后，向秘书发起会话申请，秘书通过后，向公司负责人发起会话申请，在公司负责人通过会话申请后，该基层员工才能基于所在的客户端与公司负责人所在的客户端进行会话。由于需要逐级进行会话申请，而且，仅在上一级通过会话申请后发起下一级的会话申请，从而，会话申请的审批流程长，导致会话效率低。

而若采用本申请的方案，可以为具有目标角色的用户(例如作为公司负责人、部分负责人等，为便于描述，将具有目标角色的用户称为第一指定用户)设置代理人，对于针对第一指定用户的会话申请可以直接发送到该第一指定用户的代理人所在的客户端，由代理人所在的客户端对会话申请进行审批，在审批通过会话申请后，该会话申请发起方的客户端可以直接与第一指定用户所在的客户端进行临时会话，从而，不需要逐级进行会话申请，而且，对于时间有限的第一指定用户而言，也不需要花费大量的时间进行会话申请审批，大幅降低了第一指定用户进行会话申请的压力，可以缩短会话申请的时长，提高会话效率。

本申请的方案在支持对第一指定用户基于申请进行会话的基础上，可以将会话申请发送到与第一指定用户相关联且具有指定角色的用户来协助处理针对第一指定用户的会话申请，一方面可以避免因可以随意给第一指定用户发送消息，导致第一指定用户处理会话消息压力大的问题，另一方面，通过与第一指定用户相关联且具有指定角色的用户来协助处理针对第一指定用户的会话申请，可以避免因先申请再会话导致第一指定用户需要花费大量时间审批会话申请，进而，提高会话申请审批的效率，保证与第一指定用户的会话效率。

而且，在本申请的方案中，支持具有指定角色的用户在确定会话申请所请求处理的事项与第一指定用户无关的情况下，将会话申请转发至相关的经办方进行处理，由经办方处理对应的事项，全程可以不需要第一指定用户参与，且能保证事项处理的效率。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的方法。对于本申请装置实施例中未披露的细节，请参照本申请上述方法实施例。

图13是根据本申请一实施例示出的建立会话的装置的框图，该应用于会话申请方所在的第一客户端，包括：会话申请发送模块1310，用于响应于触发的会话申请操作，发送会话申请，会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第二客户端是指会话接收方所在的客户端；通过提示信息显示模块1320，用于显示通过提示信息，通过提示信息是在第三客户端审批通过会话申请后生成的，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话。

在一些实施例中，基于图13所示的建立会话的装置，该装置还包括会话申请窗口显示模块，用于显示会话申请窗口，会话申请窗口用于输入会话申请信息；在本实施例中，会话申请发送模块1310进一步被配置为：响应于在会话申请窗口触发的会话申请操作，根据会话申请信息发送会话申请。

在一些实施例中，基于图13所示的建立会话的装置，该装置还包括：会话申请提示信息显示模块，用于在与会话接收方的会话界面中显示会话申请提示信息，会话申请提示信息包括会话申请入口；在本实施例中，会话申请窗口显示模块进一步被配置为：响应于对会话申请入口触发的操作，显示会话申请窗口。

在一些实施例中，会话申请提示信息显示模块进一步被配置为：响应于接收到发送失败提示信息，在与会话接收方的会话界面中显示会话申请提示信息，发送失败提示信息是服务端在接收到第一客户端向第二客户端发送的会话消息，且确定未建立第一客户端与第二客户端之间的临时会话后向第一客户端发送的。

在一些实施例中，会话申请还被发送到第二客户端，在第二客户端通过会话申请后，生成通过提示信息。

在一些实施例中，基于图13所示的建立会话的装置，该装置还包括：拒绝提示信息显示模块，用于显示拒绝提示信息，拒绝提示信息是在第三客户端或者第二客户端审批拒绝会话申请后生成的。

图14是根据本申请另一实施例示出的建立会话的装置的框图，图14所示的装置应用于第三客户端，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；如图14所示，该装置包括：信息显示模块1410，用于显示会话申请的信息；会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第一客户端是指会话申请方所在的客户端，第二客户端是指会话接收方所在的客户端；审批通过指令发送模块1420，用于响应于对会话申请触发的审批通过操作，向服务端发送审批通过指令；服务端在接收到审批通过指令后，建立第一客户端与第二客户端之间的临时会话，并向第一客户端发送通过提示信息；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话。

在一些实施例中，基于图14所示的建立会话的装置，该装置还包括：提醒信息显示模块，用于若接收到会话申请，显示针对会话申请的提醒信息；在本实施例中，信息显示模块1410进一步被配置为：响应于对提醒信息触发的申请查看操作，显示会话申请的信息。

在一些实施例中，在会话申请查看页面中显示会话申请的信息，会话申请查看页面包括审批入口；在本实施例中，基于图14所示的建立会话的装置，该装置还包括：审批页面显示模块，用于响应于对审批入口触发的操作，显示针对会话申请的审批页面；在本实施例中，审批通过指令发送模块1420进一步被配置为：响应于在审批页面触发的审批通过操作，向服务端发送审批通过指令。

在一些实施例中，基于图14所示的建立会话的装置，该装置还包括：转发模块，用于响应于对会话申请触发的申请转发操作，将会话申请转发至第四客户端；第四客户端是选取的用户标识所在的客户端。

在一些实施例中，基于图14所示的建立会话的装置，该装置还包括：审批拒绝指令发送模块，用于响应于对会话申请触发的审批拒绝操作，向服务端发送审批拒绝指令，服务端在接收到审批拒绝指令后，向第一客户端发送拒绝提示信息。

图15是根据本申请另一实施例示出的建立会话的装置的框图，该装置可以应用于服务端，如图15所示，该装置包括：会话申请接收模块1510，用于接收第一客户端发送的会话申请，会话申请用于请求建立第一客户端与第二客户端之间的临时会话；第一客户端是指会话申请方所在的客户端；第二客户端是指会话接收方所在的客户端；转发模块1520，用于将会话申请转发至第三客户端，第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；审批通过指令接收模块1530，用于接收第三客户端在审批通过会话申请后返回的审批通过指令；临时会话建立模块1540，用于响应于审批通过指令，建立第一客户端与第二客户端之间的临时会话；通过提示信息发送模块1550，用于向第一客户端发送通过提示信息；通过提示信息用于指示已建立第一客户端与第二客户端之间的临时会话。

在一些实施例中，基于图15所示的建立会话的装置，该装置还包括：角色配置信息获取模块，用于获取第二客户端对应的角色配置信息；指定用户标识获取模块，用于从角色配置信息中获取具有指定角色的用户的指定用户标识；指定用户标识用于确定第三客户端。

在一些实施例中，基于图15所示的建立会话的装置，该装置还包括：会话消息转发模块，用于在临时会话的有效期间内，若接收到第一客户端向第二客户端发送的会话消息，将会话消息转发到第二客户端。

在一些实施例中，基于图15所示的建立会话的装置，该装置还包括：失败提示信息发送模块，用于在未建立第一客户端与第二客户端之间的临时会话期间，或者在超出临时会话的有效期间后，若接收到第一客户端向第二客户端发送的会话消息，不向第二客户端转发会话消息，并向第一客户端返回发送失败提示信息。

在一些实施例中，基于图15所示的建立会话的装置，该装置还包括：第二会话申请转发模块，用于将会话申请转发至第二客户端；第二审批通过指令接收模块，用于接收第二客户端在审批通过会话申请后返回的审批通过指令。

在一些实施例中，基于图15所示的建立会话的装置，该装置还包括：拒绝提示信息发送模块，用于若接收到第三客户端在审批拒绝会话申请后返回的审批拒绝指令，或者接收到第二客户端在审批拒绝会话申请后返回的审批拒绝指令，向第一客户端发送拒绝提示信息。

图16示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。需要说明的是，图16示出的电子设备的计算机系统1600仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图16所示，计算机系统1600包括中央处理单元(Central Processing Unit，CPU)1601，其可以根据存储在只读存储器(Read-Only Memory，ROM)1602中的程序或者从存储部分1608加载到随机访问存储器(Random Access Memory，RAM)1603中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在RAM 1603中，还存储有系统操作所需的各种程序和数据。CPU1601、ROM1602以及RAM 1603通过总线1604彼此相连。输入/输出(Input/Output，I/O)接口1605也连接至总线1604。

以下部件连接至I/O接口1605：包括键盘、鼠标等的输入部分1606；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1607；包括硬盘等的存储部分1608；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至I/O接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入存储部分1608。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被中央处理单元(CPU)1601执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读存储介质承载计算机可读指令，当该计算机可读存储指令被处理器执行时，实现上述任一实施例中的方法。

根据本申请的一个方面，还提供了一种电子设备，其包括：处理器；存储器，存储器上存储有计算机可读指令，计算机可读指令被处理器执行时，实现上述任一实施例中的方法。

根据本申请实施例的一个方面，提供了计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一实施例中的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (20)

1.一种建立会话的方法，其特征在于，应用于会话申请方所在的第一客户端，包括：

响应于触发的会话申请操作，发送会话申请，所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第二客户端是指会话接收方所在的客户端；

显示通过提示信息，所述通过提示信息是在第三客户端审批通过所述会话申请后生成的，所述第三客户端是指与所述会话接收方相关联且具有指定角色的用户所在的客户端；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

2.根据权利要求1所述的方法，其特征在于，所述响应于触发的会话申请操作，发送会话申请之前，所述方法还包括：

显示会话申请窗口，所述会话申请窗口用于输入会话申请信息；

所述响应于触发的会话申请操作，发送会话申请，包括：

响应于在所述会话申请窗口触发的会话申请操作，根据所述会话申请信息发送所述会话申请。

3.根据权利要求2所述的方法，其特征在于，所述显示会话申请窗口之前，所述方法还包括：

在与所述会话接收方的会话界面中显示会话申请提示信息，所述会话申请提示信息包括会话申请入口；

所述显示会话申请窗口，包括：

响应于对所述会话申请入口触发的操作，显示所述会话申请窗口。

4.根据权利要求3所述的方法，其特征在于，所述在与所述会话接收方的会话界面中显示会话申请提示信息，包括：

响应于接收到发送失败提示信息，在与所述会话接收方的会话界面中显示会话申请提示信息，所述发送失败提示信息是服务端在接收到所述第一客户端向第二客户端发送的会话消息，且确定未建立所述第一客户端与所述第二客户端之间的临时会话后向所述第一客户端发送的。

5.根据权利要求1所述的方法，其特征在于，所述会话申请还被发送到所述第二客户端，在所述第二客户端通过所述会话申请后，生成所述通过提示信息。

6.根据权利要求5所述的方法，其特征在于，所述响应于触发的会话申请操作，发送会话申请之后，所述方法还包括：

显示拒绝提示信息，所述拒绝提示信息是在所述第三客户端或者所述第二客户端审批拒绝所述会话申请后生成的。

7.一种建立会话的方法，其特征在于，应用于第三客户端，所述第三客户端是指与会话接收方相关联且具有指定角色的用户所在的客户端；

所述方法包括：

显示会话申请的信息；所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第一客户端是指会话申请方所在的客户端，所述第二客户端是指所述会话接收方所在的客户端；

响应于对所述会话申请触发的审批通过操作，向服务端发送审批通过指令；所述服务端在接收到所述审批通过指令后，建立所述第一客户端与所述第二客户端之间的临时会话，并向所述第一客户端发送通过提示信息；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

8.根据权利要求7所述的方法，其特征在于，所述显示会话申请的信息之前，所述方法还包括：

若接收到所述会话申请，显示针对所述会话申请的提醒信息；

所述显示会话申请的信息，包括：

响应于对所述提醒信息触发的申请查看操作，显示所述会话申请的信息。

9.根据权利要求8所述的方法，其特征在于，在会话申请查看页面中显示所述会话申请的信息，所述会话申请查看页面包括审批入口；

所述响应于对所述会话申请触发的审批通过操作，向服务端发送审批通过指令之前，所述方法还包括：

响应于对所述审批入口触发的操作，显示针对所述会话申请的审批页面；

所述响应于对所述会话申请触发的审批通过操作，向服务端发送审批通过指令，包括：

响应于在所述审批页面触发的审批通过操作，向服务端发送审批通过指令。

10.根据权利要求7所述的方法，其特征在于，所述显示会话申请的信息之后，所述方法还包括：

响应于对所述会话申请触发的申请转发操作，将所述会话申请转发至第四客户端；所述第四客户端是选取的用户标识所在的客户端。

11.根据权利要求7所述的方法，其特征在于，所述显示会话申请的信息之后，所述方法还包括：

响应于对所述会话申请触发的审批拒绝操作，向服务端发送审批拒绝指令，所述服务端在接收到所述审批拒绝指令后，向所述第一客户端发送拒绝提示信息。

12.一种建立会话的方法，其特征在于，包括：

接收第一客户端发送的会话申请，所述会话申请用于请求建立第一客户端与第二客户端之间的临时会话；所述第一客户端是指会话申请方所在的客户端；所述第二客户端是指会话接收方所在的客户端；

将所述会话申请转发至第三客户端，所述第三客户端是指与所述会话接收方相关联且具有指定角色的用户所在的客户端；

接收所述第三客户端在审批通过所述会话申请后返回的审批通过指令；

响应于所述审批通过指令，建立第一客户端与第二客户端之间的临时会话；

向所述第一客户端发送通过提示信息；所述通过提示信息用于指示已建立所述第一客户端与所述第二客户端之间的临时会话。

13.根据权利要求11所述的方法，其特征在于，所述将所述会话申请转发至第三客户端之前，所述方法还包括：

获取所述第二客户端对应的角色配置信息；

从所述角色配置信息中获取具有所述指定角色的用户的指定用户标识；所述指定用户标识用于确定所述第三客户端。

14.根据权利要求12所述的方法，其特征在于，所述响应于所述审批通过指令，建立第一客户端与第二客户端之间的临时会话之后，所述方法还包括：

在所述临时会话的有效期间内，若接收到所述第一客户端向第二客户端发送的会话消息，将所述会话消息转发到所述第二客户端。

15.根据权利要求12所述的方法，其特征在于，所述方法还包括：

在未建立第一客户端与第二客户端之间的临时会话期间，或者在超出所述临时会话的有效期间后，若接收到所述第一客户端向所述第二客户端发送的会话消息，不向所述第二客户端转发所述会话消息，并向所述第一客户端返回发送失败提示信息。

16.根据权利要求12所述的方法，其特征在于，所述响应于所述审批通过指令，建立第一客户端与第二客户端之间的临时会话之前，所述方法还包括：

将所述会话申请转发至第二客户端；

接收所述第二客户端在审批通过所述会话申请后返回的审批通过指令。

17.根据权利要求16所述的方法，其特征在于，所述将所述会话申请转发至第二客户端之后，所述方法还包括：

若接收到所述第三客户端在审批拒绝所述会话申请后返回的审批拒绝指令，或者接收到所述第二客户端在审批拒绝所述会话申请后返回的审批拒绝指令，向所述第一客户端发送拒绝提示信息。

18.一种电子设备，其特征在于，包括：

处理器；

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，实现如权利要求1-17中任一项所述的方法。

19.一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被处理器执行时，实现如权利要求1-17中任一项所述的方法。

20.一种计算机程序产品，包括计算机指令，其特征在于，所述计算机指令被处理器执行时实现权利要求1-17中任一项所述的方法。