A data permission access method and device based on permission variables
By creating a role access model and converting permission variables, the problem of different users viewing different visual data is solved, and the flexibility and security of data access are achieved.
Patent Information
- Application Number
- CN202411405402.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-10
- Publication Date
- 2025-09-26
- Estimated Expiration
- 2044-10-10
AI Technical Summary
The existing technology fails to enable different users to view different visualized data, resulting in inflexible and insecure data access control.
By creating a role access model, obtaining the associated data table corresponding to each constructed role, determining the row-level and column-level permission variables, converting them into filter conditions, and setting them as access conditions, obtaining the permission variables of the current user to satisfy the access rights.
It achieves refined access control of data for different users, improves data security and management efficiency, and ensures data sensitivity and privacy.
Smart Images

Figure CN119416248B_ABST
Abstract
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 at a rapid pace. After analyzing these large amounts of data, in order to protect the privacy and sensitivity of the data, it is necessary to control access rights to the data. The existing technology uses a two-factor authentication (2FA) mechanism to provide secure access to data. This mechanism requires users to provide a second form of 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. However, for the same business data, the existing technology has not yet achieved the goal of allowing different users to 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 and the corresponding column-level permission variable of each construction role;
[0008] Convert the row-level permission variables of each construction role and its corresponding column-level permission variables into filter 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 associated data tables.
[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 includes:
[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 corresponding to 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 authority 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, setting 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, a data permission access device based on permission variables is provided, comprising:
[0043] A creation module is 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 visualization type of the associated data table is different;
[0045] A determination module, configured to determine the row-level permission variable and the corresponding column-level permission variable of each construction role based on the associated data table;
[0046] The conversion module is used to convert the row-level permission variables of each construction role and its corresponding column-level permission variables into filter conditions;
[0047] A setting module, configured to set the screening condition as an access condition for 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 configured 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] An 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 filtering condition, setting the filtering condition as the access condition for the associated data table, obtaining the permission variable of the current user corresponding to the different roles, and allowing the current user to access the associated data tables corresponding to the different roles if the permission variable of the current user meets the filtering 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 filtering condition to satisfy the user's access to the associated data tables corresponding to the 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 This 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 permission access device based on permission variables provided by an exemplary embodiment of the present invention.
[0055] Figure 5 It is a structural diagram of a data permission access device based on permission 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 an embodiment of the present invention, a role access model is created to manage multiple build users under different types of build roles. Different types of build roles can correspond to different types, such as administrator, seller, organizer, etc.
[0060] Step 120: Obtain the associated data table corresponding to each construction role, wherein the visualization type of the associated data table is different.
[0061] In an embodiment of the present invention, in order to realize associated data tables with different visualizations corresponding to different types of construction roles, the present invention obtains an 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 for each constructed 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 refined 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 the data, allowing data managers to assign column-level operation permissions to different users or roles based on 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 possible.
[0064] For example, roles include administrator, department manager, and employee. Row-level restricted permissions 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 ID, allowing them to access only the employee information rows belonging to their department. For ordinary employees, row-level permissions are set based on their employee ID, allowing them to access only their own information rows. Column-level restricted permissions include: For employees, the system sets row-level permissions based on their employee ID, 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 and column-level permissions allows 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 and its corresponding column-level permission variable into a screening condition.
[0066] In an embodiment of the present invention, SQL statements are used to convert the row-level permission variables of each constructed role and its corresponding column-level permission variables into screening conditions, so that users who meet the screening conditions can access 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, and SQLite.
[0067] Step 150: Set the filter condition as the access condition of the associated data table.
[0068] In the embodiments of the present invention, by setting reasonable filtering conditions, the query time cost can be significantly reduced, full table scans can be avoided, and the efficiency of data access can be improved. The filtering 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 they can access or the operations they can perform. 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] An 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 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 for the associated data table, obtaining the permission variable of the current user corresponding to the different roles, and allowing 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. 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 tables corresponding to the 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, clear and efficient internal operations 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 fine division of permissions. Specifically, it requires a set of appropriate permission sets tailored for each role based on the nature of the role, the requirements of the responsibilities 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. Therefore, the target data table corresponding to each role is obtained, and then the target data table is dragged and dropped to obtain the associated data table. When a 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 the other target data tables to obtain associated data tables.
[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 user can associate the target data table 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-and-drop operation in the modeling canvas, or the system may automatically associate the target data table with other data tables in the modeling canvas.
[0084] In one embodiment, step 120 may be specifically implemented as follows: determining the primary key and foreign key of the field to be associated in the target data table; and 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 can be connected with the foreign key matching the field to be associated in other target data tables to obtain the associated data table.
[0086] Specifically, to build a linked data table, you first need to identify the key fields in each target data table used for the association. That is, determine which fields are primary keys (fields that 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 linked data table containing richer and more complete information. This process helps 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 distribution diagram 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 variable of each constructed role and its corresponding column-level permission variable, 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, if 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 a screening condition as an access condition for the associated fields.
[0091] In an embodiment of the present invention, a related field can be extracted from a related data table and used as an access condition for the related field. For example, the related field can be a related field that associates a department with performance. In this case, the related field can only be accessed by users who are in the department and have performance.
[0092] In one embodiment, the data permission access method based on permission variables can be specifically implemented as follows: obtaining an unrelated data table; setting the permission variable to be changed corresponding to each construction role; obtaining the 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.
[0093] In an embodiment of the present invention, if a user does not need to view the associated data table but needs to view unrelated data, then the permission variable to be changed corresponding to each constructed role is set. For example, the permission variable of the constructed role is administrator, but the administrator needs to be changed to 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 department head. The unrelated data table is also associated with some of the heads. 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 unrelated database.
[0094] For example, unrelated tables are independent tables in the database that don't have direct foreign key relationships with other tables. For example, there might be a table called "Products" that contains information about all products but isn't directly related to the Orders or Customers tables. The Products table contains fields such as ProductID, ProductName, and Price. The system defines permission variables for different user roles (such as administrator, salesperson, and customer). These permission variables determine what data a user can access. Examples of roles and permission variables include: $AdminAccess$ (full access rights for the administrator role), $SalesAccess$ (view customer data related to the user), and $CustomerAccess$ (view only their own orders). For specific queries or operations, the system identifies target permission variables, which are used to verify the current user's access rights. These target permission variables are typically predefined in the business logic. The target permission variable, $TargetAccess$, might correspond to the access rights of the "Salesperson" role. Before executing a query, the system replaces the permission variable to be modified with the target permission variable. This process ensures adaptability and flexibility in user permissions. Example process: Original permission variable: $SalesAccess$, replaced permission variable: $TargetAccess$. Through a logical relationship, an unrelated data table is associated with the target permission variable. This is done to integrate data access control with user permission management. When a user requests access to the "Products" table, the system checks the access rules associated with $TargetAccess$. When the user executes the data access request, the system checks whether the current user's permission variable matches the target permission variable. If so, the user is allowed access to the unrelated data table; if not, access is denied. The current user's permission variable: $CurrentUserAccess$ (e.g., $SalesAccess$), the target permission variable: $TargetAccess$ (e.g., $SalesAccess$). If $CurrentUserAccess$ matches $TargetAccess$, access is granted; otherwise, access is denied. After completing all validations, the system makes a decision based on the matching results: If the permissions match, the user can perform queries or operations to access data in the "Products" table. If the permissions do not match, the user receives an error message indicating 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 the permission variable to be changed to each construction role; wherein the preset format is constructed by a field, an operator and the name of the permission variable to be changed.
[0096] In an embodiment of the present invention, a permission variable to be changed can be added to each construction role using 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 $) means that the preset format changes the administrator to the department head. "=" and "$" are operators.
[0097] For example, for the CustomerID field in the customer table, you can set the permission variable to be changed to $CurrentUserID$. If the target permission variable is 12345, then replace $CurrentUserID$ with 12345.
[0098] Figure 4 FIG. 1 is a schematic diagram of a data authority access device based on authority 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, which is 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, which is 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, which is 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, which is 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, which is used to set the filtering conditions as access conditions of the associated data table; a second acquisition module 206, which is used to obtain the permission variables of the current user corresponding to different roles; an access module 207, which is 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] An embodiment of the present invention provides a data permission access device based on permission variables, including: a creation module that creates 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 that obtains an associated data table corresponding to each construction role, wherein the visualization type of the associated data table is different; a determination module that determines the row-level permission variables and their corresponding column-level permission variables for each construction role based on the associated data table; a conversion module that converts the row-level permission variables and their corresponding column-level permission variables for each construction role into filtering conditions; a setting module that sets the filtering conditions as access conditions for the associated data table; a second acquisition module that obtains the permission variables of the current user corresponding to different roles; and an access module that allows 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. The row-level permission variables and their corresponding column-level permission variables for each construction role are determined through the associated data table and converted into filtering conditions to satisfy user access to the associated data tables corresponding to different roles.
[0100] Figure 5 FIG. 1 is a schematic diagram of a data authority access device based on authority 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 to: place 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, associate 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 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 based on 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 fields.
[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 variable 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 for 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 The figure shows a block diagram of an electronic device according to an embodiment of the present application.
[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, for example, include random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may, for example, include 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, configured to receive 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 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, the electronic device 10 may further include any other appropriate components according to specific application scenarios.
[0117] The computer program product may be written in any combination of one or more programming languages to implement the program code for performing the operations of the embodiments of the present application, including object-oriented programming languages such as Java, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's 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, for example, include but is not limited to a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. 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 thereof.
[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 and the corresponding column-level permission variable of each construction role; Convert the row-level permission variables of each construction role and its corresponding column-level permission variables into filter 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, characterized in that: Creating 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 associated data tables.
5. The data permission access method based on permission variables according to claim 4 is characterized in that: 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: Converting the row-level permission variable of each construction role and the corresponding column-level permission variable into a screening condition includes: 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 corresponding to 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 authority variable; If the permission variable of the current user matches the target permission variable, the current user is allowed to access the unrelated data table.
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 include: 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 is 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 visualization type of the associated data table is different; A determination module, configured to determine the row-level permission variable and the corresponding column-level permission variable of each construction role based on the associated data table; The conversion module is used to convert the row-level permission variables of each construction role and its corresponding column-level permission variables into filter conditions; A setting module, configured to set the screening condition as an access condition for the associated data table; The second acquisition module is used to obtain the permission variables of the current user corresponding to different roles; An access module is configured 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.
Citation Information
Patent Citations
Column-level permission knowledge graph construction method for operation and maintenance service data table
CN110928963A
Row and column permission setting method and device applied to data access
CN113934995A