Draft PR created by @ogomezba #232

Cuidado porque en este PR no se tiene en cuenta la retrocompatibilidad.

Muy buenas. Comento aquí la propuesta de solución técnica para Prestashop @sofia-doofinder @brunovesar.

Instalación

En cuanto a la instalación respecta, Prestashop no mantiene stores durante reinstalaciones. Por lo que cada nueva instalación genera nuevas Stores y SEs. Si no decidimos cambiar esto, el único caso que debemos considerar una vez se despliegue la nueva versión es, por lo tanto, nuevas instalaciones.

Con la PR de dooplugins que ya hay preparada para acomodar la instalación de BigCommerce a los SE multiprice, la función install
acepta opctionalmente una lista de currencies. Si se especifica, el mapeo de la Installation de lenguaje-moneda -> SE no se realiza como clásicamente usando únicamente la lista de SE sino combinando los SE con las currencies especificadas. Esto permite crear un único SE por lenguaje pero mantener el mapeo en la Installation.

Por tanto, la solución que se plantea es:

• Modificar el código de instalación en el plugin de prestashop para que especifique un único SE por lenguaje
• Incluir una lista de currencies como parámetro adicional en la llamada a dooplugins
• No incluir en las feed_url de los SEs la currency

La sección a modificar sería:

Respecto a cómo recibir el parámetro "currencies" en el controller de dooplugins, se me plantean dos opciones, expongo pros y contras que veo de cada una:

1. Crear una ruta separada para este tipo de instalación:
   • Permite tener métricas y seguimiento de forma sencilla en Grafana ya que tenemos una ruta separada. Puede ser pro o contra, según se mire
   • Es más explícita la separación, quizá ayuda más a entender la separación del flujo
   • Obliga a modificar la URL para todos aquellos plugins que quieran hacer uso del flujo
2. Mantener la misma ruta y distinguir en base a la presencia del parámetro "currencies"
   • Métricas unificadas ya que todo corresponde al mismo flujo (instalación)
   • No es necesario modificar la URL para usar el flujo

Personalmente, creo que me convence más la opción dos.

En cuanto al campo multiprice_se_enabled que guardamos en las options de la store en BigCommerce, es bastante posible que el campo no sea necesario para Prestashop por cómo se ha planteado la solución. No obstante, creo que puede tener valor guardarlo para poder identificar con facilidad stores de este tipo, tanto para features futuras como para debugar/consultas a base de datos.

Guardado de hashids en base de datos de Prestashop cliente

Actualmente, immediatamente después de crear la tienda, el plugin guarda en la base de datos del cliente los hashids de los SE creados. Estos hashids se guardan con una key que depende del lenguaje y de la currency. Aunque para stores nuevas no sería necesario usar la currency porque todos los SE del mismo lenguaje tendrán el mismo hashid, creo que simplifica el flujo y la retrocompatibilidad si mantenemos este mapeo, aunque ES-EUR y ES-GBP, por ejemplo, guarden el mismo hashid en la base de datos del cliente. De esta forma, todo el código que depende de estos valores sería retrocompatible.

Indexación

El feed de Prestashop es un CSV generado por nuestro plugin. Para generarlo, hasta ahora se hacía uso del lenguaje y currency especificados en la URL del feed. Por lo tanto, tenemos el caso antiguo donde tendremos la currency en la URL del feed y el caso en el que no la tendremos. Las modificaciones que se proponen son:

• Incluir el cálculo del campo df_multiprice. Dicho campo se especificará siempre en el resultado del feed pero estará vacío si en la URL se ha recibido una currency (correspondería a SE viejos)
• En caso de que no se reciba una moneda, usar como "moneda" la moneda default de la tienda.

Con estos dos cambios, lo que conseguimos es rellenar el campo df_multiprice para feeds nuevos pero mantener siempre los campos price y sale_price como hasta ahora, bien con la moneda especificada en la URL para SE antiguos o con la moneda por defecto de la tienda para SE nuevos. De esta forma, tenemos una moneda que usar siempre en caso de que haya algún problema con el df_multiprice.

Con esto nos beneficiamos del comportamiento que ha descrito José aquí:

EJEMPLO

Feed Antiguo (currency=EUR, language=ES)

price (en EUR) | sale_price (en EUR) | df_multiprice
15.0 | 13.0 |

Feed Nuevo (language=ES, moneda por defecto de la tienda=GBP)

price (en GBP) | sale_price (en GBP) | df_multiprice
12.0 | 11.0 | {"EUR" : {"price" : 15.0, "sale_price"...,}, "GBP" : {"price" : 12.0, "sale_price"....}}

La misma lógica se aplicaría para la obtención de la información de los productos en el update_on_save.

Lo veo muy bien @ogomezba, sobre el punto de la instalación creo que también me gusta mas la opción 2, por no tener flujos demasiado diferentes e intentar que quede todo lo mas unificado posible.

Sobre el tema de reutilizar las stores o crear nuevas justo hoy hablando con Ignacio me ha dicho que el tema de reutilizar las tiendas es algo que deberíamos implementar en todos los plugins. Pero como no es algo que esté hecho ahora mismo y por no complicar mas esta issue podemos implementarlo en un segundo paso, o crees que merece la pena hacerlo junto a esto?

Tremendo plan! 👍
La 2 suena la mejor opcion, si queremos podemos incluir en algun log un metadata para diferenciarlas 🤔
Pero suena muy bien planteado, buen trabajo!

@sofia-doofinder Respecto lo de reutilizar tiendas, realmente tiene todo el sentido hacerlo. No obstante, quizá tenga sentido abordarlo de forma separada porque:

• No creo que realmente cambie mucho la solución de esta issue en función de cómo decidamos hacer la reutilización de stores
• Creo que la reutilizacion de stores es algo que deberíamos pensar bien para poder abordarlo de forma unificada (para el resto de plataformas que no la tienen). Con plataformas como BigCommerce, tenemos un store hash que podemos usar para identificar facilmente una Store existente en Doofinder. Habría que ver bien qué podemos usar para el resto de plataformas

Si quieres, puedo crear otra issue para esto.

genial @ogomezba pues si puedes crea issue.

Muchas gracias!

@sofia-doofinder @IgnacioPursalsZ @CristobalDolz Comento por aquí un par de cosas que he visto que creo que tendría sentido adaptar pero por confirmarlo con vosotros.

1. Para Stores nuevas con SEs multiprice, entiendo que habría que adaptar el nombre que seteamos ahora mismo para los SE porque la currency ya no tiene mucho sentido. Quizá misma estructura pero solamente con el lenguaje?
   

2. En Prestashop tenemos esta sección en la config que muestra las URL de los feeds. De nuevo, entiendo que no tiene sentido para stores nuevas mostrar las combinaciones porque ahora todas las URL de los feeds son iguales para un mismo lenguaje. Lo cambiamos y mostramos solamente un enlace por idioma?
   

a mi me parece que tiene sentido ajustar esas dos cosas, como lo ves @IgnacioPursalsZ?

Añado también otra pregunta @IgnacioPursalsZ @CristobalDolz.

Pongamos el caso de un Prestashop que tiene activada la opción de multistore. Cuando despleguemos los cambios y actualicen a la última versión del módulo de Doofinder, para las tiendas que ya tenía, todo seguirá funcionando como hasta el momento y no notará ningún cambio. Cada store tendrá un SE por cada pareja lenguaje-moneda.

Ahora bien, si crea una nueva tienda en Prestashop y sigue el wizard que tenemos actualmente, cómo debería ser la tienda que se cree en Doofinder? Para mí debería ser ya con los índices multimoneda, uno por lenguaje únicamente. Os encaja también a vosotros?

@sofia-doofinder @IgnacioPursalsZ @CristobalDolz Comento por aquí un par de cosas que he visto que creo que tendría sentido adaptar pero por confirmarlo con vosotros.

1. Para Stores nuevas con SEs multiprice, entiendo que habría que adaptar el nombre que seteamos ahora mismo para los SE porque la currency ya no tiene mucho sentido. Quizá misma estructura pero solamente con el lenguaje?
   
2. En Prestashop tenemos esta sección en la config que muestra las URL de los feeds. De nuevo, entiendo que no tiene sentido para stores nuevas mostrar las combinaciones porque ahora todas las URL de los feeds son iguales para un mismo lenguaje. Lo cambiamos y mostramos solamente un enlace por idioma?
   

@ogomezba

1. Si, creo que es válido lo mismo solo con el lenguaje.

2. correcto, esto tendriamos que cambiarlo tambien. Pero estamos ya con Prestashop? creia que aun estabamos con Bigcommerce

@CristobalDolz Hola Cristóbal! Gracias por la confirmación. Por nuestra parte tenemos todos los cambios preparados para BigCommerce pero sin desplegar ya que estamos a la espera de que el equipo de kappa termine su parte de los cambios para hacer pruebas conjuntas. De todas formas, como teníamos disponibilidad, hemos ido tirando con la adaptación de otro plugin (Prestashop en este caso).

Añado también otra pregunta @IgnacioPursalsZ @CristobalDolz.

Pongamos el caso de un Prestashop que tiene activada la opción de multistore. Cuando despleguemos los cambios y actualicen a la última versión del módulo de Doofinder, para las tiendas que ya tenía, todo seguirá funcionando como hasta el momento y no notará ningún cambio. Cada store tendrá un SE por cada pareja lenguaje-moneda.

Ahora bien, si crea una nueva tienda en Prestashop y sigue el wizard que tenemos actualmente, cómo debería ser la tienda que se cree en Doofinder? Para mí debería ser ya con los índices multimoneda, uno por lenguaje únicamente. Os encaja también a vosotros?

Tiene sentido que la nueva store ya funcione con los indices multi-moneda.

@CristobalDolz Hola Cristóbal! Gracias por la confirmación. Por nuestra parte tenemos todos los cambios preparados para BigCommerce pero sin desplegar ya que estamos a la espera de que el equipo de kappa termine su parte de los cambios para hacer pruebas conjuntas. De todas formas, como teníamos disponibilidad, hemos ido tirando con la adaptación de otro plugin (Prestashop en este caso).

Gracias @ogomezba.

Acordaros para Bigcommerce de incluirnos en las pruebas y todo lo demás antes de desplegar nada 😄

Por supuesto! Os avisamos para las pruebas.

Tal y como se ha hecho, con BigCommerce, empiezo a hacer pruebas integradas con la capa para ver que el desarrollo está okay. Actualizo después con lo que se ha probado y resultados.

Pruebas realizadas con Prestashop conjuntamente con los cambios de la capa:

Tiendas Antiguas (Retrocompatibilidad)

• Indexación general y búsqueda
• Update on save y búsqueda
• Redirección a productos
• Add to Cart
• Mostrado de lista de feeds

Nueva instalación con tienda Antigua anterior

• Indexación general y búsqueda
• Update on save y búsqueda
• Redirección a productos
• Add to Cart
• Multitienda
• Reinstalación
• Mostrado de lista de feeds

Tiendas Nuevas desde cero

• Indexación general y búsqueda
• Update on save y búsqueda
• Redirección a productos
• Add to Cart
• Multitienda
• Mostrado de lista de feeds

Tiendas Antiguas Multistore (Adición nueva tienda)

• Indexación general y búsqueda
• Update on save y búsqueda
• Redirección a productos
• Add to Cart
• Creación de una nueva store
• Mostrado de lista de feeds

NOTA: Para el caso de multistore, únicamente se han tenido en cuenta Prestashops que ya eran multistore en el momento de la instalación del plugin. Si un prestashop con el plugin instalado activa el modo de multistore, actualmente la funcionalidad de crear nuevas Stores en Doofinder no se activa (esto es independiente de multicurrency). Por ese motivo, ese caso de uso no se ha considerado.

genial @ogomezba, sobre lo de multistore después de la instalación igual habría que comentarlo con @IgnacioPursalsZ por si quiere darle una pensada por si hacemos cambios aquí, en otra tarea independiente me refiero.

Totalmente de acuerdo!

Muchas gracias @sofia-doofinder y @ogomezba , lo he anotado y crearemos una tarjeta más adelante para intentar mejorar y unificar lógicas entre plugins.

@alexsomet Buenas Alex! Como hemos comentado, tras realizar algunas pruebas he comprobado que multicurrency también funciona con un Prestashop con script viejo.