Bei Datenbanken ist es sinnvoll die Änderungen in einem Historifeld mitzuschreiben, um nachsehen zu können wer (Benutzer, Modul, Shop) was wann bei Artikeln, Kunden, Kategorien geändert hat. Sichtbar müssten das dann bei den jeweiligen Elementen und einmal gesamt z.B. bei den Logeinträgen sein. Bei Artikeln indealerweise im eingeloggten Zustand über auch über das Frontend. So hätte man auch eine bessere Kontrolle über Module/Zahlungssysteme, die immer mal wieder die Bestandsmengen durcheinander bringen.
Das funktioniert nicht. Wir sehen mal davon ab, dass das schnell gross und auch eher langsam wäre und gehen mal nur in die Technik... In Shops gibts normal diverse DInge die einfach direk auf der Datenbank herumschreiben, mit ihren je eigenen Mechanismen. Das ist historisch so gewachsen und wir werden noch eine Weile brauchen, um das loszuwerden. Solange es da keinen zentralen Punkte gibt, über die jeder gehen muss, kann es keine zentrale Verwaltung einer Historie geben. Es ginge nur mit Methoden der DB selbst, die viele Hoster aber sperren. Das wird, wenn mans machen wollte, noch lange eine Utopie bleiben.
Bin ja auch in Florix unterwegs (Feuerwehrverwaltungsprogramm über Internet in Hessen). da wird auch alles online mitgeplottet. Bei mehreren Benutzern ist das natürlich von großer Wichtigkeit. Technisch dürfte dem System bekannt sein, wer gerade mit welchem Konto administriert. Klar, wenn das Hoster sperren, ist das natürlich eine Grenze. Ist jetzt auch nicht lebensnotwendig. Ein Grund wäre auch noch die Dokumentation bei externen Aktivitäten, wie Gambio-Support oder Agenturen.
Gibt es die Funktion nicht für Admins im Shop? Da wird doch etwas in die Logs geschrieben, wenn das aktiv ist.
Nein, ich meine das hier: das ist unter Kunden unten auf der Kundendetailseite, wenn das Konto zu einem Admin gehört
Ich warne ausdrücklich davor das in produktiven Shops zu aktivieren. Das ist für Debug Zwecke gedacht, wird schnell riesig und geht mächtig auf die Performance von Shops! Noch ein Problem: Das wird nicht alles loggen. Es gehen dann immernoch Sachen dran vorbei, oben genannte Gründe. Es gibt gerade einfach keinen Weg das zu tun und es wäre weit weit weit weg.
Die Idee ist im Prinzip man schaltet das kurz ein, führt eine Aktion aus über die man mehr wissen will was da auf der DB passiert, schaltets dann unmittelbar wieder aus. Das wäre tragbar... Praktisch hat der Shop selbst aber 3 Generationen DB Anbindungen mit an Bord (xtc_db_..., Codeigniter QueryBuilder, DBAL..) und nicht alle loggen dann mit. Es gab schon ewig das Thema, dass Module (gerade von dritten...) dann trotzdem noch Sachen über ihre eigenen Wege an allem vorbei tun und man das dabei nie sieht aber auch braucht. Also schaltet jeder gestandene Entwickler einfach für den interessanten Moment ein Logging auf die DB über den jeweiligen SQL Server an und arbeitet damit was da rauskommt. Was dann im Shop für Knöpfe sind, ist für die Praxis völlig egal.
Könnte man ja begrenzen auf die letzten 10-50 Änderungen. Bei Produkten, Kunden, usw. wäre es schon manchmal interesant zu sehen was / wer die letzte änderung gemacht hat. Aber verstehe auch das Problem, dass nicht jeder über eine Zentrale Stelle geht. Das könnte man aber angehen bei den Vorgaben für geprüfte Module als Qualitätsvorgabe. Dann wäre es in einiger Zeit immer vollständiger und hilfreicher für so manchen Fall.