Equipment is the core entity of the inventory system. Each record represents a physical PC or Laptop together with its internal components (processor, RAM, hard drive, motherboard) and any peripherals attached at registration time. The backend enforces serial uniqueness across the entire system using a dedicatedDocumentation 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.
indices Firestore collection, and every write that involves serials runs inside a Firestore transaction to prevent race conditions.
Equipment Types
The system recognizes two equipment types, defined ininventory.constants.js:
tipo values are normalized (lowercased, trimmed) before lookup, so "PC", "pc", and " PC " all resolve to the canonical string "PC".
Internal Components
Every equipment document may carry an array ofcomponentes. The four supported component types are:
| Field | Required | Description |
|---|---|---|
tipo | ✅ | One of the four canonical types above |
marca | ✅ | Manufacturer name |
modelo | ✅ | Model string |
serial | ✅ | Unique serial number |
estado | ✅ | Functional status |
capacidad | ✅ for Memoria_RAM and Disco_Duro | Storage or memory capacity (e.g., "16GB", "1TB"). Required when tipo is Memoria_RAM or Disco_Duro; omit for other component types. |
Dual Location Fields
Every equipment record stores two separate location objects:
procedencia— where the asset originated (warehouse, supplier, former office). This field is set at registration and is never overwritten by subsequent edits toasignacion.asignacion— where the asset is currently deployed (office, floor, wing). This is the field updated when equipment is moved.
region, estado, ciudad, sede, piso, and the optional ala.Validation Schema
The frontend validates equipment forms with Zod before sending data to the API. Key fields fromequipoSchema.ts:
z.preprocess wrappers convert null and undefined select values (common with controlled <select> components) to empty strings so Zod’s .min(1) check can produce a human-readable error.
Registering a PC
POST /api/pc — no authentication required for registration.
Prepare the request body
Build a JSON object with the equipment fields, both location objects, a
componentes array, and an optional perifericos array.Submit the request
Send the payload to
POST /api/pc. The handler normalizes all inputs, then opens a Firestore transaction to validate serial uniqueness for the equipment, each component, and each peripheral before writing anything.Registering a Laptop
POST /api/laptop accepts exactly the same request body shape as POST /api/pc. The only difference is the resulting tipo field stored in Firestore, which will be "Laptop" instead of "PC".
Serial Uniqueness Enforcement
Before any document is written, the transaction callsvalidateUniqueSerial for every serial in the payload — the equipment serial, each component serial, and each peripheral serial. This function reads from the indices collection using a deterministic document ID built with serialIndexId(prefix, serial). If any index document already exists, the entire transaction is aborted and a 400 Bad Request is returned.
Querying Equipment
List all equipment
GET /api/equipos — requires authentication (verificarToken middleware).
Supports three optional query parameters for client-side filtering:
| Parameter | Description | Example |
|---|---|---|
tipo | Filter by equipment type | ?tipo=Laptop |
estado | Filter by status | ?estado=Funcional |
serial | Exact match on serial (normalized) | ?serial=DL-OPT-00142 |
asignacion.sede matches their assigned office (torre).
Get a single equipment record
componentes and perifericos arrays.
Get a single equipment record (alternate route)
componentes and perifericos default to empty arrays when absent from the Firestore document:
List equipment summaries
GET /api/equipos/lista — no authentication required.
Returns a lightweight array containing only id, serial, marca, modelo, and tipo for every equipment record. Use this endpoint to populate equipment selector dropdowns without fetching full documents.
Search by serial number
404 if no match is found.
Editing Equipment
PUT /api/equipos/:id — updates an existing equipment record inside a Firestore transaction.
How component merging works
How component merging works
The PUT handler merges incoming component data with existing component data using the serial number as the key. For each component in the request body:
- If a component with the same serial already exists in the stored
componentesarray, the handler spreads the old object first, then the new object on top ({ ...old, ...new }). Fields you omit in the request are preserved from the existing record. - If the serial is new, the component is appended as-is.
{ serial: "CPU-10700-0042", estado: "En Reparación" } — will update just estado while keeping all other fields intact.How peripheral re-assignment works
How peripheral re-assignment works
The PUT handler computes three sets from the old and new peripheral serial lists:
- Removed serials: The matching document in the
perifericoscollection is updated toasignado: false, andequipoId/equipoSerialare cleared. - Added serials: If the peripheral already exists as a standalone record and is not assigned elsewhere, it is linked to this equipment. If it does not exist at all, a new
perifericosdocument is created and marked as assigned. - Kept serials: The
equipoRelacionadoback-reference is refreshed to reflect any changes to the equipment’s own fields (e.g., updated serial or model).