一种日程数据的获取方法、装置、电子设备及存储介质与流程

1.本技术涉及数据处理技术领域，尤其是涉及一种日程数据的获取方法、装置、电子设备及存储介质。


背景技术：

2.随着互联网的发展，越来越多的人在线上处理庞杂的日程数据，但是随着线上日程数据的日渐繁杂，现市面上可以存储日出数据的系统也越来越多，且由于日程数据会来源于不同的系统，因此，用户在想要查看其他用户的日程数据时，需要登录不同的渠道上的系统查看，大大的降低了工作效率。


技术实现要素：

3.有鉴于此，本技术的目的在于提供一种日程数据的获取方法、装置、电子设备及存储介质，本技术通过构建好的用户组织架构关系表和构建好的授权信任关系表，使得第一用户可以直接实时查看具有授权权限的第二用户的目标日程数据，在避免了需要通过不同处理渠道查看目标日程数据的同时，提高了工作效率。
4.本技术实施例提供了一种日程数据的获取方法，所述日程数据的获取方法包括：
5.获取第一用户的查询请求，所述查询请求为查询第二用户的目标日程数据的请求；
6.基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系；
7.若不满足，根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系；若满足，则向所述第一用户提供所述第二用户的目标日程数据。
8.进一步的，通过以下方式构建所述用户组织架构关系表：
9.根据每个用户的级别信息和每个用户的所属部门信息，确定每个用户的属性标识信息；
10.根据各个用户之间的所述属性标识信息，构建组织架构关系，并生成构建好的用户组织架构关系表。
11.进一步的，所述基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系，包括：
12.根据所述查询请求和构建好的用户组织架构关系表，判断第一用户和第二用户之间是否满足上下级关系；
13.若满足，判断在所述上下级关系中，所述第一用户是否为所述第二用户的上级；
14.若是，确定所述第一用户和所述第二用户之间满足预设组织关系；
15.若否，确定所述第一用户和所述第二用户之间不满足预设组织关系。
16.进一步的，通过以下方式构建所述授权信任关系表：
17.根据每个用户的属性标识信息、该用户对应的授权标准用户的属性标识信息以及该用户的授权申请状态，建立该用户与对应的所述授权标准用户之间的授权关系；
18.根据各个用户与对应的各个所述授权标准用户之间的授权关系，以及各个所述授权标准用户的日程数据类型，构建各个用户的授权信任关系，并生成构建好的授权信任关系表。
19.进一步的，所述根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系，包括：
20.若第一用户在构建好的授权信任关系表中存在与第二用户的授权关系，且所述授权关系中的所述第一用户的授权申请状态为授权申请成功状态，确定第一用户和所述第二用户之间的授权关系满足预设授权关系。
21.进一步的，在所述根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系的步骤之后，所述日程数据的获取方法还包括：
22.若第一用户在构建好的授权信任关系表中不存在与第二用户的授权关系，或所述授权关系中的所述第一用户的授权申请状态为授权申请未成功状态，确定第一用户和所述第二用户之间的授权关系不满足预设授权关系，则向所述第一用户反馈所述第二用户的目标日程数据获取失败。
23.本技术实施例还提供了一种日程数据的获取装置，所述日程数据的获取装置包括：
24.获取模块，用于获取第一用户的查询请求，所述查询请求为查询第二用户的目标日程数据的请求；
25.第一判断模块，用于基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系；
26.第二判断模块，用于若不满足，根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系；
27.第一提供模块，用于若满足，则向所述第一用户提供所述第二用户的目标日程数据。
28.进一步的，在所述根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系的步骤之后，所述日程数据的获取方法还包括：
29.若第一用户在构建好的授权信任关系表中不存在与第二用户的授权关系，或所述授权关系中的所述第一用户的授权申请状态为授权申请未成功状态，确定第一用户和所述第二用户之间的授权关系不满足预设授权关系，则向所述第一用户反馈所述第二用户的目标日程数据获取失败。
30.本技术实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如上述的日程数据的获取方法的步骤。
31.本技术实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有
计算机程序，该计算机程序被处理器运行时执行如上述的语日程数据的获取方法的步骤。
32.本技术实施例提供的日程数据的获取方法、装置、电子设备及存储介质，与现有技术相比，本技术通过构建好的用户组织架构关系表和构建好的授权信任关系表，使得第一用户可以直接实时查看具有授权权限的第二用户的目标日程数据，在避免了需要通过不同处理渠道查看目标日程数据的同时，提高了工作效率。
33.为使本技术的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
34.为了更清楚地说明本技术实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
35.图1示出了本技术实施例所提供的一种日程数据的获取方法的流程图之一；
36.图2示出了本技术实施例所提供的一种日程数据的获取方法的流程图之二；
37.图3示出了本技术实施例所提供的一种日程数据的获取装置的结构示意图；
38.图4示出了本技术实施例所提供的一种电子设备的结构示意图。
39.图中：
40.300-日程数据的获取装置；310-获取模块；320-第一判断模块；330-第二判断模块；340-第一提供模块；350-反馈模块；400-电子设备；410-处理器；420-存储器；430-总线。
具体实施方式
41.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本技术实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本技术的实施例的详细描述并非旨在限制要求保护的本技术的范围，而是仅仅表示本技术的选定实施例。基于本技术的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的每个其他实施例，都属于本技术保护的范围。
42.首先，对本技术可适用的应用场景进行介绍。经研究发现，随着互联网的发展，越来越多的人在线上处理庞杂的日程数据，但是随着线上日程数据的日渐繁杂，现市面上可以存储日出数据的系统也越来越多，且由于日程数据会来源于不同的系统，因此，用户在想要查看其他用户的日程数据时，需要登录不同的渠道上的系统查看，大大的降低了工作效率。
43.基于此，本技术实施例提供了一种日程数据的获取方法、装置、电子设备及存储介质，通过构建好的用户组织架构关系表和构建好的授权信任关系表，使得第一用户可以直接实时查看具有授权权限的第二用户的目标日程数据，在避免了需要通过不同处理渠道查看目标日程数据的同时，提高了工作效率。
44.请参阅图1，图1为本技术实施例所提供的一种日程数据的获取方法的流程图。所
如图1中所示，本技术实施例提供的日程数据的获取方法，包括以下步骤：
45.s101、获取第一用户的查询请求，所述查询请求为查询第二用户的目标日程数据的请求。
46.该步骤中，当第一用户想要查询第二用户下的目标日程数据时，会发送查询请求，这里，查询请求包括但不限制于第二用户的用户名称和第一用户与第二用户之间的组织关系标识。
47.其中，目标日程数据包括但不限制为工作事项的进展程度以及对项目客户的跟进程度。
48.s102、基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系。
49.该步骤中，基于查询请求中第一用户与第二用户之间的组织关系标识，在构建好的用户组织架构关系表中确定第一用户与第二用户之间的组织关系，并判断该组织关系是否满足预设组织关系。
50.这里，预设组织关系包括但不限制为上下级关系。
51.进一步的，通过以下步骤构建所述用户组织架构关系表：
52.步骤1021、根据每个用户的级别信息和每个用户的所属部门信息，确定每个用户的属性标识信息。
53.这里，每个用户的级别信息和每个用户的所属部门信息为采集到的通过不同说我处理渠道采集得到的。
54.其中，属性标识信息中还包括每个样本用户的身份验证信息。
55.步骤1022、根据各个用户之间的所述属性标识信息，构建组织架构关系，并生成构建好的用户组织架构关系表。
56.该步骤中，根据各个用户的级别信息和所属部门信息组成的属性标识信息，确定各个用户的组织架构关系，并将多个用户的组织架构关系组成一个构建好的用户组织架构关系表。
57.这样，构建好的用户组织架构关系表不仅仅可以通过数据表的形式进行显示，还可以通过知识图谱的形式以及其他任何能够展示分类状态的形式进行显示。
58.进一步的，在s102中，所述基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系，包括：
59.步骤1023、根据所述查询请求和构建好的用户组织架构关系表，判断第一用户和第二用户之间是否满足上下级关系。
60.步骤1024、若满足，判断在所述上下级关系中，所述第一用户是否为所述第二用户的上级。
61.该步骤中，由于是第一用户想要获取第二用户的目标日程数据，因此，需要第一用户所属的级别信息高于第二用户所属的级别信息，因此，需要第一用户为所述第二用户的上级。
62.步骤1025、若是，确定所述第一用户和所述第二用户之间满足预设组织关系。
63.步骤1026、若否，确定所述第一用户和所述第二用户之间不满足预设组织关系。
64.该步骤中，所述预设组织关系包括但不限制为上下级关系或同级别用户之间的目
标项目交叉关系。
65.s103、若不满足，根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系。
66.该步骤中，若第一用户和第二用户之间不满足预设中的组织关系上下级关系，则根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系。
67.这里，预设授权关系包括但不限制为与第一用户有交叉的业务或项目关系。
68.进一步的，在步骤s103中，通过以下子步骤构建所述授权信任关系表：
69.步骤1031、根据每个用户的属性标识信息、该用户对应的授权标准用户的属性标识信息以及该用户的授权申请状态，建立该用户与对应的所述授权标准用户之间的授权关系。
70.该步骤中，可根据具体不同的项目或业务，针对每个用户自定义对应不同的授权标准用户，其中授权标准用户为能够授予该用户授权权限的用户，这里，每个用户对应至少一个授权标准用户，且每个用户对应授权标准用户的数量不一致。
71.这样，授权申请状态包括授权申请成功状态以及授权未申请成功状态。
72.步骤1032、根据各个用户与对应的各个所述授权标准用户之间的授权关系，以及各个所述授权标准用户的日程数据类型，构建各个用户的授权信任关系，并生成构建好的授权信任关系表。
73.该步骤中，每个用户对应的具有授权权限的授权标准用户可具体为与该用户有交叉业务关系的同部门授权标准用户或与该用户有交叉业务关系的跨部门授权标准用户。
74.其中，日程数据的数据类型包括但不限制为日程数据的基础数据以及日程数据的敏感数据。
75.这样，日程数据的基础数据包括但不限制为日程数据中的事项名称、该事项对应的客户名称以及该事项对应的其他涉事用户。
76.日程数据的敏感数据包括但不限制为日程数据中事项的具体处理进度，以及该事项涉及到的保密三方机构等该项目的具体内容。
77.此外，本技术提供的实施例还可以接收目标关注指令，用于对第一用户想要关注的目标用户进行关注，便于第一用户能够通过关注列表快速定位到该目标用户，而无需通过搜索用户组织架构关系表来定位获取。
78.而且，本技术提供的实施例中的第一用户可以随时随地根据通过用户组织架构关系表查看和管理下级用户的日程数据，便于作为上级的第一用户进行日程数据的进度管理和掌握。
79.进一步的，在步骤s103中，所述根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系，包括：
80.若第一用户在构建好的授权信任关系表中存在与第二用户的授权关系，且所述授权关系中的所述第一用户的授权申请状态为授权申请成功状态，确定第一用户和所述第二用户之间的授权关系满足预设授权关系。
81.上述中，即第一用户与第二用户之间存在构建好的授权信任关系表中规定的授权关系，并且授权关系为授权申请成功状态时，才能确定确定第一用户和第二用户之间的授
权关系满足预设授权关系。
82.s104、若满足，则向所述第一用户提供所述第二用户的目标日程数据。该步骤中，若第一用户和第二用户之间是否满足上下级关系，且第一用户为所述第二用户的上级，则向所述第一用户提供所述第二用户的目标日程数据。本技术通过构建好的授权信任关系表，实现了无需登录不同的渠道上的系统查看第二用户的目标日程数据，仅仅通过授权的权限就以直接实时查看具有授权权限的第二用户的目标日程数据。
83.本技术实施例提供的日程数据的获取方法，与现有技术中相比，本技术通过构建好的用户组织架构关系表和构建好的授权信任关系表，使得第一用户可以直接实时查看具有授权权限的第二用户的目标日程数据，在避免了需要通过不同处理渠道查看目标日程数据的同时，缩短了用户对日程数据的分析和处理所消耗的时间，提高了工作效率以及对接效率，大大降低了对于不同日程获取渠道的维护成本。
84.请参阅图2，图2为本技术另一实施例提供的日程数据的获取方法的流程图。如图2中所示，本技术实施例提供的日程数据的获取方法，包括以下步骤：
85.s201、获取第一用户的查询请求，所述查询请求为查询第二用户的目标日程数据的请求。
86.s202、基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系。
87.s203、若不满足，根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系。
88.s204、若满足，则向所述第一用户提供所述第二用户的目标日程数据。
89.s205、
90.若第一用户在构建好的授权信任关系表中不存在与第二用户的授权关系，或所述授权关系中的所述第一用户的授权申请状态为授权申请未成功状态，确定第一用户和所述第二用户之间的授权关系不满足预设授权关系，则向所述第一用户反馈所述第二用户的目标日程数据获取失败。
91.该步骤中，若第一用户和第二用户之间的授权关系不满足预设授权关系，即第一用户在构建好的授权信任关系表中不存在与第二用户的授权关系，向所述第一用户发送授权验证失败，无法获取所述第二用户的目标日程数据的提示信息之后，第一用户会再次手动申请关于第二用户的授权权限，若第二用户同意该授权权限，则继续向第一用户提供第二用户的目标日程数据；若第二用户拒绝同意该授权权限，则反馈第一用户获取第二用户的目标日程数据失败。
92.若第一用户为第二用户的授权标准用户，即第一用户在构建好的授权信任关系表中存在与第二用户的授权关系，但是第一用户和所述第二用户之间的授权状态为授权申请未成功状态，确定所述第一用户和第二用户之间的授权关系不满足预设授权关系，向所述第一用户发送授权验证失败，无法获取所述第二用户的所述目标日程数据的提示信息。
93.这里，当第一用户不是第二用户的授权标准用户，或第一用户和第二用户之间的授权状态为授权申请未成功状态，均确定第一用户和第二用户之间的授权关系不满足预设授权关系，并第一用户发送授权验证失败，且无法获取所述第二用户的所述目标日程数据的提示信息，并再次接收第一用户手动发送的获取第二用户目标日程数据的授权权限，若
第二用户同意该授权权限，则继续向第一用户提供第二用户的目标日程数据；若第二用户拒绝同意该授权权限，则宣布第一用户获取第二用户的目标日程数据失败。
94.其中，敏感数据的用户预设授权等级高于基础数据的用户预设授权等级，也就是说，同样为第一用户向第二用户申请目标日程数据的权限，若目标日程数据为敏感数据，第一用户需要更高的权限才能够获取第二用户目标日程数据，若目标日程数据为基础数据，第一用户需要的获取日程数据的权限程度低于目标日程数据的数据类型为敏感数据时，第一用户获取日程数据的权限程度。
95.其中，s201至s203的描述可以参照s101至s103的描述，并且能达到相同的技术效果，对此不做赘述。
96.本技术实施例提供的日程数据的获取方法，与现有技术中相比，本技术通过构建好的用户组织架构关系表和构建好的授权信任关系表，使得第一用户可以直接实时查看具有授权权限的第二用户的目标日程数据，在避免了需要通过不同处理渠道查看目标日程数据的同时，缩短了用户对日程数据的分析和处理所消耗的时间，提高了工作效率以及对接效率，大大降低了对于不同日程获取渠道的维护成本。
97.请参阅图3，图3为本技术实施例所提供的一种日程数据的获取装置的结构示意图。如图3中所示，所述日程数据的获取装置300包括：
98.获取模块310，用于获取第一用户的查询请求，所述查询请求为查询第二用户的目标日程数据的请求。
99.第一判断模块320，用于基于所述查询请求和构建好的用户组织架构关系表，判断所述第一用户和所述第二用户之间是否满足预设组织关系。
100.进一步的，第一判断模块320通过以下方式构建所述用户组织架构关系表：
101.根据每个用户的级别信息和每个用户的所属部门信息，确定每个用户的属性标识信息。
102.根据各个用户之间的所述属性标识信息，构建组织架构关系，并生成构建好的用户组织架构关系表。
103.进一步的，第一判断模块320具体用于：
104.根据所述查询请求和构建好的用户组织架构关系表，判断第一用户和第二用户之间是否满足上下级关系。
105.若满足，判断在所述上下级关系中，所述第一用户是否为所述第二用户的上级。
106.若是，确定所述第一用户和所述第二用户之间满足预设组织关系。
107.若否，确定所述第一用户和所述第二用户之间不满足预设组织关系。
108.第二判断模块330，用于若不满足，根据构建好的授权信任关系表，判断所述第一用户和所述第二用户之间的授权关系是否满足预设授权关系。
109.进一步的，第二判断模块330通过以下方式构建所述授权信任关系表：
110.根据每个用户的属性标识信息、该用户对应的授权标准用户的属性标识信息以及该用户的授权申请状态，建立该用户与对应的所述授权标准用户之间的授权关系。
111.根据各个用户与对应的各个所述授权标准用户之间的授权关系，以及各个所述授权标准用户的日程数据类型，构建各个用户的授权信任关系，并生成构建好的授权信任关系表。
112.进一步的，第二判断模块330具体用于：
113.若第一用户在构建好的授权信任关系表中存在与第二用户的授权关系，且所述授权关系中的所述第一用户的授权申请状态为授权申请成功状态，确定第一用户和所述第二用户之间的授权关系满足预设授权关系。
114.第一提供模块340，用于若满足，则向所述第一用户提供所述第二用户的目标日程数据。
115.反馈模块350，用于若第一用户在构建好的授权信任关系表中不存在与第二用户的授权关系，或所述授权关系中的所述第一用户的授权申请状态为授权申请未成功状态，确定第一用户和所述第二用户之间的授权关系不满足预设授权关系，则向所述第一用户反馈所述第二用户的目标日程数据获取失败。
116.本技术实施例提供的日程数据的获取装置300，与现有技术相比，与现有技术相比，本技术通过构建好的用户组织架构关系表和构建好的授权信任关系表，使得第一用户可以直接实时查看具有授权权限的第二用户的目标日程数据，在避免了需要通过不同处理渠道查看目标日程数据的同时，缩短了用户对日程数据的分析和处理所消耗的时间，提高了工作效率以及对接效率，大大降低了对于不同日程获取渠道的维护成本。
117.请参阅图4，图4为本技术实施例所提供的一种电子设备的结构示意图。如图4中所示，所述电子设备400包括处理器410、存储器420和总线430。
118.所述存储器420存储有所述处理器410可执行的机器可读指令，当电子设备400运行时，所述处理器410与所述存储器420之间通过总线430通信，所述机器可读指令被所述处理器410执行时，可以执行如上述图1以及图2所示方法实施例中的日程数据的获取方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。
119.本技术实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述图1以及图2所示方法实施例中的日程数据的获取方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。
120.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
121.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
122.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
123.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
124.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以
存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
125.最后应说明的是：以上所述实施例，仅为本技术的具体实施方式，用以说明本技术的技术方案，而非对其限制，本技术的保护范围并不局限于此，尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本技术实施例技术方案的精神和范围，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。