Re: Authorization issue even if user has the correct role

Hi Sanjana

Again, did you make the assumption or did you take your analysis to a developer? I have no idea who "we" is in your replies.

Let's break it down

1. It is a custom transaction code so I am assuming it is a custom program
2. User has required authorisations
3. User has DATE FORMAT DD.MM.YYYY (or whatever)
4. User is not authorised (RC=4) in the trace file
5. User now has DATE FORMAT MM/DD/YYYY
6. User still has same authorisations and executes same transaction
7. User is now authorised (RC=0)

That is how you have explained it to us. In your explanation you have never said the user's authorisations changes - just their timezone.

The reason I conclude coding and why Julius mentions the pixies (and we're talking gremlins and not an awesome band) is that the program logic is askew.

Program Logic seems to be (not necessarily this simplistic) in following pseudo-code format.

If DATE FORMAT = "MM/DD/YYYY" Then

     XXXXXXX

      AUTHORITY-CHECK OBJECTX

     RC = 0 as the outcome --> it works

Else

     YYYYY

     AUTHORITY-CHECK OBJECTX (or another object?)

     RC = 4 as the outcome --> it does not work

End If

The possibilities could be:

• Different code is being executed based on the authority check (possibly even a different authorisation)
• The return code for the authority check is being handled differently (unlikely if you claim RC 0 in one scenario and RC 4 in another for the same user with the same roles).
• The authorisation check is for different permissions (for some reason the program is restricting based on timezone - not sure why?!?)

My recommendation

1. Take screen shot of SU56 user buffer for the user in question
2. Set time zone for scenario where it works and trace STAUTHTRACE and ST01 showing the execution - see the results
3. Set time zone for the scenario where it fails and repeat the trace
4. Send analysis to the developer and tell them to fix their code (or at least debug the code and prove to you that it is security)

If not, go back through your assumptions and check what your analysis is to see if you missed something. Regardless, stop make general claims (few users facing it and few users not). Instead deal with specifics - which users? which transaction? which program? which authorisation? Do all users have that authorisation in their user buffer (SU56) to rule out profile corruption. For the users with the issue, do they have the same DATE FORMAT? For the users receiving the error do they have the DATE FORMAT MM/DD/YYYY (the one that is meant to work).

End of the day, you need to analyse this and break down the logic.

Regards

Colleen