Fake auth. Objects in SU53 screen

[Former Member]

Could you please help me how to find out the list of dummy or fake authorization objects that we get in SU53?

For example some auth. Objects will be listed as missing in the SU53 screen but they don't actually exist in SAP. One example that I know is object "S_TRANSLATE".

Had anyone of you came across a situation like this?

[WolfgangJanzen]

Well, using AUTHORITY-CHECK for a non-existing authorization object is identical to using a SELECT statement for a non-existing table: both result in SY-SUBRC <> 0.

<u>Notice</u>: authorization objects are (like tables or any other repository objects) part of a package (formerly called "development class") shipped as part of a software component. Some repository objects might only exist in certain software components (e.g. HR objects might not exist in BI systems).

However, I would consider it a "package problem" if a coding is using an object which is not contained in that package (or any underlying package). It's a matter of depedency relationships.

Can you provide a concrete example of such a mismatch?

Have you reported this to SAP (if SAP objects are involved)?

Cheers, Wolfgang

[Former Member]

Hi Lakshmi,

I have encountered this Object only whenthe user is not able to Hit Su53 as soon as he has encountered an issue. If he tries to click the error message or earning or somethibng else on the screen and then hits SU53, S_TRANSALTE oddly pops up as the cause.

Apart from this object i never came across any other object which is depicted wrongly in SU53..

Hope it helps..

VBr,

Sri

Award points for helpful answers

[Former Member]

I cannot give you a list but I do see them from time to time. If I suspect that something on an SU53 is bogus then I run a trace. What happens sometimes is the auth check that it is really bombing on is not the one you see on the SU53. The program may check the one it needs and then looks for alternatives. The SU53 will always show the last one checked but the first one checked and bombed on could be exactly what they need and this will only be apparent through tracing. I find that the S_TRANSLAT error occurs when I user has clicked on the message to read the help before doing the SU53.

[WolfgangJanzen]

Ah, I see.

Well, SU53 displays the <b>last failed</b> authorization check. If an application implements a fallback strategy (submitting subsequent authorization checks after a previous one has failed) that could explain what you are describing.

In that case, you need to activate the <b>authorization trace</b> (using ABAP transaction ST01). Then you will be able to see <u>all</u> authorization checks that have been performed (successful and unsuccessful ones).

Cheers, Wolfgang