Bug in Search/Results.html

Two things I’ve found:

  1. If no query is passed in then the session query is not getting loaded making
    the “Show Results” button fail.

  2. The item_map does not get refreshed if the query changes but the orderby and
    order fields remain the same, like if you’re navigating using the Quicksearch.

I recovered this functionality with the following changes to the file, copying
it into the local path first of course.

I’ve resolved by:
< $session{‘tickets’}->FromSQL($Query) if ($Query);

if ($Query)
{
$session{‘tickets’}->FromSQL($Query);
undef $session{‘tickets’}->{‘items_array’};
}
else
{
$Query = $session{‘tickets’}->Query();
}

I hope this is of some use to people.

With regards,

Matthew Cheale

This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster@multiplay.co.uk.

What version of RT are you using? It’s worth trying the latest RT 3.2
from subversion, as we have a much more comprehensive fix for this
issue.
Generally, if you have to be going into the datastructure inside an RT
object, something is wrong with the abstraction.On Oct 26, 2004, at 4:43 AM, Matthew Cheale wrote:

Two things I’ve found:

  1. If no query is passed in then the session query is not getting
    loaded making the “Show Results” button fail.

  2. The item_map does not get refreshed if the query changes but the
    orderby and order fields remain the same, like if you’re navigating
    using the Quicksearch.

I recovered this functionality with the following changes to the file,
copying it into the local path first of course.

I’ve resolved by:
< $session{‘tickets’}->FromSQL($Query) if ($Query);

if ($Query)
{
$session{‘tickets’}->FromSQL($Query);
undef $session{‘tickets’}->{‘items_array’};
}
else
{
$Query = $session{‘tickets’}->Query();
}

I hope this is of some use to people.


With regards,

Matthew Cheale

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd.
and the person or entity to whom it is addressed. In the event of
misdirection, the recipient is prohibited from using, copying,
printing or otherwise disseminating it or any information contained in
it.
In the event of misdirection, illegible or incomplete transmission
please telephone (023) 8024 3137
or return the E.mail to postmaster@multiplay.co.uk.


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

I have a similar issue in rt 3.2.1.

I found that if you click on one of the links from the Quicksearch component,
and then click on one of the tickets that are shown, and then click on the “Show
Results” link, it will take you back to the results of the most recent query
builder results, and not the results from the Quicksearch link.

I’m not sure if that was the intended behavior or not, but it wasn’t what we
wanted, so we made this change in Search/Results.html that might be useful to
others:

< $session{‘tickets’}->FromSQL($Query) if ($Query);

if ( $Query ) {
undef $session{‘CurrentSearchHash’};
$session{‘CurrentSearchHash’}->{‘Query’} = $Query;
$session{‘tickets’}->FromSQL($Query);
}

This makes sure that any time the Results.html page is called with a Query, that
query becomes the new current search.

Apologies if this issue has already been addresses, but I searched the list
archives archives and could not find anything other than the message quoted
below.

Regards,
-Dan

Daniel J. Wright wright@pair.com
Lead Software Developer, pairNIC https://www.pairnic.com
pair Networks, Inc. http://www.pair.comOn Tue, 26 Oct 2004, Jesse Vincent wrote:

What version of RT are you using? It’s worth trying the latest RT 3.2
from subversion, as we have a much more comprehensive fix for this
issue.
Generally, if you have to be going into the datastructure inside an RT
object, something is wrong with the abstraction.

On Oct 26, 2004, at 4:43 AM, Matthew Cheale wrote:

Two things I’ve found:

  1. If no query is passed in then the session query is not getting
    loaded making the “Show Results” button fail.

  2. The item_map does not get refreshed if the query changes but the
    orderby and order fields remain the same, like if you’re navigating
    using the Quicksearch.

I recovered this functionality with the following changes to the file,
copying it into the local path first of course.

I’ve resolved by:
< $session{‘tickets’}->FromSQL($Query) if ($Query);

if ($Query)
{
$session{‘tickets’}->FromSQL($Query);
undef $session{‘tickets’}->{‘items_array’};
}
else
{
$Query = $session{‘tickets’}->Query();
}

I hope this is of some use to people.


With regards,

Matthew Cheale

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd.
and the person or entity to whom it is addressed. In the event of
misdirection, the recipient is prohibited from using, copying,
printing or otherwise disseminating it or any information contained in
it.
In the event of misdirection, illegible or incomplete transmission
please telephone (023) 8024 3137
or return the E.mail to postmaster@multiplay.co.uk.


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

I have a similar issue in rt 3.2.1.

I found that if you click on one of the links from the Quicksearch component,
and then click on one of the tickets that are shown, and then click on the “Show
Results” link, it will take you back to the results of the most recent query
builder results, and not the results from the Quicksearch link.

Grab 3.2.3 when it comes out. We’ve improved this behaviour a whole lot.
It should already be fixed.