Shredder User plugin mangling tickets?

RT Users
1

We have roughly 9500 illegitimate users that were created by incoming spam.
I’ve been doing my best to eliminate these users by way of the Shredder Users
plugin. For the most part, this has been a successful operation. However, due
to the number of legitimate users, picking out the spam users is not a perfect
science and I’ve inadvertently removed legitimate users.

This has resulted in a ticket getting mangled…I think. I’m not sure why it
would cause the transactions to get messed up or even if it has. But this is
the output generated on the latest ticket to suffer the problem:

error:
Can’t call method “Name” on an undefined value at
/usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm line 690.

context:
…
686: AddWatcher => sub {
687: my $self = shift;
688: my $principal = RT::Principal->new($self->CurrentUser);
689: $principal->Load($self->NewValue);
690: return $self->loc( “[_1] [_2] added”, $self->Field,
$principal->Object->Name);
691: },
692: DelWatcher => sub {
693: my $self = shift;
694: my $principal = RT::Principal->new($self->CurrentUser);
…

code stack:
/usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm:690
/usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm:602
/usr/local/rt-3.6.1/share/html/Ticket/Elements/ShowTransaction:54
/usr/local/rt-3.6.1/share/html/Ticket/Elements/ShowHistory:102
/usr/local/rt-3.6.1/share/html/Ticket/Display.html:63
/usr/local/rt-3.6.1/share/html/autohandler:279

The ticket displays a few of the transactions on the ticket then the above error.

Is this a result of the Requestor being removed as a suspected spam created user
or the indication of something else? I’ve removed roughly 8500 users already
and have only seen this happen once before. If there is no cure for it I’m not
too concerned as the nature of the method of removing these users is error prone
and I’ve made that clear to my superiors. However, if there is a way to avoid
this, I would love to know.

Thanks,
Mathew

2

plugin. For the most part, this has been a successful operation. However, due
to the number of legitimate users, picking out the spam users is not a perfect
science and I’ve inadvertently removed legitimate users.

This has resulted in a ticket getting mangled…I think. I’m not sure why it
would cause the transactions to get messed up or even if it has. But this is
the output generated on the latest ticket to suffer the problem:

You’ve removed the user a transaction referred to. RT can’t find
something that’s…well, never supposed to be removed. So it’s
exploding.

3

Jesse Vincent wrote:

plugin. For the most part, this has been a successful operation. However, due
to the number of legitimate users, picking out the spam users is not a perfect
science and I’ve inadvertently removed legitimate users.

This has resulted in a ticket getting mangled…I think. I’m not sure why it
would cause the transactions to get messed up or even if it has. But this is
the output generated on the latest ticket to suffer the problem:

You’ve removed the user a transaction referred to. RT can’t find
something that’s…well, never supposed to be removed. So it’s
exploding.

Ok, so I guess my average is actually pretty good considering this has only
happened twice out of the 8500 users I’ve removed. At least, that’s all we’ve
seen :slight_smile:

I assume there is no recovering?

Mathew

4

Jesse Vincent wrote:

plugin. For the most part, this has been a successful operation. However, due
to the number of legitimate users, picking out the spam users is not a perfect
science and I’ve inadvertently removed legitimate users.

This has resulted in a ticket getting mangled…I think. I’m not sure why it
would cause the transactions to get messed up or even if it has. But this is
the output generated on the latest ticket to suffer the problem:

You’ve removed the user a transaction referred to. RT can’t find
something that’s…well, never supposed to be removed. So it’s
exploding.

Besides, if I set the replace_relations field to nobody, shouldn’t it assign all
those transactions to the Nobody user? Or would I have to use the id for
Nobody? Or is using nobody with lowercase ‘n’ not the same as Nobody with
uppercase ‘N’?

Mathew

5

Mathew;
I think the problem is its trying to build a join and can’t find the
user id in the Users table, you need (from sql) to update the appropriate
Transactions row changing the Creator value to the id of the User
Nobody(or its safer to change it to your Id privileged user)
Roy
Mathew Snyder wrote:

6

I did some mucking about on our development server and discovered that
the mangled tickets are a result of broken connections during the shred.
The first ticket that displayed this error was after a user’s browser
hung up after clicking the Update button. While not documented, the
latest ticket was likely a result of my system freezing while running
Shredder.

I’ll see if I can manually assign a user to the transaction though.
Hopefully it will only be one that needs it.

Roy El-Hames wrote:

7

I looked at all the creators of transactions for the ticket and found that none
are users that have been removed. However, root owns a few but I don’t know if
it is typical to have root create transactions. If it is, I’m wondering if
maybe a link to another table, say Attachments was broken.

Roy El-Hames wrote:

8

This is the raw error:

Can’t call method “Name” on an undefined value at
/usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm line 690.

Trace begun at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Exceptions.pm line 129
HTML::Mason::Exceptions::rethrow_exception(‘Can’t call method “Name” on an
undefined value at /usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm line
690.^J’) called at /usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm line 690
RT::Transaction::ANON(‘RT::Transaction=HASH(0xa45b39c)’) called at
/usr/local/rt-3.6.1/lib/RT/Transaction_Overlay.pm line 602
RT::Transaction::BriefDescription(‘RT::Transaction=HASH(0xa45b39c)’) called at
/usr/local/rt-3.6.1/share/html/Ticket/Elements/ShowTransaction line 54
HTML::Mason::Commands::ANON(‘Attachments’,
‘RT::Attachments=HASH(0xa4bc418)’, ‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’,
‘AttachmentContent’, ‘RT::Attachments=HASH(0xa42ebd8)’, ‘ShowHeaders’, undef,
‘Collapsed’, undef, ‘Tickets’, undef, ‘AttachPath’, ‘/Ticket/Attachment’,
‘UpdatePath’, ‘/Ticket/Update.html’, ‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’,
‘Transaction’, ‘RT::Transaction=HASH(0xa45b39c)’, ‘ShowHeaders’, undef,
‘Collapsed’, undef, ‘RowNum’, 12, ‘ShowTitleBarCommands’, 1, ‘Attachments’,
‘ARRAY(0xa40c70c)’, ‘AttachmentContent’, ‘HASH(0xa4a0288)’, ‘LastTransaction’,
0) called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xa308b10)’,
‘Attachments’, ‘RT::Attachments=HASH(0xa4bc418)’, ‘Ticket’,
‘RT::Ticket=HASH(0xa4625ac)’, ‘AttachmentContent’,
‘RT::Attachments=HASH(0xa42ebd8)’, ‘ShowHeaders’, undef, ‘Collapsed’, undef,
‘Tickets’, undef, ‘AttachPath’, ‘/Ticket/Attachment’, ‘UpdatePath’,
’/Ticket/Update.html’, ‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’, ‘Transaction’,
‘RT::Transaction=HASH(0xa45b39c)’, ‘ShowHeaders’, undef, ‘Collapsed’, undef,
‘RowNum’, 12, ‘ShowTitleBarCommands’, 1, ‘Attachments’, ‘ARRAY(0xa40c70c)’,
‘AttachmentContent’, ‘HASH(0xa4a0288)’, ‘LastTransaction’, 0) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1251
eval {…} at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(undef, undef, ‘Attachments’,
‘RT::Attachments=HASH(0xa4bc418)’, ‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’,
‘AttachmentContent’, ‘RT::Attachments=HASH(0xa42ebd8)’, ‘ShowHeaders’, undef,
‘Collapsed’, undef, ‘Tickets’, undef, ‘AttachPath’, ‘/Ticket/Attachment’,
‘UpdatePath’, ‘/Ticket/Update.html’, ‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’,
‘Transaction’, ‘RT::Transaction=HASH(0xa45b39c)’, ‘ShowHeaders’, undef,
‘Collapsed’, undef, ‘RowNum’, 12, ‘ShowTitleBarCommands’, 1, ‘Attachments’,
‘ARRAY(0xa40c70c)’, ‘AttachmentContent’, ‘HASH(0xa4a0288)’, ‘LastTransaction’,
0) called at /usr/local/rt-3.6.1/share/html/Ticket/Elements/ShowHistory line 102
HTML::Mason::Commands::ANON(‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’,
‘Tickets’, undef, ‘Collapsed’, undef, ‘ShowHeaders’, undef, ‘Attachments’,
‘RT::Attachments=HASH(0xa4bc418)’, ‘AttachmentContent’,
‘RT::Attachments=HASH(0xa42ebd8)’) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xa2ff7f0)’,
‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’, ‘Tickets’, undef, ‘Collapsed’, undef,
‘ShowHeaders’, undef, ‘Attachments’, ‘RT::Attachments=HASH(0xa4bc418)’,
‘AttachmentContent’, ‘RT::Attachments=HASH(0xa42ebd8)’) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1251
eval {…} at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(undef, undef, ‘Ticket’, ‘RT::Ticket=HASH(0xa4625ac)’,
‘Tickets’, undef, ‘Collapsed’, undef, ‘ShowHeaders’, undef, ‘Attachments’,
‘RT::Attachments=HASH(0xa4bc418)’, ‘AttachmentContent’,
‘RT::Attachments=HASH(0xa42ebd8)’) called at
/usr/local/rt-3.6.1/share/html/Ticket/Display.html line 63
HTML::Mason::Commands::ANON(‘id’, 39852, ‘id’, 39852) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xa207760)’,
‘id’, 39852, ‘id’, 39852) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1251
eval {…} at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(undef, undef, ‘id’, 39852, ‘id’, 39852) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 914
HTML::Mason::Request::call_next(‘HTML::Mason::Request::ApacheHandler=HASH(0xa4e966c)’,
‘id’, 39852) called at /usr/local/rt-3.6.1/share/html/autohandler line 279
HTML::Mason::Commands::ANON(‘id’, 39852) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x9e1cf98)’,
‘id’, 39852) called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm
line 1246
eval {…} at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(undef, undef, undef, ‘id’, 39852) called at
/usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 459
eval {…} at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 459
eval {…} at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/Request.pm line 411
HTML::Mason::Request::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0xa4e966c)’)
called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/ApacheHandler.pm line 168
HTML::Mason::Request::ApacheHandler::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0xa4e966c)’)
called at /usr/lib/perl5/vendor_perl/5.8.7/HTML/Mason/ApacheHandler.pm line 826
HTML::Mason::ApacheHandler::handle_request(‘HTML::Mason::ApacheHandler=HASH(0x8f437b0)’,
‘Apache2::RequestRec=SCALAR(0xa4bc454)’) called at
/usr/local/rt-3.6.1/bin/webmux.pl line 123
eval {…} at /usr/local/rt-3.6.1/bin/webmux.pl line 123
RT::Mason::handler(‘Apache2::RequestRec=SCALAR(0xa4bc454)’) called at -e line 0

Mathew

Roy El-Hames wrote:

9

I performed on my development server the steps you’ve laid out. However, there
aren’t any changes.

Thanks though.

Mathew

Raed El-hames wrote: