Few authorization changes happen automatically

[former_member195427]

Hello Experts,

We restricted few users from using transaction CJI3 & CJI5. We did not touch any other control/settings.Now, what we observed is that few users who were using t-code CJ20N earlier are not authorize to use it now. We remember that we provided them authorization for creating WBS in CJ20N earlier but now they are not authorized to use CJ20N itself.

I provided them CJ20N -> WBS creation roles again with the help of Basis guy and it worked for that user. But I am still unsure of why this change happend automatically once after we restricted user to use CJI3 and CJI5 ( we removed it on t-code basis).

Kindly suggest on it.

Thanks & Regards

Saurabh

[m_coenjaerts · Accepted solution]

Hello

It is possible that somehow the CALL TRANSACTION checks changed for CJ20N? (Transaction SE97 to maintain settings). There you can configure that, when a program/transaction calls a different transaction (so CJ20N calling CJI3), if SAP executes a check on S_TCODE..So in case this is active for CJ20N, then the users need to have access to CJI3 also. By changing the check indicators is SE97 you can change this behavior.

I checked in one of our development SAP systems (ECC 6.0) and in our system the check from CJ20N to CJI3 is not active.

SAP Note 358122 describes the functionality of SE97.

[former_member195427 · Accepted solution]

Thanks for your response Marc. Please see the following screen shot:

It shows that for CJ20N the CALL TRANSACTION CJI3 is inactive, Am I correct? Do I need to change anything here?

Thanks

[m_coenjaerts · Accepted solution]

Ok,

Thanks for the input, we have the same setting in our system.. This would indicate that for indeed for CJ20N no check is executed when it calls CJI3. However there are also some SAP notes indicating that the SE97/TCDCOUPLES is not always behaves as described

You could do an authorization trace (via ST01) on a user who has the issues (so the issue that the user cannot start CJ20N when that same user does not have access to CJI3). If indeed the CJI3 is called via CJ20N you would see a 'failed' check on S_TCODE=CJI3. If this shows up in the trace then this is still an indication that CJI3 is checked when called from CJ20N. If then this same situation can be replicated to a sandbox/dev environment, then you check explicitly set the flag in SE97 to 'Not Check/Information' for the CJI3, called from the CJ20N. And then check the same error still occurs.in that system (also verified by an authorization trace).

If no S_TCODE check for CJI3 pops up, or the changing of the SE97 setting for CJ20N -> CJI3 has no effect, then the cause of the issue is at least not caused by the 'call transaction' mechanism.