Authorization Check on Radio Button

Question

Hi,
I have a custom report which has a radio button. Can I provide the authorization on this radio button, meaning only selected no. of users can run this report with radio button checked. I know it's possible through maintaining a list of users in custom table, But I want to check if we can do it using authorization object/group etc...

Answer 1

Birendra, you're absolutely correct that we need to consider future maintenance efforts. But this is exactly a weak side of the parameter approach that you've suggested. The jet analogy is impressive, but way out of proportion in this case.
Using authority check command in ABAP code and modifying screen elements is not hard-coding. The parameter approach also requires writing some code, so it has no advantage here.
Also it requires someone (a Basis admin?) to update the user profile and a table entry that you've mentioned. To use the standard authorizations, only one authorization object will need to be created (although it may even be possible to use another, existing object if it's the same authorization level). It won't take more space or more time to create than an SM30 entry. Updating the roles might be more of a hassle than updating the user parameter, but the difference can hardly be considered significant and it's a one-time thing anyway.
It is a matter of preference whether to hide a control, disable it or display a message. (By the way, in many standard transactions you'll find that controls or menu options are hidden/disabled based on authorization, so it is nothing exotic.) But I stand by my suggestion of using standard authorization check functionality specifically because it makes the future maintenance easier.
1) Basis admins most likely already maintain some document regarding the role assignment. It might be actually easier to them to maintain the roles than to keep track of the additional profile parameter and remember it in future.
2) Imagine years from now you're gone and all the new people are maintaining the system. The user gets a 'no authorization' message and, naturally, contacts a system admin. Again, naturally, admin will check security trace. Now guess what - your parameter thingy cannot be tracked anywhere. No one knows about it and it will take an ABAPer to figure this out.
With standard approach it will only take a second to run SU53 and a few minutes to resolve an issue by a Basis admin. Additionally, authorization objects have 'where used' button, so it would be easy to check if and where the object is used (e.g. if the report has been changed/deleted it will be easy to spot the 'orphaned' object). With the profile parameter sooner or later someone will have to wonder what the heck it is for and might accidentally delete it. By the way, sometimes users actually have access to their own parameters, so it's not a very secure option either.
I understand you mean well, but, unfortunately, in my work quite frequently I have to deal with some things that were developed by well-meaining consultants who overlooked some long-term effects of their approach.