Chris, I think that all of that could be accomplished without changing RT code:
1) Create a CF called "Promote". A simple "yes/no" or "off/on" would suffice. Grant the level 1 team the right to modify it. 2) When the level 1 team wants to promote it, they merely modify the CF. 3) Have a scrip validate the CF and trigger the Queue change/Owner change, grab the last email or insert a standard message that indicates the reason for promotion (the CF *could have* several values or types of promotion that would caused a specific comment related to that value to be inserted into the ticket/email/whatever), put the existing owner in as a "Cc", send out an email notice to said owner/Cc, etc. all when the CF is changed to the appropriate value. This is all done one time in the update screen, just like you wanted in the Comment/reply screen, only no code overrides need be made, just a scrip. I think this is a simpler method and it makes these changes *easier to maintain for future releases* (like the problem you're having now with 4.9) and possible changes in actions. Anyway, just a thought. Kenn LBNL On Thu, May 26, 2011 at 9:00 AM, Kevin Falcone <falc...@bestpractical.com>wrote: > On Thu, May 26, 2011 at 11:45:22AM -0400, Chris Hall wrote: > > Good times... good times... I got it working, so gotta share my > modifications w/ everyone. In > > fact, I would have had it working a LONG time ago, but I had neglected > 1 major step: removing > > all the old mason_data info! So for anybody who wants to add queue > information to your > > reply/comments section, edit share/html/Update.html in the following > way: > > You should check http://requesttracker.wikia.com/wiki/Customizing to > see if you could have done this with a callback instead. Hopefully > you're not editing in-place, otherwise you're complicating your > upgrade options. > > -kevin > > > <& /Ticket/Elements/EditBasics, > > TicketObj => $TicketObj, > > InTable => 1, > > fields => [ > > { name => 'Status', > > comp => '/Elements/SelectStatus', > > args => { > > Name => 'Status', > > DefaultLabel => loc("[_1] (Unchanged)", loc($TicketObj->Status)), > > Default => $ARGS{'Status'} || ($TicketObj->Status eq $DefaultStatus ? > undef : $DefaultStatus), > > TicketObj => $TicketObj, > > QueueObj => $TicketObj->QueueObj > > }, > > }, > > { name => 'Queue', > > comp => '/Elements/SelectQueue', > > args => { > > Name => 'Queue', > > Default => $ARGS{'Queue'} || $TicketObj->QueueObj->Id, > > ShowNullOption => 0, > > } > > }, > > { name => 'Owner', > > comp => '/Elements/SelectOwner', > > args => { > > Name => "Owner", > > TicketObj => $TicketObj, > > QueueObj => $TicketObj->QueueObj, > > DefaultLabel => loc("[_1] (Unchanged)", > $m->scomp('/Elements/ShowUser', User => > > $TicketObj->OwnerObj)), > > Default => $ARGS{'Owner'} > > } > > }, > > { name => 'Worked', > > comp => '/Elements/EditTimeValue', > > args => { > > Name => 'UpdateTimeWorked', > > Default => $ARGS{UpdateTimeWorked}||'', > > InUnits => $ARGS{'UpdateTimeWorked-TimeUnits'}||'minutes', > > } > > }, > > ] > > &> > > The new stuff is the name => 'Queue' > > and REMEMBER! when you're done, to rm -rf /opt/rt4/var/mason_data/* > > otherwise you'll be banging your head for hours wondering how you can > change damn near > > ANYTHING and yet NOTHING changes when you reload your webserver. Eh, > lesson learned the hard > > way I guess. :) > > > > On Thu, May 26, 2011 at 11:06 AM, Yan Seiner <[1]y...@seiner.com> > wrote: > > > > We do something similar. We have engineering and construction > queues. > > > > When Engineering is done with design and the job is ready to go to > the > > crews, we move it to construction queue. Right now it involves the > > following steps: > > > > 1. Change the queue > > 2. Change the owner to the Construction Manager > > 3. Move the old owner to AdminCC > > 4. Remove engineering mgr from AdminCCs > > 5. Add dispatch as AdminCC > > > > Since the people filling the roles don't necessarily have the same > > permisisons in both queues, this takes a few trips around the > various RT > > screens. It would be nice to have all of this on one screen. > > > > On Thu, May 26, 2011 7:42 am, Chris Hall wrote: > > > Sure Kenn, I'll elaborate.. and again, I had this working in > 3.8.8.. it > > > just > > > seems more... difficult to dirty hack in on 4.0.0. For example: > > > > > > Queue 1: Level 1 support > > > Queue 2: Level 2 support > > > > > > > > > Customer calls in and the guys at level 1 open a ticket in their > queue for > > > the person's problem. > > > > > > 1 hr later they call back to level 1.. they are still having a > problem. > > > It's time to pass this on to the Level 2 guys. > > > > > > The level 1 guys want to click "comment" (or reply.. whatever) on > the > > > ticket, and annotate that customer 1 is having problems beyond > their scope > > > of responsibility. It's time for level 2 to take over. On this > same > > > page, > > > they wish to change the queue to "Level 2 support", so that, upon > updating > > > the ticket: > > > > > > 1. their notes are saved to the ticket > > > 2. the ticket is moved to the appropriate queue > > > > > > > > > > > > > > > On Thu, May 26, 2011 at 10:34 AM, Kenneth Crocker <[2] > kfcroc...@lbl.gov> > > > wrote: > > > > > >> Chris, > > >> > > >> I'm not sure I understand what you're asking. You wrote "so that > my user > > >> base can change the queue when updating or replying to tickets". > Why in > > >> the > > >> world would you want to do this? Tickets reside in a Queue, so > how could > > >> RT > > >> find that ticket if you were sending an update to a different > Queue? > > >> Again, > > >> I'm sure I read this incorrectly (that happens a lot with me ;-). > Could > > >> you > > >> explain this a little differently, perhaps? > > >> > > >> Kenn > > >> LBNL > > >> > > >> > > >> On Thu, May 26, 2011 at 6:58 AM, Chris Hall <[3]hir...@gmail.com> > wrote: > > >> > > >>> Hello all, > > >>> > > >>> I was wondering if I could get a hand with a change I wanted to > make on > > >>> our end. In fact, I was able to change this in 3.8.8 days, but > the > > >>> changes > > >>> don't work on 4.0.0. I want to add to the "Ticket and > Transaction" > > >>> section > > >>> a "Queue" option, so that my user base can change the queue when > > >>> updating or > > >>> replying to tickets without having to go through the extra steps > of > > >>> going to > > >>> basic and changing it there once the ticket has been updated. > I've > > >>> tried > > >>> several modifications to the code, but nothing seems to give me > the > > >>> results > > >>> I'm looking for. > > >>> > > >>> Is anybody able to offer any assistance on adding this dropdown > into > > >>> the > > >>> Ticket and Transaction field? > > >>> > > >> > > >> > > > > > > > > > !DSPAM:4dde672e237401804284693! > > > > > > > -- > > My daughter is racing a triathlon to raise money for her swim club. > Want > > to help? > > > > [4]http://akari.seiner.com > > > > References > > > > Visible links > > 1. mailto:y...@seiner.com > > 2. mailto:kfcroc...@lbl.gov > > 3. mailto:hir...@gmail.com > > 4. http://akari.seiner.com/ >