Berechtigung für Tabellenpflege für Felder einschränken
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Beitrag
von Der Formulator (ForumUser / 34 / 8 /
0
)
»
Hallo Forum,
ich habe die Transparente Tabelle ZINVOICE_TAB mit folgenden Feldern angelegt:
MANDT
VKORG
VTWEG
SPARTE
FELD1
FELD2
FELD...
Jetzt möchte ich einen Pflegeview für diese Tabelle anlegen. Das bekomme ich noch hin. Aber zusätzlich soll es den Benutzern nur möglich sein, Daten von Verkaufsorganisationen zu ändern, für die sie auch eine Berechtigung haben. Ich muss also eine Berechtigung auf das Feld VKORG legen.
Ganz ehrlich? Ich programmiere seit 20 Jahren ABAP, habe das aber noch nie gemacht und deshalb keinen blassen Schimmer, wie das gehen soll.
Vielleicht kann mir ja hier jemand von den Experten weiterhelfen.
Schon mal vielen Dank...
ich habe die Transparente Tabelle ZINVOICE_TAB mit folgenden Feldern angelegt:
MANDT
VKORG
VTWEG
SPARTE
FELD1
FELD2
FELD...
Jetzt möchte ich einen Pflegeview für diese Tabelle anlegen. Das bekomme ich noch hin. Aber zusätzlich soll es den Benutzern nur möglich sein, Daten von Verkaufsorganisationen zu ändern, für die sie auch eine Berechtigung haben. Ich muss also eine Berechtigung auf das Feld VKORG legen.
Ganz ehrlich? Ich programmiere seit 20 Jahren ABAP, habe das aber noch nie gemacht und deshalb keinen blassen Schimmer, wie das gehen soll.
Vielleicht kann mir ja hier jemand von den Experten weiterhelfen.
Schon mal vielen Dank...
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von PeterPaletti (Specialist / 348 / 32 /
97
)
»
Man könnte in der Pflegeoberfläche mit eigenen Routinen zu bestimmten Zeitpunkten eingreifen. So zum Beispiel beim Einlesen (Zeitpunkt AA) oder Hinzufügen von Daten (Zeitpunkt 05) die Berechtigungsprüfung auf VKORG hinterlegen und entsprechend die Daten für die jemand nicht berechtigt ist gar nicht erst einlesen oder ihm beim Hinzufügen auf die Finger klopfen.
Auf die Zeitpunkt hätte ich jetzt auch hingewiesen. Allerdings ist zu klären, ob 05 (beim Hinzufügen eines neuen Eintrags) oder AA (an Stelle der Standardroutine für das Einlesen der Daten) überhaupt den Anforderungen entsprechen. Kann ja auch sein, dass der Anwender die Felder, die er nicht ändern können darf inaktiv hat. Dann wird es allerdings kompliziert.
In AA würde man die Daten u.U. gleich ausschließen und der Anwender sieht dies gar nicht erst.
Entscheidend ist aber, was auf die Datenbank geschrieben wird. Also der Anwender erst falsche Eingabe macht, die dann geprüft werden. Hier gibt es die Zeitpunkt 01 (vor dem Sichern der Daten in der Datenbank). Den würde ich auf alle Fälle ausprägen. Dann 08 (nach erfolgtem Korrigieren des Inhalts eines ausgew. Feldes) oder 18 (nach der Prüfung, ob die Daten verändert wurden), dann bekommt es der Anwender noch vor dem Speichern mit - also bei Enter oder andere Aktion.
In 01, 08 und 18 werden bei uns Daten gegen eine andere DB-Tabelle verprobt, die in der PflegeView selbst nicht enthalten ist. Also so etwas ähnliches wie die Berechtigungsprüfung.
Der Code dazu grob so. Entscheidend, dass bestimmte Deklaration bereits durch die SAP definiert sind - z.B. TOTAL, <action>...:
Die gleiche FORM-Routine hängt bei uns in allen drei genannten Zeitpunkten.
In AA würde man die Daten u.U. gleich ausschließen und der Anwender sieht dies gar nicht erst.
Entscheidend ist aber, was auf die Datenbank geschrieben wird. Also der Anwender erst falsche Eingabe macht, die dann geprüft werden. Hier gibt es die Zeitpunkt 01 (vor dem Sichern der Daten in der Datenbank). Den würde ich auf alle Fälle ausprägen. Dann 08 (nach erfolgtem Korrigieren des Inhalts eines ausgew. Feldes) oder 18 (nach der Prüfung, ob die Daten verändert wurden), dann bekommt es der Anwender noch vor dem Speichern mit - also bei Enter oder andere Aktion.
In 01, 08 und 18 werden bei uns Daten gegen eine andere DB-Tabelle verprobt, die in der PflegeView selbst nicht enthalten ist. Also so etwas ähnliches wie die Berechtigungsprüfung.
Der Code dazu grob so. Entscheidend, dass bestimmte Deklaration bereits durch die SAP definiert sind - z.B. TOTAL, <action>...:
Code: Alles auswählen.
LOOP AT total.
CHECK <action> NE original.
ASSIGN COMPONENT 'VKORG' OF STRUCTURE <vim_total_struc> TO <value>.
IF sy-subrc <> 0.
CONTINUE.
ENDIF.
lv_VKORG = <value>.
"Deine Berechtigungsprüfung auf lv_VKORG
if sy-subrc = 0.
vim_abort_saving = abap_true.
MESSAGE i123(abc) WITH lv_VKORG DISPLAY LIKE 'E'.
endif.
ENDLOOP.
Ich würde dazu tatsächlich das generierte Dynpro modifizieren und einen eigenes PBO-Module aufrufen.
Allerdings auch in Verbindung mit anderen Events, denn wenn du nur die Felder der Tabelle auf "nicht eingabebereit" setzt, kann der Anwender trotzdem den Eintrag markieren und löschen und ggfs. wieder neu mit "seinen" Werten anlegen.
Wenn du auch die Markierspalte auf "nicht eingabebereit" setzt, dann kann der Anwender den Eintrag zwar nicht markieren und demzufolge auch nicht löschen, aber er kann den Eintrag dann auch nicht auf eine andere Vkorg kopieren.
Zusätzlich kann immer noch mit "Alle Einträge markieren" auch der Eintrag markiert werden, für den der Anwender keine Berechtigung hat und diesen dementsprechend auch löschen...
Es gibt in Pflegedialogen unendlich viele Stolperfallen.
Selbst wenn du ein Feld auf "nicht eingabebereit" setzt, kann der Anwender noch über die Funktion "Feldwerte" ändern, die Werte für alle Einträge anpassen: Du musst also unglaublich viel testen.
Am sichersten ist die Lösung von PeterPaletti: Einträge, für die es keine Pflegeberechtigung gibt, gar nicht erst anzeigen.
Wenn du auch die Markierspalte auf "nicht eingabebereit" setzt, dann kann der Anwender den Eintrag zwar nicht markieren und demzufolge auch nicht löschen, aber er kann den Eintrag dann auch nicht auf eine andere Vkorg kopieren.
Zusätzlich kann immer noch mit "Alle Einträge markieren" auch der Eintrag markiert werden, für den der Anwender keine Berechtigung hat und diesen dementsprechend auch löschen...
Es gibt in Pflegedialogen unendlich viele Stolperfallen.
Selbst wenn du ein Feld auf "nicht eingabebereit" setzt, kann der Anwender noch über die Funktion "Feldwerte" ändern, die Werte für alle Einträge anpassen: Du musst also unglaublich viel testen.
Am sichersten ist die Lösung von PeterPaletti: Einträge, für die es keine Pflegeberechtigung gibt, gar nicht erst anzeigen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von Der Formulator (ForumUser / 34 / 8 /
0
)
»
Danke für die vielen tollen Antworten.
Scheint doch komplizierter zu sein, als ich dachte.
Ich hatte gehofft, ich könnte beim Tabellenpflegegenerator einfach eine Berechtigungsguppe angeben (die eventuell noch anzulegen wäre), und gut isses...
Naja, dann muss ich mal schauen, wie ich da durchkomme...
Danke nochmals!
Scheint doch komplizierter zu sein, als ich dachte.
Ich hatte gehofft, ich könnte beim Tabellenpflegegenerator einfach eine Berechtigungsguppe angeben (die eventuell noch anzulegen wäre), und gut isses...
Naja, dann muss ich mal schauen, wie ich da durchkomme...
Danke nochmals!
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2180
Views
Views
5
Antw.
Antw.
7061
Views
Views
HR Berechtigung auf eine Personalnummer einschränken
von DIL » 24.02.2005 09:46 • Verfasst in Human Resources
von DIL » 24.02.2005 09:46 • Verfasst in Human Resources
1
Antw.
Antw.
1272
Views
Views
5
Antw.
Antw.
22451
Views
Views
10
Antw.
Antw.
4480
Views
Views
Tabellenpflege mit Datumslogik generieren
von SAP_ENTWICKLER » 05.07.2016 16:05 • Verfasst in ABAP® Core
von SAP_ENTWICKLER » 05.07.2016 16:05 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor einer Stunde von ralf.wenzel 104 / 9953
vor einer Stunde von ralf.wenzel 104 / 9953
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor einer Stunde von ralf.wenzel 104 / 9953
vor einer Stunde von ralf.wenzel 104 / 9953