[rt-users] RT 3.8.10 is setting a CF value on new ticket creation?
Jeff Blaine
jblaine at kickflop.net
Tue Aug 9 15:38:16 EDT 2011
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 at kickflop.net
>>> <mailto:jblaine at 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
>
More information about the rt-users
mailing list