Selektion zur Berechtigung
Berechtigungen und die dazugehörigen Berechtigungsprüfungen sind eine mitunter eine knifflige Angelegenheit. Bei einzelnen Werten ist es einfach, diese mit der entsprechenden Berechtigung zu prüfen. Wenn es jedoch um Selektionen geht, bei denen der Anwender nur die Berechtigung über einen Teil der Daten hat, dann wird es schon schwieriger…
Problem – Selektionsoptionen
Bei dem hier beschriebenen Problem hat der Anwender bei einem Report die Möglichkeit, ein Objekt über Selektionsoptionen (SELECT-OPTIONS) einzugrenzen. Hierfür muss ich jedoch wissen, welches die zu Grunde liegende Prüftabelle mit allen existierenden Daten ist.
Beispiel Verkaufsorganisation
Der Anwender selektiert Verkaufsorganisationen A* und B*. Der Anwender hat jedoch nur die Berechtigung für A200 und B330.
In der Prüftabelle für die Verkaufsorganisationen (Tabelle TVAK) sind die folgenden Verkaufsorganisationen gepflegt:
Vkorg | Bezeichnung |
A100 | Deutschland Gebiet Nord |
A200 | Deutschland Gebiet Süd |
A300 | Deutschland Gebiet West |
A400 | Deutschland Gebiet Ost |
B330 | Nord-Italien |
B340 | Süd-Italien |
C500 | Spanien |
Lösung A – Vorselektion
Bei dieser Lösungsvariante wird vorab geprüft, für welche Objekte der Anwender die Berechtigung hat. Man würde also die tatsächlich vorhandenen Einträge aus der Prüftabelle selektieren und für jeden Eintrag prüfen, ob der Anwender die entsprechende Berechtigung hat.
Mit den verbleibenden Einträgen kann man entweder eine dynamische WHERE-Bedingung bauen oder baut aus diesen Einträgen eine genaue Ranges-Tabelle auf.
Lösung B – Einzelprüfung der Daten
Es gibt natürlich auch die relativ einfache Möglichkeit, alle Daten einzulesen und dann bei jedem einzelnen Datensatz zu prüfen, ob der Anwender berechtigt ist, ihn zu sehen. Das ist einfach zu programmieren, kann jedoch bei großen Datenmengen ein erhebliches Laufzeitproblem werden.
Unterstützung
Durch Zufall bin ich auf die Klasse CL_AUTH_OBJECTS_TO_SQL gestoßen. Mit Hilfe dieser Klasse wird der Lösungsweg A eingeschlagen. Allerdings ohne, dass ich als Programmierer wissen müsste, welches die Zugrunde liegende Prüftabelle ist und ohne, dass ich die WHERE-Bedingung selber erstellen müsste.
Der Klasse müssen folgende Daten übergeben werden:
- das zu prüfende Berechtigungsobjekt
- die Aktivität (Anzeigen, Ändern, Löschen etc)
- Ein Field Mapping (DDIC-Grundlage der Felder)
- optional: Filter für die Einschränkung auf Objekte
Mit GET_SQL_CONDITION bekommt man dann die WHERE-Bedingung für die Felder zurück, für die der Anwender eine Berechtigung hat.
Folgendes kleine Beispiel zeigt die Anwendung für die Klasse.
Code
DATA h_vkorg TYPE vkorg.
SELECT-OPTIONS s_vkorg FOR h_vkorg DEFAULT 'A100'.
START-OF-SELECTION.
DATA(lo_converter_osql) = cl_auth_objects_to_sql=>create_for_open_sql( ).
lo_converter_osql->add_authorization_object(
iv_authorization_object = 'V_VBAK_VKO'
it_activities = VALUE #(
( auth_field = 'ACTVT' value = '03' ) )
it_field_mapping = VALUE #(
( auth_field = 'VKORG'
view_field = VALUE #(
table_ddic_name = 'VBAK'
table_alias = ''
field_name = 'VKORG' ) ) )
it_filter = VALUE #( FOR selopt IN s_vkorg[]
( auth_field = 'VKORG' low = selopt-low high = selopt-high ) ) ).
TRY.
DATA(lv_where_clause) = lo_converter_osql->get_sql_condition( ).
IF lv_where_clause IS INITIAL.
MESSAGE 'Du hast die Berechtigung für alle ausgewählten Verkaufsorganisationen' TYPE 'I'.
ELSE.
cl_demo_output=>display_text( |Deine WHERE-Bedingung: { lv_where_clause }| ).
ENDIF.
CATCH cx_auth_not_authorized.
MESSAGE 'Keine Berechtigung für die ausgewählten Verkaufsorganisationen' TYPE 'I'.
ENDTRY.
- Meine Eclipse-Plugins - 22. November 2024
- Interview mit Björn Schulz (Software-Heroes.com) - 3. September 2024
- Daten aus ALV ermitteln - 3. September 2024