[rt-users] 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?
Re: [rt-users] Adding Queue to comment/reply section
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 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?
Re: [rt-users] Adding Queue to comment/reply section
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 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 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?
Re: [rt-users] Adding Queue to comment/reply section
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 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 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? http://akari.seiner.com
Re: [rt-users] Adding Queue to comment/reply section
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 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 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 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
Re: [rt-users] Adding Queue to comment/reply section
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
Re: [rt-users] Adding Queue to comment/reply section
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.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. :)
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
