Question:
Hi All,
Below what i got from John A. Jarboe in Basis forum, i would to ask some question:-
1)
You will have to transport the SREOPAUTH (SP?) table to production and use the restore option to reapply or run RSCSAUTH in production.
What is (SP?) and why do i need to transport this table to production as i plan to set the authorization direct in production?
2)
All this work is useless if the user has access from another profile or role that overrides what you have done.
How can i check for example S_PROGRAM is also set in another profile/role? I noticed in some role assigned to users already have S_PROGRAM with P_GROUG (asterick *) and P_ACTION assigned SUBMIT, BTCSUBMIT, VARIANT.
3) I created new role and assigned user the report with S_PROGRAM P_GROUP assigned to the Auth. Group which i assigned using RSCSAUTH. Also for P_ACTION i assigned only BTCSUBMIT.
Now in doing this i can restrict user not able to run in foreground, but when they schedule to run in background it said that they need SUBMIT authorization to run the program. How can i fix this?
Thank you very much for your help.
Answer:
How can i check for example S_PROGRAM is also set in another profile/role? I noticed in some role assigned to users already have S_PROGRAM with P_GROUG (asterick *) and P_ACTION assigned SUBMIT, BTCSUBMIT, VARIANT.
SUIM => search for user/roles/profiles with auths (for example s_program * / *)
I use the "compare users" txn to have a fast look at all auths an user has for an object.
Answer:
Hi Martin.S,
Thanx for the info, it would be handy.
My main problem now is "HOW TO" control users from running reports in foreground. If i restrict users without SUBMIT in S_PROGRAM then users can't run in foreground but they can't run in background either as it needs this to start program.
So i just wonder how people actually do this, please help as i've tried all possible combinations & now run out of ideas to solve this problem.
Thank you very much in advance for your help.
Answer:
The user only needs SUBMIT to get to the first screen to execute then request in batch if you want them to enter their own selections. This however ALSO give them access to run in foreground.
If the user only has BTCSUMIT the user can run the report from SA38 using the "execute with variant" button and must select a Variant. These Variant must be created for their use.
The user can also go to SM36 and scedule the job to run their report and a variant may or may not be needed. Do not give the user S_BTCH_ADM only S_BTCH_JOB.
What you imply you want (start the report to enter the selection screen info and then prevent them fom continuing with on-line execution) is not possible. You can prevent on-line execution with the use of S_PROGRAM BTCSUBMIT and variants for them to use. DO NOT give the user VARIANT access in S_PROGRAM as they will be able to execute on-line.
Answer:
Hi John A. Jarboe,
Our system SAP 4.70/620, Oracle 9i.
Thanks for the info, i think i understand what you're saying...however i still can not get restrict user running in BACKGROUND ONLY.
If i may put forward how i setup as follows:-
Preparation Phase:
1) Example report ZTESTREP
2) Assign Auth. Group to ZTESTREP (eg. TEST_BTC)
3) Create role (eg. ZTEST_BTC)
- assign report ZTESTREP under Menu Tab which creates a tcode (eg. ZTESTREP_1.
- under Authorization Tab, assigned S_PROGRAM with P_GROUP = TEST_BTC, P_ACTION = BTCSUBMIT. Also assigned S_BTCH_JOB with JOBACTION all ticked.
- Expert Mode for Profile Generation, selected "Read old status & merge with new data".
- Under User Tab, assigned to the user (eg. UTEST)
4) SU24, assigned Auth. Objects to TCode ZTESTREP_1 with
- S_PROGRAM with P_GROUP = TEST_BTC, P_ACTION = BTCSUBMIT.
- S_BTCH_JOB with JOBACTION all ticked.
Testing Phase:
1) SA38, enter report ZTESTREP
System returns "SUBMIT authorization TEST_BTC required for program ZTESTREP" which is what i wanted.
2) SA38, enter report ZTESTREP -> click "background" button
Then click "execute immed." button
System returns "Report ZTESTREP started as background job"
3) SM37, for report ZTEST -> status shows CANCEL.
The error is "SUBMIT authorization TEST_BTC required for program ZTESTREP"
As mentioned before if i give user access to SUBMIT then they can run in foreground which is not what i wanted.
Can you please suggest where i went wrong or point me in the right direction.
Thank you again for your help.
Answer:
well, I'm not a ABAP guru... but maybe it's possible to implement another auth-check to prevent foreground execution?
Answer:
well, I'm not a ABAP guru... but maybe it's possible to implement another auth-check to prevent foreground execution?
this, at the start of the code should do it
THere is a SAP delivered alternative, Activte the user exit where you can program to check if the user is in batch (SY-BATCH <> space) and the user has BTCSUBMIT for the authorization group on the report (or the report name itself if the auth group is blank) and if passes, blank out the auth group field sent to the user exit so the SAP standard check will not occur.
Interesting! In most situations SAP does not read the authorization group that is stored in TRDIR when it does the auth check. Rather it reads it from the run time ABAP object that is generated. Changing the value in TRDIR without forcing the regeneration of the program wouldn't change anything. Of course if you're doing this in ABAP you can also regenerate the program.
I liked your first option best Dr. Jarboe.
Answer:
The SAP code checking the submit of reports does a select on TRDIR just before the check...
Changing the value in TRDIR without forcing the regeneration of the program wouldn't change anything This is not being suggested and the report RSCSAUTH makes the direct change to the table and does not regenerate the code but it takes effect immediately, so this is not true.
THe call to the Customer exit sends the retreived value in a field called SECU. In your customer code if the BTCSUBMIT passes the auth check you blank out the field sent to the user exit NOT the value in TRDIR. The feild SECU is used in the SAP code AFTER the user exit and there is a check to see if the field is blank and if so skips the check.