Filters not being respected through LOGINUSER admin service

Stephen Short shared this problem 10 months ago
Defect Fixed

I'm attempting to use the FILTER<ID> parameter specified for the LOGINUSER administration web service, however it does not seem to be respecting the filters I specify in the URL. However, if I use the same filter parameters when going through the runReport.i4 entrypoint, the filters are respected.

I'm not sure why this would be the case - seems like they should be respected regardless. However, they are just bringing up whatever cached filter values the user has on the given report.

For reference:

This works (RunReport.i4 entrypoint):

http://localhost:8900/RunReport.i4?reportUUID=<REPORT UUID>&primaryOrg=1&clientOrg=12000&filter69631=S1000%7CS1500&filter69632=SS10944%7CSS10955

However this does not, despite the documentation mentioning (see http://wiki.yellowfin.com.au/display/USER73Plus/Administration+Service) that it should for the VIEWREPORT entrypoint:

http://localhost:8900/logon.i4?LoginWebserviceId=<LOGIN TOKEN>&entry=VIEWREPORT&reportuuid=<REPORT UUID>&yftoolbar=TRUE&disablesidenav=TRUE&disablelogoff=TRUE&hidefooter=TRUE&hideheader=FALSE&filter69631=S1000%7CS1500&filter69632=SS10944%7CSS10955

Notice that the filter options are the exact same, but the VIEWREPORT entry merely pulls up whatever the default / cached filters for the user are, where the RunReport entry correctly applies the specified filter options. Any idea why this is the case / could I get this looked into?

Comments (2)

photo
1

Hi Stephen,

Thanks for reaching out with your issue. I've replicated this behavior and am raising this as a Defect in our internal ticketing system. I'll keep this post updated with further information regarding a fix for this issue.

The best work around I could find was defining default filters for the report in question. If it's required that you have different instances of the report with specific filters, one could create a copy of the report and adjust the default filters. This will allow you to populate filters using defaults as desired in the meantime.

I understand this may not be the news you were hoping for and am sorry for any inconvenience this may be causing.

Thanks,

Ryan

photo
1

Hi Stephen,

I wanted to update this item and let you know that this Defect has been marked as fixed for both 7.3.12 and 7.4.6, which are available now on our Latest Builds page. Please let us know if you have any issues.

Thanks,

Ryan