Identifying the cause of broken sorting in iMIS Query Menu iPart

I’m back with my latest installment in Weird Things I’ve Found in iMIS version 20.2.65.9955. In this episode, we take a look at the Query Menu iPart and broken sorting.

I created a page with multiple instances of the Query Menu iPart, each of which loaded the results of a different IQA query. Everything looked pretty.

This made me happy.

Then I received a report that the sorting was broken: you could sort the query results in any of the Query Menu iParts one time, but nothing appeared to happen after you clicked any other column heading until you reloaded the page.

This made me sad.

Some investigation with Google Chrome’s Developer Tools revealed not a JavaScript problem, but that a 500 Internal Server Error was occurring on the second and subsequent clicks. Server event logs revealed an “invalid viewstate” error originating in Asi.Modules.ViewStateExceptionModule.

Next, I created a test page within RiSE, added the Query Menu iPart to it, and selected an IQA query. I published the page, viewed the page…and was able to sort the results as many times as I liked. After that, I tried removing all but one Query Menu iPart instance from my original page, published that page…and saw the same error as before.

After much headscratching and puzzled grunting, I finally realized the difference. I had accessed my test page, on which the Query Menu functioned as expected, at its actual location the server; e.g., http://www.example.org/ABC/Testbed/Test.aspx. In contrast, I had accessed my page where the Query Menus were not functioning as expected using the full URL as specifed under sitemaps; e.g., http://www.example.org/ABC/Portals/PortalA/ABC/Portals/PortalA/Default.aspx.

After that “aha” moment, I tried stripping the sitemap portion from my original page’s URL, accessing it directly instead (http://www.example.org/ABC/Portals/PortalA/Default.aspx). Once I did that, I was able to perform multiple sorts of the data returned in the various Query Menu instances with no further server errors.

My best guess at this point is that something about the Telerik code used to build the Query Menu iPart doesn’t play nicely with whatever black magic is happening behind the scenes to make the full URL work. Whatever the case, I’m happy to know I can use the workaround of accessing the page directly instead of including navigational structure in the URL.