Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/carlamndz/InventarioITU/llms.txt

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

InventarioITU gives administrators and staff a single, authoritative view of every computer across ITU Mendoza’s labs. The inventory management module records where each piece of equipment lives, who or what it is assigned to, and what operational state it is in — all stored in the relational database and surfaced through the Node.js/Express web interface on inventario-web (port 3000). This means you can answer questions like “which machines in Lab 3 are currently unassigned?” or “what is the status of equipment ITU-0142?” without walking the building.

​
What Data Is Tracked

Every equipment record captures the following fields:
FieldDescription
ID de equipoUnique identifier that ties this record to its hardware document in MongoDB (e.g., LAB01-PC-042)
NombreHuman-readable label for the machine (e.g., PC-042 Lab 1 Puesto 12)
LaboratorioThe lab building or wing where the equipment resides (e.g., Laboratorio 1)
UbicaciónRoom-level detail within the lab — row, bench, or workstation number
Asignado aPerson, course, or administrative purpose the machine is currently allocated to
EstadoOperational lifecycle state (see the status table below)
Having both laboratorio and ubicacion as separate fields allows queries at two granularities: broad lab-level reporting for facility planning and precise seat-level tracking for day-to-day operations.

​
Equipment States

Equipment moves through a defined lifecycle. The four states tracked in ubicacion-db are:
StateSpanish LabelMeaning
AvailableDisponibleMachine is in service and not currently allocated to any person or course
AssignedAsignadoAllocated to a specific person, course section, or administrative role
Under maintenanceEn mantenimientoTemporarily offline for repairs, upgrades, or diagnostics
DecommissionedDado de bajaRetired from service; kept in the database for audit history
Keep assignments up to date whenever equipment changes hands. Stale Asignado records cause availability reports to under-count free machines, which can lead to unnecessary purchase requests.

​
Querying Equipment

The web interface exposes three primary ways to find equipment records.

​
Browse by Lab Room

The default inventory view groups machines by laboratorio and then by ubicacion. Select a lab from the sidebar to see all workstations in that room, their current assignees, and their states at a glance.

​
Search by Equipment ID

Use the search bar at the top of the inventory page to look up a specific machine by its ID. The query runs directly against the equipos table in the relational database, so results are always current. 
-- Example: look up a single machine by ID
SELECT id, nombre, ubicacion, laboratorio, asignado_a, estado
FROM equipos
WHERE id = 'LAB01-PC-042';

​
Filter by Assignment Status

Use the Estado filter dropdown to narrow the list to a single lifecycle state. For example, selecting Disponible instantly shows every unallocated machine across all labs — useful before assigning equipment to a new intake of students. 
-- Example: all available machines in Lab 2
SELECT id, nombre, ubicacion, asignado_a
FROM equipos
WHERE laboratorio = 'Laboratorio 2'
  AND estado = 'Disponible'
ORDER BY ubicacion;

​
Data Source: Relational DB (ubicacion-db)

Location and assignment data lives in the ubicacion-db relational database instance, which is reachable inside the cluster on port 1433. The project supports both SQL Server and MySQL as the underlying relational engine — the README specifies “SQL Server / MySQL”, so either can be used depending on your deployment environment. The inventario-web backend connects using the credentials provided via environment variables at container startup.
The README specifies SQL Server / MySQL as supported relational backends. SQL Server uses TDS on port 1433; if you deploy MySQL instead, the port remains 3306 by default. Adjust your environment variables and connection driver accordingly.
The core table schema below is an illustrative example of how the equipos table can be structured. When you add schema scripts to db/sqlserver/ (or db/mysql/), define the table to match your chosen engine’s syntax: 
-- Example: equipment location and assignment table (SQL Server syntax)
CREATE TABLE equipos (
    id            VARCHAR(50)   PRIMARY KEY,        -- matches MongoDB _id
    nombre        VARCHAR(100)  NOT NULL,
    ubicacion     VARCHAR(100)  NOT NULL,            -- seat/bench identifier
    laboratorio   VARCHAR(100)  NOT NULL,            -- lab room name
    asignado_a    VARCHAR(150)  NULL,                -- person or purpose; NULL = available
    estado        VARCHAR(30)   NOT NULL             -- Disponible | Asignado | En mantenimiento | Dado de baja
        CONSTRAINT chk_estado CHECK (estado IN (
            'Disponible', 'Asignado', 'En mantenimiento', 'Dado de baja'
        )),
    created_at    DATETIME      NOT NULL DEFAULT GETDATE(),
    updated_at    DATETIME      NOT NULL DEFAULT GETDATE()
);
The id column in equipos is intentionally kept in sync with the _id field in the corresponding MongoDB hardware document. This shared key lets the web app join location data from the relational DB with hardware component data from MongoDB in a single page render without a foreign-key constraint spanning two database engines.

​
Connection Details

SettingValue
Service nameubicacion-db
Port1433 (SQL Server) / 3306 (MySQL)
ProtocolTDS (SQL Server) or MySQL protocol
The backend reads the connection string from environment variables so that credentials never appear in source code. When you add Kubernetes manifests under k8s/sqlserver/, define a Secret and ConfigMap there for the connection credentials.

Build docs developers (and LLMs) love

Get started for freeTalk to us