Resolved tickets displayed when "Next-ing" through Open/New ticket search results (fwd)

Further data points on this.

It seems that no matter how I get to a ticket which appears to be in the
item map, I get the same item map displayed. Indeed it would appear that
the item map remains cached for the whole of that user session. Deleting
the relevant authentication cookie and forcing a reauthentication (we’re
using external authentication FWIW) and doing a new search resets the item
map to the results of that first search and from there nothing will shift
it.

[…]

Well what do you know - I think I’ve fixed it. An extra line in
_ProcessRestrictions seems to cure it.

diff -c Tickets_Overlay.pm.orig Tickets_Overlay.pm
*** Tickets_Overlay.pm.orig 2003-10-10 15:24:43.000000000 +0100
— Tickets_Overlay.pm 2003-10-14 14:09:50.000000000 +0100
*** 1994,2000 ****
#Blow away ticket aliases since we’ll need to regenerate them for
#a new search
delete $self->{‘TicketAliases’};
! delete $self->{‘items_array’};

  my $sql = $self->{_sql_query}; # Violating the _SQL namespace
  if (!$sql||$self->{'RecalcTicketLimits'}) {
    #  "Restrictions to Clauses Branch\n";

— 1994,2002 ----
#Blow away ticket aliases since we’ll need to regenerate them for
#a new search
delete $self->{‘TicketAliases’};
! delete $self->{‘items_array’};
! delete $self->{‘item_map’};
!
my $sql = $self->{_sql_query}; # Violating the _SQL namespace
if (!$sql||$self->{‘RecalcTicketLimits’}) {
# “Restrictions to Clauses Branch\n”;

[this diff from rt-3.0.6]

At a guess the Tickets object is only being instantiated once per user and
being reused repeatedly?

John

J. Sloan wrote:

Further data points on this.

It seems that no matter how I get to a ticket which appears to be in the
item map, I get the same item map displayed. Indeed it would appear that
the item map remains cached for the whole of that user session. Deleting
the relevant authentication cookie and forcing a reauthentication (we’re
using external authentication FWIW) and doing a new search resets the item
map to the results of that first search and from there nothing will shift
it.

[…]

Well what do you know - I think I’ve fixed it. An extra line in
_ProcessRestrictions seems to cure it.

diff -c Tickets_Overlay.pm.orig Tickets_Overlay.pm
*** Tickets_Overlay.pm.orig 2003-10-10 15:24:43.000000000 +0100
— Tickets_Overlay.pm 2003-10-14 14:09:50.000000000 +0100


*** 1994,2000 ****
#Blow away ticket aliases since we’ll need to regenerate them for
#a new search
delete $self->{‘TicketAliases’};
! delete $self->{‘items_array’};

  my $sql = $self->{_sql_query}; # Violating the _SQL namespace
  if (!$sql||$self->{'RecalcTicketLimits'}) {
    #  "Restrictions to Clauses Branch\n";

— 1994,2002 ----
#Blow away ticket aliases since we’ll need to regenerate them for
#a new search
delete $self->{‘TicketAliases’};
! delete $self->{‘items_array’};
! delete $self->{‘item_map’};
!
my $sql = $self->{_sql_query}; # Violating the _SQL namespace
if (!$sql||$self->{‘RecalcTicketLimits’}) {
# “Restrictions to Clauses Branch\n”;

[this diff from rt-3.0.6]

At a guess the Tickets object is only being instantiated once per user and
being reused repeatedly?

John
This patch disclose another problem:
We don’t store session data after filling item_map so each time when we
have defined search conditions and load any Ticket page(Display,
Basics…) RT redo search.
Simple test:

  1. Logout/login to flush session data.
  2. Clear search conditions.
  3. Do search by any queue.
  4. click on any ticket in results
  5. Display.html loads fast enought and next navigation go fast.
  6. Clear search conditions.
  7. Search ticket with name of attachment match ‘.zip’ on my machine it’s
    about 4 minutes.
  8. click on any ticket in results.
  9. Wait… wait… wait… and every request to /Ticket/*.html is slow.

So I offer next patch in addition to John’s one.
It have only one problem which I didn’t solve. Search repeats once when
you /Tickets/*.html after changing of search conditions. It’s because of
item_map not yet filled, but session->{‘tickets’} have RedoSearch flag
set and also session->{‘tickets’}->{‘items’} is empty since we don’t
save it in db.

Best regards. Ruslan.

rt3.get_rid_from_researches_on_ticket_display.patch (1.2 KB)