Adding parameters to a report

[matthias_burhen]

Hi everybody,

I was at a customer site yesterday and they were asking for some additional possibilities when creating reports. Basically what they want is this:

- Have reporting admins who can define global reports and change them in any way shape or form.
- The report admins are supposed to be able to define filters which report consumers should not be able to change at all
- In addition to those fixed filters, the report admins should be able to name a set of 'parameters' (in most cases I guess this will be fields on the underlying table) which the report consumer (i.e. Process User without any reporting role) can fill with values according to the field type. This would basically be a second filter, only that you can not add or remove fields, but only set the values.
- if the above does not work to full extend, they would also be able to live with a second set of filters that can be set freely like any other filter field.

My idea was to put a second filter field on the report table (sys_report) which would be accessible only be report admins. This would represent the fixed filter that can not be changed by the process users. My problem is that I have no idea how to enforce this second filter to be applied when the report is run. Do you guys have any ideas, experience or sources regarding something like that?


Thanks a lot
Matt

[Michael Kaufman]

1. Have reporting admins who can define global reports and change them in any way shape or form.

There is a role called "report_global" you can use for this.

2. The report admins are supposed to be able to define filters which report consumers should not be able to change at all

There is a role called "filter_global" you can use for the report admins. User can still make personal filters OOB, to disable this, go to System Properties > UI Properties, and add roles to List of roles (comma-separated) that can use Personal Lists. If blank, all can use.

3. In addition to those fixed filters, the report admins should be able to name a set of 'parameters' (in most cases I guess this will be fields on the underlying table) which the report consumer (i.e. Process User without any reporting role) can fill with values according to the field type. This would basically be a second filter, only that you can not add or remove fields, but only set the values.

You can't set Parametered filters in ServiceNow currently. Users can personalize their filters however, just not have parameterized reports. It is a different way of reports with more flexibility, but I understand your need as well. In order to build those types of reports, I suggest using a reporting tool like SAP Crystal Reports. That isn't as nice as SN Reports, but can do all of that. I will often start building all reports in ServiceNow, and wait until the end of the project to build any parameterized reports in SAP Crystal Reports.

Your idea about creating the ability to make parameterized reports in ServiceNow would require modification of UI Macros, new GlideAjax dialogs, and possibly locked ServiceNow functionality. You may not be able to do this with your rights as a customer, and it may take considerable skill to do so if able. It would be pretty cool if you were able to do it though.

4. if the above does not work to full extend, they would also be able to live with a second set of filters that can be set freely like any other filter field.

You can add multiple types of "global" filters users can pick from. Setup instructions here which you have probably read: http://wiki.servicenow.com/index.php?title=Using_Filters_and_Breadcrumbs

I did hear that the Calgary release of ServiceNow has more reporting functionality. However I don't know if they are adding parameters.

[matthias_burhen]

Thanks for your comment. I actually found a way to do something close to parameterized reports. The trick was to add a second condition field (i.e. Filter field) to the report form (sys_report table). This filter can be set by report admins (report_admin role). For everyone else, a Client Script removes all the buttons to add or remove fields from the filter. It also disables the field selections in the filter field. So basically you can only set the values and operators on the filter.
The global filters are stored in yet another filter that is only ever visible to the report admin. When saving the report both those filters are concatenated into the original filter field so that the report can be run using the OOB 'View Report' button.
I also locked down the header expansion in the Report View/Run module so that the filters can not be changed there as well. Only exception here are report admins. I have yet to decide what happens, when report admins change the filter on the View/Run module, but I think I will then just put all the information into the fixed filter that only the admins can user. It is a bit inconvenient I think, but it should be close to the functionality that was required.

[julienr]

Hello Mathias,

I understand this is an awfully old post, but as I'm trying to get something very similar working, I thought I'd try.

I'm trying to run a report on INC table where 'opened_by' 'is member of' 'groupX'.

I have successfully implemented a script include which does that (so my condition being 'Opened_by' 'is' 'javascript:inGroup('GroupX')'. However, I do not find this solution very elegant and not really usable for anyone but us, which would then lead users who need new reports with group filtering to ask those from us. Bleh.

So I'm trying to create an operator which would make it usable for everyone. And it seems, reading your post, that you succeded.

Would you care to explain a little more how you managed this trick?

I'd be eternally grateful!