Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Report list of unused Auth objects lying in roles

Former Member
0 Kudos

Hi All

I would like to know a way of running a report which gives all the Auth objects which are currently active in a role, but none of the tcodes are using that object, hence the object is an orphan status inside the role.

Basically i beleive this situation arises when you have manually added the object into the role & after a certain tcode which was using the auth object was removed from the role, the auth object didn't get deleted automatically & is lying in the role.

this procedure will help me to clean up all the roles which i plan to release before moving to production.

Do let me know you thoughts on this

Regards

Naveen

1 ACCEPTED SOLUTION

sreekanth_sunkara
Active Participant
0 Kudos

Hi Naveen,

you can go in to AGR_1251 table and filter by Object Status "U" (means Manually added). This shows you all the Manually added objects in the roles.

Thanks,

SS

5 REPLIES 5

sreekanth_sunkara
Active Participant
0 Kudos

Hi Naveen,

you can go in to AGR_1251 table and filter by Object Status "U" (means Manually added). This shows you all the Manually added objects in the roles.

Thanks,

SS

sdipanjan
Active Contributor
0 Kudos

Hi,

As you can do the finding as per the last post by using AGR_1251 with a filter against Object Status "Manually" there is another aspect. You may use the report AGR_WITH_EMPTY_FIELDS. If somehow some of your roles are containing some unused unmaintained authorization Objects which doesn't create any issue during Transactional processing then you want to inactivate them as well as maintain them too and then do a Merge operation with other instances of the same Object if the merge is likely to happen as per the merging conditions.

Regards,

Dipanjan

Former Member
0 Kudos

Hi

Table AGR_WITH_EMPTY_FIELDS - that's a new one to me and I'll have a look tomorrow. Thank you.

However the results required are eventually gathered some care will have to be taken in the next steps.

If the need to clear out manually maintained objects is part of an audit and they have recommended the removal or you are new to the client and have found these due to a previous flawed authorisation concept you need to raise some issues before plunging in and making changes.

Manually added objects were probably caused by SU53/user issues and weren't correctly populated in SU24, you can run reports to find orphaned objects but that's as far as you can go without buy-in from the business.

Depending on your current SU24 settings you could spend many hours or days checking whether the manually maintained objects in your roles are valid, remove and reassign the transactions you have subsequently found in the role to bring in the standard objects and then delete the old manual object. You may find no current SU24 object value suggestions and remove the orphaned object as it doesn't link to any of the transactions in the role you are reviewing.

The trouble is. the role may have an object totally unrelated to the transaction it's supporting in Prod at user level. If you remove the object, transport and ask a user to test the transactions in the role you may get an all clear and move to production...at which point the fun begins. Users with the role may start reporting authorisation errors completely unrelated to any of the transactions in the role you just modified and transported.

Think carefully before making any changes to single roles without role owner/business/manager approval or you'll find you are the most hated person in I.T.

Good luck

David

sdipanjan
Active Contributor
0 Kudos

> Table AGR_WITH_EMPTY_FIELDS - that's a new one to me and I'll have a look tomorrow. Thank you.

AGR_WITH_EMPTY_FIELDS is a report and not a table.. so you need to execute it by SA38. Similarly there is another report available AGR_WITH_EMPTY_ORGS to list out the Roles with Unmaintained Organization level fields. You can give a try surely.

They save to much time.

The issue raised OP happens in most of the following cases mainly:

Incorrect Design and then due to short Test time span the authorization errors are fixed just by Adding Authorization objects Manually by referring the SU53.

Also in later time due to SP upgrade, some programs get corrected and thus new authorization checks come into place (may be directly or due to Called Transactions). When a Su53 occurs in support phase the support team used to add those Objects Manually without digging into the details to find out why this new check is coming.

In other time, these Objects are added just because lack of expertise, skill and misleading authorization concept. Sounds bad but true.

regards,

Dipanjan

Former Member
0 Kudos

Hi All

Thanks for your valuable feedback, so it is sure that we don't have a straight approach in finding these orphaned objects & so need to do some research from the reports you mentioned.

I agree with you about the process needed to follow in getting the roles corrected.

Have a nice day ahead.. tc ciao..