Search for dead tickets fails?

RT Users
1

Running RT 2.0.14, A search for dead tickets fails to find any, though
there are dead tickets, and entering a number for one pulls it up.

Bug?

2

Running RT 2.0.14, A search for dead tickets fails to find any, though
there are dead tickets, and entering a number for one pulls it up.

Bug?

It’s dead, Jim!

Dead tickets won’t ever appear in the web interface by design. The
only difference between “dead” and “deleted” is that you can’t
delete tickets without affecting referential integrity.

You might be able to use the commandline tool to see them or the
API directly – I’m not near somewhere I can test. :slight_smile:

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

3

Running RT 2.0.14, A search for dead tickets fails to find any, though
there are dead tickets, and entering a number for one pulls it up.

Bug?

It’s dead, Jim!

Dead tickets won’t ever appear in the web interface by design.

Except it will appear if you enter the number in the web interface.

You can also select Dead as a status option in search, but it’s a bogus
option and never works. This seems like a bug. Either the option
shouldn’t be visible, or it should work.

The
only difference between “dead” and “deleted” is that you can’t
delete tickets without affecting referential integrity.

I agree with that. I’m working on a spamfiltering tool to kill spam
tickets (based on the autoresponse bounce) and I did a search and noticed
'hey, wait a sec…"

4

“RL” == Rich Lafferty rich+rt@lafferty.ca writes:

RL> only difference between “dead” and “deleted” is that you can’t
RL> delete tickets without affecting referential integrity.

Sure you can, as long as your DB enforces RI for you, using foreign
keys. I posted a bunch of suitable FK’s here a while back. Of
course, this assumes you have a DB that is capable of it.

5

Running RT 2.0.14, A search for dead tickets fails to find any, though
there are dead tickets, and entering a number for one pulls it up.

Dead tickets won’t ever appear in the web interface by design.

Except it will appear if you enter the number in the web interface.

You can also select Dead as a status option in search, but it’s a bogus
option and never works. This seems like a bug. Either the option
shouldn’t be visible, or it should work.

Ok, lets clarify that:

'Dead Tickets cannot be retrieved by searching for them, in RT as
 shipped.'

This is done by a special case in the RT::Tickets->Next() method, which
goes for the Next ticket when it encounters a dead one, eg:

$ grep -A 3 ‘dead’ lib/RT/Tickets.pm
#Make sure we never show dead tickets
#TODO we should be doing this in the where clause.
#but you can’t do multiple clauses on the same field just yet :confused:

        if ($Ticket->Status eq 'dead') {
            return($self->Next());
        }
        elsif ($Ticket->CurrentUserHasRight('ShowTicket')) {

Of course, there are three lines in the above that you could comment out,
if you wanted to retrieve ‘dead’ tickets via searches.

The
only difference between “dead” and “deleted” is that you can’t
delete tickets without affecting referential integrity.

I agree with that. I’m working on a spamfiltering tool to kill spam
tickets (based on the autoresponse bounce) and I did a search and noticed
'hey, wait a sec…"

Oooh, thats nifty, but wouldn’t the bounce take a long time occasionally?

( eg, the sending domain exists, but isn’t responding on port 25. Your
local MTA would then wait a default of 8 hours before returning a
warning message. Ditto for false positives when a customer sends from
their private domain complaining that their mail is down; you’d kill
their ticket because their mail is bouncing :wink: )

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
6

Ok, lets clarify that:

‘Dead Tickets cannot be retrieved by searching for them, in RT as
shipped.’

This is done by a special case in the RT::Tickets->Next() method, which
goes for the Next ticket when it encounters a dead one, eg:

$ grep -A 3 ‘dead’ lib/RT/Tickets.pm
#Make sure we never show dead tickets
#TODO we should be doing this in the where clause.
#but you can’t do multiple clauses on the same field just yet :confused:

        if ($Ticket->Status eq 'dead') {
            return($self->Next());
        }
        elsif ($Ticket->CurrentUserHasRight('ShowTicket')) {

Thank you, that was the code I was looking for.

Of course, there are three lines in the above that you could comment out,
if you wanted to retrieve ‘dead’ tickets via searches.

yet another ‘little’ tweak to the system I guess.

I agree with that. I’m working on a spamfiltering tool to kill spam
tickets (based on the autoresponse bounce) and I did a search and noticed
'hey, wait a sec…"

Oooh, thats nifty, but wouldn’t the bounce take a long time occasionally?

Agreed. it’s not the best solution, but short of spamfiltering the
queue mail before it gets to RT, it’s a good attempt.

( eg, the sending domain exists, but isn’t responding on port 25. Your
local MTA would then wait a default of 8 hours before returning a
warning message.

True. Same for spam with a valid return address (or one that doesn’t
generate a bounce at least).

Ditto for false positives when a customer sends from
their private domain complaining that their mail is down; you’d kill
their ticket because their mail is bouncing :wink: )

I’m planning on modifying the kill script (which simply filters the bounce
address, looks for MAILER-DAEMON and the ticket #, and calls rt
commandline) to avoid killing ‘local’ domains.

But yes, this is one reason I want to be able to search dead tickets.

Seth Cohn, General Manager of Eugene Free Community Network gm@efn.org

Businesses planned for service are apt to succeed; Phone 541-484-9637

Businesses planned for profit are apt to fail. - N. Butler

7

I agree with that. I’m working on a spamfiltering tool to kill spam
tickets (based on the autoresponse bounce) and I did a search and noticed
'hey, wait a sec…"

Oooh, thats nifty, but wouldn’t the bounce take a long time occasionally?

Agreed. it’s not the best solution, but short of spamfiltering the
queue mail before it gets to RT, it’s a good attempt.

Run the mail through a spam filter, then have Rt (or RT’s procmailrc) do
stuff basic on your spamfilter’s headers.

Eg, all mail here passes through SpamAssassin, then our installation of RT
essentially does:

If got SpamAssassin 4 stars or more ; then
	If got '^\s*Received:' in the body ; then
		Mark as Spam Complaint
		Bounce to Autoresponder
	else
		Mark as Spam
	fi
	Mark as Resolved
else
	Other stuff, such as sending autoack
fi

( eg, the sending domain exists, but isn’t responding on port 25. Your
local MTA would then wait a default of 8 hours before returning a
warning message.

True. Same for spam with a valid return address (or one that doesn’t
generate a bounce at least).

Although this could be reduced by tweaking your MTA to return a warning to
RT comparitively quickly.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security