[rt-users] Auto change Queue on Take

[Kevin Falcone]

On Fri, Jan 20, 2012 at 12:02:00AM -0500, Jim Lesinski wrote:
>    I just ran into similar issue and it seems that:
>    return 1 unless $self->TransactionObj->Type eq *Take*;
>    does not work in RT 4.0.4. I checked the Transactions table in the database and it looks like
>    the type is inserted as "Set" when clicking the Take button. I found a CustomConditionSnippet
>    for Take here: [1]http://requesttracker.wikia.com/wiki/CustomConditionSnippets
>    my $txn = $self->TransactionObj;
>    return 0 unless $txn->Type eq "Set";
>    return 0 unless $txn->Field eq "Owner";
>    return 0 unless $txn->OldValue == $RT::Nobody->id;
>    return 0 unless $txn->NewValue == $txn->Creator;
>    return 1;
>    This does work, but it also fires the scrip when assigning a ticket to oneself while within a
>    ticket if the owner was nobody.
>    Can anyone confirm whether or not $self->TransactionObj->Type eq *Take*; changed intentionally
>    or if this is actually a bug?

This was an intentional change in 4.0 to normalize the types of transactions.
Type being Take was a weird outlier, when other field changes in RT
had a Type of Set and then you checked the Field to see what changed.

Your code is emulating Take properly (changed Owner from Nobody to Actor).
It sounds like you might mean Steal, which is OldValue != RT->Nobody->id.

$ git show 3dcca451f932849cbffebcd71f34ddbe54dd9890
commit 3dcca451f932849cbffebcd71f34ddbe54dd9890
Author: sunnavy <sunnavy at bestpractical.com>
Date:   Tue Nov 16 13:03:24 2010 +0800

    for SetOwner: txn type is always Set, but we also want the customized description, which can be accomplished by checking the old/new values


$ git tag --contains 3dcca451f932849cbffebcd71f34ddbe54dd9890
...
rt-4.0.0
...

-kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120120/afac861a/attachment.sig>