RT 3.8.10 is setting a CF value on new ticket creation?

RT Users
1

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

The following scrip reports (as we expect in our specific
test cases):

 No match, Discovery Method left alone
 Old '' New ''

Yet the CF named ‘Discovery Method’ is in fact being set
to a value when a new ticket is created. The value set
seems random and is not the same thing with each new
ticket.

We have no other scrips that concern themselves with this
field. Does anyone have any ideas?

… a bunch of tests here to set Discovery Method based

… on whether the ticket subject matches a regex or not

if ($matched == 0) {
$RT::Logger->info(“No match, Discovery Method left alone”);
}
my $trans = $self->TransactionObj;
my $ticket = $self->TicketObj;
my $testcf = new RT::CustomField($RT::SystemUser);

$testcf->LoadByName(Queue => $ticket->QueueObj->id,
Name => “Discovery Method”);
my $oldv = trim($self->TransactionObj->OldValue());
my $newv = trim($self->TransactionObj->NewValue());
$RT::Logger->info(“Old ‘$oldv’ New ‘$newv’”);

return 1;

2

Jeff,

I need more info. Are you saying the CF IS changed but a template or email
says it isn’t or what. Or are you saying the CF is changed and then gets
unchanged? It isn’t clear to me what is exactly happening. Also, what is it
the scrip is supposed to do? You don’t shop any code that shows what happens
to $oldy or $newy.

Kenn
LBNLOn Tue, Aug 9, 2011 at 11:59 AM, Jeff Blaine jblaine@kickflop.net wrote:

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

The following scrip reports (as we expect in our specific
test cases):

No match, Discovery Method left alone
Old ‘’ New ‘’

Yet the CF named ‘Discovery Method’ is in fact being set
to a value when a new ticket is created. The value set
seems random and is not the same thing with each new
ticket.

We have no other scrips that concern themselves with this
field. Does anyone have any ideas?

… a bunch of tests here to set Discovery Method based

… on whether the ticket subject matches a regex or not

if ($matched == 0) {
$RT::Logger->info(“No match, Discovery Method left alone”);
}
my $trans = $self->TransactionObj;
my $ticket = $self->TicketObj;
my $testcf = new RT::CustomField($RT::**SystemUser);

$testcf->LoadByName(Queue => $ticket->QueueObj->id,
Name => “Discovery Method”);
my $oldv = trim($self->TransactionObj->**OldValue());
my $newv = trim($self->TransactionObj->**NewValue());
$RT::Logger->info(“Old ‘$oldv’ New ‘$newv’”);

return 1;

RT Training Sessions (http://bestpractical.com/**services/training.htmlhttp://bestpractical.com/services/training.html
)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011
3

Jeff,

I need more info. Are you saying the CF IS changed but a template or
email says it isn’t or what. Or are you saying the CF is changed and
then gets unchanged?

‘Discovery Method’ is a CF of type ‘multiple values’ that
applies to Tickets.

The scrip sets ‘Discovery Method’ to a value IF the subject
of the ticket matches a certain regex (let’s say /foo bar/).

I’m saying the following:

If I make a ticket via email with subject “WONT_MATCH_REGEX”,
our scrip runs, logs that it did not change the CF value,
and logs the proof of that by showing OldValue and NewValue
just as the scrip is exiting.

 No match, Discovery Method left alone
 Old '' New ''

Looking at the brand new ticket in the web UI shows that
‘Discovery Method’ HAS been set to one of its possible
values.

It isn’t clear to me what is exactly happening.
Also, what is it the scrip is supposed to do?

You don’t shop any code that shows what happens to $oldy or $newy.

The code shows that the scrip returns 1 right after I
show $oldv and $newv. I’m not doing anything with
$oldv and $newv other than logging them as proof that
the value was not modified.

4

In fact, if I set this scrip to ‘disabled’,
‘Discovery Method’ still gets set to a value
upon new ticket creation.

This is not happening on our RT 3.8.7 production
box. It is only happening with our 3.8.10
test instance.On 8/9/2011 3:25 PM, Jeff Blaine wrote:

On 8/9/2011 3:07 PM, Kenneth Crocker wrote:

Jeff,

I need more info. Are you saying the CF IS changed but a template or
email says it isn’t or what. Or are you saying the CF is changed and
then gets unchanged?

‘Discovery Method’ is a CF of type ‘multiple values’ that
applies to Tickets.

The scrip sets ‘Discovery Method’ to a value IF the subject
of the ticket matches a certain regex (let’s say /foo bar/).

I’m saying the following:

If I make a ticket via email with subject “WONT_MATCH_REGEX”,
our scrip runs, logs that it did not change the CF value,
and logs the proof of that by showing OldValue and NewValue
just as the scrip is exiting.

No match, Discovery Method left alone
Old ‘’ New ‘’

Looking at the brand new ticket in the web UI shows that
‘Discovery Method’ HAS been set to one of its possible
values.

It isn’t clear to me what is exactly happening.
Also, what is it the scrip is supposed to do?

You don’t shop any code that shows what happens to $oldy or $newy.

The code shows that the scrip returns 1 right after I
show $oldv and $newv. I’m not doing anything with
$oldv and $newv other than logging them as proof that
the value was not modified.

Kenn
LBNL

On Tue, Aug 9, 2011 at 11:59 AM, Jeff Blaine <jblaine@kickflop.net mailto:jblaine@kickflop.net> wrote:

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

The following scrip reports (as we expect in our specific
test cases):

No match, Discovery Method left alone
Old ‘’ New ‘’

Yet the CF named ‘Discovery Method’ is in fact being set
to a value when a new ticket is created. The value set
seems random and is not the same thing with each new
ticket.

We have no other scrips that concern themselves with this
field. Does anyone have any ideas?

… a bunch of tests here to set Discovery Method based

… on whether the ticket subject matches a regex or not

if ($matched == 0) {
$RT::Logger->info(“No match, Discovery Method left alone”);
}
my $trans = $self->TransactionObj;
my $ticket = $self->TicketObj;
my $testcf = new RT::CustomField($RT::__SystemUser);

$testcf->LoadByName(Queue => $ticket->QueueObj->id,
Name => “Discovery Method”);
my $oldv = trim($self->TransactionObj->__OldValue());
my $newv = trim($self->TransactionObj->__NewValue());
$RT::Logger->info(“Old ‘$oldv’ New ‘$newv’”);

return 1;

RT Training Sessions
(http://bestpractical.com/__services/training.html
http://bestpractical.com/services/training.html)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA — September 26& 27, 2011
  • San Francisco, CA, USA — October 18& 19, 2011
  • Washington DC, USA — October 31& November 1, 2011
  • Melbourne VIC, Australia — November 28& 29, 2011
  • Barcelona, Spain — November 28& 29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011
5

Perhaps this is somehow related? We’re seeing these
sometimes, but definitely not with each new ticket
creation:

[Tue Aug 9 19:20:17 2011] [warning]: Use of uninitialized value in
string ne at /apps/rt/bin/…/lib/RT/Rule.pm line 59.
(/apps/rt/bin/…/lib/RT/Rule.pm:59)

line 59 of /apps/rt/bin/…/lib/RT/Rule.pm:59 says:

return (0) if $self->_Queue && $self->TicketObj->QueueObj->Name ne
$self->_Queue;On 8/9/2011 3:30 PM, Jeff Blaine wrote:

In fact, if I set this scrip to ‘disabled’,
‘Discovery Method’ still gets set to a value
upon new ticket creation.

This is not happening on our RT 3.8.7 production
box. It is only happening with our 3.8.10
test instance.

On 8/9/2011 3:25 PM, Jeff Blaine wrote:

On 8/9/2011 3:07 PM, Kenneth Crocker wrote:

Jeff,

I need more info. Are you saying the CF IS changed but a template or
email says it isn’t or what. Or are you saying the CF is changed and
then gets unchanged?

‘Discovery Method’ is a CF of type ‘multiple values’ that
applies to Tickets.

The scrip sets ‘Discovery Method’ to a value IF the subject
of the ticket matches a certain regex (let’s say /foo bar/).

I’m saying the following:

If I make a ticket via email with subject “WONT_MATCH_REGEX”,
our scrip runs, logs that it did not change the CF value,
and logs the proof of that by showing OldValue and NewValue
just as the scrip is exiting.

No match, Discovery Method left alone
Old ‘’ New ‘’

Looking at the brand new ticket in the web UI shows that
‘Discovery Method’ HAS been set to one of its possible
values.

It isn’t clear to me what is exactly happening.
Also, what is it the scrip is supposed to do?

You don’t shop any code that shows what happens to $oldy or $newy.

The code shows that the scrip returns 1 right after I
show $oldv and $newv. I’m not doing anything with
$oldv and $newv other than logging them as proof that
the value was not modified.

Kenn
LBNL

On Tue, Aug 9, 2011 at 11:59 AM, Jeff Blaine <jblaine@kickflop.net mailto:jblaine@kickflop.net> wrote:

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

The following scrip reports (as we expect in our specific
test cases):

No match, Discovery Method left alone
Old ‘’ New ‘’

Yet the CF named ‘Discovery Method’ is in fact being set
to a value when a new ticket is created. The value set
seems random and is not the same thing with each new
ticket.

We have no other scrips that concern themselves with this
field. Does anyone have any ideas?

… a bunch of tests here to set Discovery Method based

… on whether the ticket subject matches a regex or not

if ($matched == 0) {
$RT::Logger->info(“No match, Discovery Method left alone”);
}
my $trans = $self->TransactionObj;
my $ticket = $self->TicketObj;
my $testcf = new RT::CustomField($RT::__SystemUser);

$testcf->LoadByName(Queue => $ticket->QueueObj->id,
Name => “Discovery Method”);
my $oldv = trim($self->TransactionObj->__OldValue());
my $newv = trim($self->TransactionObj->__NewValue());
$RT::Logger->info(“Old ‘$oldv’ New ‘$newv’”);

return 1;

RT Training Sessions
(http://bestpractical.com/__services/training.html
http://bestpractical.com/services/training.html)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA — September 26& 27, 2011
  • San Francisco, CA, USA — October 18& 19, 2011
  • Washington DC, USA — October 31& November 1, 2011
  • Melbourne VIC, Australia — November 28& 29, 2011
  • Barcelona, Spain — November 28& 29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011
6

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

Since you don’t say what the condition of the Scrip is, it’s hard to
know what the TransactionObj actually is, and whether or not it’s
relevant.

But without knowing more about the contents of Transactions and
ObjectCustomFieldValues I’d be guessing at problems.

-kevin

7

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

Since you don’t say what the condition of the Scrip is, it’s hard to
know what the TransactionObj actually is, and whether or not it’s
relevant.

But without knowing more about the contents of Transactions and
ObjectCustomFieldValues I’d be guessing at problems.

Not that I think it matters (because disabling this scrip
still shows Discovery Method being set somewhere at ticket
creation)… but FWIW

Condition: On Create
Action: User Defined
Template: Global template: Blank
Stage: TransactionCreate

my $requestor_address = lc($self->TicketObj->RequestorAddresses);
my $subject = lc($self->TicketObj->Subject);

my %subj2discmethod = (
‘foo rule’ => ‘Foo Sensor’,
‘active proxy’ => ‘Proxy’,
);

my $discmethodset = 0;

foreach my $key (keys %subj2discmethod) {
if ($subject =~ $key) {
$RT::Logger->info(“Subject ‘$subject’ setting ‘Discovery
Method’ to ‘$subj2discmethod{$key}’”);
my $cf = RT::CustomField->new($RT::SystemUser);
$cf->LoadByName(Name => ‘Discovery Method’);
$self->TicketObj->AddCustomFieldValue(Field => $cf,
Value => $subj2discmethod{$key},
RecordTransaction => 0);
return 1;
}
}

$RT::Logger->info(“No Discovery Method set by scrip 13. No matches.
Subject was ‘$subject’ and requestor was ‘$requestor_address’”);

my $trans = $self->TransactionObj;
my $ticket = $self->TicketObj;
my $testcf = new RT::CustomField($RT::SystemUser);

$testcf->LoadByName(Queue => $ticket->QueueObj->id, Name => “Discovery
Method”);
my $oldv = trim($self->TransactionObj->OldValue());
my $newv = trim($self->TransactionObj->NewValue());
$RT::Logger->info(“Old value ‘$oldv’ for Discovery Method. New value
‘$newv’”);

return 1;

8

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

Since you don’t say what the condition of the Scrip is, it’s hard to
know what the TransactionObj actually is, and whether or not it’s
relevant.

But without knowing more about the contents of Transactions and
ObjectCustomFieldValues I’d be guessing at problems.

Not that I think it matters (because disabling this scrip
still shows Discovery Method being set somewhere at ticket
creation)… but FWIW

Condition: On Create

So, this is an On Create scrip, which means:

$testcf->LoadByName(Queue => $ticket->QueueObj->id, Name =>
“Discovery Method”);
my $oldv = trim($self->TransactionObj->OldValue());
my $newv = trim($self->TransactionObj->NewValue());
$RT::Logger->info(“Old value ‘$oldv’ for Discovery Method. New
value ‘$newv’”);

That TransactionObj isn’t going to be about setting the Custom Field.

Are there other transactions recorded on this ticket, or was the CF
set during the Create transaction? How are you creating the ticket?

-kevin

9

I’m confused and can’t see that I am doing anything
wrong. Either I am doing something wrong, or there’s
a really bizarre bug in 3.8.10. Surely it’s the former.

Since you don’t say what the condition of the Scrip is, it’s hard to
know what the TransactionObj actually is, and whether or not it’s
relevant.

But without knowing more about the contents of Transactions and
ObjectCustomFieldValues I’d be guessing at problems.

Not that I think it matters (because disabling this scrip
still shows Discovery Method being set somewhere at ticket
creation)… but FWIW

Condition: On Create

So, this is an On Create scrip, which means:

$testcf->LoadByName(Queue => $ticket->QueueObj->id, Name =>
“Discovery Method”);
my $oldv = trim($self->TransactionObj->OldValue());
my $newv = trim($self->TransactionObj->NewValue());
$RT::Logger->info(“Old value ‘$oldv’ for Discovery Method. New
value ‘$newv’”);

That TransactionObj isn’t going to be about setting the Custom Field.

Fair enough, but I still see this which means the regexp
was not matched and the CF was not touched:

 No Discovery Method set by scrip 13.  No matches. Subject
 was 'FJHFLFFKLLK' and requestor was 'jblaine@our.org'

Are there other transactions recorded on this ticket, or was the CF
set during the Create transaction? How are you creating the ticket?

There are no other transactions on this ticket.

The ticket history is 1 item (the original message content).

All of our tickets are created via email.

10

That TransactionObj isn’t going to be about setting the Custom Field.

Fair enough, but I still see this which means the regexp
was not matched and the CF was not touched:

Wasn’t touched by this scrip, but something must be touching it.

Are there other transactions recorded on this ticket, or was the CF
set during the Create transaction? How are you creating the ticket?

There are no other transactions on this ticket.

How are you determining this, from the database or from the displayed
ticket history?

The ticket history is 1 item (the original message content).
All of our tickets are created via email.

What’s the content on this ticket? What other local modifications and
plugins do you have?

-kevin

11

That TransactionObj isn’t going to be about setting the Custom Field.

Fair enough, but I still see this which means the regexp
was not matched and the CF was not touched:

Wasn’t touched by this scrip, but something must be touching it.

Yes, that “something” is the mystery.

Are there other transactions recorded on this ticket, or was the CF
set during the Create transaction? How are you creating the ticket?

There are no other transactions on this ticket.

How are you determining this, from the database or from the displayed
ticket history?

Displayed ticket history, web UI.

Though I just queried ‘transactions’ for all rows where
‘objectid = 85’ (my latest test ticket id) and it shows
1 row (‘Create’).

So not only is the field being set by something, it’s being
done on the sly.

The ticket history is 1 item (the original message content).
All of our tickets are created via email.

What’s the content on this ticket? What other local modifications and
plugins do you have?

Well, “this ticket” isn’t so much the problem, it’s one
of many test tickets, all showing the same problem. Their
contents are arbitrary text (me mashing the keyboard to
generate a junk “body” for the test messages). It’s nothing
more complex than:To: tickets@our.org
From: jblaine@our.org
Subject: dsklfjsdklfjlsdk

h34o0rth434rth83

That results in “Discovery Method” being set on the ticket
by something other than the scrip.

12

A colleague has pointed out that it’s not just the
Discovery Method field that is being set to an
arbitrary choice (from its possible choices).

There are other fields being set as well!

13

If there is only one transaction then something pushing data through Create
method. It can be callback or library, but not a scrip. List of files in
local dir may sched some light.

Regards, Ruslan. From phone.10.08.2011 20:31 пользователь “Jeff Blaine” jblaine@kickflop.net написал:

A colleague has pointed out that it’s not just the
Discovery Method field that is being set to an
arbitrary choice (from its possible choices).

There are other fields being set as well!

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Chicago, IL, USA September 26 & 27, 2011
  • San Francisco, CA, USA October 18 & 19, 2011
  • Washington DC, USA October 31 & November 1, 2011
  • Melbourne VIC, Australia November 28 & 29, 2011
  • Barcelona, Spain November 28 & 29, 2011
14

If there is only one transaction then something pushing data through
Create method. It can be callback or library, but not a scrip. List of
files in local dir may sched some light.

Gladly. More info below this, too. Note that the 2 local
callbacks below (Update.html/Initial and Modify.html/jblaine)
are in place to disallow resolving a ticket unless a certain
CF has been set to a value (not null). Neither callback
does anything unless status is ‘resolved’, and neither
set any data/fields explicitly. These callbacks have been
in place for ~6 months and are in our production 3.8.7
instance as well as this test 3.8.10 instance.

cd local
ls -R .

./etc:

./html:
Callbacks

./html/Callbacks:
MyCallbacks

./html/Callbacks/MyCallbacks:
Ticket

./html/Callbacks/MyCallbacks/Ticket:
Modify.html
Update.html

./html/Callbacks/MyCallbacks/Ticket/Modify.html:
Default.Disable
jblaine

./html/Callbacks/MyCallbacks/Ticket/Update.html:
Initial

./lib:

./man:
auto
man3

./man/auto:
RT
RTFM

./man/auto/RT:
Extension

./man/auto/RT/Extension:
SaltedPasswords
SearchResults
SpawnLinkedTicketInQueue

./man/auto/RT/Extension/SaltedPasswords:

./man/auto/RT/Extension/SearchResults:
XLS

./man/auto/RT/Extension/SearchResults/XLS:

./man/auto/RT/Extension/SpawnLinkedTicketInQueue:

./man/auto/RTFM:

./man/man3:
RT::Digest::SHA::PurePerl.3pm
RT::Extension::SaltedPasswords.3pm
RT::Extension::SearchResults::XLS.3pm
RT::Extension::SpawnLinkedTicketInQueue.3pm
RT::FM::Article.3pm
RT::FM::ArticleCollection.3pm
RT::FM::ArticleCollection_Overlay.3pm
RT::FM::Article_Overlay.3pm
RT::FM::Class.3pm
RT::FM::ClassCollection.3pm
RT::FM::ClassCollection_Overlay.3pm
RT::FM::Class_Overlay.3pm
RT::FM::Introduction.3pm
RT::FM::ObjectTopic.3pm
RT::FM::ObjectTopicCollection.3pm
RT::FM::ObjectTopicCollection_Overlay.3pm
RT::FM::Record.3pm
RT::FM::SearchBuilder.3pm
RT::FM::System.3pm
RT::FM::Topic.3pm
RT::FM::TopicCollection.3pm
RT::FM::TopicCollection_Overlay.3pm
RT::FM::Topic_Overlay.3pm
RT::URI::a.3pm
RT::URI::fsck_com_rtfm.3pm

./plugins:
RT-Extension-SaltedPasswords
RT-Extension-SearchResults-XLS
RT-Extension-SpawnLinkedTicketInQueue
RT-FM

./plugins/RT-Extension-SaltedPasswords:
lib
sbin

./plugins/RT-Extension-SaltedPasswords/lib:
perllocal.pod
RT

./plugins/RT-Extension-SaltedPasswords/lib/RT:
Digest
Extension

./plugins/RT-Extension-SaltedPasswords/lib/RT/Digest:
SHA

./plugins/RT-Extension-SaltedPasswords/lib/RT/Digest/SHA:
PurePerl.pm

./plugins/RT-Extension-SaltedPasswords/lib/RT/Extension:
SaltedPasswords.pm

./plugins/RT-Extension-SaltedPasswords/sbin:
vulnerable-passwords
vulnerable-passwords.in

./plugins/RT-Extension-SearchResults-XLS:
html
lib

./plugins/RT-Extension-SearchResults-XLS/html:
Callbacks
Search

./plugins/RT-Extension-SearchResults-XLS/html/Callbacks:
Results-XLS

./plugins/RT-Extension-SearchResults-XLS/html/Callbacks/Results-XLS:
Search

./plugins/RT-Extension-SearchResults-XLS/html/Callbacks/Results-XLS/Search:
Elements
Results.html

./plugins/RT-Extension-SearchResults-XLS/html/Callbacks/Results-XLS/Search/Elements:
ResultViews

./plugins/RT-Extension-SearchResults-XLS/html/Callbacks/Results-XLS/Search/Elements/ResultViews:
AfterTools

./plugins/RT-Extension-SearchResults-XLS/html/Callbacks/Results-XLS/Search/Results.html:
SearchActions

./plugins/RT-Extension-SearchResults-XLS/html/Search:
Results.xls

./plugins/RT-Extension-SearchResults-XLS/lib:
perllocal.pod
RT

./plugins/RT-Extension-SearchResults-XLS/lib/RT:
Extension

./plugins/RT-Extension-SearchResults-XLS/lib/RT/Extension:
SearchResults

./plugins/RT-Extension-SearchResults-XLS/lib/RT/Extension/SearchResults:
XLS.pm

./plugins/RT-Extension-SpawnLinkedTicketInQueue:
html
lib

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html:
Callbacks
Elements
Helpers

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html/Callbacks:
SpawnLinkedTicket

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html/Callbacks/SpawnLinkedTicket:
Elements

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html/Callbacks/SpawnLinkedTicket/Elements:
ShowLinks

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html/Callbacks/SpawnLinkedTicket/Elements/ShowLinks:
Default

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html/Elements:
SpawnLinkedTicket

./plugins/RT-Extension-SpawnLinkedTicketInQueue/html/Helpers:
SpawnLinkedTicket

./plugins/RT-Extension-SpawnLinkedTicketInQueue/lib:
perllocal.pod
RT

./plugins/RT-Extension-SpawnLinkedTicketInQueue/lib/RT:
Extension

./plugins/RT-Extension-SpawnLinkedTicketInQueue/lib/RT/Extension:
SpawnLinkedTicketInQueue.pm

./plugins/RT-FM:
bin
etc
html
lib
po
sbin

./plugins/RT-FM/bin:
notify

./plugins/RT-FM/etc:
acl.mysql
acl.Oracle
acl.Pg
drop_schema.mysql
drop_schema.Oracle
drop_schema.Pg
initial_data
RTFM_Config.pm
schema.mysql
schema.mysql-4.1
schema.Oracle
schema.Pg
upgrade

./plugins/RT-FM/etc/initial_data:
dyndns

./plugins/RT-FM/etc/upgrade:
2.1.0
2.1.30
2.2.0RC2
upgrade-mysql-schema.pl

./plugins/RT-FM/etc/upgrade/2.1.0:
acl.mysql
acl.Oracle
acl.Pg
content
schema.mysql
schema.Oracle
schema.Pg

./plugins/RT-FM/etc/upgrade/2.1.30:
acl.mysql
acl.Oracle
acl.Pg
content
schema.mysql
schema.Oracle
schema.Pg

./plugins/RT-FM/etc/upgrade/2.2.0RC2:
acl.mysql
acl.Oracle
acl.Pg
content
schema.mysql
schema.Oracle
schema.Pg

./plugins/RT-FM/html:
Admin
Callbacks
NoAuth
RTFM
SelfService

./plugins/RT-FM/html/Admin:
Global
RTFM

./plugins/RT-FM/html/Admin/Global:
CustomFields

./plugins/RT-FM/html/Admin/Global/CustomFields:
RTFM-Class-RTFM-Article.html

./plugins/RT-FM/html/Admin/RTFM:
Classes
Elements
Global
index.html

./plugins/RT-FM/html/Admin/RTFM/Classes:
CustomFields.html
GroupRights.html
index.html
Modify.html
Topics.html
UserRights.html

./plugins/RT-FM/html/Admin/RTFM/Elements:
ClassTabs
GlobalTabs
Header
Tabs
Topics

./plugins/RT-FM/html/Admin/RTFM/Global:
GroupRights.html
index.html
Topics.html
UserRights.html

./plugins/RT-FM/html/Callbacks:
RTFM

./plugins/RT-FM/html/Callbacks/RTFM:
Admin
autohandler
Elements
RTIR
SelfService
Ticket

./plugins/RT-FM/html/Callbacks/RTFM/Admin:
Elements
Global
index.html

./plugins/RT-FM/html/Callbacks/RTFM/Admin/Elements:
CustomFieldTabs
Tabs

./plugins/RT-FM/html/Callbacks/RTFM/Admin/Elements/CustomFieldTabs:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Admin/Elements/Tabs:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Admin/Global:
CustomFields

./plugins/RT-FM/html/Callbacks/RTFM/Admin/Global/CustomFields:
index.html

./plugins/RT-FM/html/Callbacks/RTFM/Admin/Global/CustomFields/index.html:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Admin/index.html:
Default

./plugins/RT-FM/html/Callbacks/RTFM/autohandler:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Elements:
EditLinks
Header
MessageBox
Tabs

./plugins/RT-FM/html/Callbacks/RTFM/Elements/EditLinks:
ExtraLinkInstructions

./plugins/RT-FM/html/Callbacks/RTFM/Elements/Header:
Head

./plugins/RT-FM/html/Callbacks/RTFM/Elements/MessageBox:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Elements/Tabs:
Default

./plugins/RT-FM/html/Callbacks/RTFM/RTIR:
Elements

./plugins/RT-FM/html/Callbacks/RTFM/RTIR/Elements:
Tabs

./plugins/RT-FM/html/Callbacks/RTFM/RTIR/Elements/Tabs:
Default

./plugins/RT-FM/html/Callbacks/RTFM/SelfService:
Elements

./plugins/RT-FM/html/Callbacks/RTFM/SelfService/Elements:
Tabs

./plugins/RT-FM/html/Callbacks/RTFM/SelfService/Elements/Tabs:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Ticket:
Create.html
Elements
Update.html

./plugins/RT-FM/html/Callbacks/RTFM/Ticket/Create.html:
BeforeCreate
BeforeMessageBox

./plugins/RT-FM/html/Callbacks/RTFM/Ticket/Elements:
Tabs

./plugins/RT-FM/html/Callbacks/RTFM/Ticket/Elements/Tabs:
Default

./plugins/RT-FM/html/Callbacks/RTFM/Ticket/Update.html:
BeforeMessageBox

./plugins/RT-FM/html/NoAuth:
webrtfm.css

./plugins/RT-FM/html/RTFM:
Article
Elements
index.html
Topics.html

./plugins/RT-FM/html/RTFM/Article:
Delete.html
Display.html
Edit.html
Elements
ExtractFromTicket.html
ExtractIntoClass.html
ExtractIntoTopic.html
History.html
PreCreate.html
Search.html

./plugins/RT-FM/html/RTFM/Article/Elements:
EditBasics
EditCustomFields
EditLinks
EditTopics
LinkEntryInstructions
Preformatted
SearchByCustomField
SelectSavedSearches
SelectSearchPrivacy
ShowHistory
ShowLinks
ShowSavedSearches
ShowSearchCriteria
ShowSearchResults
ShowTopics
Tabs

./plugins/RT-FM/html/RTFM/Elements:
BeforeMessageBox
CreateArticle
Error
GotoArticle
Header
NewestArticles
QuickSearch
SelectClass
ShowTopic
Tabs
UpdatedArticles

./plugins/RT-FM/html/SelfService:
Article
Elements

./plugins/RT-FM/html/SelfService/Article:
autohandler
Display.html
Search.html

./plugins/RT-FM/html/SelfService/Elements:
SearchArticle

./plugins/RT-FM/lib:
perllocal.pod
RT

./plugins/RT-FM/lib/RT:
FM
FM.pm
URI

./plugins/RT-FM/lib/RT/FM:
ArticleCollection_Overlay.pm
ArticleCollection.pm
Article_Overlay.pm
Article.pm
ClassCollection_Overlay.pm
ClassCollection.pm
Class_Overlay.pm
Class.pm
Introduction.pod
ObjectTopicCollection_Overlay.pm
ObjectTopicCollection.pm
ObjectTopic.pm
Record.pm
SearchBuilder.pm
System.pm
TopicCollection_Overlay.pm
TopicCollection.pm
Topic_Overlay.pm
Topic.pm

./plugins/RT-FM/lib/RT/URI:
a.pm
fsck_com_rtfm.pm

./plugins/RT-FM/po:
es.po
fr.po
it.po
pt_BR.po
README
rtfm.pot
ru.po
zh_tw.po

./plugins/RT-FM/sbin:
factory
migrate-2.0-to-2.1

./po:

FWIW, here’s the debug info for a new molested ticket:

[Wed Aug 10 16:48:29 2011] [debug]: Converting ‘ISO-8859-1’ to ‘utf-8’
for text/plain - rrrrrrrrrrrrrrrrrrrr (/apps/rt/bin/…/lib/RT/I18N.pm:257)
[Wed Aug 10 16:48:29 2011] [debug]: Mail from user #22 (jblaine@our.org)
(/apps/rt/bin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:77)
[Wed Aug 10 16:48:29 2011] [debug]: About to think about scrips for
transaction #636 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Aug 10 16:48:29 2011] [debug]: About to think about scrips for
transaction #637 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Aug 10 16:48:29 2011] [debug]: About to think about scrips for
transaction #638 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Aug 10 16:48:29 2011] [debug]: About to think about scrips for
transaction #639 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Aug 10 16:48:30 2011] [debug]: About to think about scrips for
transaction #640 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Aug 10 16:48:30 2011] [debug]: About to prepare scrips for
transaction #640 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:167)
[Wed Aug 10 16:48:30 2011] [debug]: Found 5 scrips for TransactionCreate
stage with applicable type(s) Create for txn #640 on ticket #93
(/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:377)
[Wed Aug 10 16:48:30 2011] [debug]: Skipping Scrip #2 because it isn’t
applicable (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:236)
[Wed Aug 10 16:48:30 2011] [info]: Transaction type is ‘Create’ so
enabling AffectedEmployee processing stuff. ((eval 4448):24)
[Wed Aug 10 16:48:30 2011] [debug]: About to commit scrips for
transaction #640 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:187)
[Wed Aug 10 16:48:30 2011] [debug]: Committing scrip #14 on txn #640 of
ticket #93 (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Aug 10 16:48:30 2011] [debug]: Committing scrip #11 on txn #640 of
ticket #93 (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Aug 10 16:48:30 2011] [debug]: Committing scrip #12 on txn #640 of
ticket #93 (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Aug 10 16:48:30 2011] [debug]: Committing scrip #13 on txn #640 of
ticket #93 (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Aug 10 16:48:30 2011] [info]: No Discovery Method set by scrip 13.
No matches. Subject was ‘rrrrrrrrrrrrrrrrrrrr’ and requestor was
‘jblaine@our.org’ ((eval 4458):118)
[Wed Aug 10 16:48:30 2011] [info]: Ticket 93 created in queue
‘IncidentReports’ by jblaine (/apps/rt/bin/…/lib/RT/Ticket_Overlay.pm:671)
[Wed Aug 10 16:48:30 2011] [debug]: Found 0 scrips for TransactionBatch
stage with applicable type(s) Create for txn #640 on ticket #93
(/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:377)
[Wed Aug 10 16:48:54 2011] [debug]: About to think about scrips for
transaction #641 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Aug 10 16:48:54 2011] [debug]: About to prepare scrips for
transaction #641 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:167)
[Wed Aug 10 16:48:54 2011] [debug]: Found 3 scrips for TransactionCreate
stage with applicable type(s) Status for txn #641 on ticket #92
(/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:377)
[Wed Aug 10 16:48:54 2011] [debug]: Skipping Scrip #2 because it isn’t
applicable (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:236)
[Wed Aug 10 16:48:54 2011] [debug]: Skipping Scrip #12 because it isn’t
applicable (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:236)
[Wed Aug 10 16:48:54 2011] [debug]: About to commit scrips for
transaction #641 (/apps/rt/bin/…/lib/RT/Transaction_Overlay.pm:187)
[Wed Aug 10 16:48:54 2011] [debug]: Committing scrip #11 on txn #641 of
ticket #92 (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Aug 10 16:48:55 2011] [debug]: Found 1 scrips for TransactionBatch
stage with applicable type(s) Status for txn #641 on ticket #92
(/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:377)
[Wed Aug 10 16:48:55 2011] [debug]: Skipping Scrip #16 because it isn’t
applicable (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:236)
[Wed Aug 10 16:48:55 2011] [debug]: Found 1 scrips for TransactionBatch
stage with applicable type(s) Status for txn #641 on ticket #92
(/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:377)
[Wed Aug 10 16:48:55 2011] [debug]: Skipping Scrip #16 because it isn’t
applicable (/apps/rt/bin/…/lib/RT/Scrips_Overlay.pm:236)

15

[Wed Aug 10 16:48:30 2011] [info]: Transaction type is ‘Create’ so
enabling AffectedEmployee processing stuff. ((eval 4448):24)

What code is throwing this?

-kevin

16

[Wed Aug 10 16:48:30 2011] [info]: Transaction type is ‘Create’ so
enabling AffectedEmployee processing stuff. ((eval 4448):24)

What code is throwing this?

One of my scrips which takes employee numbers from the
“AffectedEmployeeNumbers” custom field, looks some data
up from LDAP, and populates the “AffectedEmployeeDetails”
custom field.

17

This seems to have been fixed by ditching the previous
effort to bring “all but Tickets” from our production
database to this development host.

http://www.mailinglistarchive.com/html/rt-users@lists.bestpractical.com/2011-06/msg00406.html

I will follow up to that thread with a warning to future
thread-finders.

I dumped the 10GB of data from production, loaded it
into development, then shredded the 44,000 tickets :expressionless:

I updated http://requesttracker.wikia.com/wiki/Shredder
with a “Shred ALL TICKETS” section.

18

This seems to have been fixed by ditching the previous
effort to bring “all but Tickets” from our production
database to this development host.

Oh, if I knew this was a non-stock database that’s where I would have
suggested you look.

-kevin