Question:
I have been asked to create a new role that would allow display access to all the transactions available in the IMG (SPRO). My position is that it makes no sense to even try but i'd like to get your opinions on this.
I have identified roughly 5500 transactions that are accessible through SPRO, many of those being available in more than one customization activity. The "normal" way of building a display role would be to add the transactions and then change the Authorization Objects brought in to enable display activities only.
My response is that it should not be attempted. The IMG was created specifically to customize the system. If you want to check whether the changes worked, use the roles created to execute or display the activities you customized.
1 - The activities associated with the transactions contained in the IMG are "Create, maintain, change". Trying to create a role using these transactions and removing the "Create, maintain, change" activities in the Auth. Objects and replacing them with "Display" will leave you with a role that will not let you do what you want.
2 - This will take a huge amount of effort and time. We are talking about 5500 transactions. I am not even sure that it's possible.
3 - Even if i did change the Auth Objects to "Display" activities, many of the transactions simply will not work in display mode only.
4 - The purpose of giving users display access to confirm the changes they've made would be better served by creating small display roles specific to the area the users should have access to.
What do you think? And if any of you has been asked to do the same, how did you respond?
Thanks!
Answer:
We were asked to create a SPRO view only role by business, which they insisted they needed in production for a limited time to make sure the config was correct. Management bought it and so we didn't have much say so. Our approach was much simpler than what you are describing, we added SPRO to the role and set the following obects:
S_DOKU_AUT - default values
S_PROJECT - ACTVT = 03; PROJECT_ID = <project name>
Turned off all other objects
Manually added S_NUMBER so they could view all number ranges
ACTCT = 03, NROBJ = *
The tricky part is the t-code range in S_TCODE, since as you described, it is difficult to identify all the IMG t-codes. In our case we had a BUSNESS_ALL role that we controlled and tested via a t-code range and more importanlty, at the object level, so using the same t-code range for our SPR_VIEW role worked fine for us. I suppose you could just give them " * " in S_TCODE if you use it as a standalone role since there are only 3 object in the role, you can be confident they can't do much but view. We tested the SPRO_VIEW role by itself and with our BUSINESS_ALL role. They were happy that they couldn't change the things they were concerned with and were able to view all of their CONFIG settings. I'm sure others have done it differently but this worked for us.
Regards,
m.r.
Answer:
I created a role for Display IMG in less than 5 mins and it works.
This can be done with the following:
S_TCODE * (Call all txns)
S_TABU_DIS - activity =3 - All autho groups (Only display all tables)
S_TABU_CLI-' '
S_TRANSPORT - Disabled (Can create a transport)
S_NUMBER - Acvty=3 (Display no range objects)
S_CALENDER - Actvy=3 (Display holiday calender)
S_IMG_ACTV - Actvty=02 (Change - But S_TABU_DIS display controls the change).
Also make sure SCC4 - System change option has been assigned to "No changes allowed". This setting is more at the global level so even if guys have IMG change access, they wouldnt be able to change IMG.
Hope this helps.
_________________
SAPFAN
Answer:
Thanks for your quick and very usefull replies.
MRistic - Your solution seems a bit more involved than ESPEE's.
ESPEE - Your solution makes sense and looks to be simple enough. I'll see if i can sell that to my team.
Again, thank you both. I'm sure there are others out there who will find this very helpfull.
Answer:
NEVER create a role with S_TCODE filled with an '*'. Trouble waiting to happen.
If you search this site the is a reverence to the table that houses the tcodes in SPRO and you will find that there are many K, F, M, etc tcodes that S_TABU_DIS is not the authorization to access the data. There are MANY objects other than the few listed and it is relatively simple to create this role and change the tcodes to view tcode. Remember it all pays the same to do nothing or create the role
I'll look to see if I have a download of the view only role.
_________________
John A. Jarboe