Multitienda de PrestaShop 9.2: alcance de configuración y propiedades

Las pruebas multitienda fallan cuando todas las tiendas parecen iguales. Si dos tiendas comparten ajustes y valores de prueba idénticos, una escritura accidental con el alcance equivocado puede pasar inadvertida. El nuevo trabajo multitienda de la versión 9.2 se evalúa mejor con comportamientos deliberadamente distintos por tienda.

Este artículo se centra en cambios específicos de la versión en formularios de configuración, disponibilidad de Extra Properties y listas de reglas fiscales. No enseña la arquitectura general de módulos multitienda. Los ejemplos son comprobaciones propuestas para RC1 a fecha de 26 de septiembre de 2026 y corresponden a una instalación de pruebas desechable.

Para los datos gestionados por módulos más allá de estos cambios de versión, aplique un alcance explícito de datos multitienda a lecturas, escrituras, trabajos programados y cachés.

Administración y Ajustes de productos incorporan una gestión multitienda explícita

El cambio integrado en la versión 9.2 para Administración y Ajustes de productos añade integración de formularios multitienda y gestión de configuración consciente del alcance. Sus instrucciones de prueba en el proyecto piden editar en una sola tienda y comprobar que los cambios permanecen en la tienda seleccionada. Cambio de formularios de configuración n.º 41409.

Para el comerciante, supone un control más claro de si un ajuste pertenece a una tienda seleccionada o se hereda. Operativamente, el personal debe entender el contexto en el que guarda.

Empiece con dos tiendas en una estructura de grupos conocida. Elija un ajuste inocuo que la página exponga como consciente de multitienda y documente el valor heredado antes de cambiar nada. No suponga que todos los campos de una página multitienda tienen la misma semántica de alcance.

Use las casillas y controles de herencia reales que muestra la candidata. Evite cambiar manualmente filas de configuración para simular la función, porque eso elude precisamente el comportamiento de formulario que se está evaluando.

Una notificación de guardado correcto es solo la primera observación. Vuelva a abrir la página en cada tienda e inspeccione el comportamiento posterior afectado por el ajuste. El valor debe seguir siendo correcto después de una solicitud nueva.

Realizar un experimento de herencia con una diferencia visible

Suponga que el ajuste seleccionado se hereda del contexto superior. Registre esa base en ambas tiendas. En la tienda A, cree una sobrescritura explícita mediante el formulario. Deje la tienda B con herencia.

Ahora cambie el valor superior mediante la interfaz compatible. La tienda B debe seguir las reglas de herencia aplicables, mientras que la tienda A debe conservar su sobrescritura explícita cuando ese sea el comportamiento documentado. Por último, elimine la sobrescritura de A mediante la interfaz y verifique el valor que hereda.

Esta secuencia distingue un valor heredado de uno explícito que casualmente sea igual. Esos estados pueden parecer idénticos hoy pero comportarse de forma distinta después de un cambio superior.

La documentación general de formularios multitienda de PrestaShop describe controles para elegir configuración local frente a herencia y métodos auxiliares que aplican actualizaciones según el alcance. Úsela para interpretar la interfaz, mientras que la PR de la versión 9.2 establece qué páginas incorporaron esa gestión. Formularios de configuración multitienda.

Registre el experimento en una pequeña tabla:

Si un campo no admite un contexto concreto, registre esa limitación en vez de intentar imponerle el comportamiento idealizado de la tabla.

Comprobar los controles deshabilitados y su significado posterior

La misma PR de configuración aborda un caso de Ajustes de productos relacionado con los pedidos sin stock cuando la gestión de stock está deshabilitada. Recuerda que un control deshabilitado sigue participando en un flujo de configuración y no debe convertirse accidentalmente en un valor ausente no válido. Gestión de Ajustes de productos.

Para un test específico de tienda, capture la configuración inicial de gestión de stock y el comportamiento de producto esperado. Cambie el ajuste de control en una tienda de pruebas, guarde y vuelva a abrir. Confirme que el valor efectivo del campo dependiente y el comportamiento de la tienda coinciden.

Repita en la segunda tienda con una configuración diferente cuando se admita. Esto puede revelar un formulario que muestra el estado de una tienda pero guarda el valor de respaldo de otra.

Evite sacar conclusiones solo por el aspecto de una entrada deshabilitada. La cuestión de negocio es si la configuración resultante es válida y se aplica a la tienda prevista. Los controles del navegador pueden estar deshabilitados mientras el servidor sigue necesitando derivar un valor explícito.

Si su módulo reacciona al guardado, verifique que su efecto de negocio se produce una vez y en el contexto correcto. No suponga que una mejora de formulario del núcleo corrige automáticamente código personalizado que lee una tienda predeterminada del contexto general.

Extra Properties añade un segundo tipo de decisión de tienda

Un valor específico de tienda y una definición restringida a tiendas son cosas diferentes. El primero responde a «¿qué valor usa esta tienda?». La segunda responde a «¿está disponible este campo en esta tienda?».

El trabajo RC de la versión 9.2 incluye restringir definiciones de Extra Properties a una lista de tiendas. Use ese cambio para evaluar campos pertinentes solo para parte de una instalación multitienda. Restricciones de definiciones n.º 42490.

Imagine una tienda mayorista que necesita un campo interno de revisión del catálogo y una tienda minorista que no lo necesita. Verifique primero dónde se presenta y acepta el campo. Después verifique el comportamiento de su valor dentro del alcance permitido. Un campo oculto en el formulario minorista no demuestra por sí solo que todos los demás lectores respeten la disponibilidad prevista.

Compruebe de forma independiente los formularios, cuadrículas e interfaces API habilitadas. Incluya un producto compartido entre tiendas y otro asociado solo a una. Estos datos de prueba distinguen las restricciones de definiciones de la asociación de entidades y del alcance del valor.

No suponga que restringir una definición elimina valores antiguos o realiza una migración de datos. Si cambia la lista de tiendas permitidas de un campo, inspeccione el ciclo de vida documentado y pruebe qué permanece en un entorno desechable. Disponibilidad y conservación son decisiones separadas.

Las cuadrículas de reglas fiscales necesitan comprobaciones de regresión conscientes de asociaciones

El registro de cambios de RC1 incluye una corrección de entradas duplicadas de grupos de reglas fiscales en la cuadrícula en contexto multitienda. Es una corrección limitada de lista, no una afirmación de que se hayan rediseñado las reglas de cálculo de impuestos. Corrección de cuadrícula de reglas fiscales n.º 42245.

Para evaluar la lista, cree o use un grupo sintético asociado con las tiendas pertinentes. Compare los identificadores y números de filas en contextos de una tienda y en contextos más amplios. Aplique un filtro y cambie de página si el conjunto de prueba es lo bastante grande para probar la paginación.

La comprobación es que la cuadrícula representa los registros lógicos previstos sin duplicados provocados por asociaciones. No cambie una configuración fiscal real para producir un caso de prueba. Mantenga aislados los datos y restáurelos después.

Si una extensión añade uniones o columnas a esa cuadrícula, compare el comportamiento con y sin ella. Una corrección del núcleo no garantiza que una unión personalizada no pueda reintroducir duplicados.

Mantenga separadas las pruebas de listas y de cálculo fiscal. Una puede ser correcta y la otra incorrecta, y no deben compartir un estado vago de «impuestos aprobados».

Hacer visible el contexto de tienda en los flujos del personal

Un formulario multitienda técnicamente correcto puede usarse mal si el personal pasa por alto el contexto seleccionado. Revise el flujo con los empleados que mantienen los ajustes, no solo con los desarrolladores.

Pida a un tester que haga un cambio local, explique qué tiendas deberían verse afectadas y después verifique tanto la tienda objetivo como una no objetivo. Si no puede predecir el alcance, mejore las instrucciones operativas antes de confiar en la interfaz para el trabajo habitual.

En los tickets de soporte, incluya la tienda o grupo seleccionado y si el campo se heredaba. Sin esos detalles, un fallo aparente de guardado puede ser en realidad un malentendido de la configuración efectiva.

Considere también la administración concurrente. Dos empleados que cambien valores superiores y locales pueden crear un resultado sorprendente aunque cada guardado sea válido. Use los registros de auditoría o cambios disponibles en su despliegue para reconstruir la secuencia; no suponga que un formulario antiguo abierto sigue reflejando el estado heredado actual.

Separar sobrescrituras locales de ajustes copiados

Al preparar datos de prueba, no cree la tienda B copiando a ciegas todos los valores efectivos de la tienda A en la configuración local. Eso puede eliminar el estado de herencia que el test pretende probar. Establezca el valor superior y cree después solo las sobrescrituras locales necesarias para el escenario mediante el formulario compatible.

Un ejercicio útil para el personal es predecir el efecto de un cambio superior antes de aplicarlo. Pregunte qué tiendas deberían cambiar y cuáles conservar un valor local. Compare la predicción con los formularios reabiertos y el comportamiento posterior.

Si el resultado difiere, inspeccione primero el estado de sobrescritura guardado y el contexto seleccionado. Un valor que parece no cambiar puede ser una sobrescritura local intencionada y no un fallo de guardado. A la inversa, un cambio en una tienda no objetivo puede indicar una escritura demasiado amplia y merece investigación inmediata.

Conserve estas pruebas junto a los casos específicos de la versión. Explican si el nuevo comportamiento del formulario funciona correctamente y si el procedimiento operativo deja claro su alcance al personal. Ambos son necesarios para una administración diaria fiable.

En un entorno de pruebas compartido, anuncie los experimentos que cambien el contexto mediante el proceso habitual de coordinación del equipo para que otro tester no guarde un formulario antiguo frente a un estado superior modificado.

Definir la aceptación mediante aislamiento y valores efectivos

Un buen registro de aceptación multitienda de la versión 9.2 nombra la página afectada, el campo, el contexto seleccionado, el estado de herencia y el valor efectivo resultante. Para Extra Properties, añada disponibilidad de la definición y asociación de entidad. Para las cuadrículas, conserve identificadores y recuentos esperados.

La comprobación negativa crítica es que una tienda no objetivo permanezca igual. Esto debe observarse, no deducirse del mensaje de éxito de la tienda actual.

Estos cambios hacen que partes específicas de la versión 9.2 merezcan revisión para los operadores multitienda. Pruébelas con valores distintos y contexto explícito, y mantenga la propiedad general de datos de módulos personalizados como una cuestión de ingeniería separada.

Para conocer el contexto de la plataforma subyacente, consulte nuestra guía de desarrollo de módulos PrestaShop 9 y aplique las comprobaciones específicas de versión anteriores a la instalación que esté evaluando.