Question

Crystal Reports as Operational report and row level security

  • 5 November 2020
  • 1 reply
  • 242 views

Hi,

I’m creating reports with Crystal Reports as operational reports on IFS Applications 10 Update 8 and I have question about whether row level security is applied or not when developing the report according to the guidelines. I would guess it is but the documentation is a bit ambiguous.

I’m guessing that I don’t understand exactly what is referred to in the first text extraction below. 

I’m referring to this page: https://docs.ifs.com/techdocs/Foundation1/050_development/025_operational_reporting/200_cr_as_operationalreport/default.htm

I’m making the confusing parts bold in the text below.

In the ‘Design and Security aspects’, it is stated that:
“The Crystal Reports executed this way always access the database using the same user as the Report formatter (i.e. no row based per user security is applied).“

Further down in ‘Data integrity and row based security’ it is stated that:
“As long as the Crystal Reports only accesses the report result table when querying data, the default IFS Applications security systems applies to the original data (i.e. a user can only see data he's allowed to see). Developing a report that access any other data than the report result set (i.e. the Info Services report view) will seriously jeopardize the security mechanisms of Foundation1 and IFS Applications. Since the row based security when accessing other views (except the report view and at the same time using the IFS_RESULT_KEY parameter in the report) are completely disabled users may get access to information they are not entitled to if the reports are designed incorrectly. An example could be that a user that only is allowed to see his own salary and his employees salaries in IFS Applications could get access to everyone's salary if a report is incorrectly designed to access the salary information directly rather than through the report result view.”

 

Kind regards


1 reply

Userlevel 7
Badge +18

IFS wants you to develop operational reports using only the _REP view.

For example, you might want to join from CUSTOMER_ORDER_IVC_REP to CUSTOMER_INFO_CFV to go retrieve a custom field for a customer to put on an invoice.

Joining the _REP view to another view can expose other data. In my experience, though, if your join condition is intelligently designed, this isn’t a problem.

Reply