Permission management design-2

This article provides a solution for integrating function permissions and data permissions to achieve centralized permission management in multi-level organizations. This method is further extended and extended by RBAC (Role-Based Access Control method), that is, data permission management is added on the basis of functional permissions to achieve centralized processing of data permissions and functional permissions. Explanation: Functional permissions: what can be done, such as adding sales orders; Data permissions: What can be done? For example, check the sales order of Michael Zhang of Haidian sales department of Beijing Branch; term: Resource: resources in the system are mainly various business objects, such as sales and payment orders. Operation types: possible access methods to resources, such as adding, deleting, and modifying resources. functions: operations on resources are two groups of resources and operation types, such as adding a sales order or modifying a sales order. Data Type: Common Data permission types in business systems, such as companies, departments, projects, and individuals; Data Objects: specific business objects, such as Company A and department B, including all object values related to data permissions; permissions: functions that a role can use, including the role's functional permissions and the role's data permissions; Roles: a set of specific permissions; users: subjects involved in system activities, such as persons and systems. General data permission management system design (2) method Description: in actual applications, data permission control points are generally relatively fixed, such as for companies, departments, individuals, customers, suppliers, etc, that is to say, the data permission is generally targeted at some data objects of the specified data type. In this method, the data permission depends on the function permission, which is a further description of the function permission, indicating the data control permission of the role on the specified function point. This method adopts the principle that "no explicit provisions are deemed to be valid". If no data permission is defined for a function, the role has all permissions for this function. If you define a certain type of data permission for the function, the user only has the data permission for the specified data of this type. This section is a detour. The following is an example. A company has three sales departments: Beijing sales department, Shanghai sales department, and Guangzhou sales department. Now we need to define several roles: Sales Director-to view all sales orders; beijing Sales Manager-only view all sales orders of Beijing sales department; Shanghai Sales Manager-only view all sales orders of Shanghai Sales Department; Guangzhou sales manager-only view all sales orders of Guangzhou sales department; the preceding roles are defined as follows: role name function data type data object Butler Sales Director Inspection of sales orders Beijing Sales Manager inspection of sales orders department Beijing Shanghai Sales Manager inspection of sales orders Department Shanghai Guangzhou sales manager inspection of sales orders department Guangzhou ----------------- ---------------------------------------------- In the above definition, the sales director only defines the function permission, but does not define the data permission, so the sales director can view all the sales orders; the other sales managers define the data permissions for this function, so they can only view the sales orders of the specified department. In practice, a department group is often used. The team lead can view the sales orders processed by all the personnel in the group, and in some cases, some people can only view their own sales orders, these special situations cannot be solved in the above descriptions and need to be addressed in the design and implementation. Beijing sales representative-only view all the sales orders of the Beijing sales department; Beijing sales representative view the design of the Beijing General Data permission management system of the sales order Department (3) -- Database Design: Let's first look at the traditional role-based permission management system, as shown in, the simplest role-based permission management consists of system functions, system roles, system users, role functions, and user roles. Figure 1: Role-based database structure to implement data permission control, role-based permission management is expanded in design, as shown in Figure 2: the two general data permission management system database designs are compared. We can see that the main changes between them are: 1. Increase system resource information and operation type information, system resources are in a tree structure, such as a sales module and a sales order. Operation types record possible operations, such as adding, deleting, modifying, viewing, and querying, system functions are a combination of resources and operation types, and operations on resources are system functions. 2. added two tables: Data Object Type and data object. The data object type records the object types to be controlled in the system, such as departments, warehouses, employees, customers, and suppliers; data Object records object instances of various object types, such as Beijing sales department, Shanghai sales department, Zhang San, and Li Si. (The benefits of independent storage will be discussed later) 3. Add an association table (many-to-many) between system resources and data object types. This table is a configuration table, indicating the possible control points required by a resource, for example, the association between a sales order and a department may involve assigning permissions to different departments, and the association between a sales order and a customer may involve assigning permissions to customers. 4. Add the association between data objects and role permissions. This table is the location where data permission management is implemented. This design can minimize changes to the original permission system and flexibly add data control points. It can be used in the design of productized software to flexibly meet customers' needs. The next article will discuss how this structure can meet the functional requirements of the second part. If time permits, the program design will be further elaborated. This design method has been applied to self-developed general supply chain management systems.

 Open-source supply chain [invoicing] System Description DirectoryThis article provides a solution for integrating function permissions and data permissions to achieve centralized permission management in multi-level organizations. This method is further extended and extended by RBAC (Role-Based Access Control method), that is, data permission management is added on the basis of functional permissions to achieve centralized processing of data permissions and functional permissions. Explanation: Functional permissions: what can be done, such as adding sales orders; Data permissions: What can be done? For example, check the sales order of Michael Zhang of Haidian sales department of Beijing Branch; term: Resource: resources in the system are mainly various business objects, such as sales and payment orders. Operation types: possible access methods to resources, such as adding, deleting, and modifying resources. functions: operations on resources are two groups of resources and operation types, such as adding a sales order or modifying a sales order. Data Type: Common Data permission types in business systems, such as companies, departments, projects, and individuals; Data Objects: specific business objects, such as Company A and department B, including all object values related to data permissions; permissions: functions that a role can use, including the role's functional permissions and the role's data permissions; Roles: a set of specific permissions; users: subjects involved in system activities, such as persons and systems. General data permission management system design (2) method Description: in actual applications, data permission control points are generally relatively fixed, such as for companies, departments, individuals, customers, suppliers, etc, that is to say, the data permission is generally targeted at some data objects of the specified data type. In this method, the data permission depends on the function permission, which is a further description of the function permission, indicating the data control permission of the role on the specified function point. This method adopts the principle that "no explicit provisions are deemed to be valid". If no data permission is defined for a function, the role has all permissions for this function. If you define a certain type of data permission for the function, the user only has the data permission for the specified data of this type. This section is a detour. The following is an example. A company has three sales departments: Beijing sales department, Shanghai sales department, and Guangzhou sales department. Now we need to define several roles: Sales Director-to view all sales orders; beijing Sales Manager-only view all sales orders of Beijing sales department; Shanghai Sales Manager-only view all sales orders of Shanghai Sales Department; Guangzhou sales manager-only view all sales orders of Guangzhou sales department; the preceding roles are defined as follows: role name function data type data object Butler Sales Director Inspection of sales orders Beijing Sales Manager inspection of sales orders department Beijing Shanghai Sales Manager inspection of sales orders Department Shanghai Guangzhou sales manager inspection of sales orders department Guangzhou ----------------- ---------------------------------------------- In the above definition, the sales director only defines the function permission, but does not define the data permission, so the sales director can view all the sales orders; the other sales managers define the data permissions for this function, so they can only view the sales orders of the specified department. In practice, a department group is often used. The team lead can view the sales orders processed by all the personnel in the group, and in some cases, some people can only view their own sales orders, these special situations cannot be solved in the above descriptions and need to be addressed in the design and implementation. Beijing sales representative-only view all the sales orders of the Beijing sales department; Beijing sales representative view the design of the Beijing General Data permission management system of the sales order Department (3) -- Database Design: Let's first look at the traditional role-based permission management system, as shown in, the simplest role-based permission management consists of system functions, system roles, system users, role functions, and user roles. Figure 1: Role-based database structure to implement data permission control, role-based permission management is expanded in design, as shown in Figure 2: the two general data permission management system database designs are compared. We can see that the main changes between them are: 1. Increase system resource information and operation type information, system resources are in a tree structure, such as a sales module and a sales order. Operation types record possible operations, such as adding, deleting, modifying, viewing, and querying, system functions are a combination of resources and operation types, and operations on resources are system functions. 2. added two tables: Data Object Type and data object. The data object type records the object types to be controlled in the system, such as departments, warehouses, employees, customers, and suppliers; data Object records object instances of various object types, such as Beijing sales department, Shanghai sales department, Zhang San, and Li Si. (The benefits of independent storage will be discussed later) 3. Add an association table (many-to-many) between system resources and data object types. This table is a configuration table, indicating the possible control points required by a resource, for example, the association between a sales order and a department may involve assigning permissions to different departments, and the association between a sales order and a customer may involve assigning permissions to customers. 4. Add the association between data objects and role permissions. This table is the location where data permission management is implemented. This design can minimize changes to the original permission system and flexibly add data control points. It can be used in the design of productized software to flexibly meet customers' needs. The next article will discuss how this structure can meet the functional requirements of the second part. If time permits, the program design will be further elaborated. This design method has been applied to self-developed general supply chain management systems.Open-source supply chain [invoicing] System Description Directory