User Roles and Access Control in the Academic System

The Sistema de Gestión Académica — UTP AED implements a role-based access control (RBAC) model. When a user logs in, the application resolves their role from the authenticated Usuario object and uses it to decide which buttons are rendered visible in the MenuPrincipal sidebar. There are no runtime permission prompts — panels that a role cannot access simply do not appear.

Role Comparison

Role	Default Login	Panels Accessible	Key Operations
Administrator	`admin` / `1234`	All panels	Full CRUD on courses, students & enrollments; review and close student requests
Secretary	`secretaria` / `1234`	Courses, Students, Enrollment, Solicitudes	CRUD on academic catalog, student registry, and access to the student request queue
Student	`<carnet>` / `1234`	My Enrollments, Solicitudes, History	View own enrollments; submit and track academic requests

How Authentication Works

The login flow in LoginFrame collects a username, password, and a role selection from a JComboBox. Depending on the selected role, authentication follows one of two paths.

Administrator / Secretary
Student

Credentials are validated against the usuarios table in the SQL Server database (iestp_peru_japon) through UsuarioDAO, which implements IUsuarioDAO.

// UsuarioDAO.java — SQL path
String sql = "SELECT * FROM usuarios WHERE LOWER(username) = LOWER(?)";
// ...
if (passwordBD.equals(password.trim())) {
    String rol = rs.getString("rol");
    return new Usuario(username, password, rol, carnet);
}

If the database is unavailable, UsuarioDAO falls back to hard-coded credentials (admin/1234 and secretaria/1234) so the application remains usable offline.

Student credentials are checked by CuentasEstudiantes.autenticar(String usuario, String password), which reads a local plain-text file rather than the database.

// CuentasEstudiantes.java
public static boolean autenticar(String usuario, String password) {
    if (usuario == null || password == null
            || !PASSWORD_DEFECTO.equals(password)) {
        return false;
    }
    // reads ~/.proyecto_utp_aed_datos/cuentas_estudiantes.txt
    // and checks whether the trimmed username appears as a line
}

The file lives at:

~/.proyecto_utp_aed_datos/cuentas_estudiantes.txt

Each line in the file is a carnet. A student can log in if and only if their carnet is present in that file and the password equals "1234" (the value of CuentasEstudiantes.PASSWORD_DEFECTO).

Student Account Creation

Student accounts are created automatically — there is no manual registration screen. CuentasEstudiantes.registrarPorMatricula(carnet) is invoked in two places:

During enrollment — when a secretary or administrator enrolls a student through the Matrícula panel (PanelMatricula), the method is called immediately after a successful enrollment is recorded.
On application startup — when PersistenciaAcademica.cargar() loads saved data from disk, it iterates over all persisted enrollments and calls registrarPorMatricula for each one, ensuring the accounts file stays consistent with the enrollment list.

// PanelMatricula.java — called after a successful enrollment
CuentasEstudiantes.registrarPorMatricula(carnet);

// PersistenciaAcademica.java — called during data load at startup
listaMatricula.recorrer(
    m -> CuentasEstudiantes.registrarPorMatricula(m.getEstudiante().getCarnet())
);

The method is idempotent — if the carnet is already in the file it is simply skipped, so calling it multiple times causes no side effects. It writes the student’s carnet as a new line in cuentas_estudiantes.txt, enabling that carnet to be used as a login username from that point onward.

A student who has never been enrolled cannot log in, because their carnet will not yet exist in the accounts file.

Panel Visibility by Role

The following logic in MenuPrincipal drives panel visibility at runtime:

String rol = usuarioActual.getRol() == null
        ? "" : usuarioActual.getRol().trim().toLowerCase();

boolean esAdmin       = rol.equals("admin")       || rol.equals("administrador");
boolean esSecretaria  = rol.equals("secretaría")  || rol.equals("secretaria");
boolean esEstudiante  = rol.equals("estudiante");
boolean esDocente     = rol.equals("docente");

btnCursos.setVisible(esAdmin || esSecretaria);
btnEstudiantes.setVisible(esAdmin || esSecretaria);
btnMatricula.setVisible(esAdmin || esSecretaria);
btnHistorial.setVisible(esAdmin || esEstudiante || esDocente);
btnSolicitudes.setVisible(esAdmin || esEstudiante || esSecretaria);
btnMisMatriculas.setVisible(esEstudiante);
btnAtenderSolicitudes.setVisible(esAdmin);

Buttons that are not visible are still present in the layout — they simply have setVisible(false) applied, so they occupy no space.

Role Pages

Administrator

Full system access, including request resolution and all CRUD panels.

Secretary

Day-to-day academic data entry: courses, students, and enrollment management.

Student

Self-service view of personal enrollments, request submission, and history.

Getting Started

Core Features

User Roles

Role Comparison

How Authentication Works

Student Account Creation

Panel Visibility by Role

Role Pages

Administrator

Secretary

Student

Build docs developers (and LLMs) love

Getting Started

Core Features

User Roles

Documentation Index

​Role Comparison

​How Authentication Works

​Student Account Creation

​Panel Visibility by Role

​Role Pages

Administrator

Secretary

Student

Build docs developers (and LLMs) love

Role Comparison

How Authentication Works

Student Account Creation

Panel Visibility by Role

Role Pages