[Gelöst] Tabellen im Objektdesigner sperren

[Datenkultur]

Hallo liebe Kollegen,

einer unserer Kunden möchte unterbinden, dass Daten einer eigenen Tabelle im Objektdesigner mit einer Kundenlizenz geändert werden können. Bei den Posten aus dem Standard funktioniert das ja. Mit einer Kundenlizenz kann man die nicht anpassen. Mit einer Entwicklerlizenz schon. Kann man das irgendwie einstellen?

Besten Dank für Eure Hilfe

Zuletzt geändert von Datenkultur am 23. Juli 2012 10:31, insgesamt 1-mal geändert.

Hi,

die Rechte in welcher Tabelle Daten verändert werden dürfen können über das Rollenkonzept in NAV abgewickelt werden.
Jeder Benutzer bekommt die für ihn benötigten Rollen zugewiesen. In den Rollen selbst kann hinterlegt werden auf welche Tabellen zugegriffen werden darf.

Hallo Danjo,

es geht mir nicht um die Berechtigungen. Die Benutzer sollen aus einer Form heraus ja mit der Tabelle arbeiten dürfen. Die sollen nur im Objektdesigner diese Tabelle nicht verändern können. Und das obwohl die Berechtigungn für den Objektdesigner haben. Bei den Postentabellen aus dem Standard ist das nämlich so geregelt. Mit der Kundenlizenz kann nicht mal ein Super-User die Postentabellen verändern. Mit einer Entwicklerlizenz klappt das problemlos.

Und das obwohl die Berechtigungn für den Objektdesigner haben. Bei den Postentabellen aus dem Standard ist das nämlich so geregelt. Mit der Kundenlizenz kann nicht mal ein Super-User die Postentabellen verändern. Mit einer Entwicklerlizenz klappt das problemlos.

Hi,

der Schutz der Postentabellen kommt, wie du ja bereits gesagt hast, aus der Linzenz heraus. Dieser Schutz ist aber wirklich nur für eine Handvoll Tabellen vorhanden und kann nicht nach belieben aktiviert und deaktiviert werden.
Wenn ein Benutzer Super-Rechte hat, kommt er auch immer an alle Tabellen die innerhalb seiner Lizenz liegen. Den einzigen Weg den ich hier sehe ist dem Benutzer die Super-Rolle abzunehmen und mit einer passenden Rolle zu arbeiten.
Das Recht Daten zu verändern kann in der Form erteilt werden. Wenn die Form das Recht hat Daten zu ändern, bekommt auch der Benutzer über diese Form das Recht dazu.
Alternativ kann eine alles andere als saubere Lösung auf Triggerebene hinterlegt werden.

Hallo Danjo,

herzlichen Dank für Deine Infos.

Ich habe das eben mit jeweils dem gleichen Benutzer auf einer NAV 2009 ausprobiert:

Mit Entwickler Lizenz:
- Sachposten im Objektdesigner öffnen
- Beschreibung ändern
- Zeile verlassen
-> Änderungen wurden übernommen

Mit Kunden Lizenz:
- Sachposten im Objektdesigner öffnen
- Beschreibung ändern
- Zeile verlassen
-> Es kommt eine MessageBox: "Sachposten kann in diesem Formular nicht verändert werden."
-> Änderungen wurden verworfen.

Es gibt keinen Source im OnModify der Sachposten. Das gehört also entweder zur FIN.EXE oder ist irgendwo konfigurierbar. Interessieren würde mich, ob das konfigurierbar ist. Das wäre ja auch für eigene Postentabellen recht nützlich.

...
Es gibt keinen Source im OnModify der Sachposten. Das gehört also entweder zur FIN.EXE oder ist irgendwo konfigurierbar. Interessieren würde mich, ob das konfigurierbar ist. Das wäre ja auch für eigene Postentabellen recht nützlich.

Das ist, wie oben beschrieben, in der Kundenlizenz hinterlegt und kann nicht konfiguriert werden. Nur über das NAV eigene Rollenkonzept.

Die einzige Möglichkeit welche ich mir vorstellen könnte wäre, wenn die Tabellen zu einer Branchenlösung gehören und dort in der Kundenlizenz als nicht änderbar definiert sind. Aber da kenne ich mich leider nicht aus.

Zuletzt geändert von m_schneider am 23. Juli 2012 11:19, insgesamt 1-mal geändert.

Noch mal Danke für Eure Hilfe.

"Es geht nicht" ist manchmal ja (leider) die korrekte Antwort.

Dann werde ich das dem Kunden so erklären. Wenn er es anders haben möchte, dann wird er sich Mühe mit den Berechtigungen des Admins machen müssen.

Hi,

ich habe das jetzt noch nie ausprobiert, aber falls SQL-Server als DB könnte man einen Datenbanktrigger erstellen, der Änderungen an der Tabelle selbst (nicht den Dtaen) abfängt und ins Nirvana schickt. Die zugrunde liegende SQL-Tabelle bleibt somit gleich, ich habe aber keine Ahnung wie NAV auf so etwas reagiert.

Volker

Hi,

ich habe das jetzt noch nie ausprobiert, aber falls SQL-Server als DB könnte man einen Datenbanktrigger erstellen, der Änderungen an der Tabelle selbst (nicht den Dtaen) abfängt und ins Nirvana schickt. Die zugrunde liegende SQL-Tabelle bleibt somit gleich, ich habe aber keine Ahnung wie NAV auf so etwas reagiert.

Volker

Das knallt spätestens dann wenn du versuchsts Änderungen über Forms zuzulassen.

Hallo vsnase,

dann müsste ich dem SQL-Server aber mitteilen können, dass es aus dem Objektdesigner heraus aufgerufen wird. Aus einer Form heraus solle es ja funktionieren.

Es ist aber auch nicht so wichtig. Ich werde dem Kunden verständlich machen, dass es über die Benutzerberechtigungen gesteuert werden muss. Wenn der absolute Sicherheit haben möchte, dann kann ich auch eine Tabelle anlegen die nur über eine CU gefüllt wird. Dann vergebe ich denen nur indirekte Schreibrechte und keiner von derern Usern bekommt Super-Rechte. Dann wäre das Ziel auch erreicht. Ich vermute aber, dass die soviel Aufwand gar nicht betreiben wollen.

EDIT: Danjo hat die Pole Position

Der SQL-Server kennt 2 Trigger-Typen. Einmal Trigger, die Daten verändern. Diese würden greifen, wenn ich Daten über Forms ändere.

Es gibt aber auch noch DDL-Trigger. Diese greifen, wenn man eine Tabelle änder, also praktisch das, was man üblicherweise über den Objekt-Designer macht. Und das könnte gehen. Nur wie gesagt, nie ausprobiert.

Volker

Es sollen auch nur die Feldwerte nicht im Object Designer verändert werden können. Das Tabellendesign ändern die ohnehin nicht. Das könnten die auch gar nicht, da die Benutzer auf dem SQL-Server keine db_owner sind sondern nur die Datenbankrolle public haben.

Ok, dann habe ich das faslch verstanden. Nichts desto trotz könnte man auch das abfangen, indem man in der Tabelle im OnModify ein Feld auswertet, das nur in der Form vorhanden ist (etwa DataFromForm:=TRUE;). Wenn nicht => Rollback.

Volker

Es sollen auch nur die Feldwerte nicht im Object Designer verändert werden können.

Dafür ist aber das ganz normale Rechtesystem im NAV zuständig. Es sollten aber nicht alle Benutzer mit SUPER arbeiten

Du kannst mit den Rechten steuern, welche Tabellen, wie bearbeiten werden dürfen, aber auch ob der Object-Designer überhaupt aufgerufen werden darf.

Gruß, Fiddi

Hallo Fiddi,

die arbeiten natürlich auch nicht alle als Super. Mit der Anforderung darf aber eigentlich außer uns als Dynamics Partner bei denen keiner mehr Super sein. Ich hatte halt gehofft, dass es irgendwo für eine Tabelle eingestellt werden kann. Es liegt aber eben in der Lizenz begründet.

Das einfachste wird sein, denen den Object-Designer per Rolle zu sperren, dann hast du normalerweise Ruhe.

Gruß, Fiddi