Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/camiloivcode/biblioteca-la-palabra/llms.txt

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

El módulo de usuarios gestiona las cuentas del personal que opera Biblioteca Popular La Palabra. Es importante distinguir entre dos conceptos distintos: los socios son los miembros registrados de la biblioteca que solicitan préstamos, mientras que los usuarios son las cuentas de acceso al sistema de gestión asignadas al equipo de trabajo (administradores y bibliotecarios). El acceso a este módulo está restringido exclusivamente al rol ADMIN mediante el middleware requireRole('ADMIN'). Un usuario con rol BIBLIOTECARIO no puede ver, crear ni modificar cuentas de otros usuarios; cualquier intento devuelve 403 Forbidden.

​
Roles

El sistema define exactamente dos roles, cada uno con un conjunto de permisos diferente:
RolAcceso y permisos
ADMINAcceso completo al sistema. Gestión de usuarios, socios, materiales, préstamos, catálogos y reportes.
BIBLIOTECARIOGestión de socios, materiales, préstamos y reportes. Sin acceso al módulo de usuarios.

​
Campos del usuario

CampoTipoRequeridoDescripción
nombreString✅Nombre completo del usuario
emailString✅Dirección de correo electrónico. Debe ser única en el sistema.
passwordString✅Contraseña. Mínimo 8 caracteres, al menos una mayúscula y un dígito. Se almacena con hash bcrypt.
roleEnum✅Rol del usuario: ADMIN o BIBLIOTECARIO
activoBoolean—Estado de la cuenta. true por defecto. Las cuentas inactivas no pueden iniciar sesión.
Las respuestas de la API nunca devuelven el campo password, ni en listados ni en consultas individuales. El hash solo existe en la base de datos.

​
Restricciones de contraseña

Las contraseñas de los usuarios deben cumplir los siguientes requisitos, validados en el backend al crear una cuenta:
  • Longitud mínima de 8 caracteres
  • Al menos una letra mayúscula
  • Al menos un dígito numérico
Estas reglas se aplican únicamente al crear el usuario (POST /api/users). Al actualizar (PUT /api/users/:id), el campo password es opcional; si se omite, la contraseña existente se conserva sin cambios.

​
Operaciones

Todas las rutas bajo /api/users requieren rol ADMIN. Las solicitudes realizadas con un token de usuario BIBLIOTECARIO recibirán una respuesta 403 Forbidden, independientemente de si el token es válido.
MétodoRutaDescripción
GET/api/usersLista todos los usuarios del sistema (solo ADMIN).
GET/api/users/:idObtiene un usuario por ID (solo ADMIN).
POST/api/usersCrea una nueva cuenta de usuario (solo ADMIN).
PUT/api/users/:idActualiza nombre, email o rol de un usuario (solo ADMIN).
PATCH/api/users/:id/toggleActiva o desactiva una cuenta. Alterna el campo activo.
DELETE/api/users/:idElimina permanentemente una cuenta de usuario.

​
Ejemplo: crear un usuario

curl -X POST https://tu-api/api/users \
  -H "Authorization: Bearer <token-admin>" \
  -H "Content-Type: application/json" \
  -d '{
    "nombre": "Laura Méndez",
    "email": "laura@biblioteca.org",
    "password": "Segura123",
    "role": "BIBLIOTECARIO"
  }'

​
Ejemplo: respuesta

{
  "success": true,
  "message": "Usuario creado correctamente",
  "data": {
    "id": 5,
    "nombre": "Laura Méndez",
    "email": "laura@biblioteca.org",
    "role": "BIBLIOTECARIO",
    "activo": true,
    "createdAt": "2025-01-15T10:30:00.000Z"
  }
}

​
Activación y desactivación de cuentas

El endpoint PATCH /api/users/:id/toggle alterna el campo activo de la cuenta: si estaba activa la desactiva, y si estaba inactiva la activa. No requiere cuerpo en la solicitud. 
curl -X PATCH https://tu-api/api/users/5/toggle \
  -H "Authorization: Bearer <token-admin>"

{
  "success": true,
  "data": {
    "id": 5,
    "nombre": "Laura Méndez",
    "activo": false
  }
}
Las cuentas con activo: false son rechazadas en el login y no pueden operar el sistema. La desactivación es reversible; se prefiere sobre la eliminación cuando se desea preservar el historial de acciones del usuario.
Un administrador no puede desactivar ni eliminar su propia cuenta. Intentarlo devolverá un error 403 Forbidden con el mensaje correspondiente. Esto evita que el sistema quede sin ningún administrador operativo.

​
Solicitud de registro

Los usuarios del sistema no pueden auto-registrarse. El flujo de alta es el siguiente:
  1. El candidato envía una solicitud a través del formulario público en /register.
  2. El frontend llama a POST /api/auth/register-request, que notifica al administrador sin crear ninguna cuenta.
  3. El administrador revisa la solicitud y, si la aprueba, crea la cuenta manualmente desde el módulo de usuarios (POST /api/users).
Este diseño garantiza que solo el administrador controla quién tiene acceso al sistema de gestión.

​
Referencia de API

Para la referencia completa de parámetros, esquemas de respuesta y códigos de error consulta:

Build docs developers (and LLMs) love

Get started for freeTalk to us