Wiele sklepów w PrestaShop 9.2: zakres konfiguracji i właściwości

Testowanie konfiguracji wielosklepowej zawodzi, gdy każdy sklep wygląda tak samo. Jeśli dwa sklepy mają identyczne ustawienia i wartości testowe, przypadkowy zapis w złym zakresie może pozostać niezauważony. Nowe prace wielosklepowe wersji 9.2 najlepiej oceniać przy celowo różnym zachowaniu sklepów.

Ten artykuł skupia się na zmianach właściwych dla wydania w formularzach konfiguracji, dostępności Extra Properties i listach reguł podatkowych. Nie uczy ogólnej architektury modułów wielosklepowych. Przykłady to proponowane kontrole RC1 na 26 września 2026 r., przeznaczone do jednorazowej instalacji testowej.

Dla danych należących do modułu poza tymi zmianami wydania stosuj jawne ograniczenie zakresu danych wielosklepowych do odczytów, zapisów, zaplanowanej pracy i pamięci podręcznych.

Administracja i Ustawienia produktów zyskują jawną obsługę wielu sklepów

Scalona zmiana wersji 9.2 dla Administracji i Ustawień produktów dodaje integrację formularzy wielosklepowych oraz obsługę konfiguracji uwzględniającą zakres. Jej instrukcje testowe w projekcie przewidują edycję w pojedynczym sklepie i sprawdzenie, czy zmiany pozostają w wybranym sklepie. Zmiana formularzy konfiguracji nr 41409.

Znaczenie dla sprzedawcy to wyraźniejsza kontrola nad tym, czy ustawienie należy do wybranego sklepu, czy jest dziedziczone. Znaczenie operacyjne polega na tym, że pracownicy muszą rozumieć kontekst zapisu.

Zacznij od dwóch sklepów w znanej strukturze grup. Wybierz nieszkodliwe ustawienie, które strona udostępnia jako świadome wielu sklepów, i udokumentuj odziedziczoną wartość przed zmianami. Nie zakładaj, że każde pole na stronie wielosklepowej ma tę samą semantykę zakresu.

Używaj rzeczywistych pól wyboru i kontrolek dziedziczenia wyświetlanych przez wersję kandydującą. Unikaj ręcznej zmiany wierszy konfiguracji w celu zasymulowania funkcji, ponieważ omija to właśnie oceniane zachowanie formularza.

Powiadomienie o udanym zapisie jest tylko pierwszą obserwacją. Otwórz stronę ponownie w każdym sklepie i sprawdź dalsze zachowanie zależne od ustawienia. Wartość powinna pozostać prawidłowa po nowym żądaniu.

Przeprowadź eksperyment dziedziczenia z widoczną różnicą

Załóżmy, że wybrane ustawienie jest dziedziczone z kontekstu nadrzędnego. Zapisz tę bazę w obu sklepach. W sklepie A utwórz jawne nadpisanie przez formularz. Pozostaw sklep B przy dziedziczeniu.

Teraz zmień wartość nadrzędną przez obsługiwany interfejs. Sklep B powinien stosować właściwe reguły dziedziczenia, podczas gdy sklep A powinien zachować jawne nadpisanie tam, gdzie jest to udokumentowane zachowanie. Na końcu usuń nadpisanie A przez interfejs i sprawdź odziedziczoną wartość.

Ta sekwencja odróżnia wartość dziedziczoną od jawnej wartości, która tylko przypadkowo jest równa. Te stany mogą dziś wyglądać identycznie, lecz zachować się różnie po zmianie nadrzędnej.

Ogólna dokumentacja formularzy wielosklepowych PrestaShop opisuje kontrolki wyboru konfiguracji lokalnej lub dziedziczenia oraz metody pomocnicze stosujące aktualizacje uwzględniające zakres. Używaj jej do interpretacji interfejsu, podczas gdy PR wersji 9.2 określa strony, które otrzymały tę obsługę. Formularze konfiguracji wielosklepowej.

Zapisz eksperyment w małej tabeli:

Jeśli pole nie obsługuje konkretnego kontekstu, zapisz to ograniczenie zamiast wymuszać na nim wyidealizowane zachowanie tabeli.

Sprawdź wyłączone kontrolki i ich dalsze znaczenie

Ten sam PR konfiguracji rozwiązuje przypadek Ustawień produktów dotyczący zamawiania produktów bez zapasu przy wyłączonym zarządzaniu stanami magazynowymi. Przypomina to, że wyłączona kontrolka nadal uczestniczy w procesie konfiguracji i nie może przypadkowo stać się nieprawidłową brakującą wartością. Obsługa Ustawień produktów.

Dla testu konkretnego sklepu zapisz początkową konfigurację zarządzania zapasami i oczekiwane zachowanie produktu. Zmień ustawienie sterujące w sklepie testowym, zapisz i otwórz ponownie. Potwierdź zgodność efektywnej wartości pola zależnego z zachowaniem witryny sklepu.

Powtórz w drugim sklepie z inną konfiguracją, jeśli jest obsługiwana. Może to ujawnić formularz wyświetlający stan jednego sklepu, lecz zapisujący wartość zastępczą drugiego.

Unikaj wnioskowania wyłącznie z wyglądu wyłączonego pola. Pytanie biznesowe brzmi, czy wynikowa konfiguracja jest prawidłowa i dotyczy zamierzonego sklepu. Kontrolki przeglądarki mogą być wyłączone, podczas gdy serwer nadal musi wyprowadzić jawną wartość.

Jeśli moduł reaguje na zapis, sprawdź, czy jego skutek biznesowy występuje raz i we właściwym kontekście. Nie zakładaj, że usprawnienie formularza rdzenia automatycznie naprawia niestandardowy kod odczytujący domyślny sklep z otaczającego kontekstu.

Extra Properties dodaje drugi rodzaj decyzji dotyczącej sklepu

Wartość właściwa dla sklepu i definicja ograniczona do sklepów to różne rzeczy. Pierwsza odpowiada na „jakiej wartości używa ten sklep?”. Druga odpowiada na „czy to pole w ogóle jest dostępne w tym sklepie?”.

Prace RC wersji 9.2 obejmują ograniczanie definicji Extra Properties do listy sklepów. Użyj tej zmiany do oceny pól istotnych tylko dla części instalacji wielosklepowej. Ograniczenia definicji nr 42490.

Wyobraź sobie sklep hurtowy potrzebujący wewnętrznego pola przeglądu katalogu i sklep detaliczny, który go nie potrzebuje. Najpierw sprawdź, gdzie pole jest prezentowane i akceptowane. Potem sprawdź zachowanie jego wartości w dozwolonym zakresie. Ukryte pole w formularzu detalicznym samo w sobie nie dowodzi, że każdy inny czytnik respektuje zamierzoną dostępność.

Niezależnie sprawdzaj formularz, siatkę i włączone interfejsy API. Uwzględnij produkt współdzielony między sklepami i produkt powiązany tylko z jednym. Takie dane testowe odróżniają ograniczenia definicji od powiązania encji i zakresu wartości.

Nie zakładaj, że ograniczenie definicji usuwa stare wartości lub wykonuje migrację danych. Jeśli lista dozwolonych sklepów pola się zmienia, sprawdź udokumentowany cykl życia i przetestuj, co pozostaje w jednorazowym środowisku. Dostępność i przechowywanie to oddzielne decyzje.

Siatki reguł podatkowych wymagają testów regresji uwzględniających powiązania

Lista zmian RC1 zawiera poprawkę zduplikowanych wpisów grup reguł podatkowych w siatce w kontekście wielosklepowym. To wąska poprawka listy, a nie stwierdzenie, że przeprojektowano reguły naliczania podatków. Poprawka siatki reguł podatkowych nr 42245.

Aby ocenić listę, utwórz lub wykorzystaj syntetyczną grupę powiązaną z właściwymi sklepami. Porównaj identyfikatory i liczby wierszy w kontekście jednego sklepu i szerszym. Zastosuj filtr i przechodź między stronami, jeśli zestaw testowy jest dość duży do sprawdzenia stronicowania.

Asercja polega na tym, że siatka reprezentuje zamierzone logiczne rekordy bez duplikatów wynikających z powiązań. Nie zmieniaj rzeczywistej konfiguracji podatkowej, by stworzyć przypadek testowy. Zachowaj izolację danych testowych i przywróć je później.

Jeśli rozszerzenie dodaje złączenia lub kolumny do tej siatki, porównaj zachowanie z rozszerzeniem i bez niego. Poprawka rdzenia nie gwarantuje, że niestandardowe złączenie nie może ponownie wprowadzić duplikacji.

Oddzielaj dowody dotyczące listy od dowodów naliczania podatków. Jedno może być poprawne, a drugie błędne; nie powinny dzielić niejasnego statusu „podatki przeszły”.

Uwidocznij kontekst sklepu w procesach pracowników

Technicznie poprawny formularz wielosklepowy nadal może być używany błędnie, jeśli pracownicy przeoczą wybrany kontekst. Przejrzyj proces z pracownikami utrzymującymi ustawienia, nie tylko z programistami.

Poproś testera o lokalną zmianę, wyjaśnienie, których sklepów powinna dotyczyć, a następnie sprawdzenie sklepu docelowego i jednego niedocelowego. Jeśli nie potrafi przewidzieć zakresu, popraw instrukcje operacyjne przed poleganiem na interfejsie w codziennej pracy.

W zgłoszeniach wsparcia uwzględniaj wybrany sklep lub grupę i to, czy pole było dziedziczone. Bez tych szczegółów pozorny brak zapisu może być w rzeczywistości niezrozumieniem efektywnej konfiguracji.

Uwzględnij również równoczesną administrację. Dwaj pracownicy zmieniający wartości nadrzędne i lokalne mogą stworzyć zaskakujący wynik, nawet gdy każdy zapis jest prawidłowy. Użyj dostępnych w Twoim wdrożeniu rejestrów audytu lub zmian do odtworzenia sekwencji; nie zakładaj, że stary otwarty formularz nadal odzwierciedla bieżący stan dziedziczenia.

Oddzielaj lokalne nadpisania od skopiowanych ustawień

Przygotowując dane testowe, nie twórz sklepu B przez ślepe kopiowanie wszystkich efektywnych wartości sklepu A do lokalnej konfiguracji. Może to usunąć stan dziedziczenia, który test ma sprawdzić. Ustal wartość nadrzędną, a potem utwórz przez obsługiwany formularz tylko lokalne nadpisania wymagane przez scenariusz.

Przydatnym ćwiczeniem dla pracowników jest przewidzenie skutku zmiany nadrzędnej przed jej zastosowaniem. Zapytaj, które sklepy powinny się zmienić, a które zachować lokalną wartość. Porównaj przewidywanie z ponownie otwartymi formularzami i dalszym zachowaniem.

Jeśli wynik jest inny, najpierw sprawdź zapisany stan nadpisania i wybrany kontekst. Wartość wyglądająca na niezmienioną może być zamierzonym lokalnym nadpisaniem, a nie nieudanym zapisem. Z kolei zmieniony niedocelowy sklep może wskazywać zbyt szeroki zapis i wymaga natychmiastowego zbadania.

Zachowuj te dowody obok przypadków właściwych dla wersji. Wyjaśniają, czy nowe zachowanie formularza działa prawidłowo i czy procedura operacyjna jasno określa zakres dla pracowników. Oba elementy są potrzebne do niezawodnej codziennej administracji.

We współdzielonym środowisku testowym ogłaszaj eksperymenty zmieniające kontekst w zwykłym procesie koordynacji zespołu, by inny tester nie zapisał starego formularza względem zmienionego stanu nadrzędnego.

Definiuj akceptację przez izolację i efektywne wartości

Dobry zapis akceptacji wielosklepowej wersji 9.2 wskazuje dotkniętą stronę, pole, wybrany kontekst, stan dziedziczenia i wynikową efektywną wartość. Dla Extra Properties dodaj dostępność definicji i powiązanie encji. Dla siatek zachowuj oczekiwane identyfikatory i liczby.

Krytyczna asercja negatywna to pozostanie niedocelowego sklepu bez zmian. Należy to zaobserwować, a nie wywnioskować z komunikatu sukcesu bieżącego sklepu.

Te zmiany sprawiają, że konkretne części wersji 9.2 warto przejrzeć przy obsłudze wielu sklepów. Testuj je z odrębnymi wartościami i jawnym kontekstem, a ogólną własność danych niestandardowych modułów traktuj jako oddzielną kwestię inżynieryjną.

Kontekst platformy bazowej znajdziesz w naszym przewodniku po tworzeniu modułów PrestaShop 9; zastosuj powyższe kontrole właściwe dla wersji do ocenianej instalacji.