Entwickler, der außergewöhnliche CRM- und Laravel-Lösungen liefert

Als erfahrener Entwickler spezialisiere ich mich auf Laravel- und Vue.js-Entwicklung, die Implementierung von Vtiger CRM sowie auf vielfältige WordPress-Projekte. Meine Arbeit zeichnet sich durch kreative, dynamische und benutzerzentrierte Weblösungen aus, die individuell an die Bedürfnisse meiner Kunden angepasst werden.

Viele Nutzer von VtigerCRM haben nach dem Update von Version 7.0 auf 7.1 ein Problem bemerkt: In der Detailansicht (z. B. im Lead-, Order- oder sonstigen Modul) werden im Tab „History“ alle Änderungsprotokolle dem Benutzer Administrator zugewiesen – unabhängig davon, wer die Änderung tatsächlich vorgenommen hat.

Was tun, wenn in Vtiger 7 in der Detailansicht unter „History“ alle Änderungen fälschlicherweise dem Administrator zugeordnet werden?

Viele Nutzer von VtigerCRM haben nach dem Update von Version 7.0 auf 7.1 ein Problem bemerkt: In der Detailansicht (z. B. im Lead-, Order- oder sonstigen Modul) werden im Tab „History“ alle Änderungsprotokolle dem Benutzer Administrator zugewiesen – unabhängig davon, wer die Änderung tatsächlich vorgenommen hat. Häufig ist dies auf bestimmte Handler zurückzuführen, die nach einer Bearbeitung einer Datensatzänderung ausgeführt werden. Letztlich wird dadurch jeder Änderungsvorgang fälschlicherweise dem Administrator zugeordnet, anstatt den korrekten Nutzer zu identifizieren.

In diesem Artikel erklären wir, wie Sie dieses Problem beheben und dafür sorgen, dass in der Änderungsverlaufshistorie auch der tatsächliche Bearbeiter angezeigt wird.

Schritt 1: Den richtigen Ort finden

Die Datei, die für das Protokollieren der Änderungen verantwortlich ist, befindet sich im VtigerCRM unter:

  modules/ModTracker/ModTrackerHandler.php

Diese Datei enthält den Code, der sämtliche Änderungen an Datensätzen – durch alle Nutzer – in der Datenbank abspeichert.

Schritt 2: Den kritischen Codeblock identifizieren

Innerhalb der oben genannten Datei suchen Sie den folgenden Block, der in etwa so aussieht:

  $moduleName = $data->getModuleName();
  $isTrackingEnabled = ModTracker::isTrackingEnabledForModule($moduleName);
  if(!$isTrackingEnabled) {
    return;
  }

Vor diesem Block fügen Sie zusätzlichen Code ein, der die Informationen des aktuellen Nutzers ermittelt. Dies erreichen Sie durch die folgenden Zeilen:

  $current_user_id = $_SESSION["authenticated_user_id"];
  $current_user = Users_Record_Model::getInstanceById($current_user_id, 'Users');
  $curid = $current_user->get('id');
  global $current_user;

Der Zusatz sorgt dafür, dass der Name bzw. die ID des aktuell eingeloggen Nutzers abgespeichert wird und später für die Protokollierung zur Verfügung steht.

Schritt 3: Globale Variable anpassen

Im weiteren Verlauf der Datei suchen Sie diese Zeile:

  global $adb, $current_user;

Entfernen Sie hier den Verweis auf $current_user, sodass die Zeile anschließend folgendermaßen aussieht:

  global $adb;

Dies verhindert, dass der Administrator als Standardnutzer weiterverwendet wird.

Schritt 4: Den INSERT-Befehl korrigieren

Nun suchen Sie den SQL-Befehl, der die Änderung in die Tabelle vtiger_modtracker_basic einträgt. Er sieht typischerweise so aus:

  $adb->pquery('INSERT INTO vtiger_modtracker_basic(id, crmid, module, whodid, changedon, status)
    VALUES(?,?,?,?,?,?)', Array($this->id, $recordId, $moduleName, $current_user->id, $changedOn, $status));

Ersetzen Sie diesen Befehl durch die folgende Version, in der anstelle von $current_user->id nun $curid verwendet wird:

  $adb->pquery('INSERT INTO vtiger_modtracker_basic(id, crmid, module, whodid, changedon, status)
    VALUES(?,?,?,?,?,?)', Array($this->id, $recordId, $moduleName, $curid, $changedOn, $status));

Durch diese Änderung wird sichergestellt, dass in der Datenbank der korrekte Nutzer gespeichert wird – nämlich derjenige, der die Änderung wirklich durchgeführt hat.

Fazit

Nach Durchführung der oben beschriebenen Änderungen wird in der Änderungshistorie der Detailansicht in Vtiger 7 nicht mehr fälschlicherweise jeder Eintrag dem Administrator zugeordnet. Stattdessen erscheint dort die ID desjenigen Benutzers, der tatsächlich die Änderung vorgenommen hat – was nicht nur für mehr Transparenz sorgt, sondern auch bei der Nachvollziehbarkeit von Änderungen in Ihrem CRM-System entscheidend ist.

Sollten Sie weitere Fragen oder Probleme haben, empfiehlt es sich, die Vtiger-Dokumentation zu konsultieren bzw. Unterstützung in der Community zu suchen. Ein sauber protokollierter Änderungsverlauf ist essentiell, um den Betrieb und die Audit-Fähigkeit Ihres CRM-Systems sicherzustellen.

Ich hoffe, dieser Artikel hilft Ihnen, das Problem zu beheben und Ihre Vtiger-Installation optimal zu nutzen.