Logging von Löschungen im Änderungsprotokoll

Ich probiere gerade etwas mit dem Änderungsprotokoll herum. Wie kann ich denn einstellen, dass das Löschen von Änderungsprotokollposten (405) geloggt wird? In der Einrichtung habe ich für die 405 Löschen => Alle Felder aktiviert. Allerdings bleibt das Protokoll leer, wenn ich da drin lösche.

Vielen Dank

Ich habe das gerade mal aus Interesse in NAV 2017 getestet. Man kann zwar das Loggen von Löschungen in Tabelle 405 einrichten, aber der Lösch-Job loggt trotzdem nix. Im Prinzip ist es ja auch sinnlos, das Löschen zu protokollieren, weil dabei dann ja statt zu löschen nur noch mehr Änderungsprotokollposten entstehen. Es ist nur für den Anwender verwirrend dass man in der Änderungsprotokoll Einrichtung die Tabelle 405 auch einrichten kann.

Der Grund für dieses besondere Verhalten ist, dass das Änderungsprotokoll bei bestimmten Tabellen eine hart codierte Einrichtung befolgt, egal was man für diese Tabellen eingestellt (oder auch nicht) hat.

Hier ein Screenshot aus der Codeunit 423 "Change Log Management" aus NAV 2017:

Screenshot.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Super. Danke für den Input. Lässt es sich also nicht verhindern, dass Änderungsprotokollposten gelöscht werden? Und feststellen, ob Änderungsprotokollposten gelöscht wurden, kann ich maximal durch prüfen auf Lücken in der Lfd. Nummer?

Man könnte sicherlich vor dem Exit eine weitere Tabelle einbinden, welche die Löschungen dokumentiert. Alternativ kann man das auch (zusätzlich) in eine Log-Tabelle schreiben. Falls diese Konstrukte aber dem löschenden Bearbeiter bekannt sind, kann der natürlich auch dort die Löschungen vornehmen, falls das verschleiert werden soll (Adminberechtigungen vorausgesetzt).

Das Löschen von Änderungsprotokollposten lässt sich doch ganz einfach verhindern, indem man keinem Benutzer die Rechte dazu gibt (keine direkten oder indirekten Lösch-Rechte für Tabelle 405).

Die Lösung liegt natürlich auf der HAnd. Allerdings sehe ich sehr viele NAV-Systeme und die Rolle Super ist quasi immer vergeben.

SUPER dürfen nur Admins haben, und davon sollte es nicht viele geben. Die könnten ja auch über SQL direkt was löschen oder ändern, und dann hilft auch das Änderungsprotokoll in NAV nix. Kein Anwender, auch kein Abteilungsleiter oder Key User, sollte in einem produktiven System den Berechtigungssatz SUPER haben (oder SUPER (DATEN) oder sonstwie uneingeschränkte Rechte auf sämtlichen TableData).

Leider kenne ich aus der Vergangenheit auch viel zu viele Unternehmen, die sich gar nicht(!) mit dem NAV-Berechtigungssystem beschäftigt hatten und alle User waren als SUPER definiert, weil es ihnen zu mühsam ist, die Rollen zu spezifizieren und zuzuweisen.
Die brauchen sich dann natürlich nicht wundern, wenn ihre Daten irgendwann mal schrott oder im schlimmsten Fall weg sind.
Da muss man den Anwendern noch nicht einmal Böswilligkeit vorwerfen.

Mit dem "Record Permission Wizard" lassen sich mittlerweile sehr einfach passende Berechtigungssätze zusammenstellen.
Dafür muss man sich aber im Vorfeld ein gutes Rollen-Konzept ausdenken und zu den Rollen klare Vorstellungen haben, welche Aufgaben die dazugehörigen Anwender ausführen dürfen.

Wir haben die Berechtigungssätze nach folgendem Schema benannt:
[Abteilungskürzel]_[Teamkürzel]_[Mitarbeiterebene]

Abteilungskürzel: BH, VK, EK, SE, PR, ...
Teamkürzel: AN (Anlagenbuchhaltung), DE (Debitorenbuchhaltung), ...
Mitarbeiterebene: AL (Abteilungsleiter), TL (Teamleiter), SB (Sachbearbeiter), ...

Die SUPER-Rolle haben bei uns nur ganz wenige "Auserwählte", und die haben auch ein separates Windows-Login dafür, damit sie nicht versehentlich mit SUPER- bzw. Admin-Rechten unterwegs sind.