Problem with 'Top N tickets' links on 'RT at a glance' page in 3.8.1

RT Users
1

I’m seeing an odd problem with the ‘Top N tickets’ links (‘N highest
priority tickets I own’ and ‘10 newest unowned tickets’) on the ‘RT at a
glance’ page in RT 3.8.1. On the ‘RT at a glance’ page itself tickets
show up as they should but when I click on the link for the search (i.e.
click on the ‘10 highest priority tickets I own’ link) I get a ‘Found 0
tickets’ page. When I click on the ‘Edit Search’ link, it kicks me into
‘Advanced’ and I get an error in the ‘Results’ section:

Wrong query, expecting a OPERATOR in
‘%20Owner%>20<–here%3D%20%27__CurrentUser__%27%20AND%20(%20Status%20%3D%20%27new%27%20OR%20Status%20%3D%20%27open%27)’

And the text in the Query textbox is similarly URI-escaped. If I fix it
manually and click ‘Apply’ I then get the “Edit Search” page and if I
click the “Update format and Search” button on that page I then get the
results I was expecting. But if I then go back to the Home page and try
the same link again I get the same problem.

The really odd thing is that the ‘Bookmarked Tickets’ link on the ‘RT at
a glance’ page works fine.

Here is the link URI for the ‘N highest priority tickets I own’ link:

http://calhd01.na.local/Search/Results.html?Format='<a%20href%3D"%2FTicket%2FDisplay.html%3Fid%3D__id__">__id__<%2Fa>%2FTITLE%3A%23'%2C '<a%20href%3D"%2FTicket%2FDisplay.html%3Fid%3D__id__">__Subject__<%2Fa>%2FTITLE%3ASubject'%2C '__Priority__'%2C '__QueueName__'%2C '__ExtendedStatus__'%2C '__Bookmark__'&Order=DESC|ASC|ASC|ASC&OrderBy=Priority|id&Query=%20Owner%20%3D%20'__CurrentUser__'%20AND%20(%20Status%20%3D%20'new'%20OR%20Status%20%3D%20'open')&RowsPerPage=50

and here’s the one for the ‘Bookmarked Tickets’ link:

http://calhd01.na.local/Search/Results.html?Format='<a%20href%3D"%2FTicket%2FDisplay.html%3Fid%3D__id__">__id__<%2Fa>%2FTITLE%3A%23'%2C'<a%20href%3D"%2FTicket%2FDisplay.html%3Fid%3D__id__">__Subject__<%2Fa>%2FTITLE%3ASubject'%2CPriority%2C%20QueueName%2C%20ExtendedStatus%2C%20Bookmark&Order=DESC&OrderBy=LastUpdated&Query=id%20%3D%20'__Bookmarked__'&Rows=999

Thanks!

David Good

2

I looked into this some more and after some debugging, I see that the
query string argument ($Query) passed in
to Search/Results.html is URI encoded when it shouldn’t be. It looks
like it’s encoded properly in the link URL
when I ‘View Souce’ on the displayed ‘Home’ page but never gets decoded
(or it gets decoded and re-encoded
somehow). Does anyone have any ideas where I should look next?

I’m kinda surprised that there haven’t been any other reports of this
sort of problem. It seems to affect all saved searches.
We’re running RT 3.8.1 on a CentOS 5.2 with perl 5.10.0.

David Good wrote:

3

David Good wrote:

I looked into this some more and after some debugging, I see that the
query string argument ($Query) passed in
to Search/Results.html is URI encoded when it shouldn’t be. It looks
like it’s encoded properly in the link URL
when I ‘View Souce’ on the displayed ‘Home’ page but never gets decoded
(or it gets decoded and re-encoded
somehow). Does anyone have any ideas where I should look next?

I’m kinda surprised that there haven’t been any other reports of this
sort of problem. It seems to affect all saved searches.
We’re running RT 3.8.1 on a CentOS 5.2 with perl 5.10.0.

David,

I’ve run across this same issue, and it seems to be fixed by a (somewhat
hack-ish) patch to lib/RT/Tickets_Overlay_SQL.pm. Take a look at the
patch attached to ticket #12477:

http://rt3.fsck.com//Ticket/Display.html?id=12477

If you copy lib/RT/Tickets_Overlay_SQL.pm to
local/lib/RT/Tickets_Overlay_SQL.pm and apply that patch it should fix
the issue if it’s the same one I was seeing (which it sounds like it was).

Regards,
Tim

4

Tim Wilde wrote:

David Good wrote:

I looked into this some more and after some debugging, I see that the
query string argument ($Query) passed in
to Search/Results.html is URI encoded when it shouldn’t be. It looks
like it’s encoded properly in the link URL
when I ‘View Souce’ on the displayed ‘Home’ page but never gets decoded
(or it gets decoded and re-encoded
somehow). Does anyone have any ideas where I should look next?

I’m kinda surprised that there haven’t been any other reports of this
sort of problem. It seems to affect all saved searches.
We’re running RT 3.8.1 on a CentOS 5.2 with perl 5.10.0.

David,

I’ve run across this same issue, and it seems to be fixed by a (somewhat
hack-ish) patch to lib/RT/Tickets_Overlay_SQL.pm. Take a look at the
patch attached to ticket #12477:

http://rt3.fsck.com//Ticket/Display.html?id=12477

If you copy lib/RT/Tickets_Overlay_SQL.pm to
local/lib/RT/Tickets_Overlay_SQL.pm and apply that patch it should fix
the issue if it’s the same one I was seeing (which it sounds like it was).

Regards,
Tim

I found that at least in my case I could fix the problem by modifying my
RT_SiteConfig.pm to make the value of $WebBaseURL start with ‘https:’
instead of ‘http:’. Apparently when Apache rewrites requests from http:
to https: it triggers the problem. I’ll keep your patch handy though in
case I run into further problems (I had thought about doing something
similar but was afraid it might break something).

5

David Good wrote:

I found that at least in my case I could fix the problem by modifying my
RT_SiteConfig.pm to make the value of $WebBaseURL start with ‘https:’
instead of ‘http:’. Apparently when Apache rewrites requests from http:
to https: it triggers the problem. I’ll keep your patch handy though in
case I run into further problems (I had thought about doing something
similar but was afraid it might break something).

David,

Ah, thanks, so I solved the symptom rather than the disease - good to
know! :slight_smile: A sanity check deeper in the modules seems sensible to me
anyway, so perhaps it’ll get in there nonetheless. Thanks for the update!

Regards,
Tim