NPrinting on-demand does not recognize Section Access for the user who generated the report. The reason is that the Service Account opens the dashboard, and applies the selections the user had. Since the Service Account and the user can have different permissions, the data reduction is not passed through when generating the report.
The gist of the article is that you can build a table within the dashboard using the Section Access file, and use it to generate a recipient list with the associated filters in NPrinting, then use the run task extension object instead of the run report object. The user who runs it will have their filter applied, which is effectively the same as the Section Access.
I found some potential issues/difficulties with the method in the article:
Depending on the number of reports, this can take a lot of work to set up. You need to set up a separate task for each report, with all the settings that go with it. If you allow the user to choose an output format (Word, Excel, PDF, etc), you need even more tasks, as you can’t pass that through like you do with the Run Report object.
Sometimes the information in the report is super-confidential, and it's not supposed to be emailed without a password protecting it. With an automated email, you don’t have the same protection. NPrinting does allow you to assign a password, but it will always be the same – to change it, you’d need to migrate a new version of the nsq file.
What I realized is that we can use some of the techniques from the article, and keep using the Run Report object to generate the reports. Instead of using a task and utilizing the filters within the NPrinting client, we can use the Filters tab on the Run Report object. Since the filters are assigned the name of the user, we can use the OSUser() function (just as the article outlines to assign the recipient) to call the filter. We still need to import the recipients, because that is what generates the filters, but we won’t use the recipient list – just the filter list.
A few points about the filters:
In Section Access, you can use an asterisk to show someone has access to all values. NPrinting filters don’t recognize an asterisk. You need to assign all the values. I do this by creating either a field or a variable in the script which concatenates all the values into a single record. I then use an If statement to say that if there’s an asterisk, use the full list instead.
NPrinting does limit the number of values that can be imported, but I’m not sure what the limit is. In a dashboard where you may have thousands of case numbers, the number is too high. NPrinting does allow you to exclude values instead of including – however, the value you exclude does need to actually exist. You can’t put a dummy value in your exclude function. So if there are 10,000 case numbers, and I have access to all of them, I can’t just say exclude case X. X has to be a real value. I get around this by concatenating a row to the table with the Section Access field – in this case, [SA_CASENO], with a value of X. No other fields on the table will be populated, only the field we’re reducing. Now that it has a value of X, the filter will work properly when I exclude the value.
To set it to exclude values when doing the Recipient Import, add the string <excluded> to the end of the filter string. In this case, here is my syntax: 'SA_CASENO={' & Concat(DISTINCTUpper(SA_CASENO),',') & '}<excluded>'
Since the Recipient list needs to be constantly updated to keep up with a changing Section Access list, the Import Recipients task needs to have a schedule attached to it, and it needs to be in the folder which NPrinting monitors for scheduled tasks.
Thanks so much for writing up this very comprehensive guide.
One thing to note is that this is for NPrinting 16.
NPrinting 17 has a totally different way of managing section access and some of the functionality in 17 is also significantly different (no NSQ files...).
