Multiboutique dans PrestaShop 9.2 : périmètre de configuration et des propriétés

Les tests multiboutiques échouent lorsque toutes les boutiques se ressemblent. Si deux boutiques partagent des réglages et des valeurs de test identiques, une écriture accidentelle dans le mauvais périmètre peut passer inaperçue. Les nouveaux travaux multiboutiques de la version 9.2 s’évaluent mieux avec des comportements volontairement différents selon la boutique.

Cet article se concentre sur les changements propres à la version dans les formulaires de configuration, la disponibilité des Extra Properties et la liste des règles de taxes. Il n’enseigne pas l’architecture générale des modules multiboutiques. Les exemples sont des vérifications RC1 proposées pour le 26 septembre 2026, à effectuer dans une installation de test jetable.

Pour les données gérées par les modules au-delà de ces changements, appliquez une délimitation explicite des données multiboutiques aux lectures, aux écritures, aux tâches planifiées et aux caches.

Administration et Paramètres des produits bénéficient d’une gestion multiboutique explicite

La modification intégrée à la version 9.2 pour Administration et Paramètres des produits ajoute une intégration de formulaire multiboutique et une gestion de configuration tenant compte du périmètre. Ses instructions de test dans le projet demandent des modifications dans une seule boutique et la vérification qu’elles restent dans la boutique sélectionnée. Modification des formulaires de configuration n° 41409.

Pour le marchand, l’intérêt est un contrôle plus clair du caractère local ou hérité d’un réglage. Sur le plan opérationnel, le personnel doit comprendre le contexte dans lequel il enregistre.

Commencez avec deux boutiques dans une structure de groupes connue. Choisissez un réglage sans conséquence que la page expose comme compatible multiboutique et documentez la valeur héritée avant toute modification. Ne présumez pas que tous les champs d’une page multiboutique ont la même sémantique de périmètre.

Utilisez les cases à cocher et les contrôles d’héritage réellement affichés par la candidate. Évitez de modifier manuellement les lignes de configuration pour simuler la fonctionnalité, car cela contourne précisément le comportement du formulaire évalué.

Une notification d’enregistrement réussi n’est que la première observation. Rouvrez la page dans chaque boutique et examinez le comportement en aval affecté par le réglage. La valeur doit rester correcte après une nouvelle requête.

Mener une expérience d’héritage avec une différence visible

Supposons que le réglage sélectionné soit hérité du contexte parent. Consignez cette base dans les deux boutiques. Dans la boutique A, créez une surcharge explicite via le formulaire. Laissez la boutique B en héritage.

Modifiez ensuite la valeur parente via l’interface prise en charge. La boutique B doit suivre les règles d’héritage applicables, tandis que la boutique A doit conserver sa surcharge explicite lorsque c’est le comportement documenté. Enfin, supprimez la surcharge de A via l’interface et vérifiez la valeur qu’elle hérite.

Cette séquence distingue une valeur héritée d’une valeur explicite qui se trouve simplement être égale. Ces états peuvent paraître identiques aujourd’hui mais se comporter différemment après un changement parent.

La documentation générale des formulaires multiboutiques de PrestaShop décrit les contrôles de sélection entre configuration locale et héritage, ainsi que des méthodes utilitaires appliquant des mises à jour respectant le périmètre. Utilisez-la pour interpréter l’interface, tandis que la PR 9.2 établit les pages qui ont reçu cette gestion. Formulaires de configuration multiboutique.

Consignez l’expérience dans un petit tableau :

Si un champ ne prend pas en charge un contexte particulier, consignez cette limitation plutôt que d’essayer de lui imposer le comportement idéalisé du tableau.

Vérifier les contrôles désactivés et leur signification en aval

La même PR de configuration traite un cas de Paramètres des produits impliquant les commandes hors stock lorsque la gestion des stocks est désactivée. Elle rappelle qu’un contrôle désactivé participe toujours à un processus de configuration et ne doit pas devenir accidentellement une valeur manquante invalide. Gestion des Paramètres des produits.

Pour un test propre à une boutique, capturez la configuration initiale de gestion des stocks et le comportement produit attendu. Modifiez le réglage pilote dans une boutique de test, enregistrez et rouvrez. Confirmez que la valeur effective du champ dépendant et le comportement de la boutique concordent.

Répétez dans la seconde boutique avec une configuration différente lorsque cela est pris en charge. Cela peut révéler un formulaire qui affiche l’état d’une boutique mais enregistre le repli d’une autre.

Évitez de conclure à partir de la seule apparence d’une entrée désactivée. La question métier est de savoir si la configuration obtenue est valide et s’applique à la boutique prévue. Les contrôles du navigateur peuvent être désactivés tandis que le serveur doit encore déterminer une valeur explicite.

Si votre module réagit à l’opération d’enregistrement, vérifiez que son effet métier se produit une seule fois et dans le bon contexte. Ne présumez pas qu’une amélioration d’un formulaire du cœur corrige automatiquement un code personnalisé qui lit une boutique par défaut ambiante.

Extra Properties ajoute un second type de décision liée à la boutique

Une valeur propre à une boutique et une définition restreinte à des boutiques sont deux choses différentes. La première répond à « quelle valeur cette boutique utilise-t-elle ? » La seconde répond à « ce champ est-il disponible dans cette boutique ? »

Les travaux RC de la version 9.2 incluent la restriction des définitions d’Extra Properties à une liste de boutiques. Utilisez cette modification pour évaluer les champs qui ne concernent qu’une partie d’une installation multiboutique. Restrictions des définitions n° 42490.

Imaginez une boutique de vente en gros qui nécessite un champ interne de revue du catalogue, contrairement à une boutique de détail. Vérifiez d’abord où le champ est présenté et accepté. Vérifiez ensuite le comportement de sa valeur dans le périmètre autorisé. Un champ masqué dans le formulaire de détail ne prouve pas, à lui seul, que tous les autres lecteurs respectent la disponibilité prévue.

Vérifiez indépendamment les formulaires, les grilles et les interfaces d’API activées. Incluez un produit partagé entre boutiques et un produit associé à une seule. Ces données de test distinguent les restrictions de définition de l’association d’entité et du périmètre de valeur.

Ne présumez pas que restreindre une définition supprime les anciennes valeurs ou réalise une migration de données. Si la liste des boutiques autorisées d’un champ change, examinez le cycle de vie documenté et testez ce qui reste dans un environnement jetable. Disponibilité et conservation sont des décisions distinctes.

Les grilles de règles de taxes nécessitent des contrôles de non-régression tenant compte des associations

Le journal des modifications de RC1 inclut une correction des entrées en double dans la grille des groupes de règles de taxes en contexte multiboutique. Il s’agit d’une correction ciblée de liste, et non d’une affirmation que les règles de calcul des taxes ont été repensées. Correction de la grille des règles de taxes n° 42245.

Pour évaluer la liste, créez ou utilisez un groupe synthétique associé aux boutiques pertinentes. Comparez les identifiants et les nombres de lignes dans les contextes d’une seule boutique et les contextes plus larges. Appliquez un filtre et passez d’une page à l’autre si le jeu de test est assez grand pour exercer la pagination.

L’assertion est que la grille représente les enregistrements logiques prévus sans doublons dus aux associations. Ne modifiez pas une vraie configuration fiscale pour produire un cas de test. Gardez les données isolées et restaurez-les ensuite.

Si une extension ajoute des jointures ou des colonnes à cette grille, comparez le comportement avec et sans elle. Une correction du cœur ne garantit pas qu’une jointure personnalisée ne puisse pas réintroduire des doublons.

Séparez les preuves sur la liste de celles sur le calcul des taxes. L’un peut être correct et l’autre erroné ; ils ne doivent pas partager un vague statut « taxes validées ».

Rendre le contexte de boutique visible dans les processus du personnel

Un formulaire multiboutique techniquement correct peut tout de même être mal utilisé si le personnel ne remarque pas le contexte sélectionné. Examinez le processus avec les employés qui entretiennent les réglages, et pas uniquement avec les développeurs.

Demandez à un testeur d’effectuer une modification locale, d’expliquer quelles boutiques doivent être affectées puis de vérifier la boutique cible et une boutique non ciblée. S’il ne peut pas prédire le périmètre, améliorez les consignes d’utilisation avant de vous fier à l’interface au quotidien.

Pour les tickets support, incluez la boutique ou le groupe sélectionné et indiquez si le champ était hérité. Sans ces détails, un échec apparent d’enregistrement peut en réalité être une mauvaise compréhension de la configuration effective.

Considérez également l’administration simultanée. Deux employés modifiant les valeurs parentes et locales peuvent créer un résultat surprenant même si chaque enregistrement est valide. Utilisez les journaux d’audit ou de modifications disponibles dans votre déploiement pour reconstituer la séquence ; ne présumez pas qu’un ancien formulaire ouvert reflète encore l’état hérité actuel.

Séparer les surcharges locales des réglages copiés

Lors de la préparation des données de test, ne créez pas la boutique B en copiant aveuglément toutes les valeurs effectives de la boutique A dans sa configuration locale. Cela peut supprimer l’état d’héritage que le test doit exercer. Établissez la valeur parente, puis créez uniquement les surcharges locales requises par le scénario via le formulaire pris en charge.

Un exercice utile pour le personnel consiste à prédire l’effet d’une modification parente avant de l’appliquer. Demandez quelles boutiques doivent changer et lesquelles doivent conserver une valeur locale. Comparez la prédiction aux formulaires rouverts et au comportement en aval.

Si le résultat diffère, examinez d’abord l’état de surcharge stocké et le contexte sélectionné. Une valeur qui semble inchangée peut être une surcharge locale intentionnelle plutôt qu’un échec d’enregistrement. Inversement, une boutique non ciblée modifiée peut indiquer une écriture trop large et mérite une enquête immédiate.

Conservez ces preuves avec les cas propres à la version. Elles expliquent si le nouveau comportement du formulaire fonctionne correctement et si la procédure rend son périmètre clair pour le personnel. Les deux sont nécessaires à une administration quotidienne fiable.

Pour un environnement de préproduction partagé, annoncez les expériences qui modifient le contexte selon le processus habituel de coordination de l’équipe afin qu’un autre testeur n’enregistre pas un ancien formulaire face à un état parent modifié.

Définir l’acceptation par l’isolation et les valeurs effectives

Une bonne fiche d’acceptation multiboutique 9.2 nomme la page concernée, le champ, le contexte sélectionné, l’état d’héritage et la valeur effective obtenue. Pour Extra Properties, ajoutez la disponibilité de la définition et l’association de l’entité. Pour les grilles, conservez les identifiants et décomptes attendus.

L’assertion négative critique est qu’une boutique non ciblée reste inchangée. Cela doit être observé, et non déduit du message de succès de la boutique actuelle.

Ces changements rendent certaines parties de la version 9.2 intéressantes à examiner pour les opérateurs multiboutiques. Testez-les avec des valeurs distinctes et un contexte explicite, et gardez la propriété générale des données des modules personnalisés comme une question d’ingénierie séparée.

Pour le contexte de la plateforme sous-jacente, consultez notre guide de développement de modules PrestaShop 9 et appliquez les vérifications propres à chaque version ci-dessus à l’installation que vous évaluez.