Berechtigungsmanagement

Hallo an alle,

ich habe die Herausforderung das die Rechnungswesenabteilung nicht möchte das geb. Einkaufsrechnungen mit der Rechnungsart "Buchungsbeleg" sieht, außer die Abteilung selbst.

Bei Profilen die man nicht anpassen kann hätte ich einfach ein Profil erstellt welches einen Vordefinierten Filter nutzt.

Aber das ist bei den Profil nicht möglich / nicht gewollt.

Wie kann man die Anforderung umsetzen?

Danke schon mal vorab für eure Mühe.

Hi,

sollte mit Sicherheitsfilter möglich sein
https://docs.microsoft.com/en-us/dynamics-nav/how-to--set-security-filters

Wir haben bei uns auch die unterschiedlichsten Anforderungen an sichtbare bzw. nicht sichtbare Datensätze je nach Abteilung, so dass wir uns hierfür ein kleines Modul gebaut haben, über welches man pro Tabelle, Benutzerrolle/UserID einen frei definierbaren Filter definieren kann.

Screenshot.png

Nachdem man dort die Tabellenfilter definiert hat, wird über eine Action im Menüband eine Codeunit (im Textformat) erstellt, welche für alle Pages der beteiligten Tabellen einen Event-Subscriber erstellt, um darüber die Filter anzuwenden.
(Da wir den Object Manager Advanced bei uns einsetzen kann die Action die erstellte Codeunit sogar direkt importieren und kompilieren, ansonsten müsste man den Schritt halt von Hand machen.)

Man könnte darüber also für verschiedene Benutzerrollen unterschiedliche Filter für die Tabellen 38, 122 und 124 definieren und alle Pages, welche eine dieser Tabellen als SourceTable hat, würden diese Filter direkt beim Öffnen in der angegebenen Filtergruppe anwenden.

Anstelle der Action, welche die Codeunit mit den Event-Subscribern erstellt, könnte man auch händisch für alle gewünschten Pages einen Event-Subscriber in einer Codeunit anlegen, aber Programmierer sind von Natur aus faule Leute (deswegen nennt man sie ja auch E-D-Fauler ) und hassen sich ständig wiederholende Arbeiten.
Darüber hinaus ist durch diese Action sichergestellt, dass auch wirklich bei allen Pages zu einer der enthaltenen Tabellen entsprechende Event-Subscribers existieren.

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

sollte mit Sicherheitsfilter möglich sein

Der Nachteil bei Einsatz von Sicherheitsfiltern ist jedoch, dass dann die Datensätze auch vor NAV versteckt werden.

Beispiel:
Eine bestimmte Personengruppe darf zwar grundsätzlich die Posten sehen, jedoch sollen bestimmte Posten (z. B. von Lohn-/Gehalts-Konten) vor ihnen versteckt werden.
Wenn diese Personengruppe jetzt einen Beleg buchen möchte und zufällig der letzte (tatsächlich vorhandene) Posten ein versteckter Posten ist, dann würde NAV eine bereits vergebene "Lfd. Nr." als nächste "Lfd. Nr." ermitteln.
Ergebnis: Buchen ist nicht mehr möglich.

Daher verzichten wir bei uns auf die Sicherheitsfilter, da wir nicht vorhersagen können, wer sich wo für wen welche Filter wünscht.
Stattdessen haben wir unser Tool geschrieben, da dieses die Datensätze nur vor dem Anwender versteckt, nicht jedoch vor dem System.

Wenn diese Personengruppe jetzt einen Beleg buchen möchte und zufällig der letzte (tatsächlich vorhandene) Posten ein versteckter Posten ist, dann würde NAV eine bereits vergebene "Lfd. Nr." als nächste "Lfd. Nr." ermitteln.
Ergebnis: Buchen ist nicht mehr möglich.

tolles Beispiel! - wusste ich noch nicht. vielen Dank, werde ich zukünftig definitiv bedenken

Hallo Timo Lässer,

ehrlich gesagt klingt deine Lösung super! Aber ich habe keine Ahnung was du da gemacht hast. Das liegt sicher auch daran das ich bisher nichts in NAV entwickel. Kann man sich das Thema irgendwie nähern bzw. noch irgendwo nachlesen?
Kannst du hier etwas empfehlen? Die passende Umgebung zum entwickeln hätte ich.

Die Programmierung basiert (wie fast alle unserer eigenen NAV-Funktionalitäten) auf RecordRefs und dem Event-System:

• Zuerst habe ich die Tabelle (und die dazu passende Page) angelegt.
• Dann eine Funktion, welche alle zu einer Tabelle in Frage kommenden Datensätze ermittelt (für den konkreten Benutzer, für die dem Benutzer zugeordneten Benutzerrollen und die Allgemeingültigen).
• Dann eine Funktion, welche die in Frage kommenden Filter auf einen übergebenen RecordRef anwendet.
• Dann habe ich eine Codeunit mit zwei beispielhaften Event-Subscribern erstellt und im Text-Format exportiert.
  Diese zieht sich aus dem Rec der Page einen RecordRef und übergibt ihn an die Funktion, welche die Filter anwendet. Den RecordRef übergebe ich dann wieder an den Rec der Page.
• Diese Textdatei habe ich dann als Vorlage für die Codeunit genommen, welche mir diese Event-Subscriber-Codeunit erstellen soll. (Wann muss wo was in die Textdatei geschrieben werden?)
• Als i-Tüpfelchen habe ich dann eine Action erstellt, welche die automatisch erstellte Codeunit mittels der Funktionen des Object Manager Advanced über das "Object Import Worksheet" importiert, so dass das auch unsere ERP-Consultants ausführen könnten ohne Zugriff auf den Dev-Client haben zu müssen.

Wenn man den Programmcode sieht, dann ist das kein Hexenwerk, wenn man sich mit RecordRef, Events und dem Aufbau einer NAV-Objekt-Textdatei auskennt.
Die "Genialität" steckt meiner Meinung nach einfach nur in der Idee, auf die man erstmal kommen muss.

Anfangs hatte die "Codeunit-Erstell-Codeunit" für jede Page mit einer SourceTable ein Event erstellt.
Wenn man nur den NAV-Standard einsetzt, dann dürfte das noch funktionieren, jedoch nicht mehr, wenn man eine umfangreiche Branchenlösung und/oder mehrere Add-Ons von Drittanbietern in der Datenbank integriert hat.
Dann gibt es in der erstellten Codeunit zu viele Event-Funktionen, die NAV nicht mehr verwalten kann.
Daher haben wir es nachträglich dahingehend eingeschränkt, dass die Codeunit nur Events für Pages erstellt, dessen SourceTable-ID auch tatsächlich in der Tabelle aufgeführt ist.