Data permission access method and device based on permission variables

Abstract

The invention provides a data permission access method and device based on permission variables, and the method comprises the steps: creating a role access model which corresponds to different types of construction roles and each type of construction role corresponds to a plurality of construction users, and obtaining an associated data table corresponding to each type of construction role, the visualization types of the associated data table are different, based on the associated data table, determining a row-level permission variable and a corresponding column-level permission variable of each construction role, converting the row-level permission variable and the corresponding column-level permission variable of each construction role into a screening condition, and setting the screening condition as an access condition of the associated data table, and obtaining permission variables of the current user corresponding to the different roles, and if the permission variables of the current user meet the screening condition, allowing the current user to access the associated data tables corresponding to the different roles. And through the row-level permission variable of each construction role and the corresponding column-level permission variable, a user can access the associated data tables under different roles.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a data permission access method and device based on permission variables. Background Art

[0002] In the era of big data, huge amounts of data are generated rapidly. After analyzing these large amounts of data, in order to protect the privacy and sensitivity of the data, it is necessary to control the access rights to the data. The prior art uses a two-factor authentication (2FA) mechanism to access data securely. This mechanism requires users to provide a second form of identity authentication in addition to the traditional password during the login process, such as a mobile phone SMS verification code, a dynamic password generated by a hardware token, biometric technology (such as fingerprint recognition, facial recognition) or a time-based one-time password (TOTP). After the two-factor authentication is successfully verified, the user can only view one type of business access data, but for the same business data, the prior art has not yet achieved that different users can view different visualized data. Summary of the invention

[0003] The present invention provides a data permission access method and device based on permission variables, which solves the problem in the prior art that different users cannot view different visualized data.

[0004] According to one aspect of the present invention, a data permission access method based on permission variables is provided, comprising:

[0005] Creating a role access model; wherein the role access model corresponds to different types of construction roles, and each construction role corresponds to multiple construction users;

[0006] Obtaining an associated data table corresponding to each construction role; wherein the associated data table has different visualization types;

[0007] Based on the associated data table, determining the row-level permission variable of each construction role and its corresponding column-level permission variable;

[0008] Convert the row-level permission variables of each construction role and its corresponding column-level permission variables into screening conditions;

[0009] Setting the screening condition as the access condition of the associated data table;

[0010] Get the permission variables of the current user corresponding to different roles;

[0011] If the permission variable of the current user meets the screening condition, the current user is allowed to access the associated data tables corresponding to the different roles.

[0012] In one embodiment, creating a role access model includes:

[0013] Create multiple creation organizations; each creation organization corresponds to an organization name, each creation organization corresponds to multiple creation roles, and each creation role corresponds to multiple creation users;

[0014] Set the permission type corresponding to each created role;

[0015] Build a role-based access model based on multiple creation organizations, multiple creation roles, multiple creation users, and multiple permission types.

[0016] In one embodiment, obtaining the associated data table corresponding to each construction role includes:

[0017] Get the target data table;

[0018] The target data table is dragged and dropped to obtain a related data table.

[0019] In one embodiment, dragging the target data table to obtain the associated data table includes:

[0020] Placing the target data table and other target data tables in a modeling canvas; wherein the structure and fields of the target data table are displayed on the modeling canvas;

[0021] Based on the modeling canvas, the target data table is associated with other target data tables to obtain an associated data table.

[0022] In one embodiment, associating the target data table with other target data tables to obtain an associated data table includes:

[0023] Determine the primary key and foreign key of the field to be associated in the target data table;

[0024] The primary key of the field to be associated in the target data table is connected with the foreign key matching the field to be associated in the other target data table to obtain an associated data table.

[0025] In one embodiment, converting the row-level permission variable of each construction role and the corresponding column-level permission variable into a screening condition comprises:

[0026] Based on the correspondence between the row-level permission variable of each construction role and its corresponding column-level permission variable, obtaining the variable value of the column-level permission variable;

[0027] Selecting the maximum variable value and the minimum variable value among the variable values;

[0028] Constructing a variable interval according to the row-level authority variable corresponding to the maximum variable value and the authority variable corresponding to the minimum variable value;

[0029] The variable interval is converted into a screening condition.

[0030] In one embodiment, setting the screening condition as the access condition of the associated data table includes:

[0031] Extracting associated fields from the associated data table;

[0032] The screening condition is set as the access condition of the associated field.

[0033] In one embodiment, the data permission access method based on the permission variable further includes:

[0034] Get unrelated data tables;

[0035] Set the permission variables to be changed for each build role;

[0036] Get the target permission variable;

[0037] Replace the name of the permission variable to be changed with the target permission variable;

[0038] Associating the unrelated data table with the target permission variable;

[0039] If the permission variable of the current user matches the target permission variable, the current user is allowed to access the unrelated database.

[0040] In one embodiment, the setting of the permission variables to be changed corresponding to each construction role includes:

[0041] A preset format is used to add a permission variable to be changed for each construction role; wherein the preset format is constructed by a field, an operator, and a name of the permission variable to be changed.

[0042] According to another aspect of the present invention, there is provided a data permission access device based on permission variables, comprising:

[0043] A creation module, used to create a role access model; wherein the role access model corresponds to different types of construction roles, and each construction role corresponds to multiple construction users;

[0044] A first acquisition module is used to acquire an associated data table corresponding to each construction role; wherein the associated data table has different visualization types;

[0045] A determination module, used to determine the row-level permission variable of each construction role and its corresponding column-level permission variable based on the associated data table;

[0046] A conversion module, used to convert the row-level permission variables of each construction role and its corresponding column-level permission variables into screening conditions;

[0047] A setting module, used for setting the screening condition as the access condition of the associated data table;

[0048] The second acquisition module is used to obtain the permission variables of the current user corresponding to different roles;

[0049] The access module is used to allow the current user to access the associated data tables corresponding to the different roles if the permission variable of the current user meets the screening condition.

[0050] The embodiment of the present invention provides a data permission access method and device based on permission variables, including: creating a role access model, wherein the role access model corresponds to different types of construction roles, each construction role corresponds to multiple construction users, obtaining an associated data table corresponding to each construction role, wherein the visualization type of the associated data table is different, determining the row-level permission variable and its corresponding column-level permission variable for each construction role based on the associated data table, converting the row-level permission variable and its corresponding column-level permission variable for each construction role into a screening condition, setting the screening condition as the access condition of the associated data table, obtaining the permission variable of the current user corresponding to different roles, and allowing the current user to access the associated data table corresponding to different roles if the permission variable of the current user meets the screening condition. The row-level permission variable and its corresponding column-level permission variable for each construction role are determined through the associated data table and converted into a screening condition to satisfy the user's access to the associated data table corresponding to different roles. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is a flowchart of a data permission access method based on permission variables provided by an exemplary embodiment of the present invention.

[0052] Figure 2 It is a flowchart of a method for constructing a role access model provided by an exemplary embodiment of the present invention.

[0053] Figure 3 It is a distribution diagram of row-level permission variables and column-level permission variables of a role provided by an exemplary embodiment of the present invention.

[0054] Figure 4 It is a structural diagram of a data authority access device based on authority variables provided by an exemplary embodiment of the present invention.

[0055] Figure 5 It is a structural diagram of a data authority access device based on authority variables provided by another exemplary embodiment of the present invention.

[0056] Figure 6 is a structural diagram of an electronic device provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0057] Figure 1 FIG. 1 is a flow chart of a data permission access method based on permission variables provided by an exemplary embodiment of the present invention. Figure 1 As shown, the data permission access methods based on permission variables include:

[0058] Step 110: Create a role access model, wherein the role access model corresponds to different types of construction roles, and each construction role corresponds to multiple construction users.

[0059] In the embodiment of the present invention, multiple construction users under different types of construction roles can be managed by creating a role access model. And different types of construction roles can correspond to different types, such as administrator, seller, organizer, etc.

[0060] Step 120: Obtain an associated data table corresponding to each construction role, wherein the visualization type of the associated data table is different.

[0061] In the embodiment of the present invention, in order to realize different visualizations of associated data tables corresponding to different types of construction roles, the present invention obtains the associated data table corresponding to each construction role, and visualizes the associated data table in different types.

[0062] Step 130: Based on the associated data table, determine the row-level permission variable and the corresponding column-level permission variable of each construction role.

[0063] In an embodiment of the present invention, obtaining the row-level permission variables and their corresponding column-level permission variables for each constructed role is a sophisticated permission division process. This means that not only is it necessary to set which data rows can be accessed by the role in each associated data table (row-level permissions), but it is also necessary to further specify which columns these roles can operate on specific rows (column-level permissions). This dual permission control mechanism greatly enhances the security and flexibility of data, allowing data managers to assign column-level operation permissions to different users or roles according to actual needs. By clearly distinguishing between row-level and column-level permission variables, it can ensure that data can be legally accessed while preventing unauthorized data tampering or leakage to the greatest extent.

[0064] For example, roles include administrator, department manager, and employee. Permissions with row-level restrictions include: For administrators, there are no row-level restrictions and they can access all rows in the associated data table. For department managers, row-level permissions are set based on their department IDs so that they can only access employee information rows belonging to their own departments. For ordinary employees, row-level permissions are set based on their employee IDs, allowing them to access only their own information rows. Permissions with column-level restrictions include: For employees, the system sets row-level permissions based on their employee IDs, allowing them to access only their own information rows. Employees can only view basic information such as their name and department, and sensitive fields such as salary are completely invisible to them. In this example, the combination of row-level permissions and column-level permissions enables the company to flexibly control the access scope of different roles to data in the "Employee Information" table. This refined permission control mechanism not only protects the sensitivity and privacy of data, but also improves the efficiency and security of data management.

[0065] Step 140: Convert the row-level permission variable of each construction role into a filter condition with its corresponding column-level permission variable.

[0066] In an embodiment of the present invention, the row-level permission variables of each constructed role and its corresponding column-level permission variables are converted into screening conditions through SQL statements, so that users who meet the screening conditions can locate the associated data table corresponding to the constructed role. SQL (Structured Query Language) is a standard programming language for accessing and operating database systems. It allows users to retrieve data from a database, insert new records, update existing records, and delete unnecessary records. SQL statements are used to manage data in relational database management systems (RDBMS), such as MySQL, PostgreSQL, Oracle, SQL Server, SQLite, etc.

[0067] Step 150: Set the screening condition as the access condition of the associated data table.

[0068] In the embodiment of the present invention, by setting reasonable screening conditions, the time cost of query can be significantly reduced, the full table scan can be avoided, and the efficiency of data access can be improved. The screening conditions can help users obtain data that is highly relevant to their query requirements, thereby improving the accuracy of data analysis.

[0069] Step 160: Obtain the permission variables of the current user corresponding to different roles.

[0070] In an embodiment of the present invention, obtaining the permission variables of the current user involves identifying and mapping the permissions corresponding to different roles. This process first determines the scope of the user's permissions based on the user's role in the system (such as administrator, salesperson, customer, etc.). The system retrieves the permission variables associated with the role through an internal permission management mechanism, and then applies these variables to the current user to determine the data that the user can access or the operations that can be performed. This mechanism not only ensures the accurate allocation of permissions, but also enhances the security and flexibility of the system, allowing users to perform effective operations within the scope of their authorization. In this way, the system can dynamically adapt to changes in user roles and update permission variables in real time, thereby maintaining the compliance and security of data access.

[0071] Step 170: If the permission variable of the current user meets the screening condition, the current user is allowed to access the associated data tables corresponding to different roles.

[0072] The embodiment of the present invention provides a data permission access method based on permission variables, including: creating a role access model, wherein the role access model corresponds to different types of construction roles, each construction role corresponds to multiple construction users, obtaining an associated data table corresponding to each construction role, wherein the visualization type of the associated data table is different, determining the row-level permission variable and the corresponding column-level permission variable of each construction role based on the associated data table, converting the row-level permission variable and the corresponding column-level permission variable of each construction role into a screening condition, setting the screening condition as the access condition of the associated data table, obtaining the permission variable of the current user corresponding to different roles, and allowing the current user to access the associated data table corresponding to different roles if the permission variable of the current user meets the screening condition. The row-level permission variable and the corresponding column-level permission variable of each construction role are determined through the associated data table and converted into a screening condition to satisfy the user's access to the associated data table corresponding to different roles.

[0073] Figure 2 FIG. 1 is a flow chart of a method for constructing a role access model provided by an exemplary embodiment of the present invention. Figure 2 As shown, step 110 may include:

[0074] Step 111: Create multiple creation organizations, where each creation organization corresponds to an organization name, each creation organization corresponds to multiple creation roles, and each creation role corresponds to multiple creation users.

[0075] In an embodiment of the present invention, in order to better manage multiple creation roles and multiple creation users under each creation role, the present invention creates multiple creation organizations, and each creation organization manages multiple creation roles, thereby achieving hierarchical management and clear division of labor.

[0076] Step 112: Set the permission type corresponding to each created role.

[0077] In an embodiment of the present invention, setting the permission type corresponding to each created role is a key step to ensure smooth internal operations, clear responsibilities and efficiency of the organization. This approach not only clarifies the position and scope of responsibilities of each role in the organization, but also ensures information security and promotes the rational allocation of resources through a detailed division of permissions. Specifically, it requires a set of appropriate permission sets to be tailored for each role based on the nature of the role, responsibility requirements and the security policy of the organization. These permissions cover multiple aspects such as data access, operation execution, and decision-making participation to ensure that each member can effectively perform their duties within the scope of authorization while avoiding potential problems caused by excessive or insufficient permissions.

[0078] Step 113: Build a role access model based on multiple creation organizations, multiple creation roles, multiple creation users, and multiple permission types.

[0079] In one embodiment, step 120 may be specifically implemented as follows: obtaining a target data table; and dragging the target data table to obtain a related data table.

[0080] In the embodiment of the present invention, each role corresponds to a different data table or multiple data tables, so the target data table corresponding to each role is obtained, and then the target data table is dragged to obtain the associated data table. When the user accesses the role, the associated data table under the role can be obtained.

[0081] In one embodiment, step 120 may be specifically implemented as follows: placing the target data table and other target data tables in a modeling canvas; wherein the structure and fields of the target data table are displayed on the modeling canvas; and based on the modeling canvas, associating the target data table with other target data tables to obtain an associated data table.

[0082] In the embodiment of the present invention, since the data table visualization under each role is different, if the user wants to view the association between the target data table and other target data tables, the target data table can be associated with other target data tables by dragging and dropping.

[0083] Specifically, the target data table and other data tables may be placed in the modeling canvas, and the user may perform a drag operation in the modeling canvas or the system may directly and automatically associate the target data table and other data tables in the modeling canvas.

[0084] In one embodiment, step 120 can be specifically implemented as follows: determining the primary key and foreign key of the field to be associated in the target data table; connecting the primary key of the field to be associated in the target data table with the foreign key matching the field to be associated in other target data tables to obtain an associated data table.

[0085] In an embodiment of the present invention, when the associated data tables under different roles are based only on the association between fields, the primary key and foreign key of the field to be associated in the target data table can be determined first, and the primary key of the field to be associated in the target data table is connected with the foreign key matching the field to be associated in other target data tables to obtain the associated data table.

[0086] Specifically, in order to build a related data table, you first need to identify the key fields used for association in each target data table, that is, determine which fields are primary keys (fields that can uniquely identify each row of data in the table) and which fields are foreign keys (fields used to establish connections with primary keys in other tables). Subsequently, by matching and connecting these primary keys with corresponding foreign keys, information from different but related data tables can be integrated to form a related data table that contains richer and more complete information. This process helps to improve the efficiency and depth of data analysis, making cross-table queries and data integration more intuitive and convenient.

[0087] Figure 3 FIG. 1 is a schematic diagram showing the distribution of row-level permission variables and column-level permission variables of a role provided by an exemplary embodiment of the present invention. Figure 3 As shown, step 140 can be specifically implemented as follows: based on the correspondence between the row-level permission variables of each constructed role and its corresponding column-level permission variables, obtain the variable value of the column-level permission variable; select the maximum variable value and the minimum variable value among the variable values; construct a variable interval according to the row-level permission variable corresponding to the maximum variable value and the permission variable corresponding to the minimum variable value; and convert the variable interval into a filtering condition.

[0088] In the embodiment of the present invention, since each construction role corresponds to a different visual data table, the present invention can determine the row-level permission variables and column-level permission variables of each construction role based on the visual data table.

[0089] Specifically, Figure 3 As shown, Figure 3 Provides regional sales and profit, row-level permission variables are regions, column-level permission variables are sales or profit, Figure 3 It can be seen that the sales or profit amount corresponding to South China is the maximum value, and the sales or profit amount corresponding to East China is the minimum value. Therefore, the variable interval is set to (East China, South China), and users with the corresponding roles under this variable interval can access the sales and profit amount of this region.

[0090] In one embodiment, step 150 may be specifically implemented as follows: extracting associated fields from the associated data table; and setting the screening condition as the access condition of the associated fields.

[0091] In the embodiment of the present invention, the associated field can be extracted from the associated data table, and the associated field can be used as the access condition of the associated field. For example, the associated field can be an associated field that associates a department with performance, so the user can only access the associated field if he is in the department and has performance.

[0092] In one embodiment, the data permission access method based on permission variables can be specifically implemented as follows: obtain an unrelated data table; set the permission variables to be changed corresponding to each construction role; obtain the target permission variable; replace the name of the permission variable to be changed with the target permission variable; associate the unrelated data table with the target permission variable; if the permission variable of the current user matches the target permission variable, the current user is allowed to access the unrelated database.

[0093] In an embodiment of the present invention, if the user does not need to view the associated data table but needs to view the unassociated data, then the permission variable to be changed corresponding to each construction role is set. For example, the permission variable of the construction role is the administrator, but the administrator needs to be changed to the department head. Then the department head is the target permission variable, and the administrator is the permission variable to be changed. The name of the permission variable to be changed is replaced with the target permission variable, that is, the administrator is changed to the department head. And the unassociated data table is associated with some supervisors. If the permission variable of the current user (department head) matches the target permission variable (department head), the current user is allowed to access the unassociated database.

[0094] For example, unrelated data tables are tables that exist independently in the database and do not have direct foreign key relationships with other tables. For example, there may be a data table called "Products Table" that contains information about all products, but is not directly related to the Order Table or Customer Table. Products Table: Contains fields such as ProductID, ProductName, Price, etc. Depending on the different user roles (such as administrator, salesperson, customer, etc.), the system needs to define their own permission variables. These permission variables will determine what data the user can access. Examples of roles and permission variables: Administrator role: $AdminAccess$ (full access rights), Salesperson role: $SalesAccess$ (view customer data related to oneself), Customer role: $CustomerAccess$ (can only view one's own order information). In a specific query or operation, the system needs to identify the target permission variables, which will be used to verify the access rights of the current user. The target permission variables are usually pre-defined in the business logic. The target permission variable: $TargetAccess$ may correspond to the access rights of the "Salesperson" role. Before the query is executed, the system will replace the permission variable to be changed with the target permission variable. This process ensures the adaptability and flexibility of user permissions. Sample process: Original permission variable: $SalesAccess$, replaced permission variable: $TargetAccess$. Through logical relationships, unrelated data tables are associated with target permission variables. The purpose of this is to combine data access control with user permission management. When a user requests access to the "Product Table", the system checks the access rules associated with $TargetAccess$. When a user executes a data access request, the system checks whether the permission variable of the current user matches the target permission variable. If they match, the user will be allowed to access the unrelated data table; if they do not match, access will be denied. The permission variable of the current user: $CurrentUserAccess$ (such as $SalesAccess$), the target permission variable: $TargetAccess$ (such as $SalesAccess$), if $CurrentUserAccess$ is the same as $TargetAccess$, access is allowed; otherwise, access is denied. After completing all verifications, the system will make corresponding decisions based on the matching results: if the permissions match, the user can perform queries or operations to access the data of the "Product Table". If the permissions do not match, the user will receive a corresponding error message, prompting them that they do not have sufficient permissions.

[0095] In one embodiment, the data permission access method based on permission variables can be specifically implemented as follows: using a preset format to add permission variables to be changed to each construction role; wherein the preset format is constructed by fields, operators, and the names of the permission variables to be changed.

[0096] In an embodiment of the present invention, the permission variable to be changed can be added to each construction role in a preset format. The preset format consists of a field, an operator, and the name of the permission variable to be changed. Specifically, (permission variable to be changed operator $target permission variable $). For example, (administrator = $department head $), the meaning of this preset format is to change the administrator to the department head. "=" and "$" are operators.

[0097] For example, the CustomerID field in the customer table can be set to the permission variable $CurrentUserID$ to be changed. If the target permission variable is 12345, then replace $CurrentUserID$ with 12345.

[0098] Figure 4 FIG. 1 is a schematic diagram of a data permission access device based on permission variables provided by an exemplary embodiment of the present invention. Figure 4 As shown, the data permission access device based on permission variables includes: a creation module 201, used to create a role access model; wherein the role access model corresponds to different types of construction roles, and each construction role corresponds to multiple construction users; a first acquisition module 202, used to obtain the associated data table corresponding to each construction role; wherein the visualization type of the associated data table is different; a determination module 203, used to determine the row-level permission variables of each construction role and its corresponding column-level permission variables based on the associated data table; a conversion module 204, used to convert the row-level permission variables of each construction role and its corresponding column-level permission variables into filtering conditions; a setting module 205, used to set the filtering conditions as access conditions of the associated data table; a second acquisition module 206, used to obtain the permission variables of the current user corresponding to different roles; an access module 207, used to allow the current user to access the associated data tables corresponding to different roles if the permission variables of the current user meet the filtering conditions.

[0099] The embodiment of the present invention provides a data permission access device based on permission variables, including: a creation module creates a role access model, wherein the role access model corresponds to different types of construction roles, each construction role corresponds to multiple construction users, a first acquisition module obtains an associated data table corresponding to each construction role, wherein the visualization type of the associated data table is different, a determination module determines the row-level permission variables and the corresponding column-level permission variables of each construction role based on the associated data table, a conversion module converts the row-level permission variables and the corresponding column-level permission variables of each construction role into a screening condition, a setting module sets the screening condition as an access condition of the associated data table, a second acquisition module obtains the permission variables of the current user corresponding to different roles, and an access module allows the current user to access the associated data table corresponding to different roles if the permission variables of the current user meet the screening condition. The row-level permission variables and the corresponding column-level permission variables of each construction role are determined through the associated data table and converted into screening conditions to satisfy the user's access to the associated data table corresponding to different roles.

[0100] Figure 5 FIG. 1 is a schematic diagram of a data permission access device based on permission variables provided by another exemplary embodiment of the present invention. Figure 5 As shown, the creation module 201 may include: an organization unit 2011, used to create multiple creation organizations; wherein each creation organization corresponds to an organization name, each creation organization corresponds to multiple creation roles, and each creation role corresponds to multiple creation users; a type unit 2012, used to set the permission type corresponding to each creation role; a construction sub-unit 2013, used to construct a role access model based on multiple creation organizations, multiple creation roles, multiple creation users and multiple permission types.

[0101] In one embodiment, the first acquisition module 202 may be specifically configured to: acquire a target data table; and drag and drop the target data table to obtain a related data table.

[0102] In one embodiment, the first acquisition module 202 can be specifically configured as follows: placing the target data table and other target data tables in a modeling canvas; wherein the structure and fields of the target data table are displayed on the modeling canvas; based on the modeling canvas, associating the target data table with other target data tables to obtain an associated data table.

[0103] In one embodiment, the first acquisition module 202 can be specifically configured to: determine the primary key and foreign key of the field to be associated in the target data table; connect the primary key of the field to be associated in the target data table with the foreign key matching the field to be associated in other target data tables to obtain an associated data table.

[0104] In one embodiment, the conversion module 204 can be specifically configured as follows: based on the correspondence between the row-level permission variables of each constructed role and their corresponding column-level permission variables, obtain the variable value of the column-level permission variable; select the maximum variable value and the minimum variable value among the variable values; construct a variable interval according to the row-level permission variable corresponding to the maximum variable value and the permission variable corresponding to the minimum variable value; and convert the variable interval into a filtering condition.

[0105] In one embodiment, the setting module 205 may be specifically configured to: extract associated fields from the associated data table; and set the screening condition as an access condition of the associated field.

[0106] In one embodiment, the data permission access device based on permission variables can be specifically configured as follows: obtaining an unrelated data table; setting the permission variables to be changed corresponding to each construction role; obtaining a target permission variable; replacing the name of the permission variable to be changed with the target permission variable; associating the unrelated data table with the target permission variable; if the permission variable of the current user matches the target permission variable, allowing the current user to access the unrelated database.

[0107] In one embodiment, the data permission access device based on permission variables can be specifically configured as follows: using a preset format to add permission variables to be changed to each construction role; wherein the preset format is constructed by fields, operators and the names of the permission variables to be changed.

[0108] Figure 6 A block diagram of an electronic device according to an embodiment of the present application is illustrated.

[0109] like Figure 6 As shown, the electronic device 10 includes one or more processors 11 and a memory 12 .

[0110] The processor 11 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.

[0111] The memory 12 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 11 may run the program instructions to implement the data permission access method based on permission variables and / or other desired functions of the various embodiments of the present application described above. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0112] In one example, the electronic device 10 may further include: an input device 13 and an output device 14, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0113] When the electronic device 10 is a stand-alone device, the input device 13 may be a communication network connector for receiving collected input signals from the first device and the second device.

[0114] In addition, the input device 13 may also include, for example, a keyboard, a mouse, and the like.

[0115] The output device 14 can output various information to the outside, including the determined distance information, direction information, etc. The output device 14 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0116] Of course, to simplify, Figure 6 Only some of the components related to the present application in the electronic device 10 are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device 10 may also include any other appropriate components.

[0117] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0118] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0119] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A data permission access method based on permission variables, characterized in that: include: Creating a role access model; wherein the role access model corresponds to different types of construction roles, and each construction role corresponds to multiple construction users; Obtaining an associated data table corresponding to each construction role; wherein the associated data table has different visualization types; Based on the associated data table, determining the row-level permission variable of each construction role and its corresponding column-level permission variable; Convert the row-level permission variables of each construction role and its corresponding column-level permission variables into screening conditions; Setting the screening condition as the access condition of the associated data table; Get the permission variables of the current user corresponding to different roles; If the permission variable of the current user meets the screening condition, the current user is allowed to access the associated data tables corresponding to the different roles.

2. The data permission access method based on permission variables according to claim 1 is characterized in that: The creation of a role access model includes: Create multiple creation organizations; each creation organization corresponds to an organization name, each creation organization corresponds to multiple creation roles, and each creation role corresponds to multiple creation users; Set the permission type corresponding to each created role; Build a role-based access model based on multiple creation organizations, multiple creation roles, multiple creation users, and multiple permission types.

3. The data permission access method based on permission variables according to claim 1, characterized in that: The obtaining of the associated data table corresponding to each construction role includes: Get the target data table; The target data table is dragged and dropped to obtain a related data table.

4. The data permission access method based on permission variables according to claim 3 is characterized in that: The dragging and dropping of the target data table to obtain the associated data table includes: Placing the target data table and other target data tables in a modeling canvas; wherein the structure and fields of the target data table are displayed on the modeling canvas; Based on the modeling canvas, the target data table is associated with other target data tables to obtain an associated data table.

5. The data permission access method based on permission variables according to claim 4 is characterized in that: The associating the target data table with other target data tables to obtain an associated data table includes: Determine the primary key and foreign key of the field to be associated in the target data table; The primary key of the field to be associated in the target data table is connected with the foreign key matching the field to be associated in the other target data table to obtain an associated data table.

6. The data permission access method based on permission variables according to claim 1, characterized in that: The converting of the row-level permission variable of each construction role and the corresponding column-level permission variable into a screening condition comprises: Based on the correspondence between the row-level permission variable of each construction role and its corresponding column-level permission variable, obtaining the variable value of the column-level permission variable; Selecting the maximum variable value and the minimum variable value among the variable values; Constructing a variable interval according to the row-level authority variable corresponding to the maximum variable value and the authority variable corresponding to the minimum variable value; The variable interval is converted into a screening condition.

7. The data permission access method based on permission variables according to claim 1, characterized in that: The step of setting the screening condition as the access condition of the associated data table includes: Extracting associated fields from the associated data table; The screening condition is set as the access condition of the associated field.

8. The data permission access method based on permission variables according to claim 1, characterized in that: Also includes: Get unrelated data tables; Set the permission variables to be changed for each build role; Get the target permission variable; Replace the name of the permission variable to be changed with the target permission variable; Associating the unrelated data table with the target permission variable; If the permission variable of the current user matches the target permission variable, the current user is allowed to access the unrelated database.

9. The data permission access method based on permission variables according to claim 8, characterized in that: The permission variables to be changed corresponding to each construction role are set as follows: A preset format is used to add a permission variable to be changed for each construction role; wherein the preset format is constructed by a field, an operator, and a name of the permission variable to be changed.

10. A data permission access device based on permission variables, characterized in that: include: A creation module, used to create a role access model; wherein the role access model corresponds to different types of construction roles, and each construction role corresponds to multiple construction users; A first acquisition module is used to acquire an associated data table corresponding to each construction role; wherein the associated data table has different visualization types; A determination module, used to determine the row-level permission variable of each construction role and its corresponding column-level permission variable based on the associated data table; A conversion module, used to convert the row-level permission variables of each construction role and its corresponding column-level permission variables into screening conditions; A setting module, used for setting the screening condition as the access condition of the associated data table; The second acquisition module is used to obtain the permission variables of the current user corresponding to different roles; The access module is used to allow the current user to access the associated data tables corresponding to the different roles if the permission variable of the current user meets the screening condition.

Images