Mix of Authorization objects PLOG and ORGINCON

Former Member · ‎05-22-2012

Dear Experts

In an authorization role we have activated the ORGINCON-object incl. structural authorization so that the user can only maintain PA data from his area. On the other side we have the PLOG-Object where we set restrictions for the PD infotypes.

In practice we search for a solution to the following problem: a user can only create relationships in infoype 1001 for people from his area, e.g. book participants on a course but in case of relationship A 026 (is held by), the ORGINCON should be ignored, so that the user can book anybody as a trainer of the course.

Is there a possibility to ignore the ORGINCON restrictions for a specific relationship?

Many thanks for your help.

Former Member · ‎05-23-2012

Hi Diego,

Sorry, I would need more to accurately understand the scenerio. In structural authorization based security, structural profiles determine the PD/OM objects of org structure that are accessible to the users & P_ORGINCON values restrict the access to maintain/display PA data (PA infotypes) for the authorized OM entities.

But PLOG works independently and is only restricting access of creating, maintaining, relating OM objects which the user is authorized to, as per his structural profile. Can you please let me know in your case which PA infotype is being checked when user tries to create an OM/PD relationship in IT1001 with Subtype A026, that you want to bypass?

 so that the user can book anybody as a trainer of the course.

The above statement I believe is creation of relationship A026. Please excuse me if I have misinterpreted the actual issue Appreciate if you could ellaborate the scenerio a bit more for my understanding.

Thanks

Sandipan

Former Member · ‎05-23-2012

Hi Sandipan

For the user SCHLASL1 we have set in the P_ORGINCON the Personnel Area = 60* what means that the user only has access to PA infotypes for employees from the Area 60*.

The user SCHLASL1 now wants to create in IT1001 a relationship A026 on a course type with the employee 00513118 who is related to personnel area = 8000. If he select in the field "Type of related object" = "P" and "ID of related object" = "00513118" he receives the error message "Personnel number 00513118 does not exist". This because of the restriction of 60* in the P_ORGINCON.

Is there a technical possibility to ignore the settings of personnel area in P_ORGINCON for one specific subtype in PLOG like A026? So that the user SCHLASL1 can choose people from all personnel areas?

Thanks

Diego

Former Member · ‎05-23-2012

Hi Diego,

Thanks for ellaborating the issue. This is immensely helpful and clear.

Neither the restrictions of authorization fields of P_ORGINCON nor its context are applicable for object PLOG. In other words, the object PLOG will restrict a user to all those OM/PD objects (in this scenerio Persons-P) which are determined by his structural profiles & any further restriction will only be in terms of the authorization fields of PLOG object.

From the error message it seems to be a data issue rather than an authorization issue. Please run a ST01 trace to confirm if P_ORGINCON is being checked at any point while creating the OM relationship in IT1001.

Can you also check through program RHUSERRELATIONS if user-SCHLASL1 has access to P= 00513118 from his structural profiles? Please let me know the period of responsibility and period flags of P=00513118 from the program output if you find it there. In case you do not find that value, that means the structural profile is not determining your person at all and that needs to be fixed.

Thanks

Sandipan

P.S: I hope you have already considered running the structural indexing programs- RHBAUS02 and RHBAUS00 for the user. Thanks

Message was edited by: Sandipan Choudhury

Former Member · ‎05-23-2012

Hi Sandipan

I have checked the ST01, here the result in bold (personnal number 513118 is assigned to pers. area 3910):

Client:     200 User:        SCHLASL1     Transaction LSO_PSV2             4FBCDF0FBEAD714AE100000088EE52A5
Work Process               1 PID          Date: 23.05.2012                 Start:14:44:06:580.495Finish:14:44:06:600.744
First Block of Dialog Step                Last Block in Dialog Step
Block Version:            2080 No. of Records:               5 File Version: 1

hh:mm:ss:ms Type Lasts(us) Object Text

14:44:06:581 AUTH    - - -   PLOG       RC=0 PLVAR=01;OTYPE= ;INFOTYP= ;SUBTYP= ;ISTAT= ;PPFCODE=DISP;
14:44:06:581 AUTH    - - -   PLOG       RC=0 PLVAR= ;OTYPE=D;INFOTYP= ;SUBTYP= ;ISTAT= ;PPFCODE=DISP;
14:44:06:581 AUTH    - - -   PLOG       RC=0 PLVAR= ;OTYPE= ;INFOTYP= ;SUBTYP= ;ISTAT=1;PPFCODE=DISP;
14:44:06:587 AUTH    - - -   P_TCODE    RC=0 TCD=PP01;
14:44:06:587 AUTH    - - -   S_TCODE    RC=0 reason=C;TCD=PP01;

Client:     200 User:        SCHLASL1     Transaction PP01                 4FBCDF0FBEAD714AE100000088EE52A5
Work Process               1 PID          Date: 23.05.2012                 Start:14:44:10:650.281Finish:14:44:10:668.116
First Block of Dialog Step                Last Block in Dialog Step
Block Version:             744 No. of Records:               1 File Version: 1

hh:mm:ss:ms Type Lasts(us) Object Text

14:44:10:650 AUTH - - - PLOG RC=0 PPFCODE=INSE;PLVAR=01;OTYPE=D;INFOTYP=1001;SUBTYP= ;ISTAT=1;

Client:     200 User:        SCHLASL1     Transaction PP01                 4FBCDF0FBEAD714AE100000088EE52A5
Work Process               1 PID          Date: 23.05.2012                 Start:14:44:20:330.017Finish:14:44:20:336.777
First Block of Dialog Step                Last Block in Dialog Step
Block Version:            5764 No. of Records:              10 File Version: 1

hh:mm:ss:ms Type Lasts(us) Object Text

14:44:20:330 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0001;SUBTY=' ';AUTHC=R;PERSA=*;PERSG=*;PERSK=*;VDSK1=*;PROFL=*;TCD=PP01;
14:44:20:330 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0001;SUBTY=' ';AUTHC=R;PERSA= ;PERSG= ;PERSK= ;VDSK1= ;PROFL= ;TCD=PP01;
14:44:20:332 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=*;PERSG=*;PERSK=*;VDSK1=*;PROFL=*;TCD=PP01;
14:44:20:332 AUTH    - - -   Z_ORGINCON RC=0 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA= ;PERSG= ;PERSK= ;VDSK1= ;PROFL= ;TCD=PP01;
14:44:20:332 AUTH    - - -   Z_ORGINCON RC=0 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA= ;PERSG= ;PERSK= ;VDSK1= ;PROFL= ;TCD=PP01;
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4 INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000

You see, as soon as I want to insert the personnel number, the ORGINCON-Object is affected. I have furthermore deleted and recreated the structural authorization profiles for Org. Management, there was no difference in the result. It has no influence for this topic. The problem really seems to be the missing authorization from Infotype 0002 from the ORGINCON-Object.

In the following images you see a simplified view of the situation:

PLOG object:

ORGINCON object:

and here the printscreen from creating a relationship:

You see as soon as data from IT0002 is affected, the filter of Pers. area attracts. If I paste a personnel number from the pers.area 6000 it works without problems.

BTW: The reports RHUSERRELATIONS as well as the RHBAUS02 and RHBAUS00 seem to be ok.

Do you know any solutions?

Thanks a lot.

Diego

.

Former Member · ‎05-24-2012

Hi Diego,

14:44:20:330 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0001;SUBTY=' ';AUTHC=R;PERSA=*;PERSG=*;PERSK=*;VDSK1=*;PROFL=*;TCD=PP01;
14:44:20:330 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0001;SUBTY=' ';AUTHC=R;PERSA= ;PERSG= ;PERSK= ;VDSK1= ;PROFL= ;TCD=PP01;
14:44:20:332 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=*;PERSG=*;PERSK=*;VDSK1=*;PROFL=*;TCD=PP01;
14:44:20:332 AUTH    - - -   Z_ORGINCON RC=0  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA= ;PERSG= ;PERSK= ;VDSK1= ;PROFL= ;TCD=PP01;
14:44:20:332 AUTH    - - -   Z_ORGINCON RC=0  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA= ;PERSG= ;PERSK= ;VDSK1= ;PROFL= ;TCD=PP01;
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
14:44:20:333 AUTH    - - -   Z_ORGINCON RC=4  INFTY=0002;SUBTY=' ';AUTHC=R;PERSA=3910;PERSG=1;PERSK=18;VDSK1=3900;PROFL=YCCA:0000
You see, as soon as I want to insert the personnel number, the ORGINCON-Object is affected. I have furthermore deleted and recreated the structural authorization profiles for Org. Management, there was no difference in the result. It has no influence for this topic. The problem really seems to be the missing authorization from Infotype 0002 from the ORGINCON-Object.

Correction! What is failing is object Z_ORGINCON (not P_ORGINCON) which seems to be a customer specific authorization object (see documentation for P_NNNNNCON) and a custom authorization check has been enforced for this object via a BADI when anyone in your system tries creating OM relationships via PP01. The logic for custom auth check might be dependent on OM objects or the relationship types. This is not a SAP standard authorization check.

What I was explaining earlier was relevant to SAP delivered auth object P_ORGINCON and PLOG. Your case seems to be different and customer specific authorization check on Z_ORGINCON is causing the issue. You can look in transaction HRAUTH to identify the BADI implemented for enforcing this custom auth check or consult your developer. My best guess is BADI- HRBAS00_RELAT (HR: Exit for Relationships) or HRBAS00INFTY(Update by) has been used in your case.

Should you have any questions, please do let me know.

Thanks

Sandipan

Former Member · ‎05-30-2012

Hi Sandipan

I was not aware of the difference between Z_ORGINCON and P_ORGINCON. Some years ago we had an external employee for the authorization concept. So he has created a customer-specific authorization object. Unfortunately nobody knows the reason. The assumption is correct, the HRBAS00INFTY is implemented.

Do I understand correctly: If we would have PLOG in combination with P_ORGINCON we could solve the problem, but as soon as we have a Z_ORGINCON with a BADI implemented it doesn't work?

Best regards,

Diego

Former Member · ‎06-04-2012

Hi Diego,

Glad we could identify the root cause of the issue.

Do I understand correctly: If we would have PLOG in combination with P_ORGINCON we could solve the problem, but as soon as we have a Z_ORGINCON with a BADI implemented it doesn't work?

As I mentioned in one of my earlier posts, object PLOG and P_ORGINCON restrict user's access independently (PLOG controls OM/PD access & P_ORGINCON controls PA data access). Only thing common between them are the OM/PD objects (part of org structure) as determined by user's assigned structural profiles.

With customization in your system, BADI enforces the system to check for PLOG first and then Z_ORGINCON whenever users try to create OM relationship as you described in your first post.

Hope this is helpful. Should you have any questions, please do let me know.

Cheers!

Sandipan