Specification type authorizations

[Former Member]

Hi EHS experts,

I am trying to create PFCG roles that are restricted to specification types. I have performed the needed config. change to allow the usage of the new authorization objects (to allow the usage of the SUBCAT) field.

SPRO > Basis Data and Tools > Specify Environment Parameters

• Change value of SP_AUTH_CHECKS_WITH_SUBCAT to X

The role that I am testing should allow the user to only display the specification type that I have restricted (i.e. ALLERGEN). However, when I perform the test I am prompted with an 'Authorization error'. The system trace indicates that I am missing ACTVT 03 for other specification types which I am not authorized to display (which is correct, as I do not want the user to see any other spec. type except ALLERGEN).

Any idea as to why the specification type restriction is not working as expected? Am I missing something here?

Any help would be greatly appreciated.

Thanks,

Jerry

Message was edited by: Ingo Sigmund

[former_member209335]

Hi Jerry,

Maybe Mr C.B is correct, Add manually C_SHES_TV2 and C_SHES_TVH Authorization Object in role.

As Mr C.B told you can control display and changes rights  through Activity.

An authorization group assigns authorizations to a user for working with specifications. Example ,user can only work with specifications if an authorization group has been entered in them authorization profile

Each specification type must be assigned to at least one specification category that categorizes the specifications into major groups (substances, agents, packagings, and so on).

If a special check function is defined for the specification type in Customizing, the system checks whether the specification key entered by the user for this specification type is syntactically correct.

you can possible to customize as per your requirement for authorization profile.

see the above mention example, Now the user can possible assess only Real-Substance specification data .You can use SU53 T-code to find out missing authorization Object and field name.

Use SU53 T-code it is more useful for identify the role related issues.

Edward

[Former Member]

HI Jerry,

From what I suspect from your issue is - there maybe an instance where to display the required specification type it may pass through another spec. type.

It's same like, calling an internal transaction if you execute one.

I suggest you to test first - by giving the traced authorization and then negative test the spec. types which you don't wish to see.

Reward if useful.

Cheers,

Daya

[christoph_bergemann]

Dear Jerry

may be check:

http://help.sap.com/saphelp_banking60/helpdata/en/a7/286e860a6c11d28a220000e829fbbd/content.htm

http://www.stechno.net/sap-notes.html?view=sapnote&id=1374539

http://www.stechno.net/sap-notes.html?view=sapnote&id=1122700

You need to use may be other "authorization" object for your check. New object seems to be:

C_SHES_TV2; old object: C_SHES_TVH

http://www.consolut.com/en/s/sap-ides-access/d/s/doc/YL-C_SHES_TV2

http://www.consolut.com/s/sap-ides-zugriff/d/e/doc/YO-RELNEHS_BD_500_AUTH_OBJ (sorry: by hazard I found only the german version; but an english one exists)

http://www.consolut.com/s/sap-ides-zugriff/d/e/doc/YC-EHSENVP_SP_AUTH_CHK_WITH_SUB (here the same)

http://www.consolut.com/s/sap-ides-zugriff/d/e/doc/YM-IF_EX_BADI_EHSS_AUTH_CHECK~~~~AUTH_CHECK_SHES_... (the same).

I know that it is possible, by using authorization object, to "reduce" the "specification type" per authorization group (e.g. you can establish authorization object like that that you can create a "REAL_SUB" only in authorization group "ALL" and not "SAP" (as an example). But as we do not use this feature: I would assume that standard rules can be applied. ACTVT 03 = read // ACTVT 01 = create. You are not allowed to change the spec type after creation of spec id.

C.B.

PS: check e.g. http://www.readbag.com/saphelp-hcc-uni-magdeburg-de-ecc-500-helpdata-de-e5-2c0b42ed755f24e10000000a1...

The "new" objects are mentioned shortly.