I want the opposite actually. I want the status set to new for every ticket moving to every queue *except* tickets being moved from TriageQueue to TechOps.
Keep up with me and what I'm up to: http://theillien.blogspot.com Roy El-Hames wrote: > So Mathew I am guessing you want tickets moved to the TechOps queue to > change to new if these were moved from TriageQueue , then I would > suggest you do a queue script (ie not global) in the TechOps queue , > with the On Queue change condition and User defined Action, return 1; > for prep code and action clean up as follows: > if ($self->TransactionObj->OldValue == 18) { > $self->TicketObj->SetStatus('new'); > return 1; > } else { > return undef; > } > > Change the 18 to the value of the queue id for your TriageQueue ; I > tried using Queue name did not work. > > Good luck; > Roy > > Mathew Snyder wrote: >> Well, I thought I had solved the problem. However, had noticed a >> potential >> problem with the way I had it set up: >> >> if ($self->TransactionObj->NewValue eq "TechOps") { >> return 0; >> }else{ >> $self->TicketObj->SetStatus('new'); >> return 1; >> } >> >> I need the status set to new for anything that isn't coming from our >> triage >> queue. Right now it looks as if it will avoid being set to new >> regardless of >> which queue it comes from. This doesn't work with our policies. >> >> I thought that if I modify it to include the old value of the triage >> queue it >> would work. But instead, it sets it to new again. >> >> if ($self->TransactionObj->OldValue eq "TriageQueue" && >> $self->TransactionObj->NewValue eq "TechOps") { >> return 0; >> }else{ >> $self->TicketObj->SetStatus('new'); >> return 1; >> } >> >> I then reset the code to the former value (without the OldValue >> condition) and >> now it sets it to new again. I'm so confrused :( >> >> Keep up with me and what I'm up to: http://theillien.blogspot.com >> >> >> Mathew Snyder wrote: >> >>> Thanks. I removed the first 'if' as suggested by both you and Todd >>> (this didn't >>> seem to work before which is why it was still in there after Todd's >>> suggestion). >>> I've tested it on our development server and it seems to do what I >>> think it >>> should. However, I have admin rights so I need to verify with >>> someone who's >>> rights are limited that it is actually working. >>> >>> I've also removed the criteria that the owner not be Nobody as it >>> seems moot for >>> our needs. The NewStatus method makes use of either the queue name >>> or id. >>> >>> Thanks again. >>> >>> Keep up with me and what I'm up to: http://theillien.blogspot.com >>> >>> >>> Roy El-Hames wrote: >>> >>>> Matthew; >>>> >>>> Why do you need the first if, as your condition is Queue change which >>>> should compensate for : >>>> >>>> if ($self->TransactionObj->Type eq "Set" && >>>> $self->TransactionObj->Field >>>> eq "Queue") { >>>> >>>> Also >>>> >>>> $self->TransactionObj->NewValue eq "TechOps" >>>> >>>> I am guessing this should be the Queue Id and not Name, ie number not >>>> label. >>>> >>>> Regards; >>>> Roy >>>> >>>> Mathew Snyder wrote: >>>> >>>>> I haven't been able to sort this out. When I move a ticket from our >>>>> triage >>>>> queue to our TechOps queue it is still reset to new. Anyone have any >>>>> thoughts >>>>> on how to get this working? >>>>> >>>>> Condition: On Queue Change >>>>> Action: User Defined >>>>> Template: Global template: Blank >>>>> Stage: TransactionCreate >>>>> >>>>> Custom condition: >>>>> >>>>> Custom action preparation code: >>>>> return 1; >>>>> >>>>> Custom action cleanup code: >>>>> if ($self->TransactionObj->Type eq "Set" && >>>>> $self->TransactionObj->Field eq >>>>> "Queue") { >>>>> if ($self->TransactionObj->NewValue eq "TechOps" || >>>>> $self->TicketObj->Owner != >>>>> 10) { >>>>> return 0; >>>>> }else{ >>>>> $self->TicketObj->SetStatus('new'); >>>>> return 1; >>>>> } >>>>> } >>>>> >>>>> >>>>> Keep up with me and what I'm up to: http://theillien.blogspot.com >>>>> _______________________________________________ >>>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users >>>>> >>>>> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT: >>>>> >>>>> If you sign up for a new RT support contract before December 31, we'll >>>>> take >>>>> up to 20 percent off the price. This sale won't last long, so get in >>>>> touch today. Email us at [EMAIL PROTECTED] or call us at +1 >>>>> 617 812 0745. >>>>> >>>>> >>>>> Community help: http://wiki.bestpractical.com >>>>> Commercial support: [EMAIL PROTECTED] >>>>> >>>>> >>>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. >>>>> Buy a copy at http://rtbook.bestpractical.com >>>>> >>>>> >>> _______________________________________________ >>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users >>> >>> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT: >>> >>> If you sign up for a new RT support contract before December 31, >>> we'll take >>> up to 20 percent off the price. This sale won't last long, so get in >>> touch today. Email us at [EMAIL PROTECTED] or call us at +1 >>> 617 812 0745. >>> >>> >>> Community help: http://wiki.bestpractical.com >>> Commercial support: [EMAIL PROTECTED] >>> >>> >>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. >>> Buy a copy at http://rtbook.bestpractical.com >>> >>> >> >> > > _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users SAVE THOUSANDS OF DOLLARS ON RT SUPPORT: If you sign up for a new RT support contract before December 31, we'll take up to 20 percent off the price. This sale won't last long, so get in touch today. Email us at [EMAIL PROTECTED] or call us at +1 617 812 0745. Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
