Have you created an InfoPath form and used REST webservices to retrieve filtered data using rules to modify the filter parameters and faced issues.
Very recently we had an interesting problem reported in our production environment where one of the InfoPath form hosted for an application serving executives taking page load times of 45 seconds. We immediately started looking into the form to perform root cause analysis; after spending an hour we realized its due the way the form is designed to retrieve data from a list and use "Filter Data" assignment of the default value of the field.
The list items of that list had grown to 900 items and thus was taking a really long time to load the data and then apply filters, we immediately changed the approach to use ListData.svc REST webservice to retrieve only the filtered data based on the logged in user. While the approach worked fine for the users who had admin privileges but we were getting complaints from the executives that the form has stopped working completely.
Further analysis of ULS indicated an interesting log entry which was triggered immediately when the form was trying to modify the REST url to invoke a REST service call.
12/07/2012 17:01:52.71 w3wp.exe (0x0780) 0x1A5C SharePoint Foundation General 8kh7 High Access denied. a1403e1e-1194-4fc4-bbd7-2fcf2a9cd096
Very recently we had an interesting problem reported in our production environment where one of the InfoPath form hosted for an application serving executives taking page load times of 45 seconds. We immediately started looking into the form to perform root cause analysis; after spending an hour we realized its due the way the form is designed to retrieve data from a list and use "Filter Data" assignment of the default value of the field.
The list items of that list had grown to 900 items and thus was taking a really long time to load the data and then apply filters, we immediately changed the approach to use ListData.svc REST webservice to retrieve only the filtered data based on the logged in user. While the approach worked fine for the users who had admin privileges but we were getting complaints from the executives that the form has stopped working completely.
Further analysis of ULS indicated an interesting log entry which was triggered immediately when the form was trying to modify the REST url to invoke a REST service call.
12/07/2012 17:01:52.71 w3wp.exe (0x0780) 0x1A5C SharePoint Foundation General 8kh7 High Access denied. a1403e1e-1194-4fc4-bbd7-2fcf2a9cd096
It was found that users with read privileges won't be able to make use of the Modify Filter Parameters ruleset and they need an additional permission set "Browse Directories" in order to make this work.
So we created an additional permission level which is the replica of the "Read" permission level with an extra permission "Browse Directories" permission added to it. The permission level should look like
