CN116738451A - 低代码平台的权限控制的方法、平台、设备及存储介质 - Google Patents

Abstract

本申请涉及低代码技术领域，本申请实施例提供了一种低代码平台的权限控制的方法、平台、设备及存储介质。该方法包括将第一业务表注册为低代码平台的平台元数据表；确定第一业务表中的主键标识以及表项集，并根据主键标识、表项集以及元数据名称，生成权限元数据，根据权限元数据和用户数据，生成元数据权限列，并将元数据权限列更新至权限角色映射列表中；显示待权限配置的业务场景下的第二业务表的权限过滤条件设置界面；在权限过滤条件设置界面中对第二业务表进行权限配置，得到权限数据，平台、设备及存储介质执行上述方法，本申请实施例先将用户数据与场景元数据进行权限关联，再将场景业务数据与场景元数据的关联，能提升权限配置的便利性。

Description

低代码平台的权限控制的方法、平台、设备及存储介质

技术领域

本申请涉及低代码技术领域，尤其涉及一种低代码平台的权限控制的方法、平台、设备及存储介质。

背景技术

在低代码平台上，业务人员通常以图形化界面操作的方式进行业务数据表及业务管理场景的管理，基于安全性的考虑，不同的业务功能场景下的业务数据表不能直接共享。而实际应用中，需要根据不同的业务功能场景中的数据进行权限设置，对于同一业务功能场景也存在根据多维度的业务数据和多种用户的权限控制，或对于同一用户而言也存在跨***的业务功能场景中对同一类型的数据的权限配置。此时受限于低代码平台中业务数据与业务数据表的不确定性及无法跨***直接共享数据的限制，导致在低代码平台下无法对业务功能场景中的业务数据表中的业务数据预先设定权限设置，进而导致业务人员开发工作量大及低代码平台下权限配置过程复杂的问题。

发明内容

本申请实施例的主要目的在于提出一种低代码平台的权限控制的方法、平台、设备及存储介质，旨在提升低代码平台的权限配置的便利性。

第一方面，根据本申请实施例提出的一种低代码平台的权限控制的方法，所述方法包括：

将第一业务表注册为低代码平台的平台元数据表；其中，所述第一业务表用于记录需要进行权限控制的场景元数据；

确定所述平台元数据表中的主键标识以及表项集，并根据所述主键标识、所述表项集以及元数据名称，生成权限元数据，其中，所述表项集为所述第一业务表中除所述主键标识对应的第一业务表项以外的第二业务表项的集合；

根据所述权限元数据和用户数据，生成元数据权限列，并将所述元数据权限列更新至权限角色映射列表中；

获取待权限配置的业务场景下的第二业务表并显示所述第二业务表的权限过滤条件设置界面；其中，所述第二业务用于记录需要进行权限控制的场景业务数据；

在所述权限过滤条件设置界面中，对所述第二业务表进行权限配置，得到权限数据，以根据所述权限数据控制对所述第二业务表的访问，所述权限数据包括用于表征所述第二业务表与所述权限角色映射列表之间的权限组合关系的第一权限映射数据，以及用于表征同一业务场景下配置的第一权限映射数据之间的权限组合关系的第二权限映射数据。

第三方面，本申请实施例提出了一种低代码平台，包括：

注册模块，用于将第一业务表注册为低代码平台的平台元数据表；其中，所述第一业务表用于记录需要进行权限控制的场景元数据；

确定模块，用于确定所述平台元数据表中的主键标识以及表项集，并根据所述主键标识、所述表项集以及元数据名称，生成权限元数据，其中，所述表项集为所述第一业务表中除所述主键标识对应的第一业务表项以外的第二业务表项的集合；

元数据权限生成模块，用于根据所述权限元数据和用户数据，生成元数据权限列，并将所述元数据权限列更新权限角色映射列表中；

配置获取模块，用于获取待权限配置的业务场景下的第二业务表并显示所述第二业务表的权限过滤条件设置界面；其中，所述第二业务用于记录需要进行权限控制的场景业务数据；

配置处理模块，用于在所述权限过滤条件设置界面中，对所述第二业务表进行权限配置，得到权限数据，以根据所述权限数据控制对所述第二业务表的访问，所述权限数据包括用于表征所述第二业务表与所述权限角色映射列表之间的权限组合关系的第一权限映射数据，以及用于表征同一业务场景下配置的第一权限映射数据之间的权限组合关系的第二权限映射数据。

第三方面，本申请的实施例提出一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现第一方面任一项所述的低代码平台的权限控制的方法。

第四方面，本申请的实施例提出一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现第一方面任一项所述低代码平台的权限控制的方法。

本申请提出一种低代码平台的权限控制的方法、平台、设备及存储介质，通过将第一业务表注册为平台元数据表，使得权限元数据可以实现跨业务***调用，此时，在第一阶段的权限配置时，建立平台元数据表对应的权限元数据并与用户数据进行关联，生成元数据权限列，从而可以构建基于数据自身的权限分配，在第二阶段的权限配置时，基于业务场景下，将第二业务表与元数据权限列进行配置关联，得到权限数据。因此，本申请实施例通过先将用户数据与场景元数据进行权限关联，再通过跨***的场景业务数据与场景元数据的关联的两个阶段的权限配置的方式，实现对低代码平台下的权限配置。和相关技术相比，本申请实施例在第一阶段的权限配置仅需关注场景元数据自身的权限，在第二阶段仅需关注场景元数据和场景业务数据之间的关系，因此本申请实施例权限配置更为简单。

附图说明

图1是本申请实施例提供的低代码平台的权限控制的方法的流程示意图；

图2是本申请实施例提供的低代码平台的权限控制的方法的一个示例的流程示意图；

图3是本申请实施例提供的低代码平台的模块示意图；

图4是本申请实施例提供的低代码平台的另一模块示意图；

图5是本申请实施例的低代码平台的权限控制的方法对应的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

下面是对本申请实施例中用到的术语的阐述：

主键：即主关键字，是数据表中的一个或多个字段，它的值用于唯一的标识表中的某一条记录。在两个表的关系中，主关键字用来在一个表中引用来自于另一个表中的特定记录。主关键字是一种唯一关键字，表定义的一部分。一个数据表的主键可以由多个关键字共同组成，并且主关键字的列不能包含空值。

在低代码平台上，业务人员通常以图形化界面操作的方式进行业务数据表及业务管理场景的管理，基于安全性的考虑，不同的业务功能场景下的业务数据表不能直接共享。而实际应用中，需要根据不同的业务功能场景中的数据进行权限设置，对于同一业务功能场景也存在根据多维度的业务数据和多种用户的权限控制，或对于同一用户而言也存在跨***的业务功能场景中对同一类型的数据的权限配置。此时受限于低代码平台中业务数据与业务数据表的不确定性及无法跨***直接共享数据的限制，导致在低代码平台下无法对业务功能场景中的业务数据表中的业务数据预先设定权限设置，因此，通常会对每一业务功能场景下的业务数据表实时进行权限配置，进而导致业务人员开发工作量大及低代码平台下权限配置过程复杂的问题，基于此，本申请实施例提供一种低代码平台的权限控制的方法、平台、设备及存储介质，能提升低代码平台的权限配置的便利性。

需说明的是，在低代码平台中设置属性为平台元数据表的数据类型，以提供给跨***的使用，进而实现不同业务场景的功能需求，如仓库中的数据，其数据可以辅助订单***的订单的生成，也可以用于生产***中部件维护换新的数据跟踪。

参照图1所示，根据本申请提供的低代码平台的权限控制的方法，包括：

步骤S100、将第一业务表注册为低代码平台的平台元数据表；其中，第一业务表用于记录需要进行权限控制的场景元数据；

步骤S200、确定平台元数据表中的主键标识以及表项集，并根据主键标识、表项集以及元数据名称，生成权限元数据，其中，表项集为第一业务表中除主键标识对应的第一业务表项以外的第二业务表项的集合；

步骤S300、根据权限元数据和用户数据，生成元数据权限列，并将元数据权限列更新至权限角色映射列表中；

步骤S400、获取待权限配置的业务场景下的第二业务表并显示第二业务表的权限过滤条件设置界面；其中，第二业务表用于记录需要进行权限控制的场景业务数据；

步骤S500、在权限过滤条件设置界面中，对第二业务表进行权限配置，得到权限数据，以根据权限数据控制对第二业务表的访问，权限数据包括用于表征第二业务表与权限角色映射列表之间的权限组合关系的第一权限映射数据，以及用于表征同一业务场景下配置的第一权限映射数据之间的权限组合关系的第二权限映射数据。

通过将第一业务表注册为平台元数据表，使得权限元数据可以实现跨业务***调用，此时，在第一阶段的权限配置时，建立平台元数据表对应的权限元数据并与用户数据进行关联，生成元数据权限列，从而可以构建基于数据自身的权限分配，在第二阶段的权限配置时，基于业务场景下，将第二业务表与元数据权限列进行配置关联，得到权限数据。因此，本申请实施例通过先将用户数据与场景元数据进行权限关联，再通过跨***的场景业务数据与场景元数据的关联的两个阶段的权限配置的方式，实现对低代码平台下的权限配置。和相关技术相比，本申请实施例在第一阶段的权限配置仅需关注场景元数据自身的权限，在第二阶段仅需关注场景元数据和场景业务数据之间的关系，因此本申请实施例权限配置更为简单。

需说明的是，步骤S100中场景元数据表示该数据可以作为其他***中的一个表项的数据，如第一业务表记录了客户信息，而该客户信息在订单***中需要维护，在销售***中也需要维护，则该第一业务表中的客户信息为场景元数据。步骤S100中的注册仅表示第一业务表的属性的变更，通知低代码平台可以对第一业务表对应的权限元数据进行跨***访问。

需说明的是，步骤S200中主键标识表征第一业务表中场景元数据的主键，具有唯一性，以提升通过该主键对场景元数据的检索效率。主键标识的设置可以选用第一业务表中默认的其中一个主键，也可以由第一业务表中的各主键拼接而成。步骤S200中元数据名称用于表征权限元数据与第一业务表的关系。基于同一第一业务表生成的权限元数据具有相同的元数据名称。元数据名称可以由用户指定，也可以通过预设的规则自动生成，如直接采用第一业务表的业务表名称。

需说明的是，步骤S300中元数据权限列是通过用于基于权限元数据以及用户数据进行配置得到的。本申请实施例对用户如何对低代码平台进行交互操作实现配置以及权限元数据以及用户数据如何显示的过程不做过多详述，本领域技术人员可以根据实际需求做适应性的设计。

需说明的是，用户数据为允许在低代码平台记录的用户的信息，可以是单一用户的信息，也可以是用户群。

示例性的，以第一业务表为表1的客户表，其中，表1数据如下：

客户标识	客户代码	客户名称
			1	001	李生
2	002	王生

表1

当设定客户标识为主键标识，元数据名称为“custmerTable”,则根据步骤S200，可以得到两个权限元数据，分别为{metadataTableName:”custmerTable”,metadataKey:’1’；metadataName:“001,李生”}，{metadataTableName:”custmerTable”,metadataKey:’2’；metadataName:“002,王生”}。

以上述表1中的{metadataTableName:”custmerTable”,metadataKey:’1’；metadataName:“001,李生”}的权限元数据为例，假设用户数据如下表2所示：

用户标识	用户名称
		1	001
2	002

表2

则根据上述表2以及根据步骤S300可以得到一个元数据权限列如下表3：

表3

其中，表3中，“权限组标识”以及“权限组名称”是对用户数据进行分组划分得到的权限组的名称，权限组标识为用户数据中分组划分的多个权限组的索引，权限组名称为权限组对外显示时的名称。“权限列标识”为权限角色映射列表的主键，以在权限角色映射列表中快速检索出所需的元数据权限列。权限列标识为“1”的元数据权限列记录了权限组标识为“1000”且权限组名称为”部门1权限”的用户的信息由用户标识为1且用户名称为001的用户以及用户标识为2且用户名称为002的用户组成，两个用户均具有元数据名称(即metadataTableName)为custmertable、主键标识(即metadataKey)为1且内容(metadataName)为“001,李生”的权限元数据的控制权限。

需说明的是，步骤S100～步骤S300实现了第一阶段的权限配置，建立了用户数据与场景元数据之间的关联关系。在该阶段的权限配置过程中，仅需关注用户数据与场景元数据之间的关系，无需考虑实际的业务应用场景，再通过实际业务场景中第二业务表的业务数据与第一业务表的业务数据之间的关联关系、多个第二业务表之间的关系，进行用户数据的权限分配，此时，在进行第二阶段的权限配置时仅需关注场景元数据与场景业务数据之间的关系，因此，通过两个阶段之间的权限配置，使得每个阶段进行权限配置时关注的因素单一化，使得配置更为简单。

需说明的是，对于步骤S500而言，由于权限元数据可以跨***共享，用户数据也可以实现跨***共享，因此，元数据权限列也能实现跨***的访问；因此可以直接在权限过滤条件设置界面选项将元数据权限列进行关联，此时，配置过程中，仅需关注第二业务表中哪一个表项为受控表项，哪一个表项需要和元数据权限列关联，即可实现权限配置，因此，配置更为简单。

示例性的，以***中有项目A、B，A项目由张工1、张工2管理，其中张工1管控资产类，张工2管控生产物料类；项目B由李工1、李工2管理，其中李工1管理资产类，李工2管理生产物料类。当业务场景为：张工1在“项目物资看板”中只能看到项目A中资产类的物料情况，张工2在“项目物资看板”中只能看到项目A中生产物料类的物料情况；李工1在“项目物资看板”中只能看到项目B中资产类的物料情况，李工2在“项目物资看板”中只能看到项目B中生产物料类物料情况。此时操作如下：

参照步骤S100和步骤S200所示，先对资产类以及生产物料类对应的第一业务表注册为平台元数据表，并得到权限元数据。然后参照步骤S300生成元数据权限列，此时，建立的元数据权限列如下表4和表5所示：

表4

表5

此时，表4和表5中每一条记录对应一个元数据权限列。在进行步骤500配置时，以业务场景为“项目物资看板”为例，则需要将表4中的元数据权限列与第二业务表中资产类相关的字段进行关联，即可实现对不同人员下项目的管控。以业务场景为“项目物资看板”为例，则需要将表5中的元数据权限列与第二业务表中项目相关的字段进行关联，即可实现对不同人员的资产的管控。

需说明的是，在一些实施例中，步骤S500中的权限数据还包括数据库执行脚本，从而既可以实现以文本形式展示的第一权限映射数据和第二权限映射数据，也可以直接执行的数据库执行脚本，从而可以提升执行效率的同时便于用户验证。

示例性的，参照图2所示，描述本申请的一个具体配置的过程，首先生成第一业务表对应的权限元数据，将用户数据根据业务需求配置为用户、用户组或角色中任意一种或多种，在低代码平台上配置权限元数据和用户数据之间的关联关系，生成元数据权限列，选定业务场景，并在业务场景下选择第二业务表的第三业务表项和元数据权限列的关联关系，得到权限数据，根据权限数据生成数据库执行脚本。

可理解的是，步骤S500中在权限过滤条件设置界面中，对第二业务表进行权限配置，得到权限数据，包括：

根据权限过滤条件设置界面中显示的第二业务表的表项输入信息，从第二业务表中确定第三业务表项；

建立第三业务表项和权限角色映射列表之间的权限关系，得到第一权限映射数据；

根据第一权限映射数据的“或”逻辑以及“与”逻辑的选中状态，得到第二权限映射数据；

将第一权限映射数据和第一权限映射数据组合，得到权限数据。

需说明的是，在一些实施例中，第三业务表项为直接输入，此时，表项输入信息为第三业务表项的内容，在另一些实施例中，第三业务表项为在下拉列表中选中确定的，表项输入信息为其选中状态，在另一些实施例中，第三业务表项为拖拽产生的，则表项输入信息为拖拽信息，对此，本申请对表项输入信息不做过多限定，本领域技术人员可以根据实际需求选择性设置第三业务表项的输入方式。

需说明的是，在一些实施例中，“或”逻辑以及“与”逻辑均作为逻辑选项框的下拉选项之一，在权限过滤条件设置界面中每创建一条第一权限数据的权限设置框均会对应生成一个逻辑选项框，此时，通过逻辑选项框的的下拉选项的选中状态确定权限设置框中的第一权限设置数据与其他第一权限设置数据的逻辑状态为“与”还是“或”。在另一些实施例中，设置有文本框，用于通过拖拽方式将第一权限数据填入文本框，并根据“或”逻辑以及“与”逻辑的选中状态在文本框中生成组合逻辑，得到第二权限数据。

需说明的是，通过设置与逻辑以及或逻辑，使得每一个第三业务表项可以独立配置，从而简化配置过程。

需说明的是，第二权限映射数据用于表示各第一权限数据之间为和还是或的关系，从而可以得到整张第二业务表的权限数据。对于业务场景而言，其可能存在多张第二业务表，此时，通过第二权限数据，可以做到同一业务场景下，多个业务表的权限联动设置。

示例性的，参照上述步骤得到的权限数据如下表6所示：

场景标识	业务表名称	第三业务表项	权限组标识	关联逻辑
					1	orderTable	customId	1000	and
2	orderTable	customTypeId	2000	or

表6

其中，“customId”和“customTypeId”均为业务表名称为“orderTable”的第二业务表的第三业务表项，第一权限数据为权限组标识与第三业务表项之间的关联，第二权限数据为关联逻辑。因此，通过对每一业务表项逐一配置得到整个第二业务表的权限控制，实现多级拆分配置，从而简化权限的配置。需说明的是，参照表6所示，在一些实施例中，当生成有数据库执行脚本时，对于第一行的数据，其执行脚本如下：orderTable.customId in(select metadataKey from metaDataAndUserRelation where groupId＝1000andmetadataTableName＝’custmertable’and userId like‘％1,％’)；对于第二行的数据，其执行脚本如下：orderTable.customTypeIdin(select metadataKey frommetaDataAndUserRelation where groupId＝2000and metadataTableName＝’orderType’and userId like‘％1,％’)。此时，对于第二数据表而言，参照上述表6，得到权限数据的数据库执行脚本为and(orderTable.customId in(select metadataKey frommetaDataAndUserRelation where groupId＝1000 and metadataTableName＝’custmertable’and userId like’％1,％’)or orderTable.customTypeIdin(selectmetadataKey from metaDataAndUserRelation where groupId＝2000andmetadataTableName＝’orderType’and userId like‘％1,％’))。

可理解的是，建立第三业务表项和权限角色映射列表之间的权限关系，得到第一权限映射数据，包括：

在权限过滤条件设置界面中，从权限角色映射列表中选出第一元数据权限列；

将第一元数据权限列的主键标识、权限组以及元数据名称、业务场景的场景名称以及第三业务表项之间进行关联，得到第一权限映射数据。

可理解的是，将第一元数据权限列的主键标识、权限组以及元数据名称、业务场景的场景名称以及第三业务表项之间进行关联，得到第一权限映射数据，包括：

根据主键标识、权限组以及第三业务表项，生成用于查询第一业务表的数据库执行脚本；

将数据库执行脚本、主键标识、权限组、元数据名称、业务场景的场景名称以及第三业务表项作为同一条明细记录的字段内容，得到第一权限映射数据；

对应的，方法还包括：

接收业务操作请求，业务操作请求包括待操作的业务场景的场景名称和用户信息；

根据待操作的业务场景的场景名称，确定待执行的数据库执行脚本；

根据待执行的数据库执行脚本对用户信息对应的操作用户进行操作控制。

需说明的是，在一些实施例中，在权限过滤条件设置界面中会通过列表的方式显示权限角色映射列表中的所有元数据权限列，从而可以进行选择。在另一些实施例中，在权限过滤条件设置界面中会通过列表的方式显示权限角色映射列表中的所有元数据权限列的元数据名称，从而可以通过元数据名称来进一步缩小配置的选择范围，提升配置的便利性。

需说明的是，将第一元数据权限列的主键标识、权限组以及元数据名称、业务场景的场景名称以及第三业务表项之间进行关联的目的是，建立权限匹配条件，该匹配条件用于校验第一元数据权限列的主键标识以及元数据名称对应的权限元数据是否与第三业务表项中的数据内容匹配且对第二业务表操作的操作用户在第一元数据权限列的权限组中。

可理解的是，在权限过滤条件设置界面中，从权限角色映射列表中选出第一元数据权限列，包括：

在权限过滤条件设置界面中，显示权限角色映射列表中包含的元数据名称；

根据元数据名称的选中状态，确定第一元数据表并显示第一元数据表下的元数据权限列；

根据元数据权限列的选中状态，确定第一元数据权限列。

需说明的是，元数据名称更加便于人为识别出对应第一业务表的作用，因此，通过先选择元数据名称再选择对元数据权限列进行选定，操作更为简单。

需说明的是，在一些实施例中，可以对权限角色映射列表进行分类，从而可以在权限过滤条件设置界面中先选择分类信息，筛选出对应分类的权限角色映射列表，进而可以缩减查找范围，简化配置。

可理解的是，根据元数据和用户数据，生成元数据权限列，包括：

根据用户配置请求，创建权限名称；

从用户数据中选出权限名称下用户成员，得到权限组；

在权限组下选取权限元数据，以将权限组与权限元数据进行关联，得到元数据权限列。

可理解的是，确定第一业务表中的主键标识以及表项集，并根据主键标识、表项集以及元数据名称，生成权限元数据，包括：

根据用户的元数据配置请求，确定第一业务表的第一业务表项下的数据为主键标识并确定元数据名称；

对于第一业务表中的每一条业务记录，将业务记录中第二业务表项下的数据按照预设的拼接规则进行拼接并将拼接得到的结果作为预设的元数据结构中的第一字段；

对于第一业务表中的每一条业务记录，将元数据名称作为元数据结构中的第二字段；

对于第一业务表中的每一条业务记录，将业务记录中第一业务表项下的数据作为元数据结构中的第三字段；

根据第一字段、对应的第二字段以及对应的第三字段，得到业务记录对应的权限元数据。

示例性的，假设元数据结构为{metadataTableName:”custmerTable”,metadataKey:’$id$’；metadataName:“$code$($name$)”}，其中，metadataTableName对应第二字段，metadataKey对应第三字段，metadataName对应第一字段，则参照表1所示，第一行的权限元数据为{metadataTableName:”custmerTable”,metadataKey:’1’；metadataName:“001,李生”}。

参照图3所示，根据本申请实施例提供的一种低代码平台，包括：

注册模块110，用于将第一业务表注册为低代码平台的平台元数据表；其中，第一业务表用于记录需要进行权限控制的场景元数据；

确定模块120，用于确定第一业务表中的主键标识以及表项集，并根据主键标识、表项集以及元数据名称，生成权限元数据，其中，表项集为第一业务表中除主键标识对应的第一业务表项以外的第二业务表项的集合；

元数据权限生成模块130，用于根据元数据和用户数据，生成元数据权限列，并将元数据权限列更新权限角色映射列表中；

配置获取模块140，用于获取待权限配置的业务场景下的第二业务表并显示第二业务表的权限过滤条件设置界面；其中，第二业务用于记录需要进行权限控制的场景业务数据；

配置处理模块150，用于在权限过滤条件设置界面中，对第二业务表进行权限配置，得到权限数据，以根据权限数据控制对第二业务表的访问，权限数据包括用于表征第二业务表与权限角色映射列表之间的权限组合关系的第一权限映射数据，以及用于表征同一业务场景下配置的第一权限映射数据之间的权限组合关系的第二权限映射数据。

需说明的是，参照图4所示，在一些实施例中，低代码平台包括第一配置模块200和第二配置模块300，其中，注册模块110、确定模块120以及元数据权限生成模块130属于第一配置模块200，配置获取模块140以及配置处理模块150属于第二配置模块300。低代码平台还包括交互模块400，交互模块400与注册模块110、确定模块120、元数据权限生成模块130、配置获取模块140以及配置处理模块150均连接；交互模块400向注册模块110、确定模块120、元数据权限生成模块130、配置获取模块140以及配置处理模块150提供用户的操作请求以及将确定模块120、元数据权限生成模块130、配置获取模块140以及配置处理模块150中部分数据进行展示，以提供界面配置以及用户配置结果的反馈。对此，本申请实施例对哪些数据需要展示不做过多的详述，本领域技术人员可以根据实际需求选择性的配置。

可理解的是，根据本申请实施例提供的电子设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述的低代码平台的权限控制的方法。

该电子设备可以为包括平板电脑、车载电脑等任意智能终端。

请参见图5，图5示意了另一实施例的电子设备的硬件结构，电子设备包括：

处理器501，可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；

存储器502，可以采用只读存储器(Read Only Memory，ROM)、静态存储设备、动态存储设备或者随机存取存储器(Random Access Memory，RAM)等形式实现。存储器502可以存储操作***和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器502中，并由处理器501来调用执行本申请实施例的低代码平台的权限控制的方法；

输入/输出接口503，用于实现信息输入及输出；

通信接口504，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信；和，

总线505，在设备的各个组件(例如处理器501、存储器502、输入/输出接口503和通信接口504)之间传输信息；

其中处理器501、存储器502、输入/输出接口503和通信接口504通过总线505实现彼此之间在设备内部的通信连接。

可理解的是，根据本申请实施例提供的计算机可读存储介质，存储介质存储有计算机程序，计算机程序被处理器执行时实现上述低代码平台的权限控制的方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

需要说明的是，在本申请的各个具体实施方式中，当涉及到需要根据用户信息、用户行为数据，用户历史数据以及用户位置信息等与用户身份或特性相关的数据进行相关处理时，都会先获得用户的许可或者同意，而且，对这些数据的收集、使用和处理等，都会遵守相关国家和地区的相关法律法规和标准。此外，当本申请实施例需要获取用户的敏感个人信息时，会通过弹窗或者跳转到确认页面等方式获得用户的单独许可或者单独同意，在明确获得用户的单独许可或者单独同意之后，再获取用于使本申请实施例能够正常运行的必要的用户相关数据。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、***、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

本申请的说明书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括多指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例的方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序的介质。

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.一种低代码平台的权限控制的方法，其特征在于，所述方法包括：

将第一业务表注册为低代码平台的平台元数据表；其中，所述第一业务表用于记录需要进行权限控制的场景元数据；

确定所述平台元数据表的主键标识以及表项集，并根据所述主键标识、所述表项集以及元数据名称，生成权限元数据，其中，所述表项集为所述第一业务表中除所述主键标识对应的第一业务表项以外的第二业务表项的集合；

根据所述权限元数据和用户数据，生成元数据权限列，并将所述元数据权限列更新至权限角色映射列表中；

获取待权限配置的业务场景下的第二业务表并显示所述第二业务表的权限过滤条件设置界面；其中，所述第二业务用于记录需要进行权限控制的场景业务数据；

在所述权限过滤条件设置界面中，对所述第二业务表进行权限配置，得到权限数据，以根据所述权限数据控制对所述第二业务表的访问，所述权限数据包括用于表征所述第二业务表与所述权限角色映射列表之间的权限组合关系的第一权限映射数据，以及用于表征同一业务场景下配置的第一权限映射数据之间的权限组合关系的第二权限映射数据。

2.根据权利要求1所述的低代码平台的权限控制的方法，其特征在于，所述在所述权限过滤条件设置界面中，对所述第二业务表进行权限配置，得到权限数据，包括：

根据所述权限过滤条件设置界面中显示的所述第二业务表的表项输入信息，从所述第二业务表中确定第三业务表项；

建立所述第三业务表项和所述权限角色映射列表之间的权限关系，得到第一权限映射数据；

根据所述第一权限映射数据的“或”逻辑以及“与”逻辑的选中状态，得到第二权限映射数据；

将所述第一权限映射数据和所述第一权限映射数据组合，得到权限数据。

3.根据权利要求2所述的低代码平台的权限控制的方法，其特征在于，所述建立所述第三业务表项和所述权限角色映射列表之间的权限关系，得到第一权限映射数据，包括：

在所述权限过滤条件设置界面中，从所述权限角色映射列表中选出第一元数据权限列；

将所述第一元数据权限列的主键标识、权限组以及元数据名称、所述业务场景的场景名称以及所述第三业务表项之间进行关联，得到第一权限映射数据。

4.根据权利要求3所述的低代码平台的权限控制的方法，其特征在于，所述将所述第一元数据权限列的主键标识、权限组以及元数据名称、所述业务场景的场景名称以及所述第三业务表项之间进行关联，得到第一权限映射数据，包括：

根据所述主键标识、所述权限组以及所述第三业务表项，生成用于查询所述第一业务表的数据库执行脚本；

将所述数据库执行脚本、所述主键标识、所述权限组、所述元数据名称、所述业务场景的场景名称以及所述第三业务表项作为同一条明细记录的字段内容，得到第一权限映射数据；

对应的，所述方法还包括：

接收业务操作请求，所述业务操作请求包括待操作的业务场景的场景名称和用户信息；

根据所述待操作的业务场景的场景名称，确定待执行的数据库执行脚本；

根据所述待执行的数据库执行脚本对所述用户信息对应的操作用户进行操作控制。

5.根据权利要求3所述的低代码平台的权限控制的方法，其特征在于，所述在所述权限过滤条件设置界面中，从所述权限角色映射列表中选出第一元数据权限列，包括：

在所述权限过滤条件设置界面中，显示所述权限角色映射列表中包含的元数据名称；

根据所述元数据名称的选中状态，确定第一元数据表并显示所述第一元数据表下的元数据权限列；

根据所述元数据权限列的选中状态，确定第一元数据权限列。

6.根据权利要求1所述的低代码平台的权限控制的方法，其特征在于，所述根据所述元数据和用户数据，生成元数据权限列，包括：

根据用户配置请求，创建权限名称；

从所述用户数据中选出所述权限名称下用户成员，得到权限组；

在所述权限组下选取所述权限元数据，以将所述权限组与所述权限元数据进行关联，得到元数据权限列。

7.根据权利要求1所述的低代码平台的权限控制的方法，其特征在于，所述确定所述第一业务表中的主键标识以及表项集，并根据所述主键标识、所述表项集以及元数据名称，生成权限元数据，包括：

根据用户的元数据配置请求，确定第一业务表的第一业务表项下的数据为主键标识并确定元数据名称；

对于所述第一业务表中的每一条业务记录，将所述业务记录中所述第二业务表项下的数据按照预设的拼接规则进行拼接并将拼接得到的结果作为预设的元数据结构中的第一字段；

对于所述第一业务表中的每一条业务记录，将元数据名称作为所述元数据结构中的第二字段；

对于所述第一业务表中的每一条业务记录，将所述业务记录中第一业务表项下的数据作为所述元数据结构中的第三字段；

根据所述第一字段、对应的所述第二字段以及对应的所述第三字段，得到所述业务记录对应的权限元数据。

8.一种低代码平台，其特征在于，包括：

注册模块，用于将第一业务表注册为低代码平台的平台元数据表；其中，所述第一业务表用于记录需要进行权限控制的场景元数据；

确定模块，用于确定所述第一业务表中的主键标识以及表项集，并根据所述主键标识、所述表项集以及元数据名称，生成权限元数据，其中，所述表项集为所述第一业务表中除所述主键标识对应的第一业务表项以外的第二业务表项的集合；

元数据权限生成模块，用于根据所述权限元数据和用户数据，生成元数据权限列，并将所述元数据权限列更新权限角色映射列表中；

配置获取模块，用于获取待权限配置的业务场景下的第二业务表并显示所述第二业务表的权限过滤条件设置界面；其中，所述第二业务用于记录需要进行权限控制的场景业务数据；

配置处理模块，用于在所述权限过滤条件设置界面中，对所述第二业务表进行权限配置，得到权限数据，以根据所述权限数据控制对所述第二业务表的访问，所述权限数据包括用于表征所述第二业务表与所述权限角色映射列表之间的权限组合关系的第一权限映射数据，以及用于表征同一业务场景下配置的第一权限映射数据之间的权限组合关系的第二权限映射数据。

9.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的低代码平台的权限控制的方法。

10.一种计算机可读存储介质，所述存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述低代码平台的权限控制的方法。