Saleor 3.23.40 en bodegas: catálogo, parches y salida
Saleor 3.23.40 trae parches Django y abre una revisión práctica: catálogo, stock, permisos, apps, backup y salida para ventas B2B de bodegas.
Antes, la tienda tomaba pedidos y depósito corregía stock al final del día; después, cada canal necesitó precio, reserva, pago y evento visible. Saleor 3.23.40 salió el 7 de octubre con parches de seguridad de Django y vuelve útil revisar cómo una bodega o tienda mayorista expone catálogo sin perder control operativo. El caso muestra qué dato se guarda, quién lo cambia y cómo se sale.
Qué revela una actualización de seguridad en comercio digital
La release 3.23.40 de Saleor aplica parches de Django asociados a cuatro CVE: CVE-2026-77050, CVE-2026-84429, CVE-2026-87890 y CVE-2026-87975. La cifra corrige una idea cómoda: una tienda B2B no queda ordenada por tener catálogo, queda ordenada cuando seguridad, stock y permisos entran en el mismo calendario. El aviso de seguridad de Django explica el origen de esos parches. Para una bodega de Luján de Cuyo, la discusión baja rápido: el portal de distribuidores muestra listas de precio, disponibilidad, mínimos de compra y estado de pedido; si el framework tiene parche, el equipo necesita saber qué versión corre y quién aprueba la ventana. El dato técnico global viene de la encuesta Stack Overflow 2025, donde Python y SQL siguen entre tecnologías extendidas. Saleor usa GraphQL como API y se apoya en una pila que los equipos pueden auditar con herramientas conocidas. El antagonista es el stock prometido sin lote. Un pedido web de 48 cajas puede estar aceptado, pero depósito ve que veinte pertenecen a otro canal. El número disponible debe vivir en una regla, no en una conversación de cierre.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. 1. Comercial carga productos, variantes, listas de precio, canal, moneda y regla de disponibilidad. 2. Depósito informa stock por ubicación, lote o reserva operativa. 3. Saleor guarda catálogo, usuarios, canales, pedidos, pagos y eventos de cambio. 4. La API GraphQL entrega productos, órdenes, pagos y envíos a frontend, ERP o tablero. 5. Las apps se comunican con Saleor mediante API y webhooks, según la documentación de apps. 6. Los permisos separan edición de catálogo, precios, stock, pedidos, apps y lectura gerencial. 7. El backup copia base, archivos, configuración y secretos; la restauración abre un pedido completo. El README de Saleor presenta la plataforma como comercio API-first. En un caso chico, esa definición sirve si se traduce a operaciones concretas: el sitio pide stock, el ERP confirma reserva, el pago cambia estado, el despacho adjunta remito y gerencia ve margen sin editar productos. PostgreSQL guarda registros estructurados y auditoría de la aplicación. Redis o cola de tareas sostiene trabajos de fondo. El almacenamiento conserva imágenes, comprobantes y adjuntos. El monitoreo mira errores de API, webhooks fallidos, tareas atrasadas y certificados. Si falla la API, la tienda pierde consulta; si falla la cola, pedidos y correos quedan demorados; si falla el backup, el historial comercial queda incompleto.
Qué se instala o configura primero
El primer entregable verificable es un catálogo piloto con veinte productos, dos listas de precio, dos usuarios comerciales, un canal B2B, una app de integración y diez pedidos de prueba. Una pila concreta usa Saleor 3.23.40, PostgreSQL, Redis, almacenamiento de medios, frontend separado, proxy HTTPS, monitoreo y backups con restauración. Con dólar oficial vendedor informado por DolarAPI, una prueba controlada de USD 620 a USD 1.240 equivale a ARS $954.800 a ARS $1.909.600. Ese costo cubre piloto, permisos, integración mínima y restore; no incluye rediseño comercial ni catálogo completo. UMSA puede arrancar con un recorte de temporada: productos de alta rotación, clientes mayoristas, listas por zona y regla de reserva. El primer corte útil muestra un pedido creado por portal, un cambio de stock, un webhook recibido, una orden exportada y una restauración dónde el pedido conserva precio, cliente, estado y adjuntos.
Dónde se rompe y cómo probarlo
El primer riesgo es separar catálogo y stock. La señal aparece cuando venta acepta unidades que depósito ya reservó. La prueba crea dos pedidos simultáneos sobre el mismo producto y revisa bloqueo o reserva. El segundo riesgo es instalar apps sin permisos acotados. La señal aparece cuando una app de despacho puede editar precios. La prueba crea una app con permisos mínimos y registra cada llamada. El tercer riesgo es postergar parches de seguridad. La señal aparece cuando producción corre una versión anterior y nadie tiene fecha de actualización. La prueba mantiene inventario de versiones y simula una ventana de parche sobre copia. El cuarto riesgo es backup de base sin medios. La señal aparece cuando el pedido vuelve, pero falta comprobante, foto o remito. La prueba restaura base y almacenamiento, abre tres pedidos y compara adjuntos. El quinto riesgo es salida incompleta. La señal aparece cuando el sistema exporta productos, pero no pedidos ni eventos. La prueba mensual exporta catálogo, clientes, pedidos, pagos y cambios de estado, y abre el paquete fuera de Saleor. Una tienda B2B queda lista cuando puede rechazar un pedido incorrecto y explicar por qué, con fecha, usuario y dato recuperable.
