Adding "Queue" to comment/reply section

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?

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
LBNLOn Thu, May 26, 2011 at 6:58 AM, Chris Hall hiro24@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?

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 queueOn Thu, May 26, 2011 at 10:34 AM, Kenneth Crocker kfcrocker@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 hiro24@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?

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 kfcrocker@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 hiro24@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?

http://akari.seiner.com

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:

<& /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 yan@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 kfcrocker@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 hiro24@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?

http://akari.seiner.com

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

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
LBNLOn Thu, May 26, 2011 at 9:00 AM, Kevin Falcone falcone@bestpractical.comwrote:

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. :slight_smile:

On Thu, May 26, 2011 at 11:06 AM, Yan Seiner <[1]yan@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@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@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@seiner.com
  2. mailto:kfcrocker@lbl.gov
  3. mailto:hiro24@gmail.com
  4. http://akari.seiner.com/