Value for field DICBERCLS for Auth Object S_TABU_DIS for VL33N

[Pawan_Kesari]

When I add VL33N to role, it automatically adds authority object S_TABU_DIS to it. Though it does propose the value for ACTVT but I doesn't propose anything for DICBERCLS.

Any Idea what authorisation group does VL33N need or is there any way to find it out?

[jurjen_heeck]

If not the nicest way, the easiest is to disable the object, attach the role to a user and wait till it goes wrong. SU53 hopefully will provide the information you're looking for.

[Pawan_Kesari]

Jurjen .. thanks for reply...

I was trying to use the transaction VL33N in all possible ways after putting break-point on statement AUTHORITY-CHECK but so far it hasn't checked for S_TABU_DIS .

We removed authority object S_LAYOUT from user profile to prevent users to save global ALV layout and in most of the case this appears in SU53. I guess I need to put a trace from ST01 to get the correct values.

I still believe there must be a nice way to get around this..

[jurjen_heeck]

> We removed authority object S_LAYOUT from user profile to prevent users to save global ALV layout and in most of the case this appears in SU53. I guess I need to put a trace from ST01 to get the correct values.

Yeah, that's a notoriuos polluter of SU53 uotputs, as is S_GUI. ST01 will be the better solution.

[Former Member]

Hi Pawan,

Have you checked whether S_TABU_DIS is coming due to tcode VL33N only.

May be it is not needed and deactivating it will be a good option.

Peeyush.

[Pawan_Kesari]

Peeyush,

It is coming from VL33N only.

It shows VL33N when I choose Utility->Authorization Object Assignment for S_TABU_DIS in Tx PFCG and Tx SU24 for VL33N this object is marked as 'Yes' for proposal.

[Former Member]

>

> Any Idea what authorisation group does VL33N need or is there any way to find it out?

Pawan, go ahead and disable the object, VL33N should work fine without it.

I looked up the SU24 value for VL33N in the < ECC 6.0 versions, it didn't had "YES" for S_TABU_DIS. And it is there in the > ECC 6.0 versions.

Cheers !!

Zaheer

[former_member701183]

s_tabu_dis is normally checked for transactions which requires Table Updates or Table View belonging to specific authorization group. This transaction VL33N is related to inbound delivery display which is not directly linked to any Table related object. Hence drop VL33N in su24 from the Check Maintained or Covert it to No in ECC6. Add the transaction again to the role and s_tabu_dis wont be pulled inside. Thus you dont require the value for s_tabu_dis. Please let me know if any issue.

Regards

Aveek.

[Former Member]

Sometimes if was used in F4 lookups and some transactions use "current settings", so there is the posibility that a view will be called.

"Yes" in Su24 means that the transactions has the ability to use a function which is controlling access via the object.

It does not mean that you have to grant that ability to the users simply on the grounds of the transaction.

My recommendation: Trace it and set the object to inactive, unless it turns out that you do want to use it - in which case maintain it in Su24 for an appropriate role and transaction context for ease of re-use.

That may, or may not, be this role and tcode VL33N. Only you can know this...

Cheers,

Julius

[Pawan_Kesari]

Thanks for your valuable suggestions!

I didn't know that we can change/add the authority objects in SU24.(you can guess I am newbie for authorization stuff). We had problems with VL02N where few authority objects used by transaction is not defined in SU24. I can now add those authority object to VL02N so next time we don;t have to follow same procedure to find the problem.

I guess I need to deactivate S_TABU_DIS from role and wait for any user complaint.

Will do that one by one with all roles having S_TABU_DIS (not necessarily for VL33N).

Many Thanks,

Pawan.

Edited by: Pawan Kesari on Jun 12, 2009 3:49 PM