There are not many background management systems on the market for reference, and it is impossible to refer to the background of competing products. For students who are new to designing background management systems, designing the basic functions has become a difficult task.
After working on three background management systems, I gradually became familiar with the infrastructure and necessary functional modules, so I sorted them out and shared them with you. The background management mentioned in this article is only applicable to the management of mobile terminals (such as small programs/APPs), and is not suitable for large-scale saas platforms.
In the background management system (hereinafter collectively referred to as the background), the core module is the design of the authority module. I have summed up a set of general solutions for everyone to learn from and optimize.
First of all, we need to be clear about some nouns, definitions and models in order to better understand the permission system.
1. Definition, interpretation and permission model
- User: refers to the login user of the system, which can be understood as a series of operators, such as operation colleague Xiao Zhang, salesman Xiao Wang, etc.;
- Role: refers to the role played by the user in the system, which is the title given to the user by the system, such as general manager, operation, test, etc., which are more than linked to positions and responsibilities, and are used to configure various permissions for corresponding positions;
- Authority: the authorization qualification to be able to access an interface or perform an operation; Menu authority: refers to the page access authority corresponding to the first-level menu/second-level menu in the background, such as order management-group order list;
- Operation authority: refers to the authority to add, delete, modify, view, export and other operations on data in the background;
- Data permission: refers to the range of data that the role can view or operate. For example, if a salesperson enters customer information, each salesperson can only see the data created by himself, and cannot see the data of other sales. This is a common Data permission scope.
After introducing the definitions of nouns, the following explains the RBAC permission model.
RBAC permission model: RBAC, or Role-Based Access Control (Role-Based Access Control), is an excellent permission control model. It mainly establishes and manages roles and permissions, and then assigns users different roles to achieve the goal of permission control.
The direct advantage of using this model to configure permissions is that the number of roles is less than the number of users. First assign permissions to roles to complete the assignment of permissions; and then assign corresponding roles to users to directly obtain the permissions owned by the roles.
A boon for interaction design, simply define which menu permissions a limited role has.
2. Functional design
Enter the simple and easy-to-understand link of looking at prototypes and making functions. A slightly experienced product manager should know how the function is designed after seeing the interface. This chapter includes: account management, role authority management, menu management.
1. Account Management
In the system I designed, integrated organizational structure management.
Organizational structure management will not be discussed, it is to set the company's structure, which will affect the user's data permissions, because the user's data permissions are matched according to the tree of the organizational structure, which will be explained in detail later.
When creating a new account, set the account of the current employee and configure the corresponding role. Because we have designed the WeChat login and official account to push messages to internal personnel, we need to bind the user's WeChat account.
2. Menu management
Menu management is mainly used by front-end personnel to configure system menus, including menu levels, additions, deletions, and modifications. There is no need to explain too much here. If it involves designing this requirement, just put forward the corresponding requirement, and the front end will conduct research and development according to the specific situation.
3. Role Management
In role management, it includes the core of the entire authority module, menu authority and data authority.
Configuring menu permissions is to configure the user's page access permissions and operation permissions. It is better understood here that when designing requirements, it is necessary to describe the functions that need to be controlled by permissions according to the business.
I usually ask R&D to control the permissions of all the buttons that can be clicked on the page, so that the subsequent permission configuration will be more flexible.
Data permissions At present, the business scenarios I encounter need to include: only view personal data/view data of the person and the following personnel/view data of this department/view all data/custom data.
1) View personal data
As the name implies, you can only view the data you created. For example, in order to avoid vicious competition, employees Wang Wu and Xiao Liu each have different customers under their names, so when they inquire about customers in the background, they can only check the customers under their own names.
2) Check the person and the following data
For example, in the organizational structure, you are the team leader Zhang San (the lower left corner in the picture), and there are two younger brothers A and B below. Then the configuration is complete (you need to be configured as the person in charge in the organizational structure), you can see your data plus your younger brother's data.
3) Check the data of this department
You continue to be Zhang San. If you configure to view the data of your own department, you can view the data of the group at the same level as you. For example, you can view all the data of Group 1 and Group 2.
4) View all data
Generally, it is the authority of the general manager's office. Of course, the boss can view everyone's data.
5) Custom data
You can configure a role to view the data of a specific person. This business scenario is quite special and may not be very general. For example, a sales assistant can view the data of some sales personnel and conduct work inspections.
3. Other permissions
This refers to some special permissions included in the business, such as the visibility of fields. If you want to control the granularity of permissions down to fields, you need to extract the fields of each function page and configure them individually for roles. Another example is the visibility of some sensitive data.
For example: a user's mobile phone number is visible to some roles and encrypted to some roles. This part should be designed separately in the operating authority and listed separately.
Four. Conclusion
The good saas systems on the market have a relatively complete permission system. For details, you can refer to Fanxiang Salesforce, salesforce, etc. Although I don’t understand salesforce, you can study it if you are interested.