prohibited_inputs_api
API de Insumos/Componentes Prohibidos por Programa
Contexto
Esta API permite gestionar qué insumos y/o componentes están prohibidos en cada programa de trazabilidad de un workspace.
La tabla anterior (prohibited_inputs) solo soportaba insumos. La nueva tabla (prohibited_inputs_components) soporta insumos O componentes (mutuamente excluyentes por fila).
Endpoints
Base URL: /activities/prohibited-inputs
| Método | Ruta | Descripción |
|---|---|---|
| GET | /activities/prohibited-inputs | Obtener prohibidos por programa |
| PATCH | /activities/prohibited-inputs | Agregar/quitar prohibidos de un programa |
Ambos requieren autenticación (Bearer token) y permisos de admin del workspace.
GET /activities/prohibited-inputs
No requiere query params. El workspace se toma del token JWT.
Response 200
{
"data": {
"1": {
"inputs": ["uuid-insumo-a", "uuid-insumo-b"],
"components": ["uuid-componente-c"]
},
"5": {
"inputs": [],
"components": ["uuid-componente-d", "uuid-componente-e"]
}
}
}
- Las keys del objeto
datason lostemplate_id(ID del programa de trazabilidad) como string. inputs: array de UUIDs de insumos prohibidos en ese programa.components: array de UUIDs de componentes prohibidos en ese programa.- Si un programa no tiene prohibidos, no aparece en el objeto.
PATCH /activities/prohibited-inputs
Request body
{
"template_id": 1,
"changes": [
{ "input_uuid": "uuid-insumo-a", "value": true },
{ "input_uuid": "uuid-insumo-b", "value": false },
{ "component_uuid": "uuid-componente-c", "value": true }
]
}
| Campo | Tipo | Obligatorio | Descripción |
|---|---|---|---|
template_id | integer | sí | ID del programa de trazabilidad |
changes | array | sí | Lista de cambios a aplicar |
changes[].input_uuid | string (uuid) | uno de los dos | UUID del insumo |
changes[].component_uuid | string (uuid) | uno de los dos | UUID del componente |
changes[].value | boolean | sí | true = prohibir, false = permitir |
Reglas de cada item en changes:
- Debe tener
input_uuidocomponent_uuid, nunca ambos. value: true→ agrega la prohibición (si ya existía, no hace nada).value: false→ quita la prohibición (soft-delete).
Response 200
{
"msg": "ok"
}
Errores posibles
| HTTP | Caso |
|---|---|
| 400 | template_id faltante o inválido |
| 400 | changes vacío o formato inválido |
| 400 | Item sin input_uuid ni component_uuid |
| 400 | Item con ambos input_uuid y component_uuid |
| 400 | value no es boolean |
| 401 | Token inválido o expirado |
| 400 | Usuario no es admin del workspace |
Formato de error estándar:
{
"res": "error",
"code": "...",
"info": "...",
"data": { "msg": "detalle del error" }
}
Comparación con la firma anterior
La versión anterior manejaba solo insumos. Esta es la evolución:
GET Response
Antes:
{
"data": {
"1": ["uuid-insumo-a", "uuid-insumo-b"],
"2": ["uuid-insumo-c"]
}
}
Ahora:
{
"data": {
"1": {
"inputs": ["uuid-insumo-a", "uuid-insumo-b"],
"components": ["uuid-componente-c"]
},
"2": {
"inputs": ["uuid-insumo-c"],
"components": []
}
}
}
Cada key del mapa pasó de ser
string[]a ser{ inputs: string[], components: string[] }.
PATCH Body
Antes:
{
"template_id": 1,
"changes": [
{ "input_uuid": "uuid-a", "value": true },
{ "input_uuid": "uuid-b", "value": false }
]
}
Ahora:
{
"template_id": 1,
"changes": [
{ "input_uuid": "uuid-a", "value": true },
{ "input_uuid": "uuid-b", "value": false },
{ "component_uuid": "uuid-c", "value": true }
]
}
Se agregó la opción de enviar
component_uuiden lugar deinput_uuid. Son mutuamente excluyentes por item.
Notas para el frontend
- No mezclar
input_uuidycomponent_uuiden el mismo objeto del arraychanges. - Se pueden enviar insumos y componentes en la misma request como items separados del array.
- Si un UUID de insumo/componente no existe en la BD, se ignora silenciosamente (no rompe la request).
- El
template_idcorresponde al ID numérico del programa de trazabilidad (traceability_program_templates.id). - El workspace se resuelve automáticamente del token JWT — no hace falta enviarlo.