Custom Auth Object Su21 prompts for developer key

[Former Member]

Hello All,

When I create a custom auth object in existing class using Su21, its prompts me enter developer key? IS there any NOTE which we need to apply.

Thank you,

Sri

[Former Member]

Hi,

SU21 should not prompt for Developer key if you are creating the auth object with Z or Y. Ensure that you are following this convention. If yes, let me know the client in which you are creating the auth object, and also any other relevant information on from when this issue is popping up.

Regards,

Raghu

[Former Member]

Raghu,

Creating new custom auth object in existing custom class,

Su21->click on create custom auth object(Z...)->enter description, values->click on documentation->then click on permitted values->pop up ->enter developer key.

I am trying in development system.

Why does it ask for developer key? Do we need to apply any SAP NOTES?

Thank you,

Sri

_

[Former Member]

Hi Sri,

What is your current version & patch level. As per my understanding there are no issues that are identified with creating of auth objects. If you are at a recent patch level, raise a message to SAP.

Regards,

Raghu

[Former Member]

Hello Raghu,

Support pakage L: 254 / Kernel : 700

ECC6.0

Thank you,

Sri

[Former Member]

I assume that you already added fields to your object (SAP Standard ones with domains) and now you want to extend the value ranges of the domains.

That requires a developer key as it is developer work (domains do not only relate to authorizations but also the typing and search helps of fields for programmers) and once you have a developer key it will also require an object key if it is a SAP domain --> it is a modification.

Can you confirm which fields this custom object has and which you are trying to change?

Chances are good that the fields for the object have not been chosen with care (in the technical specifications).

Cheers,

Julius

[Bernhard_SAP]

Hi Sri,

please refer to note [SAP Note 1316963|https://service.sap.com/sap/support/notes/1316963] .

Authorization object definitions are (now;-) ) part of the development workbench and are used in workbench objects (like programs, services and transactions) which also can only be changed/defined by registrated developer users. that has nothing to do with the name range....

The name has only influence on the necessity of an object key, which you do not need for z-objects of course.

b.rgds,

Bernhard

[Former Member]

Thanks Bernhard!

Particularly changing auth object definitions is best done by a developer who understands the programming side of the coin, but I cannot say the same for tcodes.

Tcodes do not check the developer key and I dont think they should either. Will this remain so?

Cheers,

Julius

[Bernhard_SAP]

Hi Julius,

the spanish inquisition expected that quesiton obviously and prepared therefore [SAP Note 1494248|https://service.sap.com/sap/support/notes/1494248] .

b.rgds, Bernhard

[Former Member]

Okay, so changing an SAP transaction in SE93 requests an object key (gud!) but creating a Z-tcode or adding a quiery to a role menu to generate a tcode only checks S_DEVELOP right?

I think this is correct as the authorization admin should have the ability to create transactions for applications and use them in roles annd SU24, without having to be a developer.

the spanish inquisition expected that quesiton

LOL!

The peasants and infidels down here would also like to know about changeability of the client (SCC4)? Can we keep that one?

Cheers,

Julius

[Bernhard_SAP]

Hi again,

no same in se93 now. Developer registration is checked before, also for Z-tcodes...

Same in PFCG, for instance for ABAP report: CALL FUNCTION 'SRT_CREATE_TCODE_FOR_REPORT'

calls then the standard t-code creation routines and also the developer registration (beneath s_develop....). It should not make a difference, if a t-code is created in SE93 or through PFCG.

Regarding SCC$-->Customizing! No Dev.registration necessary.

b.rgds, bernhard

[Former Member]

Thanks for the infos Bernhard!

I guess we are going to have more granular S_DEVELOP authorizations then for the authorization admins down here as the "missing" developer key check was usefull to keep them out of SE38 / SE37 etc's harm even if they did have "blunt" authorizations.

Or, we will need to change our development processes and have the ABAPers even trained to build roles and maintaining SU24 for the applications they develop. Not all bad, but I think it will be a painfull adjustment for some "out here in the wild" where the developers only did the "programming" part and security then "protected" it via tcodes and gave access back to users via roles without having to manage or know about developer keys.

I will add this to the FAQ thread to give others a notice about the change.

Cheers,

Julius

[Bernhard_SAP]

...propably a workaround will be, that the auth.-admins ask the abaper to create the t-codes for them for the reports they want to enter in pfcg/for the reports the abapers have created....

My feeling is, that this would be the most consistent solution. Auth.-admins should not necessarily be able to create t-codes, what they could do in the past (pfcg did it for them automatically).....

Bernhard

[Former Member]

>

> workaround 
> 

Lets explore this a bit further... I think a marketing person came up with this idea?

For me it will be a pain as I often create tcodes in cleanups (SA38 --> tcode battle) and use symbolic tcodes in SU24 - particularly for batch processing and role specific values which should not have a transaction context because the GRC folks persuaded SAP to maintain a load of nonsense in some cases so that their rules work...).

Okay, Se93 can be used to create a new tcode for a program which does not check FM AUTHORITY_CHECK_TCODE... but that is a lesser evil compared to auth admins becoming developers now.

From my observations "in the wild" this is not a good move and real developers will not be happy about it. Removing "debug" was enough for them to trigger the auth admin to have to contact them - auth admins can now change programs on their own (possibly).

Anyway... for sure it will be a big process change for customers out here, once they realize it or suffer the consequences.

Personally, I am still undecided, because neglecting S_DEVELOP is not really a solution for development systems either.

Very interesting topic...

Cheers,

Julius