Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to assign auth group through RSCSAUTH

Former Member
0 Kudos

Please let me know how to assign auth group to custom program through RSCSAUTH,

I can do this through se38 but I dont have access/dev key

Ajay

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Julius,

Thank you, I will check this and also can we use the auth group one we created in se54 or it is only good for tables ??

5 REPLIES 5

Former Member
0 Kudos

Not sure if there is another methode, but anyway the request for a developer key indicates that it should be done by an Abapper, who should always do this when writing new abaps!!

Former Member
0 Kudos

If you try to change the authorization group of a program from the Attributes screen of the ABAP Editor (SE38), the system throws a warning message at you advising that you use RSCSAUTH. There is a good reason for this, and also how to use RSCSAUTH, which is in the documentation of RSCSAUTH (select the "Documentation" button on it).

Cheers,

Julius

Former Member
0 Kudos

Julius,

Thank you, I will check this and also can we use the auth group one we created in se54 or it is only good for tables ??

0 Kudos

The auth groups in SE54 are for BEGRU (German = "BErechtigungsGRUuppe"; English = "Authorization Group") of tables (in table TBRG) and other objects which use BEGRU.

The available Authorization Groups of ABAP report programs are different (they are a longer field in table TPGP, and texts in TPGPT).

Check your system (and SAP notes for your release) for the correct transaction or program to define the available "Auth Groups" for S_PROGRAM.

I know that in earlier times you could assign an auth group to a report which was not defined in TPGP and the system gave a warning message about this possible inconsistency with the conventions for report auth group names, but as before you can accept the warning (German = "Selber schuld"; English = "Your own fault"

A small comment, my opinion only: There certainly are reports which need S_PROGRAM authorization groups on them. For example standard ones delivered without checks, or ones for which you want to protect the maintenance of a variant to a group of persons and not just a single user, using P_ACTION = 'VARIANT' of S_PROGRAM which only kicks in once an auth group is assigned to the report (see RSVARENT for an example of both) - but assigning an S_PROGRAM group to a report is a bit of an "all or nothing" security to run the whole report... so it is a "hardcore" way to protect reports, variants and background programs, but also a bit of a primitive one.

Cheers,

Julius

Former Member
0 Kudos

Julius,

Got it !!! thanks a lot

Ajay