[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