Authorization control for 2, T-codes at a same role

[Former Member]

Hi all I need your professional support

When we execute the PV00 t-code and try to “Create Attendance “and it will allow the user to create it by going to PA40 which should not allowed and this has to be blocked.

But in the same user under a different role, PA40 is also attached and we have to keep it available to the user.

If I specify more about this issue, under HR role we have assigned PA40, for 5 personal areas and for another role we have assigned 20 personal areas for PV00, so if the same user try to click on the “Create Attendance” it will give 20 personal areas access through PA40 , which we have to block it some how. Through PV00, should not allow the user to access PA40 transaction. I tried through authorization which I couldn’t control.

We are using role based authorization. Please advice me how to resolve this issue.

[Former Member]

Hi there.

what about restric access to one of the transactions at the role level. If you are using the role based approach for authorizations it should be based on the derived role concept.

Basically you'll have a master role with as many derivations as the organization requires. The menu structure and transaction assignment willl be maintained at the Master role level which does not have any authorization profile. The authorizations are maintained at the derived role level.

In other words your security concept will be based on transaction+Object access control following the derived approach.

Consider running Virsa reports to identify security overlaps, and SOD breaches.

Cheers,

Damien

[Former Member]

Hi ,

Here the different master role with the T code PA 40 and PV00 have to be created and the roles can be derieved from the master roles as per the personal areas , here in this case 5 derived roles for PA40 role and 20 derived roles for PV00 role .Then the users belonging to the specific personal area can be assigned to their derieved roles and the authorisation can be given .

Here we can avoid a user from a particular personal area getting the view of other personal areas.

Regards,

Sagar

[manohar_kappala2]

Hi,

If you feel that the access to PA40 cannot be avoided then the control can be made through the control of infotype.

So avoid giving him access to create attendees (Authorization Level: W) for the infotype 0000 so that even if he is in that transaction he will not be able to make that action. but if he needs this access for sure which is the case for PA40 then the option left is to go for a customization or redesigning the role mapping .

[RainerKunert]

Hi,

authorizations are additive. If you have some role with TCode PV00 and another with TCode PA40, both will be granted. If role 1 grants access to 20 personal areas and role 2 only to 5 personal areas, the sum of both roles will grant access to all personal areas. The authorizations depend on the infotypes in both roles.

If you need PV40 with 20 personal areas and PA40 with only 5 areas (and the same infotypes with the same activities for these infotypes; object P_ORGIN) you must use two different users.

I think you should try to restrict the roles dependent on infotype and activity.

Kind regards

Rainer