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

Kenneth Crocker kfcrocker at lbl.gov
Thu May 26 14:10:01 EDT 2011


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 <falcone at 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]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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110526/5773572d/attachment.htm>


More information about the rt-users mailing list