[rt-users] Adding "Queue" to comment/reply section

[Kevin Falcone]

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]yan at 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]kfcrocker at 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]hiro24 at 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:yan at seiner.com
>    2. mailto:kfcrocker at lbl.gov
>    3. mailto:hiro24 at gmail.com
>    4. http://akari.seiner.com/
-------------- 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/20110526/f2a59c1e/attachment.sig>