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: 

Always many "New" authorizations when I edit authorizations....

Former Member
0 Kudos

Guys...

A thing that irritates me a lot is all these u201CNewu201D objects that keep appearing when I am making minor changes to a role.

Let me explain. If I am making a big role (many transaction codes) from scratch there might be 10-15 authorizations for e.g. S_TABU_DIS, one for each transaction code based on the SU24 input. If I want to make this role display only, rather than editing all authorizations I keep one and deactivate the rest (not delete, just deactivate).

Next day I want to delete a transaction code (not the first time the customer changes their mind!) when I edit the authorizations a large number of authorizations are u201CNewu201D and I have to go though them to inactivate them again.

Am I doing something wrong or is it just SAPu2019s way of keeping us busy?

/vitofava

1 ACCEPTED SOLUTION

Former Member
0 Kudos

I hope there are not many auth objects in a CHANGE status and causing Yellow trafic light problem.

If the object which had status as STANDARD is changed directly instead of creating a copy of it (and then changing it in the copy while deactivating the standard one), then when you change the role agains t-codes in menu will pulls the auth object again in Standard status.

5 REPLIES 5

Former Member
0 Kudos

You are doing something wrong and this is SAP's way of keeping you busy if you do not read the manual before you start using an application...

Cheers,

Julius

Former Member
0 Kudos

I hope there are not many auth objects in a CHANGE status and causing Yellow trafic light problem.

If the object which had status as STANDARD is changed directly instead of creating a copy of it (and then changing it in the copy while deactivating the standard one), then when you change the role agains t-codes in menu will pulls the auth object again in Standard status.

0 Kudos

and then changing it in the copy while deactivating the standard one

Even in this case, the system will propose a new standard instance if the menu relation was merged and then on of them changed for what ever reason. The system does not remember how nor why it merged the instances of the authorizations and you cannot easily unmerge them individually again.

I had a related problem when I wanted to do this intentionally and ended up having to provoke temporary mistakes to get the authorization as new again, see -->

This whole mechanism of merging and new instances (and how they are occupational therapy for the folks who create changed, delete and indiscriminately merge authorizations....) are described in [SAP Note 113290|https://service.sap.com/sap/support/notes/113290]

I have a reminder in my Outlook calendar to read this note once every 3 months. I have been doing this for years now and I find it is the only thing which helps to remember how it works. It leads me back onto the path of the rightiousness and safely down the valley of the shadow of manual profiles...

I still think the intentional unmerge function would be usefull, but have accepted the fate that for the moment it is not going to happen because of stuff like this...

Cheers,

Julius

0 Kudos

Julius... thanks for the link to the SAP Note. It was interesting reading.

I have one more question:

So if my client for some (strange) reason want a change transaction (e.g. SU01) in a display role, rather than deleting 02 from ACTVT (making the authorization "Changed") I should Deactivate it and manually add a new one with the required 03 ACTVT?

/vitofava

0 Kudos

The choice of transaction should be your weapon of prefered choice, so what you are looking for here is transaction SU01D for display only.

As SU01 has the capability of being used in a display only manner, you can also consider removing the ACTVT values and leave the field open to being maintained. If chosen, then this should be done early (i.e. before other roles are dependent on the fields being filled with values.

If you set to inactive and create a manual authorization, then you loose the benefit of SU24 to propose changes to the object in the role again in future.

Worste-case scenario is to change the authorization directly. Even with copying and changing the copy, this still hurts you a lot when you upgrade.

Cheers,

Julius