OKP2 and KZS2 conflict on Table Auth group KC

[Former Member]

Hi,

We have a role that contains both OKP2  transaction KZS2, both are checking for Table Auth group KC on S_TABU_DIS. The requirment is to grant display access to OKP2 and maintain access to KZS2. I want to isolate which tables are in the table auth group KC for KZS2 and see if I can use S_TABU_LIN to grant maintain access to tables related to KZS2.

I set up a test user and traced but even when I removed S_TABU_DIS from the role and gave open access to S_TABU_LIN the system never checks for S_TABU_LIN. So I see that this approach will not work. Checking the code it does seem to be set up to check for S_TABU_LIN. I'm not sure if this is an error or expected behaviour. Both these programs are using structures and are not simple table views.

Any ideas on how to meet the requirment? Custom development of something like Z_KZS2 with different checks is not an option.

Like the new look of SCN (beta).

Cheers,

Carl

[Former Member]

I cannot say that I agree with you about the new look, but there is a new object called S_TABU_NAM.

Let the S_TABU_DIS check fail and you will see it appear --> access to table / view names.

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for your answer, I meant to say S_TABU_NAM. Odd, I just tested in a different client (the other client was closed for changes) and the trace now shows S_TABU_NAM. Thanks!

[Former Member]

In this case it is hardcoded against S_TABU_DIS instead of (correctly) calling FM VIEW_AUTHORITY_CHECK..  😞

You will have to report it to SAP and wait for a correction if you want to use S_TABU_NAM.

Cheers,

Julius

[Former Member]

BTW:  If you want to be able to change in OKP2 then you must ALSO be authorized for OKP1. So if you remove the tcode OKP1 from the user, then OKP2 is available only in display mode even if S_TABU_DIS authorizes changes.

You should see that check in the trace.

Cheers,

Julius

[Former Member]

The requirment was to grant access to KZS2 and OKP2 to the same user, but not grant maintain access to OKP2.

The solution as mentioned by Julius was to grant change access to KSZ2 via S_TABU_NAM and not via S_DABU_DIS.

The trick was that it was only possible for me to trace the requirements for S_TABU_NAM in a client with the correct settings (config client).

Many thanks Julius for the continued support. Where do you find the time?