User & Person Management

In the Atslegas system, management is divided into two distinct categories: Users and Persons. Understanding the difference between these two is essential for maintaining system security and operational efficiency.

Overview: Users vs. Persons

• Users: These are system accounts with login credentials (username and password). They are used to access the web interface, manage the database, or view key statuses. Users are assigned roles (e.g., root, admin, user).
• Persons: These represent physical individuals within the institution (e.g., teachers or staff). While a "Person" may also be a "User," the Person entity is primarily used as a record of who is physically holding a key.

User Management

Users are managed via the Admin Dashboard or the RESTful API. Every user account is tied to a set of credentials and a specific access level.

User Roles

1. Root: The initial super-user account. Has full access to system configuration and user management.
2. Admin: Can manage keys, persons, and view system logs.
3. User: Standard access, typically restricted to viewing key availability or managing their own assigned tasks.

Creating and Updating Users

System administrators can create users by providing a username and password. The system automatically handles password hashing using bcrypt and salt generation for security.

Configuration Limits: The following constraints are defined in config.json to ensure database integrity:

• Username: Max 64 characters.
• Password: Max 64 characters.

API Usage Example

To programmatically list all users registered in the system:

// Example: Fetching user list via API
fetch('/api/user/list')
  .then(response => response.json())
  .then(data => {
    console.log("Registered Users:", data);
  });

Person Management

The "Persons" database acts as a directory of everyone eligible to interact with keys. This allows the system to track physical assets without requiring every individual to have a system login.

Person Attributes

A Person record typically contains:

• Name & Surname: For identification.
• Email: For notifications or contact regarding held keys.
• ID: A unique identifier used to link the person to key logs.

Managing Persons in the Dashboard

Within the Admin interface, you can:

1. Add Person: Register a new individual in the directory.
2. Edit Details: Update contact information or names.
3. Delete: Remove individuals no longer affiliated with the institution.

Linking Users to Persons

For staff members who both use the software and physically carry keys, a User account can be linked to UserData.

• User Table: Stores authentication data (ID, Username, Hashed Password).
• UserData Table: Stores the profile information (Name, Surname, User Type, Enabled Status).

This separation ensures that if a user's login is disabled (e.g., for security reasons), their historical record as a "Person" (who held specific keys in the past) remains intact in the logs.

Enabling/Disabling Access

Administrators can toggle the enabled flag in a user's profile.

• Enabled (1): The user can log in and perform actions.
• Disabled (0): The account is locked, but all historical key logs and associations are preserved for auditing purposes.

Security Best Practices

1. Initial Setup: Upon first run, the system creates a default root user with the password root. Change this password immediately via the Admin settings.
2. Session Security: The system uses server-side filesystem sessions. By default, sessions timeout after 3600 seconds (1 hour). This can be adjusted in the client_sessions section of the config.json.
3. Audit Logs: Every action taken by a User (issuing a key, returning a key, or modifying a record) is captured in the system logs with a timestamp and the User ID.