Backend

Die Server-Seite besteht aus der Plugin-Klasse (Zusatzfeld anlegen und entfernen) und einem Event-Subscriber, der die Suchkriterien des Basis-Plugins LeopardenBusinessTransactions erweitert. Der Überblick steht unter Entwickler.

Der Subscriber

Leoparden\BusinessSalesRepresentative\Subscriber\TransactionCriteriaSubscriber ist in services.xml mit dem Tag kernel.event_subscriber registriert und hat keine Abhängigkeiten. Er hört auf zwei Events:

Event	Methode	Gesuchter Filter
`TransactionCriteriaEvent`	`onTransactionCriteriaEvent()`	Filter, dessen Felder `customerId` enthalten
`TransactionItemsCriteriaEvent`	`onTransactionItemsCriteriaEvent()`	Filter, dessen Felder `transaction.customerId` enthalten

Beide Events werden im Basis-Plugin nach dem Setzen des Kundenfilters ausgelöst (in TransactionsRoute::load() und TransactionItemsRoute::load()). Beide Routen verlangen vorher einen angemeldeten Kunden (ensureLoggedIn).

Ablauf in onTransactionCriteriaEvent()

Der Subscriber liest alle Filter der Kriterien.
Jeden Filter, dessen Felder customerId enthalten, ersetzt er unter demselben Schlüssel durch einen OrFilter.
Der OrFilter enthält den EqualsFilter('customerId', <ID des angemeldeten Kunden>) und zwei Bedingungen auf das Zusatzfeld customFields.leoparden_business_sales_representative_field: ein EqualsFilter auf die ID (der Wert ist genau die ID, etwa aus einem Import) und ein ContainsFilter auf die ID in Anführungszeichen (die ID ist ein eigener Eintrag der Liste, die die Administration speichert). Ein Wert, der die ID nur enthält, trifft nicht. Ohne angemeldeten Kunden ergänzt der Subscriber keine Vertreter-Bedingung, ein leerer Suchtext träfe jeden Vorgang, der das Feld hat.
Danach ergänzt er die Assoziation customer und setzt die Kriterien mit setCriteria() zurück ins Event.

onTransactionItemsCriteriaEvent() arbeitet gleich, nur mit den Feldern transaction.customerId und transaction.customFields.leoparden_business_sales_representative_field sowie der Assoziation transaction.customer.

Die Assoziation customer wird gebraucht, weil die Templates die Kundennummer des Besitzers anzeigen (siehe Frontend).

Was der Filter bedeutet

Ein Vorgang trifft die Bedingung, wenn er dem angemeldeten Kunden gehört oder wenn der gespeicherte Wert des Zusatzfelds die ID des angemeldeten Kunden als Zeichenfolge enthält. Alle übrigen Filter der Routen bleiben unverändert, zum Beispiel der Typfilter typeId bzw. transaction.typeId aus der Konfiguration des Basis-Plugins und die Sortierung.

Grenzen der Umsetzung

Prüfung auf den Text, nicht auf die Menge. Das Zusatzfeld hält eine Liste von Kunden-IDs. Der Filter sucht die ID als ganzen Eintrag (in Anführungszeichen) im gespeicherten Text und akzeptiert zusätzlich den Wert, der genau die ID ist. Er prüft nicht die Menge selbst. Ein Wert, der die ID nur als Teil eines längeren Textes enthält, trifft nicht.
Jeder passende Filter wird ersetzt. Der Subscriber ersetzt jeden Filter der obersten Ebene, dessen Felder customerId enthalten, und nicht nur den Filter, den das Basis-Plugin selbst gesetzt hat. Setzt die Anfrage ihrerseits einen solchen Filter, wird auch er ersetzt.
Nur Filter auf der obersten Ebene. getFilters() liefert die Filter der obersten Ebene. Ist der Kundenfilter verschachtelt, findet ihn der Subscriber nicht.
Kein Zugriff über das Feld selbst. Das Zusatzfeld regelt nur die Sichtbarkeit in diesen beiden Routen. Andere Stellen, die Vorgänge laden, kennen es nicht.
Typfilter bleibt gültig. Der Vertreter sieht zugewiesene Vorgänge nur, wenn deren Typ für seine Kundengruppe freigegeben ist.

Das Zusatzfeld anlegen (postInstall)

LeopardenBusinessSalesRepresentative::postInstall() sucht über das Repository custom_field_set.repository ein Feldset mit dem Namen leoparden_business_sales_representative samt Feldern und Zuordnungen. Danach schreibt es per upsert() das Feldset mit:

der Zuordnung zur Entität leoparden_business_transactions_transaction,
dem Feld leoparden_business_sales_representative_field vom Typ CustomFieldTypes::ENTITY, Komponente sw-entity-multi-id-select, Entität customer, labelProperty firstName und lastName.

Die IDs vorhandener Datensätze werden übernommen, sonst werden neue erzeugt. Dadurch ist eine wiederholte Installation ohne Verletzung der eindeutigen Schlüssel möglich.

Deinstallieren

uninstall() tut nur etwas, wenn $uninstallContext->keepUserData() falsch ist. Dann führt es über die DBAL-Verbindung zwei delete-Anweisungen aus: eines in custom_field_set mit dem Namen leoparden_business_sales_representative und eines in custom_field mit dem Namen leoparden_business_sales_representative_field. Mit --keep-user-data bleiben beide erhalten.

Nicht angefasst werden die an den Vorgängen gespeicherten Werte in custom_fields des Vorgangs. Ist das Plugin deinstalliert, ist die ODER-Bedingung nicht mehr aktiv; dann gilt wieder nur der Besitzerfilter des Basis-Plugins.

Zwischenspeicher

In der Linie 6.7 gibt es im Basis-Plugin keine eigene zwischenspeichernde Routenklasse (CachedTransactionsRoute existiert nur in 6.6). TransactionsRoute::load() meldet stattdessen über den CacheTagCollector die Tags transactions-<ID des angemeldeten Kunden> sowie den Kriterien- und den Kontext-Hash. Dieses Plugin greift in die Zwischenspeicherung nicht ein; es gibt keinen Code, der bei einer geänderten Vertreter-Zuweisung Einträge verwirft. Ob eine Änderung am Zusatzfeld die Einträge eines Vertreters zurücksetzt, ergibt sich aus dem Code dieses Plugins nicht.

Last modified: 08 November 2026