[Product Design] RBAC Authority Design

Rights management is a common topic in the B-side. It stipulates the respective roles and functions of users, and also provides protection for data security.

Authority management is an unavoidable topic for B-end products. This article summarizes my design experience and design methods for authority management, and is divided into 4 parts:

1. Conceptualization of rights management
2. General steps of RBAC permission design
3. Three axes for designing function permissions: basic version (permissions, roles, user management), advanced version (department, position, menu management), expansion (version management)
4. How to Design Data Permissions

All content is based on my own thinking, practice and experience. If there are any mistakes, please correct me.

Chapter 1: Conceptualization of Rights Management

1. What is the authority

Permissions include functional permissions and data permissions:

Functional authority is the basic unit of system execution authority control, including page authority, menu authority, button authority, etc.
Data authority includes basic data, business data, resource data, etc.

Dividing user authority for functional modules is a coarse-grained division method. Different users can view the same data, but they can perform different operations. For example, the data in the online database can only be deleted by super management, and others can only view it; dividing user permissions for data is a fine-grained division method. When different users enter the same page/menu, the visible data is different. For example, the operation manager can see all the data of the department, and the operation personnel can only see the data created by themselves. When designing permissions, you must first distinguish the boundaries between functional permissions and data permissions, and don't combine the two for convenience.

2. Why do we need permission management

• job responsibilities
• data security needs

3. The core idea of ​​permission design

Rights management is a system used to control users to access and only access certain resources. According to this definition, we can draw the following diagram: It can be seen

that users and resources form an intricate mapping relationship, which is difficult to manage. To solve this problem, there are two methods: one is to reduce the number of users/resources, which is obviously impractical, so there is only one method left - reducing the mapping relationship.

Before introducing this method in detail, let's take a look at how to solve the problem of slow query in the database. You can think about a question, how to quickly find the number 55 in the sequence [35, 27, 48, 12, 29, 38, 55]?

Most people's first reaction is to traverse one by one, so a total of 7 queries are required. For database engineers, they will first find a medium to construct the representation relationship of this set of arrays (see the figure below - balanced binary tree), and then find 55 in only 3 times through simple judgment. This medium is the index in the database. When the amount of data is huge, the advantage of using the index to query is very obvious.

If this example is difficult to understand, you can also think of the index in the dictionary, the catalog in the book, or the shelf label in the library. The core idea is to abstract the public attributes of the object and then perform classification management.

Using this idea, let's look back at how to reduce the mapping relationship between users and resources.

1. Determine whether there are common attributes between users?
2. Find public attributes that affect permissions, such as departments, positions, etc.
3. Continuously abstract out the intermediary

The same is true for resources.

After the above steps, the originally chaotic mapping relationship becomes simple and layered (see the figure below). We only need to assign permissions to the abstracted virtual media, which can greatly reduce the complexity of management.

4. Evolution of authority management model

After understanding the core idea of ​​permission design, we take the update of CMS system as an example to illustrate the evolution of the permission management model.

1. ACL: user-based authority management model

Xiao Wang is a product manager of a start-up company, responsible for the design of a CMS system. At first, all the content of the website was in charge of the company's only operator, Xiaohong, so Xiaowang enabled all permissions to Xiaohong's account.

This method of directly binding permissions to user accounts is called user-based authority management (ACL).

2. RBAC: role-based authority management model

With the continuous development and growth of the operation department, every time a new employee joins the job, Xiao Wang has to configure permissions for them individually, and it cannot be modified in batches, which is very cumbersome. At the same time, Xiao Wang found that the operation department has a clear division of labor. Some personnel are responsible for content review, and they need to open the audit management authority for them; repetitive work. So Xiao Wang wanted to abstract another layer on the existing user layer—the role layer. As long as the permissions are set for the role, the personnel belonging to the role will automatically have these permissions.

This method of binding permissions to roles and assigning roles to user accounts is called role-based authority management (RBAC). This model was developed by the National Institute of Standards and Technology in 1992 and is currently the most common. The authority management model saves a lot of authority maintenance costs.

Ravi Sandhu, a professor at George Mason University, improved the RBAC model in 1996 and proposed the RBAC96 model family, including four models: RBAC0, RBAC1, RBAC2 and RBAC3. The figure above represents the RBAC0 model, which is also the basis for the other 3 models.

a. RBAC1: RBAC model of role inheritance

After using the CMS system for a period of time, Xiao Wang discovered a new problem - there are too many roles in the system, because as long as a user with different permissions joins the system, a new role needs to be created. When it is detailed, it is even more cumbersome than ACL, so Xiao Wang wants to solve this problem.

Click him to find that there is a superior-subordinate relationship between roles similar to the organizational structure, such as COO > Operations Manager > Operations Supervisor > Operations Team Leader > Operations Personnel > Operations Interns, and the superior has all the permissions of the subordinate, and can additionally have other Permissions, so he abstracted another layer of role levels based on the existing roles.

This RBAC model that introduces subordinate-subordinate relationships into roles is called the RBAC model of role inheritance (RBAC1). By grading roles, high-level roles can inherit the permissions of low-level roles, which simplifies permission management to a certain extent.

In addition, the inheritance relationship between roles can be divided into general inheritance relationship and restricted inheritance relationship. The general inheritance relationship requires that the role inheritance relationship is an absolute partial order relationship, allowing multi-directional inheritance between roles, that is, a lower-level role can have multiple upper-level roles, and a higher-level role can also have multiple lower-level roles. The restricted inheritance relationship requires that the role inheritance relationship is a tree structure, and roles can only be inherited in one direction, that is, a subordinate role can only have one superior role, but a superior role can have multiple subordinate roles.

b. RBAC2: Role-restricted RBAC model

After a period of time, Xiaohong, the operation manager, reported to Xiaowang that her account could actually see the company's financial bills. After verification, it was Xiaowang's carelessness that tied an extra role of financial manager to Xiaohong's account. In order to completely avoid this risk, Xiao Wang asked the developer to add a judgment: when the role is an operation manager, it cannot be a financial manager at the same time.

This role-based restriction model is called the role-restricted RBAC model (RBAC2), which can be specifically divided into static duty separation (SSD) and dynamic duty separation (DSD):

SSD：

• Mutually exclusive roles: the same user can only be assigned to at most one role in a set of mutually exclusive roles, for example, a user cannot have two roles of accounting and auditing at the same time
• Cardinality constraints: the number of roles that a user can have is limited; the number of users that can be assigned to a role is limited; the number of permissions corresponding to a role is limited
• Prerequisite role: If the user wants to become an upper-level role, he must first become a lower-level role, such as a job change in the game

DSD: Allows a user to have multiple roles, but only some of them can be activated at runtime, such as BOSS direct recruitment, a user can be both a recruiter and an applicant, but can only choose one identity to operate at the same time

c. RBAC3: Unified RBAC model

RBAC3=RBAC1+RBAC2, which not only introduces the inheritance relationship between roles, but also introduces the role restriction relationship.

d. Group: Perfect RBAC model

Although the existing authority management model has optimized the "role" level, it has not optimized the "user" side, which means that every time a new employee is recruited, Xiao Wang has to set the authority for him separately, which is still very troublesome, so He uses abstract ideas to classify users with the same attributes. In a company, the simplest common attribute is "department". If roles and permissions are assigned to a department, then all users in this department will have department permissions, and there is no need to specify a role for each user separately.

Users can be grouped, and permissions can also be grouped. In the case of a particularly large number of permissions, permissions at the same level can be combined into one permission group. For example, there are more than a dozen buttons under the second-level menu. If there is no role restriction on button operations, these button permissions can be combined with the second-level menu permissions. Merge into a permission group, and then assign the permission group to a role.

The introduction of the concept of "group" improves the RBAC model, which is closer to the actual business and easier to understand while simplifying operations.

3. ABAC: Attribute-Based Authority Management Model

For the safety of the content, Xiaohong, the operation manager, raised a requirement with Xiaowang: the personnel in charge of content management are not allowed to publish content outside the company. This stumped Xiao Wang, because the existing RBAC permission model can only grant permissions to pages/functions/data, and cannot implement such fine-grained permission control. After consulting relevant information, Xiao Wang found a solution to this problem - the attribute-based authority management model (ABAC).

ABAC makes authorization judgments by dynamically calculating whether one or a group of attributes meet certain conditions, including user attributes (such as gender and age), environmental attributes (such as time and place), operational attributes (such as editing and deletion) and object attributes (such as a Article).

Compared with RBAC, ABAC can achieve very flexible permission control, and its scalability is also high, which can meet almost all types of needs. However, it is more complicated to design, and it can be replaced by writing simple judgment logic for a single attribute, so it has not been widely used.

5. Authority management and authority system

Rights management refers to the method adopted to solve a specific rights distribution problem. For example, the ACL model can be used to solve the problem of file rights distribution, and RBAC+ABAC can be used to solve the problem that users of different age groups can access different types of movies.

The authority system refers to the collection of authority management methods used in the entire system.

Six, the misunderstanding of authority design

1. Only RBAC theory

Although RBAC has been widely used, it is still necessary to avoid doing it at the beginning. The design of permissions needs to evaluate the data volume and business complexity. If the estimated data volume is very small and the business is very simple, then other methods can be used.

2. Only free allocation theory

Don't think that you are satisfied with setting permissions that are flexible and assignable to users. In fact, users are not that smart. They will struggle with role names and be at a loss when they see a series of permission configurations. If your business can abstract some fixed roles and unified permissions, then build them in.

3. The more permissions / the finer the better

Permissions are not a list of functions. Blindly refining them without paying attention to actual business will only increase the workload of development and is not conducive to user configuration. You can select only commonly used function points as the permission configuration, or abstract multiple function points into one permission point, such as abstracting the three functions of "addition, deletion and modification" into one "management" permission point.

Chapter 2: General steps of RBAC permission design

1. Sort out the roles

1. List all characters

A role is an abstract identity, and RBAC is inseparable from roles, so the first step is to find all possible roles involved in the business.

If you are working on an enterprise internal management system (such as ERP, OA), you can refer to the organizational structure to find all roles (such as product manager, product assistant, project leader); other systems can find related roles through business processes, such as launching a line According to the process of taking the written test, you need a question teacher, question review teacher, test room administrator, assistant, test invigilator, patrol teacher, examinee, and paper marking teacher.

2. Find the relationship between the characters

找到所有角色后，第二步就是找出各角色之间的联系。常见的有继承、互斥和共享关系，还可根据实际业务找到角色之间的其他关系：

• 等级/继承：产品总监、产品经理、产品助理、产品实习生
• 互斥：财务和审计不能是一个人
• 共享：阅卷老师和监考老师可以是同一个人
• 串行：先由产品经理进行设计再由开发人员开发
• 并行：前端后端一起开发
• ……

3. 分析角色是否需要内置以及是否需要隐藏

分析哪些角色我们可以事先定好，哪些角色可由用户自定义。内置角色适用于角色通用且固定、使用频率高的情况，目的是为了简化用户的操作步骤。常把“管理员”角色进行内置，也可根据实际业务选择，比如线上考试系统，“考生管理”菜单就属于内置角色，添加到该列表中的账号只能是“考生”。

同样还要考虑角色是否需要展示给用户，比如一些系统的“超级管理员”就不需要展示给用户。

二、梳理权限

1. 梳理功能权限

权限分为功能权限和数据权限，其中功能权限又可分为菜单权限和按钮权限。

梳理功能权限一个最简单最实用的办法就是用“功能列表”（下图以“有赞”为例）。

2. 梳理数据权限

数据权限就是系统中存在的数据、资源能够被谁查看和管理。说到数据权限，就不能不提数据库。

1）表/对象

表是包含数据库中所有数据的数据库对象，不同的业务数据存在于不同的表中，如下图从上到下依次为考生表、考场表和考官表。

2）数据

表中存放着二维数据，由行和列组成，如下图的考生表，每一行代表一个考生，每一列代表考生的一个属性。

通过表和数据之间的关系，可以把数据权限分为以下四种情况：

（1）基于系统的数据权限

即系统中的所有表都能被大家看到并管理，也可理解为没有数据权限，比如管理员A、B都能看到并管理所有考生、考官、考场数据。

（2）基于对象的数据权限

即按表划分数据权限，比如管理员A只负责管理考生，管理员B只负责管理考场。

（3）基于行的数据权限

That is, the data permissions are divided according to the data rows in the table. For example, administrator A can only manage candidates from school B, but cannot manage candidates from school C; or the manager of department A can only see the weekly report of the staff of department A.

(4) Column-based data permissions

That is, the data permissions are divided according to the data columns in the table. For example, administrator A can only see the candidate's name, while administrator B can see the candidate's name, mobile phone number, and ID number.

When sorting out data permissions, you can freely combine the data permissions of objects, rows, and columns according to the actual business. For example, the administrator of school A can only view the names and phone numbers of candidates and examiners of school A, but cannot view the ID number. If required, row and column-based data permissions are used.

3. Connection roles and permissions

1. Connection roles and functional permissions

After obtaining the function list, it needs to be associated with the role. You can directly add the role column after the table, and then judge whether the role has the function permission according to the business.

2. Connection roles and data permissions

Data permissions are generally a series of rules, which can be attached to the above table through text descriptions.

3. Analysis and arrangement

All permissions need to be assigned, but not every permission is worth configuring by the user.

After the previous step is completed, we have established the relationship between all roles and permissions, but the above table cannot be used directly. Before the detailed design, we need to analyze which permissions need to be manually assigned by the user and which ones do not? Which functional permissions can be combined to reduce the number of user actions? In what scenarios do data permissions need to be configurable? And so on, these must be judged according to the specific business.

Still taking "Youzan" as an example, the above picture is the actual page for configuring the "lead management" function permissions. You can see that it only provides users with "view, edit, transfer, abandon, add data items, and audition" for users. function, and other function permissions are either attributed to "view" (adding, registering, etc.), or merged into one function ("batch transfer" is merged into "transfer").

In theory, all functional permissions can be taken out for users to configure, but considering the user experience, it is very necessary to analyze and organize permissions.

Chapter 3: Three tricks for designing functional permissions

Through the above analysis, we get the final relationship between roles and permissions, and then enter the link of how to design the interface.

The design of functional permissions is inseparable from the most basic three elements: user management, role management, and authority management; depending on the business, it may also involve more complex three elements: department management, position management, and menu management. Different versions will be configured to meet different customer needs, which requires version management. The following will introduce in detail how to design these management functions.

1. Triple Ax - Basic Edition

1. Rights Management

Permission management is to grant permissions to roles. Permissions can be built-in or user-defined. The configuration of permissions needs to be tied to roles. When the permissions are relatively simple and relatively fixed, the back-end personnel can write them in the code or in the code. configuration file.

2. Role Management

In the step of "sorting out roles", we list all the roles involved in the system, and "role management" is to mirror and manage these roles online.

According to the source of roles, they can be divided into user-defined roles and system built-in roles:

Custom roles: The names and permissions of roles can be freely configured by users and can be modified arbitrarily.

Built-in role: The name and authority of the role are built-in by the system, and the user can only view it and cannot modify it.

Design "Role Management" mainly has three pages:

• Role list page: display all roles in the system, at least display the role name and operations such as query, delete (custom role), view (built-in role), add, edit, etc.
  
• Add role page: You must enter a non-repeatable role name, and you can fill in status, notes, sorting and other information. In terms of interaction mode, you can choose the form of pop-up window or drawer according to the richness of the page content.
  
• Configure permissions page: You can configure permissions while creating a role (see the figure above), or configure permissions after creating a role (see the figure below). There is no essential difference between the two methods.
  
  In addition, in some systems, the carrier of binding permissions is not called "role", but other names, such as "management group" in DingTalk. Here we must be clear that it is actually a "role".

3. User Management

"User Management" is used to manage user information, such as changing user roles, creating or deleting users, changing passwords and user information.

Design "User Management" mainly has two pages:

• User list page: display all users in the system. It should support adding, editing, deleting, exporting, importing and batch operations.
  
  • Add user page: select the fields required for creation according to the business. When adding a user, a role must be set for the user, and optional roles include custom roles and built-in roles that exist in the "role list".

Like "Privilege Assignment", "Role Assignment" can also be placed separately in the operation of the user list. This kind of interaction is more specific, but there is actually no difference.

4. Precautions

1) Users and roles

It is necessary to determine how many roles a user can be bound to based on the actual business. If multiple roles can be bound, whether there is any relationship between roles such as inheritance and mutual exclusion, and how to divide functional permissions, these situations must be considered in advance.

In addition, if there are built-in roles, don't forget to design management functions specifically for "built-in roles" on the internal "operation management platform".

2) The relationship between characters

Above we listed the relationship between roles (hierarchy/inheritance, mutual exclusion, sharing, etc.), the existing "role management" can only achieve "role sharing" by binding multiple roles with one user, but there is no There is no way to implement inheritance and mutual exclusion between roles.

If there is an inheritance relationship between roles, it can be realized through the "role group (position) management" below; if there is a mutually exclusive relationship (such as accounting and auditing), the built-in role can be hard-coded in the code, and for the custom role, you can Let the user additionally set the mutex rules.

3) Permission group

The analysis and sorting mentioned above are actually the establishment of permission groups to merge unnecessary permissions, which can simplify user operations.

After the above steps, a basic permission system is designed, which is enough to deal with 80% of the scenarios.

2. Three axes - advanced version

If you are doing the rights management of the OA system, or have high requirements for flexibility, then you can learn about the advanced version of the rights management three tricks.

1. Department management

"Department Management" has three usage scenarios.

The first is to build the organizational structure of the enterprise. In this case, department management has nothing to do with functional permissions, and is only used to classify users and assign data permissions.

The following two scenarios are related to functional permissions:

The second scenario is to assume the role of "user group". In the RBAC introduced above, if there are a lot of users, it will be very troublesome to match each user with role permissions. At this time, it is necessary to abstract the common attributes of users. In an enterprise, the common attributes of users can be represented by departments .

The third scenario is to assume the role of a "role". You can directly assign functional permissions to the department, and users in the department inherit the functional permissions of the department. If the user also has permissions of other roles (user 2 in the figure below), the actual functional permissions are the union of the two.

In addition, when assigning department permissions, you also need to consider the permission relationship between the sub-department and the parent department: you can choose to keep the permissions of the parent department consistent, or you can choose the sub-department to inherit the permissions of the parent department and edit within its scope. Permissions can be set completely different from those of the parent department, depending on the complexity of the business.

2. Job Management

There are two usage scenarios for Job Management. The first is to improve employee information, which is an attribute and has nothing to do with functional permissions.

The second scenario is related to functional permissions and is to assume the role of a "role group". "Role group" is a concept derived to satisfy the relationship between superiors and subordinates. For example, a "product manager" should have all the permissions of a "product assistant". It sets all the functional permissions, just parent it to the "Product Manager" role, and add some special permissions.

3. Menu management

Whether it is "department" or "position", it is to solve the problem of how to configure "users" and "roles" more flexibly. There is also a "permission" in RBAC. The current management of permissions only introduces that the back-end personnel can write them in the code or in the configuration file. If the function permissions change frequently and the demand for free configuration is extremely high, Is there a more flexible way to manage permissions? have! It is "menu management".

"Menu management" is also called resource management, which is an external manifestation of system resources. With "menu management", it can not only make the management of permissions easier (no need to hard-code the backend), but also make the system display more flexible (menu information can be changed).

The Menu is divided into three categories:

1. Directories: no actual pages in the system
2. Menu: actual page exists
3. Buttons: actionable items in the menu
   
   
   
   Designing the "Menu Manager" has two main pages:

1) Menu list page:

The navigation menu is divided into upper and lower levels, so it can be represented by a tree diagram. Common menu attributes include menu name, menu type (directory, menu, button), icon, sorting, routing address (address for browser access menu), component Path (the path of the component file of the project), permission identification (view, edit, add, etc.), whether it is an external link, enabled status, and creation time. In addition to the fields shown in the figure, fields such as "number, whether to open a new page, whether to hide, whether to cache (the current menu will be cached when switched to other menus)" can be added according to business needs.

2) Add menu page:

Add directory: The directory can be an external link, that is, click to jump to the external address, and https:// or http:// must be included. If it is not an external link, you need to fill in the routing address, which is given by the developer.

Add menu: When the menu is an external link, the rules are the same as the directory. If it is not an external link, you can choose to fill in the component name, permission identifier, and component path (the details should be discussed with the development system to see if it is involved).

Add button: When adding a button, just enter the permission ID.

4. Precautions

1) Who inherits whom

Regarding "authority inheritance", careful readers will find that when I introduced RBAC in the first chapter, I wrote: "High-level roles can inherit the permissions of low-level roles", and in this chapter I also said: "Sub-departments can inherit parent departments. Permissions", is there a conflict.

In fact, it is not true. Assuming that there are two departments, AB, and a department C is to be established on top of them, then the authority of department C is the union of the two departments of AB. From this perspective, department C inherits the authority of department AB, and Department C can also set permissions separately; and if a department C is to be assigned to department A, department C will inherit the permissions of department A and can refine the permissions within this range. The meaning of the two expressions is the same, and both the child level belongs to the authority of the parent level.

2) Functional permissions are best not tied to multiple entities

In the above introduction, "departments" and "positions" can act as "role groups" to directly bind functional permissions, but in practice, few systems are designed this way. The fundamental reason is that it is unnecessary - functional permissions are the best It is only tied to one entity, which means that if the system already has "role management" (setting functional permissions for roles), there is no need to set functional permissions for departments or positions. Once the authority is set for the position, there is no need to introduce the concept of "role". Because in real work, few people have separate functional permissions for departments, positions, and roles. Even if they do, the complexity can be simplified by creating a new "role". In most OA systems today, positions and departments are more used for user classification and management of data permissions.

3) How does menu management implement permission groups

It should be noted that "menu management" is the smallest operation in the system, which can be directly used to assign role permissions, but if in order to improve user experience, it is necessary to show users the combined functional permissions (see the figure below) , you cannot directly set the button of "view and operation" in the "menu management", but should build a layer of functional permissions on top of the "menu management" to display to the user, in which the "view and operation" permissions are bound "New+Edit+Delete" button.

5. Expansion: version management

For SAAS software, it is often divided into multiple versions to meet different levels of customer needs, and the functional permissions between different versions will be different. Faced with this situation, flexible management can be achieved through "version management" (this "version" is not a product iteration version).

Design "Version Management" mainly has two pages:

• Version list page: The list displays version information.
  
  Version function permission configuration page: similar to assigning permissions to roles, here it can be understood as assigning permissions to versions. The difference is that the functional permissions here are more detailed than those in "Menu Management". Take "topic management" as an example. Generally, in "menu management", only the "add, import, delete, edit topic" buttons on the first-level page will be set, but in version management, it will be refined to the type of topic, such as free The version cannot add "listening questions", and even limits the number of times the function can be used. There are two design solutions to solve this requirement. If the permissions between each version are divided into fine details and many (see the first picture in this section, the version function comparison of the test star), then it is best to cover it in the menu management Buttons on all sub-pages can be used, and the number of available times is limited by a separate rule; if there are only individual minor functional differences between versions, it is sufficient to add a restriction rule based on the existing "menu management" function.
  
  In a more complicated situation, different clients of the same version also have different functional permissions, so it is also necessary to configure functional restrictions for each client.
  

Chapter 4: How to Design Data Permissions

As mentioned above, data permissions are divided into four situations (see Chapter 2 for the basis of division):

1. System-Based Data Permissions
2. Object-Based Data Permissions
3. Row-Based Data Permissions
4. Column-based data permissions

Among them, "system-based data permissions" can be understood as regardless of data permissions, because what everyone sees and can operate is the same; "object-based data permissions" can be realized through functional permissions, such as assigning user A If the authority of the customer table is granted, then A can see and operate all customers, which is equivalent to assigning the functional authority of "customer management" to user A. Therefore, the latter two cases are mainly discussed below.

In addition, the allocation of data permissions can also be divided into two types: built-in and user-defined. Built-in data permissions belong to hard-coded rules in the system. For example, teachers in this school can only see resources in their own school, resources in the public library can be seen by teachers in all schools, and leads created by salespersons can only be managed by themselves, etc. Built-in data Permissions are too simple and beyond the scope of this article.

1. Row-based data permissions

There are two types of row-based data permissions. One is to assign data to objects (departments/roles), such as upper-level departments can manage all data of lower-level departments; data can also be assigned to objects, such as shared files.

1. Assign data to the object

1) No organizational structure

For systems that do not involve organizational structure, the design of data permissions is relatively simple. When configuring permissions for roles, it is sufficient to display the assignable data permissions.

The premise of assigning data permissions is to assign corresponding functional permissions. For example, to allow computer teachers to only manage all topics of "Software Engineering", the premise is to enable the functional permission of "Exam Bank Management" for the teacher, otherwise the teacher will not even have "Exam Bank Management" I can't see it, how can I manage the topic data in it. Of course, function permissions do not have to be assigned manually, and can also be built-in. For example, in Blue Lake, the added members open the "team file" menu by default, so only the data permission list needs to be displayed during configuration.

2) Organized structure

Data authority control between the upper and lower levels can be realized by setting the "management scope". For example, for the requirement that the superior can see the question bank of the subordinate, you can set a "department leader" role, and set the management scope as "the department and the subordinate department", and then add the company leader and the heads of each department to this role , this requirement can be fulfilled.

You can also implement cross-departmental data access control by setting the "management scope". For example, if the person in charge of the R&D department can see the topics of the IT department, you can create a new role, select "specific department" for the management scope, and check "R&D department and IT department".

You can also implement data authority control between the same department by setting the "management scope". For example, in the product department, the product team leader can see the topics created by his subordinates, but not the topics created by the product director, and the product assistant can only see the topics created by himself. In this case, the hierarchical relationship of positions needs to be used.

2. Assign objects to the data

It can be understood as directly sharing data to a certain role/department, which is often used for file/resource sharing. The following figure shows the permission management of files on DingTalk.

2. Column-based data permissions

If data permissions are the vertical extension of functional permissions, then field permissions are horizontal extensions. Because setting data column permissions can prohibit specified roles from accessing certain sensitive fields, such as ID number, transaction amount, etc.

There are two main pages to design "Column Permissions":

• Entrance: It can be set together when creating the role, or it can be used as an operation of the role alone. It can also be set in batches for all roles in "Role Management", and can be set in the corresponding menu page.
• Column permission setting page: The figure below shows the design of setting column permissions in batches for all roles, listing the roles with various functional permissions and the fields in this menu, which can be checked by the user.