topic Re: Authorization check approach needed for custom transaction code. in Application Development and Automation Discussions

Authorization check approach needed for custom transaction code.

Former Member — Wed, 18 Feb 2015 09:56:38 GMT

Hi Friends,

We have developed a custom report to display TRIPS (Travel Requests/Expenses). Also a transaction code has been assigned to it. The requirement is that, based on the user who is executing the report, the output should be displayed accordingly.

a. If the user is an Employee, then only his/her trips needs to be displayed.

b. If the user is an Accountant/Manager, then the report must display all the trips. Other Employees' as well as their own.

Our understanding was that a combination of the authorization object P_TRAVL and an authorization check code in the report program will be sufficient.

There are 3 different roles existing in the system for Employee, Accountant and Manager. The P_TRAVL object used in these roles has the below values:

1. Employee Role : P_TRAVL -> AUTHP = O

2. Accountant Role : P_TRAVL -> AUTHP = E,O

3. Manager Role : P_TRAVL -> AUTHP = E,O

In the authorization check part of the report program, we are utilizing the FM "SUSR_USER_AUTH_FOR_OBJ_GET" by passing the User Name and the authorization object P_TRAVL and retrieving the AUTHP values and the profile name. Depending on these values (E or O) we get to know if it is an Employee or Accountant/Manager. Then the output is displayed accordingly.

The scenario where the above logic fails is when a person is assigned both the roles i.e. Employee's as well as Accountant/Manager's roles. In this scenario the Employee's validation restricts the output to be displayed.

Also now the client has come back saying that only the P_TRAVL object needs to be utilized and the custom coding authorization check should be removed. The reason being, when the custom transaction code for this report is put in a separate role which is meant for reporting purpose they are facing issues one of them being the above mentioned scenario which is failing.

QUERY : How can we put restrictions in the report only on the basis of P_TRAVL object? OR Is there some other approach to achieve this?

Please do share your expertise/experience. Do let me know if any more details are to be provided.

Thank you for your help in advance.

Regards,

Vish

Re: Authorization check approach needed for custom transaction code.

kiran_k8 — Wed, 18 Feb 2015 11:38:54 GMT

Vishwanath,

If I understood your issue correctly,try creating two T-Codes and then validating within the program based on the T Code in addition to the existing validations.Depending on the need you can add the required tcodes in the User Profile.

K.Kiran.

Re: Authorization check approach needed for custom transaction code.

Former Member — Wed, 18 Feb 2015 11:52:04 GMT

Hi,

Will the following approach help solve your problem:

Let us assign one role per user-interface:

1. Employee Role: P_TRAVL -> AUTHP = O

2. Accountant/Manager Role : P_TRAVL -> AUTHP = E

In the report, while custom coding authorization check, if AUTHP retrieved value is:

O -> display filtered content

E -> display whole content

Let me know.

Re: Authorization check approach needed for custom transaction code.

Former Member — Wed, 18 Feb 2015 13:23:33 GMT

Hi Kiran,

Not sure if you got the requirement fully, but two transactions is not what we are looking for.

The report output needs to be displaying values as per the user, Employee to see only his trips and Manager/Accountant to be able to view all the trips.

Thanks for sharing your thoughts.

Regards,

Vish

Re: Authorization check approach needed for custom transaction code.

Former Member — Wed, 18 Feb 2015 13:29:37 GMT

Hi Utkarsha,

The existing approach is inclusive of what you have mentioned. If you look at the below part that I had mentioned in my post:

"In the authorization check part of the report program, we are utilizing the FM "SUSR_USER_AUTH_FOR_OBJ_GET" by passing the User Name and the authorization object P_TRAVL and retrieving the AUTHP values and the profile name. Depending on these values (E or O) we get to know if it is an Employee or Accountant/Manager. Then the output is displayed accordingly."

Here you have proposed to assign one role per user type. This works fine in the current logic but there are few users having all the types of roles, so this approach fails.

Thanks for giving it a try.

Regards,

Vish

Re: Authorization check approach needed for custom transaction code.

Former Member — Thu, 17 Sep 2015 19:11:02 GMT

Closing the thread. Solution identified was to handle it at the role level.