RSO2 --Authorization

[former_member1190121]

Hi,

I am in process of creating BI sustainement role.I have added the tcode RSO2 in the role.Still the BI team is not able to acces the RSO2 trasanction.The reason for this is ,In the the back end RSO2 takes the data from some cross client tables.As per customer policy we should not give cross client table access in sustainment role.

If i allow the cross client table maintanence,they will abe to access & change all cross client tables.We don't want to give all the access.

Is there any way to give authorization to only few cross client tables?

Thanks,

Nagarjun.

[Former Member]

Hi,

You use S_TABU_DIS to restrict access to the table groups that are required. If you also give access to change cross client tables then it will only be x-cli tables that are permitted through the S_TABU_DIS groups that you already have listed.

If you carefully select your table groups then you will achieve what you want.

Personally it sounds like your client has got hung up on "banning" an authorisation object without necessarily understanding how the control can be enforced.

[Former Member]

Hi,

RSO2 is not required on daily basis for BI activities.So Instead of adding RSO2 in sutainment role. You can also create one separate role for RSO2 including S_TBAU_CLI and give the role access only for temporary purpose based on approvals. You can propose this idea to your company.

Or you can try whatever Alex mentioned.

Best Regards

Imran

[former_member1190121]

Hi,

Still i am not able to fix this.

Can any one please guide me on this?

Thanks,

Nagarjun.

[Former Member]

Elaborate the issue you are facing, where are you stuck only then you can get help.

Regards,

Rajesh

[Former Member]

Nagarjun,

Which part of my post did you not understand?

You limit access to tables via S_TABU_DIS so with S_TABU_CLI users can only change cross client tables that you have permitted in S_TABU_DIS.

[Former Member]

I found this thread because I faced a similar issue. Someone requested RSO2 for PRD support but we didn't want to assign it because it's a maintenance txn that requires s_tabu_cli=X in order to start the txn. The users have &nc& in s_tabu_dis (we are working to remove that but for the time being they have it) and didn't want to add to the problem by giving s_tabu_cli=x.

The solution is to assign RSA2, a display txn that doesn't check s_tabu_cli.