on 12-15-2014 6:27 AM
Hi Experts,
We are in Nakisa OrgChart (Version 4.0 SP1). And 4 different roles have been configured in Nakisa and as well as SAP R3.
After assigning the structural profiles to users in R3,In Nakisa OrgChart, Org Unit Listing is working fine, means manager will not be able to search Org Units that are not under the functionality.
Whereas in Nakisa Org chart hierarchy, initially his Org unit get defaulted, but when user clicked on “Start chart one level above” icon it is still moving up the level means system is allowing to see other org units which strictly doesn’t need to be accessed by manager.
As Observed, Structural profile is not working in Org chart hierarchy.
Also i have identified nakisa's standard rfc "/NAKISA/OC_OU_STRUCTURE " is not functioning as per structural profiles ...while debugging we came to know that it is calling 4 times when we click on "start chart one level above" icon. enhancing this rfc may be this issue would be resolved but is this correct approach...?
Kdly suggest if any notes are available to fix this issue.
Regards,
Subba.
Some RFCs, such as the one you have highlighted, have import params called
AUTH_CHECK
By default no value is passed from OrgChart into the RFC for this import para. If you wish auth checks to take place you need to set this value to X when calling the RFC.
The call to "/NAKISA/OC_OU_STRUCTURE" is made from
..\AppResources\dataelementconfiguration\OrgUnitHierarchyDataElement.xml
You will need to add an import param to the list like this:
<importparam> | |||||||
<param>AUTH_CHECK</param> | |||||||
<source>DefaultValue</source> | |||||||
<value>X</value> | |||||||
<caption><![CDATA[Authorisation checks]]></caption> | |||||||
</importparam> |
The your authorisation checks will apply (based on the auth profile assigned to the user making the RFC call (i.e. if you have put a specific user name in the data connection then this user will be used for all RFC calls. Remove that user name if you wish to use the user name of the authenticated user who is using OrgChart).
Note: Other data elements will need modifying in similar ways to cover position hierarchy calls, searching and details panels.
Regards,
Stephen
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't believe it is clearly documented (either how to do it or that the default is that no auth check takes place!).
Listings you can do in a similar way.
e.g. Position listing uses data element "Position_SearchDataElement.xml" which calls RFC "/NAKISA/OC_POSITION_LISTING" which has import parameter "IW_AUTH_CHECK".
QuickSearch is only about employees and you can't apply a similar method to it as it uses OTF schemas and lots of RFC READ_TABLE calls (which don't take account of auth profiles). On one project I'm involved in we are using other criteria within the OTF schema to restrict the data that QuickSearch indexes. That is the only method I can think of to control access but of course this will not restrict data based on the user.
Stephen
Hi Stephen,
sorry for late reply.
yes ..structural profile has been assigned to user and also it is working in listing. but structural authorization is not working in structures both Org and Position , also i have seen rfc trace and observed RFC "/NAKISA/OC_OU_STRUCTURE" which was called 5 times when i click the buttton "one level above icon".
I have no idea about parameters, please see the RFC TRACE log image below.
Also we have enhanced the above rfc for a temporary solution.
Thanks& Regards,
SUBBA
User | Count |
---|---|
107 | |
12 | |
11 | |
6 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.