search

Departamento-TI / cenabast-tienda

BSD 3-Clause "New" or "Revised" License
2 stars 0 forks source link

Revisión de la Configuración Inicial #47

Closed nmella closed 6 months ago

nmella commented 7 months ago

Hola @Saulaccid

Hoy revisamos los aspectos funcionales de la configuración inicial. Nos quedaron las siguientes dudas:

Eso por ahora, gracias !

Queda pendiente probar el comportamiento cambiando las asociaciones de los organismos a los usuarios en las respuestas de la API.

cc: @LeonardoSantis-AcidLabs, @GloriaVenegas2024, @Claudioten

LeonardoSantis-AcidLabs commented 7 months ago

Hola Nicolas, Muchas gracias por la revisión. Voy respondiendo a los comentarios

La versión de elasticsearch es antigua (7.10 es del 2021). ¿Será posible instalar la última versión? (8.12). Por ahora sólo es relevante el motor de ES, y no es necesario instalar Kibana.

Se trabajó con la ultima versión disponible de elasticsearch-oss, la cual tiene el modelo de licenciamiento libre. Tuve algunos problemas al instalar la 8+. Estaré revisando este cambio posible junto con @Saulaccid.

No funciona la sección por de defecto de "My Account" para los usuarios compradores. Idealmente debería quedar tal como funciona por defecto para que los usuarios puedan revisar su historial de pedidos. (2024-03-04_16-10)

De momento el botón es un mockup de cuando estuve trabajando en el header. Podemos ligar esto con la pagina de mis ordenes nativa de Spree.

El "logout" no está funcionando correctamente. Si bien al hacer click vuelve a la pagina de login con el mensaje "Signed out successfully.", al recargar la página o intentar logear nuevamente me redirige al sitio con el usuario previamente autentificado. Luego no se puede cambiar de usuario (logout-test). Entiendo que para desloggear en Keycloak, habría que hacer un llamado a este endpoint.

No hemos trabajado en el logout propiamente tal, pero entiendo que tenemos que llamar al endpoint correspondiente. Lo estarémos realizando prontamente.

No se puede cambiar el organismo "Solicitante". El ingresar con el usuario "88.888.888-8", por defecto carga el organismo solicitante "HOSPITAL SALVADOR". Se intenta cambiar por el organimos "INST.DE NEUROCIRUGIA" pero no es posible. Se espera que al selecionar una nuevo organismo "Solitante", este quede visible. (2024-03-04_16-06)

No he logrado replicar ese problema, ingreso con el RUN 88.888.888-8 y puedo cambiar el organismo Solicitante de esa forma. Alternando entre los dos disponibles. El resultado se actualiza en la vista:

https://github.com/Departamento-TI/cenabast-tienda/assets/156705333/5d745527-cff6-43c6-b88e-2032aa99497e (No se si Github soporta adjuntar videos, estaré enviando esto tambien por Slack)

No se puede logear con el usuario proveedor "55.555.555-5". Posiblemente porque el RUT del usuario también es un usuario comprador ya que arroja error "Validation failed: Email has already been taken". (log-del-error). Queda pendiente validar si existe este escenario o no con el equipo de negocio. Lo que sí creo relevante considerar, es que el email podría repetirse en distintos RUTs (Distintos RUTs de personas utilizan el mismo correo institucional => contacto@hospitaldetalca.cl), luego idealmente el "email" no debería ser único, sólo el RUT.

Tiene sentido, por defecto el email tiene validación de tipo unico para Spree. Haremos los cambios para que esto no suceda.

No pude probar el envio de los emails. Configuré el email "hola@patagon.dev" en la seccion de la tienda (email-config) y luego reenvié un pedido. Revise en los logs, y no encontré nada raro. También en sidekiq aparece que el job fue procesado correctamente. ¿Que puede estar pasando? Estos son los valores del archivo ENV.

Las variables de entorno se ven correctas, y similares a las que utilicé para realizar las pruebas. A que correo le corresponde esa orden? Por defecto el confirm_email del Spree::OrderMailer enviará los correos al correo asociado a la orden (esto es, @order.email), el cual dependerá del usuario que realizó la orden.

Tampoco pude probar el almacenamiento de las imagenes en S3. Subí una imagen de un producto, pero me trata de cargar desde "localhost:4000" a pesar que en la configuración está como "tienda-dev.cenabast.gob.cl". Estos son los valores del archivo ENV. ¿Que podrá estar faltando en la configuracíón ?

Las variable de entorno son correctas, lo que sucede es que estamos usando el modo proxy de ActiveStorage. Esto implica que al momento de servir las imagenes en el sitio, el framework crea una URL intermedia, la cual descarga los assets y los sirve desde ahí:

Desde la consola de Rails, puedes hacer la siguiente consulta ActiveStorage::Attachment.last.blob.url para consultar del ultimo adjunto subido, cual es la URL original de la cual se cargan los datos: "https://patagon-labs.s3.amazonaws.com/v7ev3aykq7u1a06cmly14cioy6io"

Puedes revisar el bucket en S3 y deberías poder ver el archivo adjunto con esa key Luego utilizando:

Rails.application.routes.url_helpers.rails_storage_proxy_url(ActiveStorage::Attachment.last)

puedes ver como se transforma el dato a una url proxy, tipo: "http://localhost:4000/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBEQT09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--ac0cc5b14c331b6638d235489b7a6921d4c73b1a/Fondo%20Acid%201.jpg"

Esta configuración la podemos cambiar a modo Redirect, para generar URLs intermedias que redirigen a la URL de servicio final (S3).

https://guides.rubyonrails.org/configuring.html#config-active-storage-resolve-model-to-route

nmella commented 7 months ago

Buenísimo, gracias @LeonardoSantis-AcidLabs Se entiende perfecto.

Si sirve, yo probé ES 8 con esto y me funcionó ok agregándolo al docker-compose:

elasticsearch:
    image: elasticsearch:8.12.2
    ports:
     - "9200:9200"
    environment:
      - node.name=elasticsearch
      - discovery.type=single-node
      - network.host=0.0.0.0
      - xpack.security.enabled=false
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - ELASTIC_PASSWORD=$ELASTIC_PASSWORD
    volumes:
      - 'elasticsearch-data:/usr/share/elasticsearch/data'

A que correo le corresponde esa orden? Por defecto el confirm_email del Spree::OrderMailer enviará los correos al correo asociado a la orden (esto es, @order.email), el cual dependerá del usuario que realizó la orden.

Cambié el email del pedido que viene por defecto y puse mi email. Y revisando el log, aparece mi email como destinatario. Ni idea que puede ser 🤔.

Ok, probé lo del bucket y sí, me aparece perfecto que se subió al bucket. Aun así no se ve la imagen en el panel. ¿Que puede ser?

No se puede cambiar el organismo "Solicitante". El ingresar con el usuario "88.888.888-8", por defecto carga el organismo solicitante "HOSPITAL SALVADOR". Se intenta cambiar por el organimos "INST.DE NEUROCIRUGIA" pero no es posible. Se espera que al selecionar una nuevo organismo "Solitante", este quede visible. (2024-03-04_16-06)

Tengo este error en el navegador...¿Sabes que puede ser? (2024-03-05_13-02)

LeonardoSantis-AcidLabs commented 7 months ago

Buenas tardes Nicolas,

Gracias por la ayuda con lo de Elastic, ya con eso que me enviaste lo pude instalar bien y sin problemas. Estaré subiendo un parche con eso y otras mejoras producto de la revisión.

Voy contestando a las dudas:

Cambié el email del pedido que viene por defecto y puse mi email. Y revisando el log, aparece mi email como destinatario. Ni idea que puede ser 🤔.

En mi caso esta es la configuración que utilicé:

Al utilizar la opción de reenvio, llega este correo a mi casilla de entrada: Correo Vale destacar que el correo llegó en mi casilla de "Updates" en Gmail. Quizás en tu caso llegó a una casilla secundaria, o fue marcado como spam por tu casilla de correos. Valdría la pena revisar 🤔

Ok, probé lo del bucket y sí, me aparece perfecto que se subió al bucket. Aun así no se ve la imagen en el panel. ¿Que puede ser?

En mi caso funciona así:

Tendrás el log de la aplicación a mano? cuando se le hace la solicitud a la url proxy, se deberían ver entradas de este estilo: Logs de aplicación

Tengo este error en el navegador...¿Sabes que puede ser? (2024-03-05_13-02)

Favor adjuntar el output de la llamada al endpoint /api_tokens. Me suena que está retornando una excepción no controlada, cuando debería ser una respuesta JSON. En mi caso, devuelve esto: Resuesta JSON /api_tokens

nmella commented 7 months ago

Gracias @LeonardoSantis-AcidLabs. Los actualizo con las últimas pruebas que hice recién.

Funcionó OK el tema de las imagenes del storage. Nos había faltado agregar una variable de entorno. Si bien el email no llega, es porque el puerto 587 está bloqueado en el servidor...asi que al abrirlo debería quedar resuelto.

Eso por ahora. Gracias.

nmella commented 7 months ago

Gracias. Ya pudimos validar todos los puntos en el ambiente local. Todavía tenemos que resolver el problema en nuestro ambiente de desarrollo.

nmella commented 7 months ago

Hola @LeonardoSantis-AcidLabs

Nuestro sysadmin revisó nuestro ambiente de desarrollo y encontró que la aplicación se comporta distinto debido a que el Spree Frontend está utilizando el caché del navegador, y por eso no llega el request al servidor.

Me dice que en el controlador del homepage existe está validación por el valor del http_cache_enabled que por defecto estaba como true, aunque hace unos días está este PR justamente para dejarlo como false.

Así que por favor podemos dejar el valor por defecto del atributo http_cache_enabled en "false" ?

Gracias !

cc: @Claudioten

LeonardoSantis-AcidLabs commented 7 months ago

Hola buenos dias,

Acabo de mergear un pull request que agrega un inicializador, dejando el valor de http_cache_enabled como false. https://github.com/Departamento-TI/cenabast-tienda/pull/62

Quedo atento si necesitan mas cambios.

Saludos!

nmella commented 7 months ago

Gracias @LeonardoSantis-AcidLabs

Lo probé y sigue sin funcionar en el ambiente de desarrollo. 😭

Le dije a nuestro contacto interno que no funcionaba, y me respondió lo siguiente. ¿Quizás te sirve ?

Hi Nicolas, I checked this again and find out few things -

  1. When we are changing the drodowns, its TURBO STREAM request and we are responding with the redirect, one option to fix this will be to respond with updated turbo frame.
  2. Spree cache the entire header with the spree_menu_cache_key(https://github.com/spree/spree_rails_frontend/blob/main/app/helpers/spree/navigation_helper.rb#L34), and our dropdowns are in this header, so its always being served from cache entire expired.

So, we either need to update this helper method to implement logic, or move out our header component code from this cache block or implement turbo frame solution.

Here is video made explaining the issue - https://www.awesomescreenshot.com/video/25830223?key=6a0fc421d683282d289aa901b586cdc0

Gracias !

cc: @Claudioten

ncmella commented 7 months ago

@LeonardoSantis-AcidLabs

A todo esto, creo que no lo mencioné, pero funciona perfecto cuando seleccionó la opción de disable cache en el tab de "Network" del navegador. (imagen)

El problema sigue siendo en el header al cambiar de organismo Solicitante, o haciendo logout/login con distintos usuarios.

Gracias.

LeonardoSantis-AcidLabs commented 7 months ago

Hola @nmella muy buenas tardes,

Con ayuda del video de Rahul, logré replicar el problema con mi local al activar el cache y hice un fix en base a las sugerencias. Así mismo, tambien logré replicar el otro problema que teniamos (visitante se logea, dropdowns aparecen en blanco). Tambien agregué en ese PR un fix para ese defecto:

https://github.com/Departamento-TI/cenabast-tienda/pull/66

Quedo atento 🙌