Cannot bookmark searches on relative comparisons?

Hi, folks –

I am using RT 3.0.2 and am having trouble bookmarking searches that
involve relative comparisons. For example:

  • I search for tickets where “owner = joe” and “priority < 100”
  • Bookmark this search.
  • Search for tickets where “owner = fred”, but don’t bookmark it.
  • Open a new browser window.
  • Visit the bookmarked search.

The bookmarked search should show me Joe’s tickets with priority less
than 100, but instead it shows me Fred’s tickets – it returns the
currently cached search rather than the one frozen in my bookmark.

Has anyone seen behavior like this? I was not able to find any
similar problem reports in the rt-users archive or elsewhere on
Google, and nothing in the release notes to suggest that this behavior
had been noted and fixed.

– Tim Pierce
twp@unchi.org

Yes, I’m seeing more or less the same thing. I think it may have
something to do with length of the URL.

I’m running RT 3.0.7 on FreeBSD 4.8 and using Firebird 0.7.

Tim Pierce wrote:

Tim Pierce wrote:

Hi, folks –

I am using RT 3.0.2 and am having trouble bookmarking searches that
involve relative comparisons. For example:

  • I search for tickets where “owner = joe” and “priority < 100”
  • Bookmark this search.
  • Search for tickets where “owner = fred”, but don’t bookmark it.
  • Open a new browser window.
  • Visit the bookmarked search.

The bookmarked search should show me Joe’s tickets with priority less
than 100, but instead it shows me Fred’s tickets – it returns the
currently cached search rather than the one frozen in my bookmark.

Has anyone seen behavior like this? I was not able to find any
similar problem reports in the rt-users archive or elsewhere on
Google, and nothing in the release notes to suggest that this behavior
had been noted and fixed.

– Tim Pierce
twp@unchi.org


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Jason Taylor wrote:

Yes, I’m seeing more or less the same thing. I think it may have
something to do with length of the URL.

I’m running RT 3.0.7 on FreeBSD 4.8 and using Firebird 0.7.

Forgive me for 1) top posting last time and, 2) replying to myself.

I’ve been struggling with this for hours now and haven’t gotten very
far. I can tell that the entire HTTP request is making it to Apache
environment variable sizes up to 4k.

Here are a couple more spec’s:
Apache 2.0.48
mod_fastcgi 2.4.0

My suspicions are still leaning toward a URL length issue. Maybe
getting truncated in Mason or some other perl module. I know nothing
about Mason. I’ve also considered the possibility that it might be a
caching issue with FastCGI of which I also know nothing. I did spend
some time looking at some FastCGI docs, but I didn’t find anything
useful. Is anyone else either definitely seeing or not seeing this
behavior? Any pointers on where to look next or FMs to R will be
greatly appreciated.

Tim Pierce wrote:

I am using RT 3.0.2 and am having trouble bookmarking searches that
involve relative comparisons. For example:

  • I search for tickets where “owner = joe” and “priority < 100”
  • Bookmark this search.
  • Search for tickets where “owner = fred”, but don’t bookmark it.
  • Open a new browser window.
  • Visit the bookmarked search.

My suspicions are still leaning toward a URL length issue. Maybe
getting truncated in Mason or some other perl module.

Oops, I fixed this after a couple days of hunting but neglected to
post the fix back to the list (since no one else seemed to be bothered
by it :slight_smile:

Unfortunately my development environment is a little squotzed at the
moment, so I don’t have true diffs to give you, but you need to modify
Search/Listing.html. There’s a line that looks like this:

<&|/l&>Bookmarkable URL for this search</&>

“FreezeLimits()|u” should be changed to “FreezeLimits()|u,n”:

<&|/l&>Bookmarkable URL for this search</&>

The reason is that RT is both HTML-escaping and URL-escaping the
bookmark search parameters when it sends this URL to the browser, but
it doesn’t HTML-unescape the string when the browser sends it back.
So the server attempts to perform a search on criteria like “priority
< 100” which of course is not intelligible to SQL. Since the
string is already being URL-escaped (with the “|u”) flag, we can turn
off HTML-escaping (which is what adding “,n” means).

At some point I’ll collect my changes and submit a proper diff for
this fix.

– twp

Tim Pierce wrote:> On Tue, Dec 09, 2003 at 06:34:30PM -0800, Jason Taylor wrote:

Tim Pierce wrote:

I am using RT 3.0.2 and am having trouble bookmarking searches that
involve relative comparisons. For example:

  • I search for tickets where “owner = joe” and “priority < 100”
  • Bookmark this search.
  • Search for tickets where “owner = fred”, but don’t bookmark it.
  • Open a new browser window.
  • Visit the bookmarked search.

My suspicions are still leaning toward a URL length issue. Maybe
getting truncated in Mason or some other perl module.

Oops, I fixed this after a couple days of hunting but neglected to
post the fix back to the list (since no one else seemed to be bothered
by it :slight_smile:

Unfortunately my development environment is a little squotzed at the
moment, so I don’t have true diffs to give you, but you need to modify
Search/Listing.html. There’s a line that looks like this:

<&|/l&>Bookmarkable URL for this search</&>

“FreezeLimits()|u” should be changed to “FreezeLimits()|u,n”:

<&|/l&>Bookmarkable URL for this search</&>

The reason is that RT is both HTML-escaping and URL-escaping the
bookmark search parameters when it sends this URL to the browser, but
it doesn’t HTML-unescape the string when the browser sends it back.
So the server attempts to perform a search on criteria like “priority
< 100” which of course is not intelligible to SQL. Since the
string is already being URL-escaped (with the “|u”) flag, we can turn
off HTML-escaping (which is what adding “,n” means).

At some point I’ll collect my changes and submit a proper diff for
this fix.

– twp

Yes. That fixed it. Thank you very much! Not having to constantly
recreate queries is going to save me a lot of time.