Help Documentation AUTHORITY_CHECK_TCODE

[Former Member]

Please help me to understand this documentation.

(This is the documentation of Function module AUTHORITY_CHECK_TCODE)

What does the diff values of the profile parameter auth/check/calltransaction means??

auth/check/calltransaction (default = 2) =>> means authorization is checked at kernal level?

Am i right?

What does different values of this profile parameter indicates. (say 0,1).

Another thing which confuse me is what does n,j stands for.??

Also, what is the difference between the two??

The function modules behaves differently in each case (call in the calling transaction, call in the called transaction).

Also, what does the values of table TCDCOUPLES Mean?

What effect does the value of Check Indicator 'X' makes , while calling transaction from Command Box.

What effect does the value of Mssg Type 'X' makes , while calling transaction from Command Box.

[Former Member]

I'll take the easy but not so obvious part of the question...  😉

n = "nein" = "no" (no check)

j = ""ja" = "yes" (as in yes, it is checked)

Cheers,

Julius

[Former Member]

okay, what does table TCDCOUPLES fields stands for:

What happens when:

Check indicator is 'X'.

Mssg Type 'X'.

Also i asked what is the diff between the two:

call in the calling transaction, call in the called transaction).

[asaithambi]

Table TCDCOUPLES is used to check a t-code(calling t-code) that calls another t-code(called t-code).

Check Inidicator 'X' is used check Authorization check for called t-code in S_TCODE.

Mssg Type 'X' is used to return warning when called t-code ended with warning

Ex: While executing the t-code SM37(calling) its calls the t-code SM36(called) while executing. If Check Inidicator 'X' is maintained then it check the user buffer for S_TCODE with SM36. If Mssg Type 'X' is maintained if SM36 returns a warning then it will display the warning message in SM37 screen

[Frank_Buchholz]

Note 515130 shows the same information about (undocumented) profile parameter auth/check/calltransaction.

The columns of the tables shown in the note and in the documentation explain the meaning of the values of the profile parameter in quite technical terms.

Anyway, you do not want to change the default (because of this, the parameter is not documented) which produces following standard result:

CALL TRANSACTION does not perform an authority check for S_TCODE unless there exists a corresponding entry in table TCDCOUPLES with value Y = yes.

If a developer wants to force an authority check for S_TCODE as part of CALL TRANSACTION he/she either

• can create an entry in TCDCOUPLES with value Y = yes using transaction SE93 (if the calling transaction is known) or
• can use CALL FUNCTION 'AUTHORITY_CHECK_TCODE' just before CALL TRANSACTION. 

Kind regards

Frank

[Former Member]

IMO the best use of the function module is to call it in the initialization of the called transaction. That way you can also control the start authorization if the user runs the application from the ABAP workbench and only need to maintain it's functional equivalent friends in SE97 for which a CALL TRANSACTION is allowed to skip the check.

This is more efficient and bullet proof than turning all checks on in SE97.

I think this is what confused the guru -> you can use the FM before the call but also very effectively after the call.

Cheers,

Julius

[Former Member]

Ps: if the called transaction offers any "Other objects" or "Other document" search help navigation, then passing parameters in the call looses it's security power. So it is a good candidate for calling the FM in the target tcode start events. Actually, the tcode is not a good candidate for CALL TRANSACTION in the first place in those cases.

Nice example is ME21N and also SU01. You cannot call them, and for non-dialog processing they have BAPIs so no need for Batch-Input calls to commit screens...

Cheers,

Julius

[Former Member]

CALL TRANSACTION does not perform an authority check for S_TCODE unless there exists a corresponding entry in table TCDCOUPLES with value Y = yes.

Y = Yes, i dont understand that.which field contains the entry YES.?

I cannot see the note  as i dont have s user id.

But my question is still unanswered, what happens what value of profile parameter

auth/check/calltransaction changed to 0, or  1.

[Frank_Buchholz]

The parameters controls if CALL FUNCTION 'AUTHORITY_CHECK_TCODE' respective CALL TRANSACTION perform an authority check for S_TCODE or not depending on the (optional) settings in table TCDCOUPLES (which can be maintained using transaction SE93). 

The screen pictures above from the documentation in function AUTHORITY_CHECK_TCODE already show the system reaction, however, let's swap the  columns and replace yes with 'X' as this value is used in the table:

auth/check/calltransaction	TCDCOUPLES-OKFLAG	CALL FUNCTION 'AUTHORITY_CHECK_TCODE'	CALL TRANSACTION
0 = always off	independant	no check	no check
1 = always on	independant	check	check
*2* = default, lazy call transaction	X (yes)	check	check
	N (no)	no check	no check
	*no entry or empty*	*check*	*no check*
3 = strong call transaction	X (yes)	check	check
	N (no)	no check	no check
	no entry or empty	check	check

The field TCDCOUPLES-MAINTFLAG defines the severity of the error message (info, error, dump, ...) if the authority check fails.

Developers use CALL FUNCTION 'AUTHORITY_CHECK_TCODE' before CALL TRANSACTION to force the authority check for S_TCODE, see line marker with *.

Using auth/check/calltransaction = 0 would be a quite bad idea, but auth/check/calltransaction = 1 or 3 is not much better as it would force you to adjust your authorization concept and it would force you to grant authorizations for S_TCODE to users which should not get them.

(For now I've skipped the part where CALL FUNCTION 'AUTHORITY_CHECK_TCODE' is executed within the called transaction.)

Kind regards

Frank