Su24 Issue

[Former Member]

Dear Friends,

Pls tell me how the USOBT/USOBT_C/USOBX/USOBX_C tables related to Su24 .

I have to change the SAP Default values of fields in SU24 .Please let me know it is a standard Practice or not to change Su24 for SAP Standard Codes.

Actually we have a scenario like this :

We make new roles by copying the field values from lot of other roles .

The object having Status as :Standard then convert to Status :Changed

Because we have to insert more filed values.

Now we have to convert the Changed Status from our Roles to Standard Status, It can be done by modifying the Roles and modifying the Su24 .

Can you please assist how to proceed?

Thanks n Regards,

Premraj Kaushik

[Former Member]

You are breaking just about every rule in the book...

Why not start by just reading the documentation on SU24 before you launch such a question?

Enjoy the weekend,

Julius

[Former Member]

Hi Luius,

Intention was not breaking any rule, if u think so , i am sorry , i know little bit about su24 , my question was that :is it best way to change Su24 for SAP Standard Tcodes ??

Requirement is to chnage for lot of SAP Standard PP Tcodes ..

Hope u got my point and appreciate if you gave any helpful suggestion ...

Premraj Kaushik

[Former Member]

Sorry for my initial answer. I thought you wanted to change SAP default data in SU22 and not the SAP transactions in SU24, would have been a breach of common sense...

But "changed" authorizations are still a very bad practice!

Anyway, SU24 is an "expert transaction" and if you are not very sure about using it then it is best to only add entries and define proposals for your own transactions. This will make your live much easier when you apply support packs and upgrades (in SU25 steps 2) as you can simply accept the SAP default data (from SU22) and hope for the best.

I would still at the very least read the documentation on SU24 and the FAQ thread at the top of the forum page before you do anything in SU24.

Cheers,

Julius

[Former Member]

Thanks Juiluis ,

Reading the same only , Actually , The problem is that

We have many Roles Having Auth . Object with "Changed Status", they reason of changed Status is that we make these roles by copying the auth. data from lot of other small roles to decrease the count of roles b ut now client did not want the Roles to be in Changed Status , They want them to be either in Standard or in Maintanied Status , What we should do now :

1. If we do Read old Status and Merge With New , then the Standard Object will POP up and we can Inactive the Chnaged Auth .but then users might have issue of missing Authorisation because Standard object has less Auth .

Ex: S_TABU_Dis Changed: Actvity 03,02 (if user need 02 and 03 both)

S_TABU_Dis Standard Activity 03 only ( if we deactivate above then user will be missing 02 activity)

2. Second option is to Change the Su24 default values and make them same as the values in Chnaged Auth in Role so that when we do by Expert mode(Read old and merge with new) the Standard object will POP with the required values which we is there in Chnaged Auth and then we can Inactivate the chnaged Auth .

What you suggest now ?

Thanks a lot for your nice suggestions

Premraj Kaushik

[Former Member]

S_TABU_DIS is a special pain, but genetally I would compare the roles between DEV and PROD and the SU24 data between them as well.

Then sample a few by opening them in "expert mode" with read new and merge old to see how big the damage is and how many auths are still standard or maintained in old status.

Usually one can conclude that the menus and org. levels from PROD are worth salvaging but start over with all the rest.

Cheers,

Julius

[Former Member]

Hi Julius,

The Roles are not in Prod till now , We just made them in Dev ,S_TAbu_Dis is just as example , We have lot of obkject like this in a Role (near aboout 25 per Role) and more than 45 Roles, So is it better to ad manuaaly all the Chnaged object in The Roles and Add the reqyuired Filed values and then Inactive the Changed Auth.

What you says ?

I want to avoid Su24 modification ..

Premraj

[Former Member]

Changing them is always wrong, bar SPRO roles (in my books). At the next upgrade it will cause chaos for you... so never do it .

Most common causes are an incorrect choice of transaction or incorrect (too many) proposals delivered by SAP or even your own SU24 entries without considering other roles impacted (via the same SU24 reference).

If you read the docs, then you will see that this also impacts parameter transactions.

Depending on how confident you are about the menu entries, you might be better off building them from scratch.

Please fix it - someone else might need to maintain or upgrade it!

Cheers,

Julius

[Former Member]

SU24 displays and updates the values in tables USOBT_C and USOBX_C.Here,C stands for Customer.

The profile generator gets its data from the _C tables.And is used for Maintaining Authorization of objects

In the USOBT and USOBX tables the values refer to SAP standard values.

Similarly,SU22 displays and updates the values in tables USOBT and USOBX.

Bharath Kasula.

[Former Member]

Thanks

[Former Member]

Hi PremRaj

I (think) I remember coming across this when we were trying to find ways to merge roles (lots of little singles after remediation) into larger singles. Inserting the profiles from another role brought the objects in but as changed (but it's been many months and could have been manually) status which wasn't allowed.

I don't like orphaned manual objects but I'm not sure how bad changed would be? Another to try out tomorrow

Cheers

David

[Former Member]

Dont modify SU24.Do merge role option which will be advisable.

[Former Member]

You can change SU24 and this can be very helpfull, particularly if you see SAP is going to deliver an SU22 correction which reverts back to the same without a doubt.

However, you must read the documentation and SAP notes (see FAQ thread to tips) on it first. It is an "expert transaction" and will not be kind to the "lets change this and see what happens" type of approach to application security...

Cheers,

Julius