REVOKE USER TO RELEASE TR
In this doc we will discuss various methods to restrict the user to release the Transport request in SAP.
THis scanerio is used when you are having third party support and you want to check all TRs at your end and dont want to give them authorization to release the TRs.
We don’t have any enhancement points in program so we will go with BADI.
First Method: Authorization Check Method
This is a little bit complex method but you will learn authorization object creation & using it in SAPUser Roles.
Go to SU21:
Fill the Object name, class, authorization field:
Click on permitted activities & fill Release Code activity i.e. 43:
Now save it all.
Now Punch Tcode SE19 &
Create Implementation of CTS_REQUEST_CHECK Badi as in following Screenshot:
Select 2nd option which is area to check coding before releasing a request:
Use your coding in this method to restrict as per requirement.
What we have used here is an authorization check, so following is the code:
Save it. Don’t forget to activate it as well as BADI in previous screen.
Now give the user the Authorization object we created, with the help of BASIS Consultant:
Users having upper listed object (Z_TR_REL) can only release the TR.
Otherwise will have following error while releasing the TR.
JOB Done!!
2nd Method: Table Entries check method
This one is easier as we don’t have to go to every user role. We just have to enter the User name in table & that will be checked while releasing the TR.
Create a Z table with following fields & maintenance view:
Save & Activate the Table.
Now open SE19 & do the same procedure as mentioned (to add coding in 2nd option):
Code will be different for this one as it will check the table & the username entered there will not able to release the TR.
NOTE: If you want opposite of this, do following coding in the block:
Now save it. Activate it.
Make entries in table we created earlier:
Now create TR from the SAP ID & Check.
Voila !! JOB DONE!!..
Thanks all for reading this as it is my first time blog & hope you all get benefits from this.
Unfortunately you have not explained any scenario under which this would be needed, also no words when you would use the first option and when and why the second option.
Thnkx deae..
Added that point..
And for your info this is when we are having 3rd party support for some upgradation and we want to keep our system secure and dont want then to release any request... this is what we use then...
Won't standard authorization object S_TRANSPRT (ACTVT=43) do the work?
HEy dear!!!
Its when you have to give the user sap all and have to revoke the same in sap all profile....
but there is a good chance SAP_ALL is regenerated with Z objects included. So you are stuck with same issue as S_TRANSPRT for option 1 with custom object
Yups!!! Thanks I didnot consider that one... Noted....
Then you have to go with second option only.
It feels good when receive queries.... thanks dear....
Recommend option 3: don't have sap_all in conjunction with train, trust and audit
ahmmmmm I have not heard about this...... can you refer something against this..... ??
It would be so nice of you .....
Build dedicated security roles to assign to users instead of sap_profile. That way you can rely on s_transprt activity 43
This is best practise not to give users sap_all
Even if a basic starting point is to build your sap_all role and strip out permissions you don’t want your users to have
Training to tell them they must follow process and not release the change
Trust that they don’t use debug change or another workaround to release it
***update your can use a step in SU25 to run a program to build the role and exclude objects or classes from it. Much faster than PFCG manually built role***
Hey Sukhwinder,
Nice blog along with the options.
We have a weird problem with releasing the main transports.
Very few users are able to release the transports in a system which was locked under the ChaRM. In which, technically, no one should be able to release the main TR, and this restriction is working absolutely fine for most of us. However, few developers were able to release the main TRs from SE10 transaction without even moving any status from ChaRM UI.
As Colleen mentioned in the comment sections, can we try with s_transprt activity 43?
Any advice on this?
Thanks
Vinayak Budapanahalli
Hey Vinayak, thanks for going through my blog..
Yes, activity 43 is responsible for allowing releasing the TRs. Don't assign activity 43 to the same users, those will not be able to release the TRs.
Also, give a look at the TTypes given to those users.
Thanks
Sukhwinder Singh
Hi,
I have followed the steps and it works perfectly for me ! I would like to know if there is a method that exists to check if the user in my Z table is authorized to delete a transport request.
Thanks a lot !
Antoine