## 5 Design of Front-End Application Layer Function Pages
### User Management Page  
The user management page includes user information, role management, and permission management. User information includes user ID, login name, user type, status, creation time, last update time, and operation.  
When the administrator clicks on user information, the front-end application layer sends a request to the back-end service layer. Subsequently, the RoleController in the back-end service layer accesses the database and queries all users in the user table. The retrieved data are then returned to the front-end business logic layer for rendering and display in the user information page, and the administrator can perform operations such as querying, updating, and deleting users. User queries are submitted by clicking the button in the top right corner and submitting the query form. To delete a user, the user ID of the selected user is stored in the Session object. The front-end application layer requests the userDelete(userID) method in the back-end service layer to delete the user using the user_id field in the user table. The parameter userID represents the user_id in the Session object. If the user_role field in the user table is 0, this indicates that the user is an administrator; in this case, the deletion fails. The database has the ability to roll back to avoid dirty reads, repeated reads, and phantom reads, which could greatly decease the accuracy and integrity of the data.  
Figure 15: Process of querying the historical data of a monitoring terminal.  
In the role management page, the administrator can assign access permissions to users, such as the permission to view historical data. Unauthorized users cannot query the historical data of monitoring terminals. After clicking on assigning permissions, the Session object records the role type role_id and the front-end application layer sends a request. The back-end service layer then calls the searchRoleRoot(roleID) method and accesses the role_permissions table in the database. The root_num field is used to determine whether the permission belongs to a first-level permission or a second-level permission (the front-end application layer uses the ztree component to display the permission categories in a tree format). If the root_state is 1, this means that the permission is disabled. The query is performed through the intermediate table between the user table and the role_permissions table, and the result is returned to the front-end application layer for display.  
the permissions of the entire monitoring system can be managed in the permission management page through CURD operations, facilitating subsequent system permission maintenance and upgrades. For example, when deleting the data module permission, the front-end application layer sends a request and the back-end service layer calls the deleteRoot(rootNum) method, checks the role_permissions table, and displays all permissions on the page. The Session object records the permission code role_num. The parameter rootNum is the same as role_num. When deleting the data module, parent_num is queried based on root_num. If parent_num%1000 = 0, this means that the permission belongs to a first-level permission, in which case the operation can only be performed after deleting all the second-level permissions it belongs to and cannot be deleted otherwise. When deleting the running state parameter, the back-end service layer calls the deleteRoot() method, checks whether it belongs to a second-level permission, directly deletes it, and returns a \"Delete successful\" prompt. If the root_state field is 1, this means that the permission is disabled.