Differences

This shows you the differences between two versions of the page.

--- abap:autorisations [2015/05/11 15:47] – [Authority check] ginko
+++ abap:autorisations [2020/01/24 16:59] (current) – [Transactions utiles] ginko
@@ Line 8: / Line 8: @@
   * SU53 : Last authorization check log (voir ce qui manque lors d'un refus d'autorisation)
   * SE54 : Génération dialogue de gestion de tables > accès table/vue > Groupes d'autorisation
+  * SUIM : Navigation/recherche dans le contenu des divers objets d'autorisations
 ===== Classes d'objets & objets d'autorisation classiques =====
@@ Line 33: / Line 34: @@
   * Objet O1, C1 = A, C2 = D  => Forbidden (La combinsaison A-D n'existe pas)
   * Objet O1, C1 = C, C2 = B  => Granted (par combinaison C-*, la combinaison C-D n'est pas considérée comme limitante)
+**__NB__ : Cela signifie que si un user porte un mélange de rôles restreint sur un niveau organisationnel et d'autres non limités (avec un ''*''), TOUS les objets portés par les rôles non limités prendront le pas sur leurs équivalents limités.**
 ==== Contrôle du code transaction ====
@@ Line 83: / Line 86: @@
   * Si les critères que l'on recherche ne sont pas dispo, regarder les objets maintenus en SU24.
   * Si toujours rien, il faudra faire de nouveaux objets d'autorisation.
+===== Bug analysis =====
+Une différence entre la définition des rôles et les accès réels par les users peut avoir 2 origines :
+  * La génération (la transcription d'un rôle en profile - ''PFCG'', ''SUPC'')
+  * L'assignation (l'entrée correspondant au profile dans la user master data ''USRBF2'', ''UST12'' - ''SU01'', ''PFUD'')
+Pour l'analyse, toujours partir du profile utilisateur (''SU01''). Tester en direct. Tracer avec ''ST01''.
+En cas de problème tenace, activer les traces SQL (toujours en ''ST01'').
+NB :
+  * le menu de l'utilisateur est construit à partir des rôles (tables ''AGR*'') il ne dépend pas des profiles.
+  * Au contraire, la ''SUIM'' lit les profiles.
+=> On peut donc se reposer sur une différence entre menu et ''SUIM'' pour détecter un problème de génération/assignation.
+===== Pseudos AUTHORITY-CHECK =====
+Dans certains cas la trace des authority-checks "ment" : la transaction peut remonter des défauts d'authorisations alors que la trace ne montre que des RC=0. En passant par le MF SUSR_USER_AUTH_FOR_OBJ_GET, le programme peut récupérer des autorisations sans AUTHORITY-CHECK. Ex : la restriction sur la division en MI20.