In the architecture of the B-end system, user management and role management modules are the core components to ensure the safe operation of the system and improve management efficiency. These two modules are like the “access control system” and the “permission distribution center” of the system, which are both independent and closely related. This article will comprehensively dismantle the practical experience of these two modules from the basic cognition of the module, practical details, design ideas to problem solving and pit avoidance guides.
1. Basic introduction to the module
1. Module function
User management module: Focuses on the whole life cycle control of system users, including user information entry, query, editing, deletion, and user status (enabled/disabled) management. At the same time, user login logs (login time, IP address) and operation logs (operation content and time) are recorded to provide a basis for behavior traceability.
Role management module: Responsible for defining roles and assigning permissions, including creating, modifying, and deleting roles, and configuring functional permissions (such as “Modify Data” and “Approval Process”) and data permissions (such as “View Department Data” and “Only My Data”) to achieve batch management of permissions.
2. Functional value
User management: Through accurate user information control and status management, prevent illegal login and ensure the security of the system entrance; User logs provide key credentials for troubleshooting and responsibility determination.
How can product managers do a good job in B-end digitalization?
All walks of life have taken advantage of the ride-hail of digital transformation and achieved the rapid development of the industry. Since B-end products are products that provide services for enterprises, how should enterprises ride the digital ride?
View details >
Role management: Solve the problem of “one-size-fits-all permissions” and allocate permissions according to job requirements to ensure smooth business development and avoid sensitive information leakage, realizing the “principle of least permission”.
3. Module Connection
The two are linked through a three-tier architecture of “user-role-permission”: users obtain permissions through associated roles, one user can associate multiple roles (permission superposition), and one role can associate multiple users (batch authorization). This design greatly reduces the complexity of permission management and allows for more flexibility in permission adjustments.
2. Detailed analysis of actual combat
1. Function description
1) User management module
- Information maintenance: Support entering basic information such as name, work number, department, authority department, etc., and provide multi-condition query and batch editing functions.
- State control: Quickly switch user status with the “Enable/Disable” button, and immediately block login permissions after disabling.
- Role associations: Supports checking multiple roles for users and synchronizing permissions in real time after association (need to refresh the cache).
- Log tracking: Visually displays user login records and operation tracks, and supports filtering by time and operation type.
2) Role management module
- Role definition: When creating a role, you need to fill in the name, description (for example, Resource Approval Post), and associate the department dimension (optional).
- Permission configuration: Check the function permissions through the tree structure, and select the data permission range (full/department/individual) by dropping down.
- Efficient operation: Supports role duplication (quickly create roles with similar permissions) and batch deletion (need to verify associated users).
2. Mind mapping
3. Prototype diagram description
User management page: There is a search bar at the top (support name/job number/department filtering), the list displays user ID, name, role collection, status and other information, and the operation column includes “Edit”, “Assign role”, and “Disable” buttons.
When a user is responsible for multiple department permissions, you can add multiple department permissions to them
Role management: The structure is similar to the user management page, with a new “Number of Permissions” field in the list, and the “Assign Permissions” and “Role Status” buttons in the operation columns. When creating a role, select Whether to set a system default role (the default role cannot be deleted).
Add a new character
Delete the role
4. Example of the permission configuration of the role
5. Module design ideas
- Demand first: Clarify the core scenarios (such as “whether to support cross-departmental roles” and “whether temporary permissions are required”) through user interviews, output a list of requirements and ask the business party to sign and confirm.
- Permission hierarchy: Break down permissions into “functional permissions” (action buttons) and “data permissions” (data scopes) to avoid confusion in permission design.
- Scalable reservations: Fields such as “User Extension Field” and “Role Label” are reserved during database design to facilitate later iterations (such as adding the “User Level” dimension).
- Ease of operation: High-frequency operations (such as batch assignment of roles) need to optimize interaction and reduce the number of clicks (such as Excel import user-role association).
3. Problems encountered in the development process and solutions
issue: Permission conflicts when users associate multiple roles (for example, Role A allows “Delete” and Role B prohibits “Delete”).
settle: Set permission priority rules – “Prohibit permissions” is higher than “Allowed permissions”, and “Prohibit” is set by default in case of conflict.
issue: After the permission is modified, the user needs to log in again to take effect.
settle: The development permission cache refreshes the interface in real time, and automatically pushes new permissions to the front-end after modification, without the need to log in again.
issue: When a user belongs to multiple departments, there are overlapping or contradictory data permissions (for example, both departments A and department B have viewing permissions, but the data of the two departments has confidentiality and isolation requirements).
settle: Design the “Department Permission Priority” mechanism to allow users to set priorities for multiple departments associated with users, and the permission rules of the highest priority department are executed by default when accessing data. At the same time, the “Department View Switching” function is provided, and users can manually select the department dimension of the current operation, and the system automatically matches the corresponding data permissions.
issue: When the A/B corner (such as the approval post A and B are backed up by each other) needs to be temporarily handed over permissions, manual assignment of permission items is inefficient and easy to miss.
settle: Developed the A/B corner association configuration function, preset the A/B corner relationship in the system, and when the A corner is marked as “offline”, the system automatically temporarily grants the same permissions as the A corner (including function and data permissions), and records the permission handover log.
6. Pitfall avoidance guide: traps to be wary of in actual combat
1) Ambiguity in demand leads to rework
- pit point: Initially, it was not clear whether the data permissions included historical data, but after the launch, users were unable to view the historical data before the new permissions.
- Avoid pits: Specify the scope of permissions (“Add data only” or “Include historical data”) in the requirements document, and mark the description in the prototype.
2) The granularity of permissions is too fine
- pit point: Split “View”, “Add”, “Edit”, and “Delete” into independent permissions, resulting in a long role configuration page that is difficult for users to understand.
- Avoid pits: Initially, the “module-level” design permissions (such as “approval management permissions”) are gradually split into fine-grained permissions based on feedback.
3) Character naming is not standardized
- pit point: The role name is vaguely named “Temporary Post 1” or “Special Permission Group”, which is difficult to maintain in the later stage.
- Avoid pits: Formulate naming conventions (e.g., “[department]-[position]-[authority type]”, e.g., “marketing department-event planning-editorial post”), and maintain a role dictionary.
4) Ignore data permission levels
- pit point: Only supports the “individual/system-wide” data permission, and cannot meet the “cross-departmental collaboration” scenario (for example, “R&D 1 can view R&D 2 data”).
- Avoid pits: Design multi-level data permissions (individual→ department→ cross-department→ system-wide), and support customized data scopes (such as specifying “R&D Department 1 + R&D Department 2”).
7. Summary
At the heart of the User Management and Role Management modules is “balancing security and ease of use”. In practice, it is necessary to design permission granularity in combination with business scenarios, achieve flexible management and control through the “user-role-permission” architecture, and be wary of pitfalls such as ambiguous requirements and confusing naming. Subsequent iterations can consider introducing functions such as “Permission Application – Approval Process” and “Automatic Recycling of Temporary Permissions after Expiration” to further enhance the value of the module.
