Is there an alternative to prevent access to a transaction?

[Former Member]

Hello Everyone!

Is there an alternative to prevent access to a standard transaction when a user has the S_TCODE value already? A custom program was created through batch input recording and there are transaction calls made to the standard transaction. I had to give the S_TCODE value for the program to run for the user, but one requirement was to force the user to use the custom t-code and not use the standard one. Unfortunately, I have provided the user access to the standard t-code as demanded by the program. Is there a way around this? I assume this has to be manipulated in the program.

Thanks!

[Former Member]

If no further intervention is needed, then you can execute the processing as a batch job with the SYSTEM type jobsstep user?

If the dialog user is processing the session in SM35 themselves or the job is executed in their name, then must also have been able to process the data manually.

In the stead of Batch Input, you should also consider redesigning the process to call a BAPI locally or via a group to process the data. This way they typically need the application authorizations but do not need an entry point to them such as S_TCODE or S_RFC.

Or reconsider the transaction code used in the Batch Input call?

Or reconsider the person (job function) who executes this processing?

Or give the originator of the data a webservice to process the data real time?

Lots of options...

Cheers,

Julius

[Former Member]

Thanks.

My custom transaction (mass upload function) is an end-user transaction based on recordings of IMA1N and IMA2N. Turns out they utilize authorization objects that cause one of the standard tcode meant for display only (IMA11) to unlock its create and change functions, which is a no no. Is there a workaround in bypassing the authchecks in the recorded transactions so IMA11 can remain display (by revoking the create and change auths meant for IMA1N and 2N)?

[Former Member]

Some transactions (e.g. FB03) have menu options to and use "change mode", but then they make the corresponding "change activity" authorization checks.

If the user would have been able to change anyway, then they can also change from many display transactions.

An option you have is to deactivate a check for the variant transaction from the SHD0 recording in SU24, but leave it active for the original transaction. But this does not always work and for "Enjoy" type transactions generally does not work.

SHD0 is anyway dead IMO. Create your own UI and call the corresponding BAPI to "do the work". This gives you much more flexibility and sometimes you have many more choices for how strict the authority checks should be if the calling application has taken care of the security.

Cheers,

Julius

[Former Member]

When you say deactivate a check in SU24, would it really bypass the auth-check in the transaction? I've been toying back and forth with whether it really does affect program behavior or the indicators in SU24 are mere documentations to make PFCG easier to maintain?

[Former Member]

No need to toy. Just try the real one to set an indicator to "no check".

Cheers,

Julius