Berechtigung auf Satzebene vergeben?

[Schnichels]

Hallo,

ist es möglich in einer PF oder LF Berechtigungen auf Satzbebene zu vergeben?

Hintergrund ist, dass eine externe Mitarbeiterin nur Zugriff auf bestimmte Aufträge und den dazugehörigen Kunden haben soll. Wir könnten natürlich in die betreffenden Files ein Satuskennzeichen einfügen, welches dann in den betreffenden Programmen abgefragt wird. Wir haben aber keine grosse Lust dazu, die ganzen Files und Programme anzupacken. Kann man evtl. Join-LF's erstellen, die
man über die Auftragsdatei und eine neu zu erstellende Datei mit den betreffenden Auftragsnummer legt? Im Startmenü der Mitarbeiterin könnten wir dann ein OVRDBF auf die Join-LF's machen.

Oder gibt es noch eine bessere Möglichkeit?

mfg

Jürgen Schnichels

[RobertMack]

Hallo,

die Lösung über Join-LF ist nicht nur die eleganteste, sondern auch die zuverlässigste ...

Wegen des ggf. veränderten Satzformates (zus. Feld/er) muss dann evtl. auch der "normale" Zugriff über eine Join-LF (diesmal ohne Einschränkung) geschehen.

Gruß,
Robert

[BenderD]

Hallo Jürgen,

das dürfte Probleme geben, mit den Join Files, die sind nämlich read only und ob das die Programme vertragen, das könnte fraglich sein.
Mit SQL Views kann man das read only Problem mit einem Subselect in der Where Klausel vermeiden, aber das gibt mit Rekord Löffel Exzess und das OVRDBF sieht eher danach aus, Probleme mit dem Zugriffspfad.
Der OVRDBF ist ebenfalls nicht so ganz ohne, wenn da in der Applikation irgendwo ein DLTOVR hängt, dann könnte auch das daneben gehen.
Wenn alles SQL basiert ist, dann geht es eleganter mit dem oben erwähnten Subselect in der Where Klausel, in dem man auch Referenz auf das SQL Register Current_User nehmen kann, sodass dieses View Layer Benutzer bezogen unterschiedliche Sätze liefert, dann kann man die Tables schnöde renamen und die Views so nennen, wie die Tables vorher et Voila.

mfg

Dieter Bender

Hallo,

ist es möglich in einer PF oder LF Berechtigungen auf Satzbebene zu vergeben?

Hintergrund ist, dass eine externe Mitarbeiterin nur Zugriff auf bestimmte Aufträge und den dazugehörigen Kunden haben soll. Wir könnten natürlich in die betreffenden Files ein Satuskennzeichen einfügen, welches dann in den betreffenden Programmen abgefragt wird. Wir haben aber keine grosse Lust dazu, die ganzen Files und Programme anzupacken. Kann man evtl. Join-LF's erstellen, die
man über die Auftragsdatei und eine neu zu erstellende Datei mit den betreffenden Auftragsnummer legt? Im Startmenü der Mitarbeiterin könnten wir dann ein OVRDBF auf die Join-LF's machen.

Oder gibt es noch eine bessere Möglichkeit?

mfg

Jürgen Schnichels

[Schnichels]

Hallo,

danke für die Antworten.

Join-Files können echt nur read only? Das war mir nicht bewusst.

Bei den Programmen die wir einsetzen ist nichts SQL basiert. Alles "normales" RPG mit PF's und LF's.

mfG

Jürgen Schnichels

[RobertMack]

... wie sieht denn die Anwendung aus?

I.d.R. hat man eine Subfile (sowieso nur read) aus der man dann einen Satz zur Bearbeitung auswählt.

Wenn nun das Programm eine zusätzliche LF/JF zum Füllen der Subfile erhält, bleibt der Rest gleich. Denn wo nix auszuwählen ist ist auch nix mit Zugriff.

Gruß,
Robert, pragmatisch.

[BenderD]

Hallo,

mal ganz pragmatisch:
in der Regel öffnte man dann in dem Programm, das den Einzelsatz anzeigt dieselbe Datei, wie in dem Subfile, diesmal zum Update und Peng!

mfg

Dieter Bender

... wie sieht denn die Anwendung aus?

I.d.R. hat man eine Subfile (sowieso nur read) aus der man dann einen Satz zur Bearbeitung auswählt.

Wenn nun das Programm eine zusätzliche LF/JF zum Füllen der Subfile erhält, bleibt der Rest gleich. Denn wo nix auszuwählen ist ist auch nix mit Zugriff.

Gruß,
Robert, pragmatisch.

[Schnichels]

Hallo,

es handelt sich um die Auftragsbearbeitung und die Kundenstammbearbeitung. Beides definitiv mit UPDATE und WRITE.

Gruss

Jürgen Schnichels

[BenderD]

Hallo Jürgen,

da geht an einem Redesign der Anwendung nix vorbei!!!
1. Schritt: Erstellung einer SQL basierten separaten Datenbankzugriffsschicht, die analog zu jedem Rekord Löffel Exzess Zugriff eine Procedure anbietet, die das gleiche liefert.
2. Schritt Austausch der Rekord Löffel Exzess Zugriffe durch die entsprechenden Callp Aufrufe (geht auch mit CALL, wenns denn kein ILE ist, was ich mal so vermute).
3. In der nunmehr SQL Zugriffsschicht, kann man dann auf die Subselect Variante zurück greifen.
Wenn man das geschickt einfädelt, kann man den Aufwand durch Generierung minimieren - ganz wenig wird es nicht werden, Designschwächen werden halt bestraft.

Dieter Bender,
grundsätzlich

Hallo,

es handelt sich um die Auftragsbearbeitung und die Kundenstammbearbeitung. Beides definitiv mit UPDATE und WRITE.

Gruss

Jürgen Schnichels

[RobertPic]

1. Hier noch folgende Alternative:

Wir hatten vor den Internetzeiten, Zugänge für unsere Kunden auf die AS/400. Auch die Kunden durften mit unserer Auftragsbearbeitung arbeiten.

Wir lösten das Problem mit eigenen Bildschirm-DDS-Files, welche bei der Anmeldung vorne (in die Libl) reingehängt wurden.

In unseren Fällen war die Kundenummer einfach immer vorausgefüllt (Default) und nicht änderbar (Achtung! muss ein Inputfeld bleiben, sonst Lvlchk). Ob es in deinem Fall mit vorausgefüllten und gesperrten Feldern geht, kann ich für deine Applikation nicht sagen. Bei uns wäre das auch mit der Verkäufernummer gegangen.

2. Noch zum Thema Joinlog + WRITE und UPDATE:

Ob das funktioniert, hängt natürlich von der Machart der Applikation ab.

Mitunter wird das Subfile ja wegen der Sortierung aus einer logischen Datei aufgebaut (diese ist dann zur Joinlogischen "hingebogen"), wenn der Auftrag/Kunde ausgewählt wurde, wird wieder mit der PF-Datei gearbeitet, welche aber kein Override benötigt, da der Sachbearbeiter bereits vorher eingeschränkt wurde.

Eventuell kommt man ja mit einem Mix aus 1 und 2 hin.

LG Rob

PS: Wenn es irgendwie geht, schmeiße ich 3GL-Programme natürlich weg und schreibe sie mit LANSA/VB6/VB.NET/Access/Perl neu