Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/kenri89/PROYECTO_UTP_AED_1_1/llms.txt

Use this file to discover all available pages before exploring further.

Administrators have unrestricted access to every panel in the MenuPrincipal sidebar. They are the only role that can open the Atender Solicitudes (Admin) panel, which allows them to review and close requests submitted by students. Because all panel visibility flags resolve to true for an admin, the sidebar displays the full set of navigation buttons without any hidden entries.

​
Available Panels

1

Gestión de Cursos

Opens PanelCursos, which provides full create, edit, and delete operations on the course catalog. Courses are stored in both a ListaCursos (linked list) and an ArregloCursos (array-backed structure), and are organised by semester through a MatrizSemestres.
2

Gestión de Estudiantes

Opens PanelEstudiantes, backed by an ArbolEstudiantes binary search tree. Administrators can register new students, update existing records, and delete students from the registry.
3

Matrícula

Opens PanelMatricula for enrolling and un-enrolling students. Every enrolment action is pushed onto the shared PilaAcciones_U3 history stack and CuentasEstudiantes.registrarPorMatricula(carnet) is called automatically after each successful enrollment to ensure the student has a login account. The method is idempotent — if the carnet is already registered it is simply skipped.
4

Historial Académico

Opens PanelHistorial, a read-only view of the PilaAcciones_U3 stack. Administrators can inspect the full chronological trail of enrolment actions across all students.
5

Solicitudes

Opens PanelSolicitudesEstudiante, which shows the shared Queue<Solicitud>. Administrators can view all pending requests in the queue alongside students.
6

Atender Solicitudes (Admin)

Opens PanelAdministradorSolicitudes — exclusive to the administrator role. This panel lets administrators dequeue and close student requests. Attempting to open it with any other role triggers an access-denied dialog:
// MenuPrincipal.java
if (!(rolClick.equals("admin") || rolClick.equals("administrador"))) {
    JOptionPane.showMessageDialog(this,
        "Acceso restringido solo para administradores.");
    return;
}

​
Default Credentials

The default administrator account is seeded into the usuarios table by schema.sql: 
INSERT INTO usuarios (username, password, rol)
VALUES ('admin', '1234', 'Administrador');
FieldValue
Usernameadmin
Password1234
Role (rol)Administrador

​
Login Path

When the login form is submitted with the Administrador role selected, UsuarioDAO.autenticar() executes a case-insensitive query against the usuarios table: 
// UsuarioDAO.java
String sql = "SELECT * FROM usuarios WHERE LOWER(username) = LOWER(?)";
On a successful match, the returned Usuario object is constructed without a carnet: 
// carnet is null for admin accounts read from the DB
return new Usuario(username, password, rol, carnet); // carnet = null
If the database is unreachable, the fallback authenticator in UsuarioDAO accepts admin/1234 in-memory so the application continues to function offline: 
// UsuarioDAO.java — autenticarFallback()
if (u.equals("admin") && p.equals("1234")) {
    return new Usuario(u, p, "Administrador"); // no carnet field
}
The fallback hard-codes admin/1234. If the database is offline, anyone with knowledge of these credentials can authenticate. Ensure the SQL Server instance is reachable in production environments.
Change the default password in the usuarios table before deploying to a shared or networked environment:
UPDATE usuarios
SET password = 'your_secure_password'
WHERE username = 'admin';
The hard-coded fallback in UsuarioDAO.autenticarFallback() should also be removed or replaced with a secure alternative for production use.

Build docs developers (and LLMs) love

Get started for freeTalk to us