Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Danielings/Pasantia-Proyecto/llms.txt

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

The Sistema de Inventario Tecnológico enforces a three-tier role model that controls both what data a user can see and what operations they can perform. Every user is assigned exactly one role at creation time, and that role is embedded in their JWT token and validated against it on every protected API call. The three roles — Superadministrador, Administrador, and Visualizador — are defined as a strict enum in the frontend validation schema (userSchema.ts) and checked server-side through dedicated Express middleware.

​
The Three Roles

Superadministrador

Full system access across all offices and locations. Manages users and can read every asset in the inventory regardless of sede.

Administrador

Write access to inventory items and locations, scoped to their own sede. Cannot manage other users.

Visualizador

Read-only access to inventory items scoped to their sede. All write operations are blocked at the middleware layer.

​
Superadministrador

The Superadministrador role is the only role permitted to call GET /api/usuarios, which returns the full list of active user accounts. This restriction is enforced by the esSuperAdmin middleware, which runs after verificarToken and immediately returns HTTP 403 if the decoded token’s rol field is anything other than "Superadministrador". 
// backend/middleware/esSuperAdmin.js
export default function esSuperAdmin(req, res, next) {
  if (req.user.rol !== "Superadministrador") {
    return res
      .status(403)
      .json({ message: "Acceso denegado. Requiere ser Superadministrador." });
  }
  next();
}
Beyond user management, the Superadministrador sees inventory data across all locations and offices — there is no sede filter applied to their queries. They can update any user profile (PUT /api/usuarios/:id) and soft-delete accounts (PUT /api/usuarios/eliminado/:id). Note that POST /api/usuarios (user creation) is an open endpoint — it requires no authentication — and is therefore accessible to any caller with network access. In practice, new users are created by a Superadministrador through the frontend registration form.

​
Administrador

The Administrador role has full write access to inventory items and locations within the system. The permitirEscritura middleware checks whether the authenticated user’s role is "Visualizador" and, if not, allows the request to proceed — meaning Administrators pass through freely. 
// backend/middleware/permitirEscritura.js
export default function permitirEscritura(req, res, next) {
  if (req.user?.rol === "Visualizador") {
    return res.status(403).json({
      message:
        "Acceso denegado. Los visualizadores no pueden editar ni eliminar.",
    });
  }
  next();
}
Administrators can create, update, and delete inventory assets and manage location records. However, their data view is scoped to the sede value stored in their JWT token — queries against inventory collections are automatically filtered to return only assets assigned to their office.

​
Visualizador

The Visualizador role is a read-only consumer of the system. Whenever a Visualizador attempts any POST, PUT, or DELETE request that is guarded by the permitirEscritura middleware, the server responds with: 
{
  "message": "Acceso denegado. Los visualizadores no pueden editar ni eliminar."
}
This HTTP 403 response is returned before any business logic runs, so no partial writes can occur. Like the Administrador, inventory data visible to a Visualizador is scoped to their own sede.

​
Role × Capability Matrix

The table below summarises every major capability and which roles can exercise it. “Open” endpoints (no verificarToken) are accessible without a session; rows marked ✅ for all roles reflect that any authenticated user may call them.
CapabilitySuperadministradorAdministradorVisualizador
View all users (GET /api/usuarios)✅❌❌
Create users (POST /api/usuarios) ¹✅✅✅
Update users (PUT /api/usuarios/:id)✅✅✅
Soft-delete users (PUT /api/usuarios/eliminado/:id)✅✅✅
View own profile (GET /api/usuarios/me)✅✅✅
View inventory items (own sede)✅✅✅
View inventory items (all sedes)✅❌❌
Create inventory items✅✅❌
Update inventory items✅✅❌
Delete inventory items✅✅❌
Create / update locations✅✅❌
View audit log (bitácora)✅✅✅
¹ POST /api/usuarios carries no authentication middleware — it is an open endpoint. Access should be controlled at the network or application level in production.

​
How the Role Is Enforced at Runtime

Role enforcement is a two-step process on every protected request:
1

Token extraction and verification

The verificarToken middleware reads the acceso_token HTTP-only cookie and calls jwt.verify() using JWT_SECRET. The decoded payload — which includes id, rol, sede, username, and correo — is attached to req.user.
2

Role-specific middleware check

Routes that require elevated privileges chain an additional middleware (esSuperAdmin or permitirEscritura) immediately after verificarToken. This middleware inspects req.user.rol and either calls next() or returns HTTP 403 — before any controller logic is reached.
The role value is read from the JWT on every request, but the JWT itself is signed from the Firestore document at login time. If an administrator changes a user’s role, the affected user must log out and log back in for their new role to take effect in the token.
When building frontend UI, you can read the current user’s role from the AuthContext (useAuth().user.rol) and conditionally render action buttons — for example, hiding “Edit” and “Delete” controls for Visualizador users. This is a UX convenience; the real enforcement always happens server-side.

Build docs developers (and LLMs) love

Get started for freeTalk to us