Ich muss im Backend den Order Filter erweitern um die supplierID.
Aktuell sehe ich nur die Möglichkeit das über einen Hook umzusetzen mit
**Shopware\Models\Order\Repository::filterListQuery::after**
oder gibt es eine elegantere Lösung ?
Das bringt garnichts, weil auf die SupplierID so nicht zugegriffen werden kann
Hallo,
es gibt keinen Hook für ein Repository, das ist Doctrine und kein Shopware. Nur bei Shopware Klassen gibt es Hooks. Außerdem wirst Du das denke ich auch gar nicht brauchen. Das müsste eine simple ExtJS Tabellen Spalten Erweiterung sein. Solche Daten müssten denke ich schon ins Template geladen werden, Du müsstest sie einfach nur noch ausgeben in einer eigenen Spalte. SupplierID hängt ja am s_articles (\Shopware\Models\Article\Article).
Normales Vorgehen bei nicht dokumentierten Funktionien ist eig immer wie folgt: Browser Debugger öffnen, und nachsehen, welche Action aufgerufen wird, wenn man im Backend auf Kunden => Bestellungen klickt. Von dieser Action aus hangelst Du dich dann nach unten bis zu Deiner gesuchten Stelle vor. Die von Dir gezeigte Methode hängt ja nur ein paar Where Conditions an den QueryBuilder an und wird auch von mehrere Stellen im Repository verwendet. Das ist also schonmal die falsche Stelle für Deine Aufgabenstellung.
Also, wie bereits angesprochen: Der einfache Weg wäre, unter der Annahme, dass die SupplierID pro Bestellzeile in der Bestellliste schon vorhanden ist, die Tabelle um eine Spalte erweitern. Eine kurze Analyse ergab, dass das aktuell nicht der Fall ist. Muss aber nicht heißen, dass die SupplierIDs nicht mittels Doctrine geladen werden und einfach nicht mit an die XHR Request backend/Order/getList?_dc=1487170338238&page=1&start=0&limit=20 übergeben werden. Du solltest vielleicht in den Controller Order die Action getList im Modul backend Dir einmal ansehen. Vielleicht findest Du dort Filter Events, die du verwenden kannst. Ansonsten wirds recht hässlich:
Die komplexe Variante: Es ist eigentlich nicht vorgesehen, seitens Doctrine sich von einem Basis Repository zu vererben. Nichts desto trotz müsstest Du das aber tun, damit Du die eine Methode, die für die Liste verantwortlich ist, überschreiben kannst. Damit ist es aber noch nicht getan. Nun hast Du die Überschreibung, jetzt geht es noch darum, das ganze Shopware bekannt zu machen. Ansonsten ruft Shopware weiterhin die Basisklasse auf. Um das zu erreichen, müsstest Du den Service models komplett ersetzen. Also du müsstest die ModelManager Core Klasse komplett durch eigene Logik ersetzen. Oder besser gesagt, Dich ebenfalls von ModelManager vererben, die getRepository Methode überschreiben und dann hier dein eigenes Repository übergeben, falls das von dem Entity Order angefordert wird. Wie Du Services durch eigene ersetzt, findest Du in der Entwickler Doku von Shopware.
Die hässliche Variante: Du ergänzt einfach die Order Repository Methode mit deinen Code. Das wäre eigentlich auch das normale Vorgehen, wenn man Doctrine in sein Projekt als Bibliothek einbindet. Deswegen muss man sich normalerweise auch nicht von Repositories ableiten, man passt sie einfach an. Das kannst Du theoretisch auch machen, aber dann forkst Du quasi Shopware und agierst dann selbst als Herausgeber deines angepassten Shopwares. Damit haftest Du auch für Fehler, Schadensersatz oder sontige Regressansprüche, die durch Deine Änderung entsanden sind. Diese Bürge würde ich mir nicht anhängen wollen…
MFG
derwunner
Das ist mal eine ausführliche Antwort 
In meinem Fall dürfen bestimmte User im Backend nur bestimmte Bestellungen von bestimmten Lieferanten sehen. Gewünscht wäre es sogar, wenn man die Bestellungen nach Abschluss danach splittet.
Aber egal wie man es dreht und wendet. Ist das ein grosser Eingriff
Danke für die INfos
Dann würde ich es komplett anders lösen:
Shopware hat doch ein Rollenrecht System. Baue komplett Deine eigene Bestellübersicht. Und entferne per Recht die normale Bestellübersicht, für die User, die sie nicht sehen dürfen.
Ich gehe mal nach Deinen Beschreibungen davon aus, dass Du versuchst das Shopware Backend für Lieferanten nur beschränkt zugänglich zu machen. Also im normalen Business Umfeld gibt es aber dafür einen komplett anderen Ansatz: Der Lieferant bekommt eine Schnittstelle, was durchaus dann über die Shopware API abbildbar ist. Und um die Einbindung der Schnittstelle in das hauseigene ERP System muss sich dann der Lieferant selber kümmern. Oder Du schreibst die REST Endpoints direkt verständlich für das ERP System der Lieferanten, das wäre auch eine Möglichkeit. Jedenfalls in aller Regel läuft soetwas über Schnittstellen Komminukation ab. Schließlich muss das dann ein Mensch entweder abtippen, damit es in die eigene Software passt, oder er oder sie bezieht es direkt über eine API, die die Lieferanten Software versteht. Deswegen macht das in der Regel keiner so, weil das doppelte Arbeit ist.
Nein da habe ich mich wohl nicht korrekt ausgedrückt.
Die Artikel sind jeweils einem Lieferanten zugeordnet. Einige Backend User dürfen nur Bestellungene sehen dürfen, wo Artikel von bestimmten Lieferanten sind. Hier wird es als Hersteller bezeichnet. Ob es Sinn macht ist eine andere Frage. Das sind die Vorgaben.
Das liegt daran, dass die Produkte in verschiedenen Bereichen selbst produziert werden und manche woanders. Bestimmte Admins dürfen zb keine Aufträge sehen, die extern bei xy hergestellt werden.
In der Regel besteht die Bestellung nur aus einer Position. Sollten aber 2 oder mehrere Positionen von unterschiedlichen Herstellern/Lieferanten sein, so kann er Sie ruhig sehen.
Daher ist der Hauptwunsch, bei mehreren Positionen diese autom. zu splitten, so dass mehrere Bestellungen angelegt werden. Aber da ziehen sich Probleme wie ein roter Faden durch das System.