cancel
Showing results for 
Search instead for 
Did you mean: 

HCM Authorizations - Activating P_ORGINCON (...already using P_ORGIN)

Former Member
0 Kudos

Hi all,

I have a question regarding taking context (structural) based authorizations into use.

Until now, we have been using the P_ORGIN & P_ORGXX objects for HR authorizations.

Now we would like to implement new structural authorizations for managers, by taking the P_ORGINCON (context) object into use. The idea is to add relevant access to all manager related HR processes into 1 context based manager role.

We will keep using the P_ORGIN & P_ORGXX objects for other HR authorization, at least for a while.

I am assuming that it is possible / no harm in activating the P_ORGINCON object for our new manager role, even though we are still using P_ORGIN & P_ORGXX as well (?).

My questions are:

- Which precautions should we take when activating P_ORGINCON, now that we already use P_ORGIN & P_ORGXX?

- Is it necessary to do any adjustments to our existing P_ORGIN & P_ORGXX based roles, after P_ORGINCON has been activated?

Am looking forward to your comments, thank you!

Jenzen.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

> - Which precautions should we take when activating P_ORGINCON, now that we already use P_ORGIN & P_ORGXX?

> - Is it necessary to do any adjustments to our existing P_ORGIN & P_ORGXX based roles, after P_ORGINCON has been activated?

Technically you can have both settings active (ORGIN and INCON) but remember that you have to add P_ORGINCON with corresponding values to roles which currently have P_ORGIN. So at the end it doesn't really make sense to have both options active unless you have lot of custom programs with AUTHORITY-CHECK statements against P_ORGIN. Even then I would consider changing those.

Remember also that when you assign first structural profile to user then access is actually delmited because users who don't have any structural profile assigned will get their authorisation from SAP* entry which normally have profile ALL. So if you assign a manager structural profile which gives access to his/her own employees only the ALL access is gone unless you assign also profile ALL separately.

's

Former Member
0 Kudos

Hi SaQ,

Thanks a lot for your answer!

I agree with you that normally it does not really make sence to activate both ORGIN and INCON. However, our currenly situation is that we do not have time/budget for changing our intire HR role catalog from ORGIN to INCON now - so we will start out with the manager roles.

I have a question to one of your comments: "...remember that you have to add P_ORGINCON with corresponding values to roles which currently have P_ORGIN".

Do you mean that we have to add the P_ORGINCON object to ALL our existing HR roles which currently use P_ORGIN, or are you 'only' referring to our existing manager roles, which we would like to change now?

If you are referring to ALL our HR roles, is it then sufficient to add the P_ORGINCON object as being inactive, or do we also have to add all the values which are already added to the P_ORGIN object?

Thanks again for your help!

Former Member
0 Kudos

> Do you mean that we have to add the P_ORGINCON object to ALL our existing HR roles which currently use P_ORGIN, or are you 'only' referring to our existing manager roles, which we would like to change now?

>

> If you are referring to ALL our HR roles, is it then sufficient to add the P_ORGINCON object as being inactive, or do we also have to add all the values which are already added to the P_ORGIN object?

Hi Jenzen,

I am afraid you have to add active P_ORGINCON with corresponding values to all roles which have P_ORGIN. Depending on the number of roles and P_ORGIN-objects in them it can be lot of work. So it's pretty much same effort of work required when when you use both objects or just P_ORGINCON.

Regards,

s

Answers (1)

Answers (1)

Former Member
0 Kudos

hmm... I agree with the answers provided by saq.. and would like to add that your requirement could potentially mean a lot testing effort.

I am also curiouswhy p_orgincon? why not plain old simple structural auths based on lets say a z-function-module for determining area of responsibility? I have come across very few context based requirements in my experience.. ..

would appreciate a reply..

cheers