Due to the diverse needs of different background management systems, the ones shared here are general-purpose, which are sufficient for most background management system logic, and are mainly used in WEB applications, such as: website management background, CMS, CRM, OA, etc. wait.
Of course, you can also further design him to make a stronger system.
Issues related to permissions are often complex issues. In terms of system permission control, we often refer to existing cases to design our own permission control. The following are the four most common permission control methods I have summarized . (Attach the high-fidelity prototype link + overall structure diagram: see the bottom)
1. Account and login of the control system
1. To log in, you must first have an account, and the definition of an account
Basically all Internet products, whether they are mobile, PC, C-end or B-end products, require an account to log in. Only for C-end products, users can register by themselves.
For background products, it is necessary for internal personnel of the company to create an account. And this account is a key. We control the scope of operations of this employee by controlling the permissions of the account.
2. Two levels of accounts: enterprise (administrator) account and ordinary account
The actual operator of the company should have the most core and most authorized enterprise account, so it can also be called the "administrator account", and the others are ordinary accounts.
The core business steps in the actual system are as follows:
- When an enterprise purchases a system, it creates an enterprise account, and the mobile phone number bound to this enterprise account is the mobile phone number of the actual operator of the company. The mobile phone number can be unbound and modified if necessary (for example, the company operator is changed), but the enterprise account cannot be deleted or resigned.
- During the deployment training phase, the enterprise account holder can be instructed to create one or more ordinary accounts (but the administrator role is authorized to the account), which is generally authorized to the administrative director or human resources director, and the subsequent configuration is performed by the administrator account .
Note the difference between the two:
- Account disabled: If you enter the wrong password multiple times when logging in to the system, the system will temporarily disable it due to account security issues. Or if the account is stolen or other scenarios are involved, you need to disable it immediately, change the password and other operations.
- Account deactivation: The employee resigns, but all the operation record information still exists when he is on the job, so it is set to deactivate. (ps: You can get through with the personnel system. After an employee resigns, all system accounts will be automatically disabled.)
Add status control to user status, available users can log in to the system, and disabled or disabled users cannot log in.
2. Role management
Roles are often pre-set fixed labels in the system based on business management requirements. Each role corresponds to a clear system authority. It is a collection concept and is composed of many minimum authority particles. We realize the permissions of the account by giving the permission to the role and then giving the role to the account, so it acts as a bridge. Introducing the concept of roles can help us expand flexibly so that an account can have multiple roles.
The system permissions it owns generally do not change at will, and roles do not change as users are added and removed, which is more stable than user management.
As the company expands, the number of roles increases, which is difficult to manage. For example, for the role of hr, if the group has branches, it can be classified, such as: Shanghai Branch: HR Director; Beijing Branch: HR Director.
The data permissions granted by this role will be different. For small and medium-sized companies, it is more convenient to manage the roles in a fine-grained manner.
3. Control function permissions
Functional authority definition: It is the scope of functions that can be seen and operated. For example: a certain part of the menu, or various operations in a certain page.
1. Menu management module
There are 3 types: directory, menu, and button.
- Add authority control to directories and menus, those who have authority can access the corresponding modules, and those who do not have the authority cannot even see the menu name.
- Add permission control to the function buttons of the business module to control user behavior at the smallest granularity. For example, if the proprietress has the permission to enter the product, she can see the button for product entry, and click the button to enter the product; otherwise, there is no such permission. The clerk cannot carry out the operation of product entry.
2. Control function rights management
The underlying menu management configuration is generally configured by developers early on, and now users are assigned to use these functional permissions.
Functional rights: Based on roles, by dividing different functional rights of different roles and adding employees to corresponding roles, the division and isolation of employee functional rights can be realized, including:
- Object-level functions : For example, whether the entrance of the function is visible. For example, if the role is "Blue Whale Watcher" and the "View List" permission point of the object "Personnel Management" is canceled, employees under this role will not be able to see the function entrance of personnel management.
- Operation point permissions : such as business operations such as creating and editing;
- Field permissions : Add permission control when displaying information to ensure the security of sensitive information. Object fields can be configured for roles as read-write, read-only, or invisible. For example: configure the [Sales Order Amount] field of the sales order for the role "service personnel" to be invisible.
Control the visibility and editability of the fields for employees. For example, if you don’t want telemarketers to see the customer’s phone number, and you don’t want service personnel to see the sales order amount in the customer’s sales order, you can hide the corresponding fields.
- [Read and write] permissions: Employees will have the maximum permissions for this field, and can edit it when [New] and [Edit], and this field can be seen on the list and detail pages.
- [Read-only] permission: Employees cannot edit when they are in [New] [Edit], and this field can be seen on the list and detail pages.
- [Invisible] Permission: The field (or the value of this field) is not visible to employees in the interface of [New], [Edit], [List], [Details].
The impact of function permissions on the front-end interface:
- If an employee does not have the permission to "view list" for an object, the function entry of the object will be hidden.
- If the employee does not have the operation point permission for an object, the corresponding operation button is hidden on the object page.
- If an employee does not have visibility permission for a given field of an object, the corresponding field is hidden on the object page.
3. Control field permission user interface
Control field permissions need to be supported by a page configuration page, and this interface is controlled by the developer.
Click on a page to configure, you can add, or quickly generate fields belonging to this page from the database. Which fields are selected from the fields on this page are provided for users to set field permissions, so there is the above picture. As well as the display name of the field, whether the field is required is to control the interface provided to the user to set the field permission.
4. Control data permissions
Definition of data authority: Data authority management mainly controls whether a certain data record is visible to users. Combined with functional authority, it can more flexibly configure the functional operation authority and data visibility range of each employee in the business process, so as to fully guarantee the security of enterprise data.
Similar to the matrix list, functional permissions determine which columns are visible to the user, such as name, phone number, email and other fields visible in the customer object. Data permissions determine which pieces of data the user can see, for example: "Mr. Wang", "Mr. Li", etc.
Data permissions are divided into two levels to control data:
- Basic data permissions: It is decided according to the person in charge of the data.
- Data sharing: According to the data records in the basic data permissions, share them with other users to view or edit them.
Basic data permissions:
- Private: All data in the object follows that relevant team members (including the person in charge) and their superiors are visible to the data, and have the same permissions [read-only, editable] on this data, and the department heads of the superior department can see the subordinate departments all data for .
- Public read-only: All data in the object is public to the entire company, and the person in charge of a single piece of data and his superiors, as well as members of the relevant team with editing permissions, can edit the data.
- Public reading and writing: All data in the object is open to the entire company and can be edited by all employees.
Remarks: The "superior" here refers to the user's reporting object, which can be edited in the user management interface.
At the beginning of the system initialization, the default setting is good (the default setting should be based on the actual operation of the customer company), and the user can change the default setting according to the company's development, or restore the default setting, because the default setting covers 90% of the customer company scene.
Data permission sharing:
The data sharing rule is to share all the data responsible for a certain object (such as a customer) of a certain department/employee (data source) to a certain department, person or user group (sharing scope). After the data sharing rules are configured, the shared party can see all the data that the sharing party is responsible for, and has the operation rights corresponding to the sharing rights.
Business configuration description:
- Data source: the data that needs to be shared. Selecting an employee refers to the recorded data that the employee is responsible for, and selecting a department refers to the recorded data that the employee under the department is responsible for.
- Shared data: Select the object to be shared, for example: share the customer data that employee A is responsible for with employee B.
- Data sharing to: To be shared, employees, departments or user groups can be selected, and the selected employees, departments or user group members will be able to see the shared data.
- Permissions after sharing: configure the permissions of the shared party to view or edit the data. If it is configured as "read and write" permissions, the permissions of the shared party to the shared data can be compared to the permissions of the person in charge.
Example of a business scenario : A sales department wants Zhang San of the finance department to see all the sales order data of the department and allow Zhang San to edit it.
(1) Sharing rule configuration
- [Data source] is "sales one";
- [Shared data] is "sales order"
- [Sharing range] is "Zhang San";
- 【Share permission】is "read and write".
(2) After the configuration is complete
After the configuration is complete, Zhang San can see the sales order in charge of all the employees in the sales department under the [Sales Order] object and [Shared to me] scene.
Summarize
The background authority management system is not as complex as possible. Only the authority system that meets the actual needs of customers and has the greatest flexibility, and effectively controls the development cost is a reasonable design.