Authorization in Particular tab in Module Pool

[former_member183607]

Hi All,

     Is it possible to set Authorization of Particular tab in Module Pool Programmatically

     Like In Screen I Have Created three Tabs & I need to set Authorizations for this tabs.

     first tab is authorized to User Group 1

     Second Tab is Authorized to user Group 2

     Third Tab is Authorized to user Group 3

     All Tab Authorization to User Group 4.

Thanks in Advance

Soumendra

[FredericGirod]

Hi,

obviously yes, have a look to the transaction MM01 / MM02

regards

Fred

[former_member183607]

Hi,

     Thanks for Reply , But This requires an involvement of Basis Person To Create Three Objects for Three Tabs & Four Groups of User , Is it Possible Programmatically?.

[FredericGirod]

You don't want to use standard authorization ?  check SU21 / SU20 trans.

You could obviously create new authorization object using the same transaction, and add it to your code.

For my point of view, these tasks are development.

is it standard trans.  ?

if yes, check with SU24 if there are not an object already in place that could do that check.

Fred

[former_member183607]

Hi,

     This is a Custom Business Requirement & Not an Standard Object .

     Thats why SU24 is not useful in this Case.

     Shall I Make a Ztable and Store Screen/Subscreen No & UserId and

     Use this table for Authorization Checking?? Or is their is any Other way to Do this.

Thanks & Regards

[FredericGirod]

No,

if you create your object, it's the value of a field that will give the availibility to a tab.

imagine : Z_CONTROL_1  with field ACTVT (to specify 01 -> Create, 02 -> Modify, ...)  and Group.

each time the user change the tab, you will have to check the authorization.

and in the profile (PFCG) you will add to the corresponding user the authorization to the group.

that's all

[Arun_Prabhu_K]

Hello Somendra Shukla.

     Why you are going for authorization control?

     You can still perform the desired functionality by hiding that tab based on the user names.

Regards.

[FredericGirod]

did you really work like that ?

[Arun_Prabhu_K]

Yes. My concept is

*Show user the buttons/tabs etc. in a screen what is required for that user.

*I feel it is better than showing everything to users and saying NO AUTHORIZATION when trying to use that

[matt]

You don't think perhaps a better approach is to check the authorisation of the user, and if the authorisation check fails, then don't display the tab?

Basing suppression directly on user name is staggeringly bad practice. I mean really bad.

[former_member183607]

Hi Arun,

     Thanks for the Concept,

      But If I hide User will not be able to see the entered values by Other User Group, However I Will      have to make that disable that is Screen Field Input = 0 .

     According to My Understanding , How I May Know that particular User is having Authorization,

     This User Group & Authorization Values Must be Maintained Some Where, This is my Requirement      Where & How to maintain This.

Regards:

[Arun_Prabhu_K]

Accept your point. Thanks and good to know that.

[Jelena_Perfiljeva]

We can create custom authorization objects or use the standard ones in the custom programs if they fit. Authorization object maintenance (SU21) is the development task, as already pointed out. The object will need to be assigned to the roles by a Basis/Security admin, which is a part of their job. Using something other that the standard concept just because Basis/Security admin can't be bothered or you're afraid to talk to them for some reason would be a very nearsighted decision, to say the least.

[former_member183607]

Hi Jelena,

     I Would like to accomplish this with out the help of Basis person, That is why I am looking to do it Programmatically, But It Seems it will be much Better to take Basis help & Create Object & Profile

and Assign Them.

Thanks Every One for your Valuable Response.

Regards:

Soumendra Shukla

[matt]

Sometimes, to build an efficient system, the different departments have to work together. Also, the attitude of "it's easier to program it that way" is something I drummed out of my developers. Your job is to make life easier for the business your supporting.