[rt-users] RT 3.8.10 is setting a CF value on new ticket creation?

[Jeff Blaine]

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
>