Prior to 4.7 there was a role "SAP_ALL_DISPLAY" but not after that.
If you are working on 4.7 versions you can download the role from 4.6 and upload to 4.7 ver and then generate the role.
Or we can create a new role from SAP_ALL profile
For this create a Zee role in PFCG. Go to authorization tab in change mode (don't select template). Go to Edit tab
-Insert Authorizations-From Profile. In the profile name tab enter SAP_ALL. This will copy all the authorization objects from SAP_ALL into this new Zrole and generate.
Download this role to your PC, Open the role with notepad, Search for 'ACTVT * '
Replace it with "ACTVT 03", S_TCODE -
Transaction should be *
And then upload and generate the role.
Note: But this is not good practice.
I have copied the SAP_ALL_DISPLAY from the SAP Standard role, and created a new one but while testing the user can execute payroll transactions, I've blocked a some of the transactions which execute payroll and also ensured Clusters have 'read only access'. It still doesn't work, has anyone else encountered the same problem and how have you been able to restrict the access to "DISPLAY"
Adding to the above, if you download it into excel ( .xls ) then you will be able to replace all the values for all the ACTVT fields by 03 in one stroke; using find and replace functionality.
1. Download the role to your harddisk in excel format.
2. filter it with the term AGR_1251*
3. Replace all values for ACTVT with 03.
4. Save it and upload it into the system.
Please confirm if solved.
Message was edited by:
You might also want to consider ACTVT 08 (display change docuemnts) and deactivating some other objects entirely.
Also, if you want the user to only display the audit log (SM20) you would need to maintain the program context name and the exact name of the routine to distinguish between change and display.
I dont think that there is any quick solution, but working with such a role is worth mentioning that the user should not have any other roles at the same time. Most likely that is also why SAP removed the temptation of their generic delivered SAP_ALL_DISPLAY role? Just a guess.
I do also agree with you.
assigning the above role will add all tcodes to s_tcode object which means the user will be able to view atleast the first scrren of every transaction.
If some other role is also assigned to him then the object authorizations in that role in combination with our display_all role may give access to some other transaction codes also which we really did not mean for....
your point should strongly be considered.
There are some tcodes which submit programs without selection screens. One would hope that the programs have the appropriate authority-checks or other system security features / validations in them; or at least an absolute authorization group restriction (in which case the DISPLAY role also needs to consider, for example, which P_GROUP field values for S_PROGRAM P_ACTION SUBMIT etc are in authorizations, and whether the program has an authorization group on it at all).
Another area to be considered, are displaying / starting the objects from outside of the SAP name range. Personally, I try to be very carefull when navigating in those areas, even without a display type role.
To add to what you already mentioned, one should be very careful in creating this so call SAP_ALL_DISPLAY role. A good thought should be given on the BC class objects........
and a host of other objects........and my favourite S_ADMI_FCD shouldnt be overlooked
I have done this SAP_ALL display profile, but if you belive me - DONT DO IT - it is not worth it
I'd agree with Shekar. If the request for an 'all display' role comes from a functional team I'd be tempted to go back to them to define what they actually want to display, i.e. what transactions they expect to be running. They'll either have a clear idea of what they want to do or they'll go very quiet.
This happens (or is resurected to the top again...) when people push ancient threads from 2007 etc. to the top of the forum again because they thought they know the solution, or just learn something.
If it adds value it is okay, but in this case it is into the grey area.
For all we know, Hemant is himself pushing daisies already or driving a truck somewhere
@ Manish: Su01N does not exist either...
ps: Shekar's post is a good one --> objects which do not have the field ACTVT but control "action" type fields.
Unfortunately it's not a simple find and replace.
You'll find anomalies after you upload the role.
Even though it's maintained in the a.object, you'll get authorization check failed.
If you don't believe me, just do SE37, ME1M, or MM03 after you've uploaded the role contain ACTVT 03 only.
Check with SU53 and PFCG to compare.