Entwicklung
Architektur in Kürze
Das Plugin bringt kein eigenes Datenmodell mit. Es hängt sich an den Artikel und stellt an drei Stellen dieselbe Frage: Darf dieser Kunde diesen Artikel haben?
Die Regel selbst liegt in einer einzigen Klasse, Content\CustomProduct\CustomerAssignment. Seite und Warenkorb rufen isAccessible() beide auf — genau deshalb kann eine Variante, die die Seite ausliefert, im Warenkorb nicht plötzlich verschwinden. Die Produktsuche nutzt dieselbe Regel als DAL-Filter (searchFilter()). Die Store-API-Route CustomProductsRoute ruft die Regel nicht auf: Sie filtert nur auf die Kundenzuweisung des angemeldeten Kunden.
Baustein | Klasse | Aufgabe |
|---|---|---|
Zugriffsregel |
| Beantwortet die Zugriffsfrage — die einzige Stelle mit der Logik |
Seite & Suche |
| Detailseite, Suche und Suggest; Ersatzsuche (zugängliche Variante oder Vaterartikel) über |
Produktsuche |
| Setzt |
Warenkorb |
| Entfernt fremde Positionen, korrigiert den Child-Count |
Store-API |
| Liste der eigenen Artikel |
Artikelfelder |
| Laufzeitfelder |
Abhängigkeiten
Paket | Rolle |
|---|---|
| Plattform |
| Basis für CMS-Element und Storefront-JS |
| Lizenzprüfung im Plugin-Lebenszyklus |
|
|
| Filter und Antwortverarbeitung |
Die Kopplung an BusinessTransactions ist eng: Das Twig-Element erweitert @BusinessTransactions/storefront/element/transactions_base_element.html.twig, und das Storefront-Plugin importiert seoUrls sowie ProcessTransactionResponseFunction daraus.