f3f6fb7166ee9d9822b6c7f99a8a4d02b00a152c
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  devopsandClaude Opus 5.5
|
cfd9a7ec96 |
feat(reseñas): reseñas de productos de compradores verificados, moderadas
Backend (commerce-backend):
- Módulo product-review (tabla nueva product_review; migración generada con
medusa db:generate, no toca tablas existentes).
- GET /store/reviews?product_id (solo aprobadas), /store/reviews/summary,
GET /store/reviews/me y POST /store/reviews con auth de cliente: exige que
el pedido sea del cliente, no esté cancelado y contenga el producto
("Compra verificada"); 1 reseña por cliente y producto; nace "pending".
- /admin/reviews (+ /:id POST status, DELETE) y página "Reseñas" en el admin
para aprobar/rechazar/borrar.
Storefront (ecommerce):
- /cuenta/pedidos ("Mis pedidos"): historial real + diálogo "Califica tu
compra" (radiogroup accesible, flechas de teclado).
- Ficha: sección de reseñas con "Compra verificada" y estrellas junto al
título; tarjetas: promedio y cantidad (una llamada /api/reviews/summary).
- Accesos: "Mis pedidos y reseñas" en la cuenta y en Ayuda.
Validado en entorno descartable (Postgres/Redis/Meilisearch/Medusa propios):
E2E de API 20/20 (incluye pedido interno por draft order, cancelación y
borrado), E2E de tienda con navegador 15/15, admin "Reseñas" verificado en
build de producción. Revisado por frontend-critic (contraste de estrellas
amber-600, patrón radiogroup).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018r19s4H8MBGegqToqw5guP
|
||
|
devopsandClaude Sonnet 5
|
76b7d827c5 |
fix(ecommerce): corrige origen de bodega Bogotá→Cali y activa redes/Cambios/FAQ
Build and Push Medusa / Escaneo de Secretos (Gitleaks) (push) Successful in 30s
Build and Push Frontend / Escaneo de Secretos (Gitleaks) (push) Successful in 21s
Build and Push Medusa / Construir y publicar Medusa (push) Successful in 19m40s
Build and Push Frontend / Construir y Subir Imagen (push) Successful in 9m12s
- ENVIOCLICK_ORIGIN_DANE_CODE en configmap.yaml estaba cargado con el código DANE de Bogotá (11001000) por error; corregido a Santiago de Cali, Valle del Cauca (76001000). Toda cotización real de envío hecha antes de esta fecha se calculó desde el origen equivocado. - Corregido también el fallback stale en medusa-config.ts (originDaneCode) que seguía apuntando a Bogotá. - Actualizado el texto de /envios y /contacto (misma dirección física, Cra 100 #42-65, solo cambia la ciudad). - Footer: Instagram y Facebook reales enlazados (verificados en vivo contra los perfiles antes de linkear), y "Preguntas frecuentes" / "Cambios" ya apuntan a contenido real en vez de /catalog. - Nuevas páginas /cambios (5 días hábiles, envío de devolución a cargo de ARI Shopping) y /preguntas-frecuentes. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_012Y4df3Z7odr9Cg8F2nw6uV |
||
|
devopsandClaude Sonnet 5
|
c507da8abc |
feat(fulfillment): integrar EnvíoClick para cálculo real de envío
ADR 0009 §2 ya había anticipado esto: la shipping option actual es un placeholder de negocio ($15.000 COP fijo), no un cálculo real por peso/volumen -- y el modelo de direcciones del checkout (IDs DIVIPOLA en vez de texto libre en lib/data/colombia.ts) ya se había construido pensando en esta integración. Este commit la implementa. Investigación en vivo (no solo documentación -- misma disciplina que ya costó varios rehechos con las pasarelas de pago): la SPA de docs públicas (apidoc.envioclickpro.com.co) no renderiza sin sesión, pero está generada con apiDoc, así que se bajó y leyó directo su api_data.json/api_project.json (spec completa real), y se probó /quotation en vivo con la API key real del usuario -- 200 OK con tarifas reales de PIBOX/COORDINADORA/ENVIA/RAPPI/TCC. Esto corrigió varios datos mal asumidos de un plugin de WordPress desactualizado usado como referencia inicial (API v1): la URL base real es api.envioclickpro.com.co/api/v2 (no api.envioclickpro.com a secas), y el header de auth real es "Authorization" a secas, no "AuthorizationKey". Hallazgo crítico evitado leyendo el código fuente de @medusajs/utils/dist/common/define-config.js: defineConfig() ya registra por defecto un módulo de fulfillment con el provider manual_manual, aunque medusa-config.ts no lo mencione explícitamente -- pero transformModules() indexa por serviceName y el último que llega pisa al anterior (no mezcla providers). Agregar un bloque propio de fulfillment sin incluir también manual_manual ahí habría roto en silencio el envío manual que ya usa la shipping option existente. Verificado cargando la config compilada real: ambos providers quedan registrados juntos. - src/modules/envioclick-fulfillment/: AbstractFulfillmentProviderService. calculatePrice() cotiza en vivo durante el checkout -- Medusa advierte explícitamente que un error acá bloquea el checkout completo, así que NUNCA se deja propagar una excepción: cualquier falla (red, dirección sin id DIVIPOLA, EnvíoClick caído) cae al precio fijo de $15.000 que ya se usaba, para no romper la compra. createFulfillment() vuelve a cotizar en el momento de generar la guía real en vez de reusar el idRate mostrado en checkout (más correcto: CalculatedShippingOptionPrice no tiene forma de persistir ese id entre llamadas, confirmado leyendo el tipo real, y un idRate viejo podría estar vencido si el fulfillment pasa horas/días después). cancelFulfillment() sí cancela de verdad (cancellation/batch/order existe y está confirmado, a diferencia del refund de ePayco que quedó sin implementar). - Solo 1 paquete por cotización/guía (límite real de la API, confirmado: "min 1, max 1") -- el carrito se agrega a un solo paquete. Como hoy NINGÚN producto tiene peso/dimensiones cargados (confirmado en vivo: 18 productos activos, 0 con weight), se usa un paquete de fallback conservador completo en vez de mezclar datos reales con inventados a medias -- la cotización no va a ser precisa hasta que se carguen esos datos (tarea de datos, no de código, fuera de alcance de este commit). - Frontend: cambio chico pero necesario en checkout-client.tsx/ medusa-cart.ts -- el checkout mandaba el nombre de la ciudad a Medusa, nunca el id DIVIPOLA (aunque el form sí lo tenía disponible). Hay municipios con el mismo nombre en distintos departamentos de Colombia, así que el nombre solo no alcanza para identificar la ciudad sin ambigüedad -- se guarda el id real en la metadata de la dirección (Medusa sí tiene ese campo), que el fulfillment provider lee para derivar el código DANE real que pide EnvíoClick (5 dígitos + "000" de relleno, confirmado contra su propio ejemplo: "11001000" = Bogotá). Pendiente de verificar con una llamada real (no se quiso generar una guía de prueba en la cuenta real del usuario sin avisar): /shipment_sandbox y cancellation/batch/order, verificados contra la spec oficial real pero no probados en vivo todavía. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR |
||
|
devopsandClaude Sonnet 5
|
12c4afa09c |
fix(payments): reemplazar PayU LatAm por ePayco como pasarela PSE
PayU LatAm (integrado en el commit anterior) resultó inviable: Rapyd compró ese negocio completo en LatAm/África en 2023, y el registro real del usuario quedó en la plataforma de Rapyd (board.rapyd.net, credenciales access_key/secret_key incompatibles con el módulo ya construido, API completamente distinta). Se evaluó reconstruir contra Rapyd, pero el usuario comparó costos para su volumen real (~8 ventas/mes) y encontró que ePayco cobra menos en PSE. Se investigó ePayco en vivo: es 100% de Davivienda desde 2024, acepta liquidación a cualquier banco colombiano (no exige Bancolombia/Nequi como Wompi) y da tarifa preferencial a cuentas Davivienda -- el usuario ya tiene una. Mejor encaje de negocio y más barato que PayU/Rapyd. Confirmado como elección definitiva. - src/modules/epayco-pse/ reemplaza a src/modules/payu-pse/: mismo contrato AbstractPaymentProvider (initiatePayment/authorizePayment "pending_authorization"/getWebhookActionAndData con firma SHA256 verificada), pero envuelve el SDK oficial `epayco-sdk-node` en vez de llamar la API cruda -- leyendo el código fuente del SDK (no la documentación pública, que resultó desactualizada en más de un campo) se confirmó que el protocolo real de ePayco para PSE es bastante más particular de lo que sugieren los ejemplos: cada campo del payload se cifra con AES usando la private key del comercio, más un login previo que da un bearer token que también viaja en la misma request. Reimplementar esto a mano tenía mucho más riesgo de error que delegar en el SDK mantenido por el propio proveedor. - Corregido en el camino: el método real para listar bancos es `bank.getBanks()`, no `pseBank()` (así aparecía en un resumen de búsqueda, pero no existe en el SDK real -- confirmado leyendo node_modules/epayco-sdk-node/lib/resources/bank.js directamente). El campo real para la URL de confirmación es `method_confirmation` (con guión bajo en medio), no `metodoconfirmacion` como mostraba la documentación pública -- confirmado contra tests/bank.js del propio paquete. - retrievePayment sí se implementó esta vez (endpoint de validación de ePayco documentado); refundPayment sigue sin implementar -- ese endpoint no quedó verificado en vivo, tira error explícito en vez de fingir éxito. - Frontend: el step de pago recupera el selector de banco + tipo de persona + documento (a diferencia del diseño que se había planeado para Rapyd, donde esos datos se recolectaban en la página del propio Rapyd/SafetyPay) -- ePayco sí necesita esos campos de nuestro lado, como PayU. - Dos puntos quedan sin verificar contra un sandbox real (anotados en el código con qué hacer si fallan): el nombre exacto del campo con la URL del banco en la respuesta de bank.create() (initiatePayment tira un error con el payload completo si no matchea ningún candidato probado), y si p_cust_id_cliente/p_key del webhook son iguales a las API keys o valores aparte del dashboard de ePayco. Verificado: build real de Medusa con las 7 env vars EPAYCO_* dummy, smoke test del wrapper del SDK cargando y la verificación de firma dando el resultado esperado contra un caso conocido, typecheck+lint+ build completo del frontend. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR |
||
|
devopsandClaude Sonnet 5
|
2ceea23f40 |
feat(payments): integrar PayU LatAm (PSE) como pasarela de pagos
ADR 0009 ya había decidido PayU LatAm como proveedor (única opción que no exige cuenta Bancolombia/Nequi) y confirmado que no existe ningún plugin real de Medusa para su API -- los paquetes que aparecen buscando "PayU" son para PayU Polonia/CEE, API completamente distinta (clientId/posId/secondKey vs. apiLogin/apiKey/merchantId/accountId). Este commit implementa esa decisión: módulo de pago custom (AbstractPaymentProvider) para PSE (transferencia bancaria), primer alcance del método de pago -- Nequi/Daviplata quedan fuera por ahora. Backend (commerce-backend): - src/modules/payu-pse/: initiatePayment arma y postea SUBMIT_TRANSACTION contra la API real de PayU LatAm; authorizePayment devuelve "pending_authorization" (PSE es async, la confirmación real llega por webhook, no en el momento de completar el carrito); getWebhookActionAndData valida la firma MD5 del webhook antes de confiar en cualquier confirmación de pago -- falla cerrado si no matchea. refundPayment/ retrievePayment tiran error explícito en vez de simular éxito: esos endpoints de PayU no quedaron verificados en vivo y hay dinero real de por medio. - No hace falta un subscriber propio para completar la orden -- el subscriber nativo de Medusa (payment-webhook + process-payment-workflow) ya hace ese trabajo con los métodos de arriba bien implementados (confirmado leyendo el código fuente instalado de @medusajs/medusa 2.18.0, no la documentación). - Correlación webhook↔sesión: Medusa inyecta su propio session_id en `data` antes de initiatePayment; se usa ese mismo valor como referenceCode de PayU, así el reference_sale que vuelve en el webhook ya es directamente el session_id de Medusa. - src/lib/payu.ts: cliente HTTP + firmas (orden y webhook, fórmulas distintas, confirmadas contra el SDK PHP oficial de PayU). - src/api/store/payments/pse-banks/route.ts: lista de bancos PSE, cacheada en memoria. - medusa-config.ts, Dockerfile, configmap/secrets.template: 7 env vars nuevas (PAYU_API_LOGIN/API_KEY/MERCHANT_ID/ACCOUNT_ID/ENV/RESPONSE_URL/ NOTIFY_URL), dummies de build agregados, secrets con placeholder "CAMBIAR". Frontend (ecommerce): - Nuevo step "payment" en components/checkout/checkout-client.tsx (reemplaza al step "review" que solo ofrecía WhatsApp): selector de banco, tipo de persona (N/J), tipo/número de documento, botón "Pagar con PSE" que crea la sesión de pago, completa el carrito y redirige al banco (navegación completa, no iframe -- así lo exige PayU). WhatsApp queda como respaldo manual si falla la iniciación del pago. - lib/headless/providers/medusa-payment.ts + 3 rutas proxy nuevas bajo app/api/cart/, mismo patrón que el resto del carrito (medusaCartFetch, ahora exportado desde medusa-cart.ts). - app/checkout/pse/return/: página de vuelta del banco -- nunca afirma éxito, la confirmación real es el webhook async. Arranca contra las credenciales de sandbox genéricas y públicas de PayU (developers.payulatam.com) mientras el usuario termina su propio registro de comercio -- swap de las 4 credenciales via secret cuando estén listas, sin cambios de código. Verificado: build real de Medusa con las env vars dummy (no solo tsc), tipos de AbstractPaymentProvider/WebhookActionResult/PaymentActions confirmados contra @medusajs/utils y @medusajs/types instalados (node_modules limpiado después), typecheck + lint + build completo del frontend, páginas nuevas renderizando sin error. Pendiente: prueba end-to-end contra el sandbox real de PayU (necesita el backend desplegado) y habilitar el provider en la región Colombia desde el Admin. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR |
||
|
devops
|
fecac320d9 |
feat(commerce-backend): habilitar login con Google via Medusa auth module
Agrega el modulo @medusajs/medusa/auth con providers emailpass (explicito, para no perder el default al customizar el modulo) y google, leyendo GOOGLE_CLIENT_ID/GOOGLE_CLIENT_SECRET/GOOGLE_CALLBACK_URL desde commerce-secrets con required(). |
||
|
devops
|
e3eca46e0e |
Fase 2 fix: indexar precio crudo (variants.prices), no calculated_price
Encontrado en vivo (gate de verificacion de Fase 2): el job de sync inicial del plugin fallaba en TODOS los productos con "Method calculatePrices requires currency_code in the pricing context" -- variants.calculated_price necesita region_id/currency_code en el contexto de query.graph, que el workflow interno del plugin (sync-products.js) no provee. Las categorias si indexaron bien (21), solo productos fallaba, por eso numberOfDocuments quedaba en 0 pese a que el indice y sus settings se crearon correctamente. variants.prices (lista cruda, sin resolver promociones/reglas de precio) no requiere ese contexto y alcanza para el filtro/orden por precio de la busqueda -- no necesitamos el precio final promocional ahi, esa resolucion ya la hace la ruta /store/search via query.graph con el contexto real al re-hidratar los productos. |
||
|
devops
|
6be8dd409c |
Fase 2 ADR 0006 Etapa 2: plugin de Meilisearch + ruta de facetas
Instala @rokmohar/medusa-plugin-meilisearch@^1.4.1 (linea v1, la unica compatible con nuestro Medusa 2.18.0 exacto -- confirmado contra peerDependencies reales de npm: @medusajs/* ^2.15.2, satisfecho por 2.18.0). Conectado via un array `plugins:` nuevo en medusa-config.ts (primer uso en este repo, no `modules:`), env vars leidos con `?? ""` en vez de required() -- si Meilisearch esta caido o mal configurado, el plugin se degrada solo en vez de tumbar el arranque de Medusa entero. No se escribe un subscriber propio: se verifico contra el codigo fuente real del paquete (descargado el tarball exacto de npm, inspeccionado en /app/node_modules dentro de una imagen Docker de verdad) que trae sus propios subscribers de product/category/ collection/variant/etc, descubiertos por Medusa en runtime desde dentro del propio paquete -- confirmado que sobreviven a `npm prune --omit=dev` y llegan intactos a la imagen final. Tambien trae un job de indexado inicial de una sola corrida al boot (numberOfExecutions: 1, no un cron recurrente -- no viola la restriccion del ADR de "nunca cron"). Nueva ruta Store API propia (src/api/store/search/route.ts): las rutas /store/meilisearch/* que trae el plugin no devuelven facetDistribution (verificado leyendo su codigo fuente), asi que esta ruta pide facets explicitamente via additionalOptions.facets, y despues re-hidrata los productos via query.graph (mismos campos que ya usa el storefront) en vez de confiar en precios/inventario indexados -- mismo patron "safe path" que ya usa la ruta oficial del plugin para /store/meilisearch/products. Transformer custom en medusa-config.ts que espeja mapProduct() del storefront (category/collection/brand/ageRange desde metadata, disponibilidad desde la primera variante) para que el documento indexado sea exactamente lo que el storefront ya muestra. Validado en vivo: build completo de Docker (target builder) corre limpio -- npm ci, medusa build (typecheck + compile backend/frontend), npm prune -- cero errores. package-lock.json regenerado con un contenedor node:22.18.0-bookworm-slim real (mismo base image que el Dockerfile), no a mano. Dockerfile: dummy MEILISEARCH_HOST/MEILISEARCH_API_KEY en el stage de build (insurance barata, no son required() asi que no eran estrictamente necesarios para que el build pasara, y de hecho paso sin ellos en la prueba -- se dejan de todas formas por consistencia con el resto de dummies de esa capa). |
||
|
devops
|
c6cf394c26 |
fix: desactivar cookie Secure en sesion admin de Medusa
Todos los Ingress del lab terminan en Traefik por HTTP plano (entrypoint web, sin TLS); Cloudflare es quien atiende HTTPS de cara al navegador. Con secure:true (default en produccion), express-session nunca emite Set-Cookie porque no detecta la conexion como HTTPS, dejando el dashboard admin con 401 en /admin/users/me pese a loguear bien. |
||
|
devops
|
aa857bc2ae | fase 1 |