Issues with ACL for report using project fields on status report

[staceyrocheleau]

I'm trying to run a report on the "status report" table under projects. This works fine for users who project roles but if I add the "project manager" field from the project table, it removes the records in the report due to a security constraint. I see that it's referring to the pm_project acl for read access which calls PPMRoleClassMapper. Now, this takes in the class name which I assume would be the status report table when I'm running the report from that view and therefore it fails as this isn't   in the script.

If the user views the project or the status report, he has no issues seeing the project manager information at all.

Any ideas of how to get around this?

Report:

ACL that fails with the highlighted issue (I believe) as the user has the roles required.

[staceyrocheleau]

My only thought is that this makes no sense how they've done it because they are assuming you are viewing the project ON the pm_project table and not in a report from another table.

In reporting, it causes a major issue.

So what about changing it to simply state "pm_project" instead of current.sys_class_name as it's the security for pm_project.

if ( gs.hasRole('project_user') ) {
   if ( PPMRoleClassMapper.validateAccess(gs.getUser(), 'pm_project') )
   answer = true;
   else
   answer = false;
} else {
   answer = true;
}

or to simply solve my issue

var class_name = current.sys_class_name;
if (class_name == 'status_report') {
class_name = 'pm_project';
}

if ( gs.hasRole('project_user') ) {
   if ( PPMRoleClassMapper.validateAccess(gs.getUser(), class_name) )
   answer = true;
   else
   answer = false;
} else {
   answer = true;
}

[stephenbassett · Accepted solution]

Stacey,

I was having the same problem with reporting on a custom table that pulled fields from the project table through a reference field.   I had scripted an answer similar to yours that worked, but I also put in a ticket with SN support.   Support told me that this is an issue, PRB581123: Reporting that involves dot-walked fields returns no data (list report).  

The fix is to add a property to the sys_properties table called "glide.ui.optimize.lists" and give it a string value of "false."

From support:

"What is happening is, when the property is True the glide-record with those columns defined on the ACL (at the same time not present on the list view of the report) are not initialized to a value and are null. So when the ACLs are evaluated for conditions/scripts for non-null values the ACL will fail. The only downside of having these properties set to false is, when there are large rows of data to be displayed, there could be performance implications. Meaning, the report rendering might take longer than usual, depending on the amount of data being displayed."

This worked for me.

Stephen