[rt-users] Scrip question
Hi RT 3.8.7 MySQL I have been asked to do the following: when updating a ticket and a specific User is selected as the new Owner, I will Force that User to be the new Owner. We have several Users which I need to Force as new Owners. Is it possible to create a Scrip to do this? Should I use the TransactionObj or the TicketObj? I am thinking I should use the TransactionCreate Stage. Thanks, Roman
Re: [rt-users] Scrip Question
Thanks, That was exactly as I needed. On Fri, Nov 13, 2009 at 6:46 PM, Ruslan Zakirov ruslan.zaki...@gmail.comwrote: Hello Aaron, $txn-Content returns text of the comment/reply, but if you need all attachements then you should walk $txn-Attachments collection. On Fri, Nov 13, 2009 at 6:18 AM, Aaron Guise aa...@guise.net.nz wrote: Hi All, Silly question but, how can I access the Attachments for a related Transaction via a scrip? I am wanting to collect a piece out of the plaintext content to populate a CF on comment. -- Regards, Aaron ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Best regards, Ruslan. -- Regards, Aaron ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Scrip Question
Hi All, Silly question but, how can I access the Attachments for a related Transaction via a scrip? I am wanting to collect a piece out of the plaintext content to populate a CF on comment. -- Regards, Aaron ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip Question
Hello Aaron, $txn-Content returns text of the comment/reply, but if you need all attachements then you should walk $txn-Attachments collection. On Fri, Nov 13, 2009 at 6:18 AM, Aaron Guise aa...@guise.net.nz wrote: Hi All, Silly question but, how can I access the Attachments for a related Transaction via a scrip? I am wanting to collect a piece out of the plaintext content to populate a CF on comment. -- Regards, Aaron ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Scrip Question
Hi, I want to check if a Custom Field Value is Set to a particular value and if so don't send autoreply on TicketCreate. My Question is how do I select a Custom field Value within a scrip? *Regards,* *Aaron Guise 027 212 6638 aa...@guise.net.nz * ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip Question
Found it,
$TicketObj-FirstCustomFieldValue('The CF Name');
On Thu, Jun 11, 2009 at 9:59 AM, Aaron Guise aa...@guise.net.nz wrote:
Hi,
I want to check if a Custom Field Value is Set to a particular value and if
so don't send autoreply on TicketCreate.
My Question is how do I select a Custom field Value within a scrip?
*Regards,*
*Aaron Guise
027 212 6638
aa...@guise.net.nz
*
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question and how to debug?
Vivek:
Looking at log output made me realize that $Owner does not contain the
name of the owner. Where is the actual owner name stored as a string? I
want to compare that string to Nobody. This seems like it should be
fairly simple but I don't understand enough about how RT works
internally to figure that out.
my $admincclist = $self-TicketObj-AdminCc;
my $Owner = $self-TicketObj-OwnerObj;
if ( $Owner-Id ne Nobody){
$admincclist-AddMember($Owner-Id);
}
Vivek Khera wrote:
On Mar 14, 2008, at 2:25 PM, John Arends wrote:
Second, is there a good way to debug scrips? I feel like I'm just
feeling around in the dark and don't know how to tell if they're
really
working, or what the contents of variables are, etc. If I was writing
sprinkle your scrip with lines like this:
$RT::Logger-error(Got a create transacation...);
and look in your RT logfile.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question and how to debug?
You compare owner-id with nobody string?!? Nobody id is 10 compare owner id
with nobody id could work.
Torsten
Kühne + Nagel (AG Co.) KG, Geschäftsleitung: Hans-Georg Brinkmann (Vors.),
Uwe Bielang (Stellv.), Bruno Mang, Alfred Manke, Thorsten Meincke, Mark
Reinhardt (Stellv.), Jens Wollesen, Rainer Wunn, Sitz: Bremen, Registergericht:
Bremen, HRA 21928, USt-IdNr.: DE 812773878, Persönlich haftende Gesellschaft:
Kühne Nagel A.G., Sitz: Contern/Luxemburg Geschäftsführender Verwaltungsrat:
Klaus-Michael Kühne
-Original Message-
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: Vivek Khera [EMAIL PROTECTED]
CC: RT Users rt-users@lists.bestpractical.com
Sent: Mon Mar 17 16:19:10 2008
Subject: Re: [rt-users] Scrip question and how to debug?
Vivek:
Looking at log output made me realize that $Owner does not contain the
name of the owner. Where is the actual owner name stored as a string? I
want to compare that string to Nobody. This seems like it should be
fairly simple but I don't understand enough about how RT works
internally to figure that out.
my $admincclist = $self-TicketObj-AdminCc;
my $Owner = $self-TicketObj-OwnerObj;
if ( $Owner-Id ne Nobody){
$admincclist-AddMember($Owner-Id);
}
Vivek Khera wrote:
On Mar 14, 2008, at 2:25 PM, John Arends wrote:
Second, is there a good way to debug scrips? I feel like I'm just
feeling around in the dark and don't know how to tell if they're
really
working, or what the contents of variables are, etc. If I was writing
sprinkle your scrip with lines like this:
$RT::Logger-error(Got a create transacation...);
and look in your RT logfile.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question and how to debug?
$Owner-Name was what I was looking for. I'll have to post my scrip so
other people can figure out what is going on.
John Arends wrote:
Vivek:
Looking at log output made me realize that $Owner does not contain the
name of the owner. Where is the actual owner name stored as a string? I
want to compare that string to Nobody. This seems like it should be
fairly simple but I don't understand enough about how RT works
internally to figure that out.
my $admincclist = $self-TicketObj-AdminCc;
my $Owner = $self-TicketObj-OwnerObj;
if ( $Owner-Id ne Nobody){
$admincclist-AddMember($Owner-Id);
}
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] Scrip question and how to debug?
I have a scrip that should be adding the owner as an AdminCC on ticket
create. It works fine. However, if a ticket is created with no owner
set, it sets an AdminCC as Nobody, which is annoying.
I threw an if statement in there to try to handle it, but I am doing
something wrong.
my $admincclist = $self-TicketObj-AdminCc;
my $Owner = $self-TicketObj-OwnerObj;
if ( $Owner ne Nobody){
$admincclist-AddMember($Owner-Id);
}
$Owner must not really be the string nobody, because Nobody is still
being added as an AdminCC. Any suggestions on what I should be looking
for instead?
Second, is there a good way to debug scrips? I feel like I'm just
feeling around in the dark and don't know how to tell if they're really
working, or what the contents of variables are, etc. If I was writing
straight perl code I could have it print the content of $Owner so I
could see what was in there.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question and how to debug?
On Mar 14, 2008, at 2:25 PM, John Arends wrote: Second, is there a good way to debug scrips? I feel like I'm just feeling around in the dark and don't know how to tell if they're really working, or what the contents of variables are, etc. If I was writing sprinkle your scrip with lines like this: $RT::Logger-error(Got a create transacation...); and look in your RT logfile. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question...Getting there slowly...Time Worked
Greg,
With apologies if this is off-base but I see process as the answer to your
problem. Whether an issue needs to be tracked for troubleshooting over the
phone, at the desk or in the server room it should be created from the get
go. Here's my rationale - I look at the first comment (STATUS = New) as the
problem description. It should be short and to the point. Collect necessary
information and create the ticket. To help train your phone support to
comply with this process, make sure they provide end users with a ticket
number before they start to troubleshoot (nice customer service touch).
All comments posted after the fact (STATUS = Open OR Stalled) make up the
bulk of the ticket history and detail troubleshooting steps and
communication with the end user. When solved, the final comment (STATUS =
Resolved) is the resolution which again should be short and to the point.
This allows for reporting to include an easy to read recap of Date |
Requestor | Problem Description | Resolution | Time worked (thanks to your
scrip). If you allow front line/techs to cram all parts of an issue into one
comment that serves as problem/troubleshooting/resolution, you miss out on
important tracking steps that can help with ticket histories/trending/ and
repeatable solutions for a knowledge base. That kind of report can also be
useful in demonstrating work to end-users or management where the details of
a ticket can be confusing or perhaps even inappropriate at times.
The harder part of this process may be training everyone to separate out the
resolution as a separate event (and learning how to make it
concise/clear/valuable) but I think the end result may justify the effort.
Nat
On *Sun Feb 10 02:53:22 EST 2008 *gevans at
hcc.netrt-users%40lists.bestpractical.com?Subject=%5Brt-users%5D%20Scrip%20question...Getting%20there%20slowly...Time%20WorkedIn-Reply-To=589c94400802081837r2b17416fw111541c11c0cc85b%40mail.gmail.com
**
--
Hi Ruslan, Mike and everyone reading the list.
I have got the scrip working now, thanks for your input Mike, Ruslan,
it was a lot of help. I thought I would post it here and then ask a
follow-up question or two :)
Here is what I have so far and it works great as long as you set the
time worked in the ticket after you first create it.
Description: Set Time Worked
Condition: On Transaction
Action: User Defined
Template: Global template: Blank
Stage: Transaction Create
Custom Condition: None
Custom Action Preparation Code: 1;
Custom Action Cleanup Code:
# If we reply to or comment on a ticket
$RT::Logger-debug(Got to Stage 2);
if ($self-TransactionObj-Type eq Correspond || $self-
TransactionObj-Type eq Comment)
{
#set our variable $ticket_Worked to the difference in time between the
Created
#datestamp and the updated datestamp
my $date_update=$self-TicketObj-LastUpdatedObj-Unix;
my $date_create=$self-TicketObj-CreatedObj-Unix;
#check current value of time worked for debug
#my $ticket_check = $self-TicketObj-TimeWorked;
#calculate the new value we will place in the TimeWorked field we are
working in unix time
#so everything is in seconds, divide by 60 to get minutes.
my $ticket_Worked = (($date_update - $date_create)/60);
#change the TimeWorked field to the value of our variable
($ticket_Worked)
$self-TicketObj-SetTimeWorked($ticket_Worked);
return 1;
} else {
return undef;
}
So, that works. now my questions.
1) As I stated the above code works, but with one caveat. If I do not
manually enter the time worked the first time, any updates to the
ticket result in the time worked remaining at 0. I can understand
that for many organizations this would be the preferred method for
this, because someone would create the ticket and there may be lengthy
research involved, etc. before the ticket can be updated, however in
the case for how we are using RT, it is for phone calls in to the
helpdesk, and most tickets are resolved during that first call. On a
slow day, this would not be an issue, because we could manually enter
the time worked, though if we forget, that destroys the value of the
time worked field. This leads to question #2...
2) When I create a new ticket, I would like to be able to do the same
as above, but it should automatically set the time worked from when I
clicked New TIcket In... to when I actually clicked the Create
button. I am assuming that I *should* be able to do this through the
scrip process somehow, so I decided to watch the rt.log while I
clicked New Ticket In... but I saw no entries into the log file that
would indicate that I am creating a new ticket, which I assume is
because it will not be logging that until I actually hit the create
button. So I am interested in knowing how would I go about
implementing something like this, so that I can ensure hat each ticket
gets an entry in Time Worked without any user having to manually enter
it, or is there no way to accomplish this?
Regards,
Greg Evans
Re: [rt-users] Scrip question...Getting there slowly...Time Worked
Hi Ruslan, Mike and everyone reading the list.
I have got the scrip working now, thanks for your input Mike, Ruslan,
it was a lot of help. I thought I would post it here and then ask a
follow-up question or two :)
Here is what I have so far and it works great as long as you set the
time worked in the ticket after you first create it.
Description: Set Time Worked
Condition: On Transaction
Action: User Defined
Template: Global template: Blank
Stage: Transaction Create
Custom Condition: None
Custom Action Preparation Code: 1;
Custom Action Cleanup Code:
# If we reply to or comment on a ticket
$RT::Logger-debug(Got to Stage 2);
if ($self-TransactionObj-Type eq Correspond || $self-
TransactionObj-Type eq Comment)
{
#set our variable $ticket_Worked to the difference in time between the
Created
#datestamp and the updated datestamp
my $date_update=$self-TicketObj-LastUpdatedObj-Unix;
my $date_create=$self-TicketObj-CreatedObj-Unix;
#check current value of time worked for debug
#my $ticket_check = $self-TicketObj-TimeWorked;
#calculate the new value we will place in the TimeWorked field we are
working in unix time
#so everything is in seconds, divide by 60 to get minutes.
my $ticket_Worked = (($date_update - $date_create)/60);
#change the TimeWorked field to the value of our variable
($ticket_Worked)
$self-TicketObj-SetTimeWorked($ticket_Worked);
return 1;
} else {
return undef;
}
So, that works. now my questions.
1) As I stated the above code works, but with one caveat. If I do not
manually enter the time worked the first time, any updates to the
ticket result in the time worked remaining at 0. I can understand
that for many organizations this would be the preferred method for
this, because someone would create the ticket and there may be lengthy
research involved, etc. before the ticket can be updated, however in
the case for how we are using RT, it is for phone calls in to the
helpdesk, and most tickets are resolved during that first call. On a
slow day, this would not be an issue, because we could manually enter
the time worked, though if we forget, that destroys the value of the
time worked field. This leads to question #2...
2) When I create a new ticket, I would like to be able to do the same
as above, but it should automatically set the time worked from when I
clicked New TIcket In... to when I actually clicked the Create
button. I am assuming that I *should* be able to do this through the
scrip process somehow, so I decided to watch the rt.log while I
clicked New Ticket In... but I saw no entries into the log file that
would indicate that I am creating a new ticket, which I assume is
because it will not be logging that until I actually hit the create
button. So I am interested in knowing how would I go about
implementing something like this, so that I can ensure hat each ticket
gets an entry in Time Worked without any user having to manually enter
it, or is there no way to accomplish this?
Regards,
Greg Evans
On Feb 8, 2008, at 6:37 PM, Ruslan Zakirov wrote:
On Feb 9, 2008 3:20 AM, Greg Evans [EMAIL PROTECTED] wrote:
Well, at least I know I am doing it wrong! LOL :) Better to know
now and
learn then to regret it later.
Here is everything about how I have it set up (this is my first one
BTW, be
gentle)
Description : Set Time Worked Test
Condition : On Transaction
Action : User Defined
Template: Global template: Blank
Stage : TransactionCreate
Custom Condition: none
Custom Action preparation code: 1;
Custom Action cleanup code:
The code I sent in the previous message
I think I see what you mean regarding the object types, so I can
assume that
the beginning where I am trying to use correspond or comment should
be
'TransactionObj-Type eq ...' instead of 'TicketObj-Type eq ...'? or
something else entirely?
TransactionObj-Type
Greg Evans
RT newbie :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ruslan Zakirov
Sent: Friday, February 08, 2008 4:10 PM
To: Greg Evans
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Scrip question...Getting there
slowly...Time Worked
On Feb 9, 2008 2:57 AM, Greg Evans [EMAIL PROTECTED] wrote:
following up on my own post to the list...The following
code is *mostly*
working but there is a GLARING ERROR that makes it unusable
Please NOTE THE ABOVE because if you use it as is, it will
require a restart
of httpd each time you try to update a ticket.
#code begin
if ($self-TicketObj-Type eq Correspond ||
$self-TicketObj-Type eq
Comment || $self-TicketObj-Type eq ticket)
This is wrong. you're mixing transactions' types and tickets'
Ticket's
type almost always is 'ticket', so this if condition is true all the
time.
What condition are you using for this scrip?
# Why it has to be ticket to work I don't understand yet
{
# Saw something
[rt-users] Scrip question...Getting there slowly...Time Worked
As has been mentioned I am working on trying to get a time worked scrip up
and running. So far everything is going well except for one thing, I can
retrieve dates from the ticket without problem and they come through like:
2008-02-08 21:24:49
This seems like a fine format, but once I have 2 of them, I can't figure out
how to calculate the difference. It was suggest that I might need to convert
them to unix time and back, but I am not sure how to do that. I see that
Time::Local could possibly be used or maybe Date::Manip but my admittedly
novice Perl skills don't particularly help me out here.
Here is the scrip as it sits, and after using RT::Logger-debug it appears
that all I need is to get the date difference calculation to work
if ($self-TicketObj-Type eq Correspond || $self-TicketObj-Type eq
Comment || $self-TicketObj-Type eq ticket)
{
#This is the part that is not working.
my $ticket_Worked = ($self-TicketObj-LastUpdated -
$self-TicketObj-Created);
#End part that is not working
$self-TicketObj-SetTimeWorked($ticket_Worked);
} else {
return undef;
}
The other thing that I thought was weird when I looked in my rt.log was that
when I would comment on the ticket, the returned result of the if test that
I start with was ticket which seems strange to me, but what do I know.
Maybe someone could explain that to me as well?
Greg Evans
Internet Support
Hood Canal Communications
(360) 898-2481 ext.212
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question...Getting there slowly...Time Worked
On Feb 9, 2008 2:57 AM, Greg Evans [EMAIL PROTECTED] wrote:
following up on my own post to the list...The following code is *mostly*
working but there is a GLARING ERROR that makes it unusable
Please NOTE THE ABOVE because if you use it as is, it will require a restart
of httpd each time you try to update a ticket.
#code begin
if ($self-TicketObj-Type eq Correspond || $self-TicketObj-Type eq
Comment || $self-TicketObj-Type eq ticket)
This is wrong. you're mixing transactions' types and tickets' Ticket's
type almost always is 'ticket', so this if condition is true all the
time.
What condition are you using for this scrip?
# Why it has to be ticket to work I don't understand yet
{
# Saw something similar somewhere that I was looking at RT stuff.
# Looked like it may work, it does.
my $date_update=$self-TicketObj-LastUpdatedObj-Unix;
my $date_create=$self-TicketObj-CreatedObj-Unix;
my $ticket_check = $self-TicketObj-TimeWorked; #tells us the current value
of TimeWorked
my $ticket_Worked = (($date_update - $date_create)/60); #time in minutes
#this was the problem before and seems to be the problem again!!!
$self-TicketObj-SetTimeWorked($ticket_Worked);
return 1;
} else {
return undef;
}
Here is what happens when I run it as is just a quick copy/paste job of the
ticket:
Fri Feb 08 15:39:22 2008 gevans - Comments added[Reply] [Comment]
Download (untitled) [text/plain 1.2k] On Fri Feb 08 15:37:16 2008, gevans
wrote:
[snipped]
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '19.1'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '19' to ''
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '21.21667'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '21' to ''
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '21.21667'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '21' to ''
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '21.21667'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '21' to ''
...
...
#Fri Feb 08 15:42:39 2008 RT_System - TimeWorked changed from (no value)
to '24.48333'
#Fri Feb 08 15:42:39 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:39 2008 RT_System - TimeWorked changed from (no value)
to '24.48333'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.48333'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
It will continue adding time until you kill httpd. This has got to be
something simple that I am missing. At least I think so... Ideas?
Thanks,
Greg Evans
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg Evans
Sent: Friday, February 08, 2008 2:09 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Scrip question...Getting there slowly...Time
Worked
As has been mentioned I am working on trying to get a time worked
scrip up and running. So far everything is going well except for one thing,
I can retrieve dates from the ticket without problem and they come through
like:
2008-02-08 21:24:49
This seems like a fine format, but once I have 2 of them, I can't
figure out how to calculate the difference. It was suggest that I might need
to convert them to unix time and back, but I am not sure how to do that. I
see that Time::Local could possibly be used or maybe Date::Manip but my
admittedly novice Perl skills don't particularly help me out here.
Here is the scrip as it sits, and after using RT::Logger-debug it
appears that all I need is to get the date difference calculation to work
if ($self-TicketObj-Type eq Correspond || $self-TicketObj-Type
eq Comment || $self-TicketObj-Type eq ticket)
{
#This is the part that is not working.
my $ticket_Worked = ($self-TicketObj
Re: [rt-users] Scrip question...Getting there slowly...Time Worked
following up on my own post to the list...The following code is *mostly*
working but there is a GLARING ERROR that makes it unusable
Please NOTE THE ABOVE because if you use it as is, it will require a restart
of httpd each time you try to update a ticket.
#code begin
if ($self-TicketObj-Type eq Correspond || $self-TicketObj-Type eq
Comment || $self-TicketObj-Type eq ticket)
# Why it has to be ticket to work I don't understand yet
{
# Saw something similar somewhere that I was looking at RT stuff.
# Looked like it may work, it does.
my $date_update=$self-TicketObj-LastUpdatedObj-Unix;
my $date_create=$self-TicketObj-CreatedObj-Unix;
my $ticket_check = $self-TicketObj-TimeWorked; #tells us the current value
of TimeWorked
my $ticket_Worked = (($date_update - $date_create)/60); #time in minutes
#this was the problem before and seems to be the problem again!!!
$self-TicketObj-SetTimeWorked($ticket_Worked);
return 1;
} else {
return undef;
}
Here is what happens when I run it as is just a quick copy/paste job of the
ticket:
Fri Feb 08 15:39:22 2008 gevans - Comments added[Reply] [Comment]
Download (untitled) [text/plain 1.2k] On Fri Feb 08 15:37:16 2008, gevans
wrote:
[snipped]
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '19.1'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '19' to ''
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '21.21667'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '21' to ''
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '21.21667'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '21' to ''
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from (no value)
to '21.21667'
#Fri Feb 08 15:39:23 2008 RT_System - TimeWorked changed from '21' to ''
...
...
#Fri Feb 08 15:42:39 2008 RT_System - TimeWorked changed from (no value)
to '24.48333'
#Fri Feb 08 15:42:39 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:39 2008 RT_System - TimeWorked changed from (no value)
to '24.48333'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.48333'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from '24' to ''
#Fri Feb 08 15:42:40 2008 RT_System - TimeWorked changed from (no value)
to '24.5'
It will continue adding time until you kill httpd. This has got to be
something simple that I am missing. At least I think so... Ideas?
Thanks,
Greg Evans
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg Evans
Sent: Friday, February 08, 2008 2:09 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Scrip question...Getting there slowly...Time
Worked
As has been mentioned I am working on trying to get a time worked
scrip up and running. So far everything is going well except for one thing,
I can retrieve dates from the ticket without problem and they come through
like:
2008-02-08 21:24:49
This seems like a fine format, but once I have 2 of them, I can't
figure out how to calculate the difference. It was suggest that I might need
to convert them to unix time and back, but I am not sure how to do that. I
see that Time::Local could possibly be used or maybe Date::Manip but my
admittedly novice Perl skills don't particularly help me out here.
Here is the scrip as it sits, and after using RT::Logger-debug it
appears that all I need is to get the date difference calculation to work
if ($self-TicketObj-Type eq Correspond || $self-TicketObj-Type
eq Comment || $self-TicketObj-Type eq ticket)
{
#This is the part that is not working.
my $ticket_Worked = ($self-TicketObj-LastUpdated -
$self-TicketObj-Created);
#End part that is not working
$self-TicketObj-SetTimeWorked($ticket_Worked);
} else {
return undef;
}
The other
[rt-users] Scrip question: Approvals and changing ownership of the originating ticket
I implemented the approval process listed in the wiki here: http://wiki.bestpractical.com/view/ApprovalCreation If a ticket is created via email sent to the approval queue, the ticket and the resulting approval ticket do not have an owner. I wrote a scrip to set the owner of the approval ticket when it is approved (resolved), but I can't figure out how to set the owner of the originating ticket (created by the original email) to the requestor Is this possible? The reason I ask, is because once a ticket has its dependancy resolved, it sits in the approval queue unowned and it is up to the requestor to go get the ticket and take ownership. Any guidance would be greatly appreciated. -- Chris Nelson CDA Unix Administrator NightHawk Radiology Services 250 Northwest Blvd. #206 Coeur D'Alene, ID 83814 208.415.0588 (Office) 509.294.1835 (Cell) 208.664.2720 (Fax) [EMAIL PROTECTED] (email) http://www.nighthawkrad.net (Web) CONFIDENTIALITY NOTICE: This email, including any attachments, contains information from NightHawk Radiology Services, which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this email in error, please notify NightHawk Radiology Services immediately by forwarding message to [EMAIL PROTECTED] and destroy all electronic and hard copies of the communication, including attachments. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [Fwd: Re: [rt-users] Scrip question]
Yes, that's behaving as defined. It might be possible to use a cleverer scrip to work around it, but each change to a ticket is a separate transaction. On Apr 12, 2007, at 3:16 PM, Kenneth Crocker wrote: Jesse, Sorry to just address this to you, but it came up in RT Users and I wanted to ask you if Stephan is correct about this. Is it possible for a user-defined scrip to be executed and an initial modification to a CF be reversed? If so, is this a bug that is corrected in 3.6.3 or what? Thanks. Kenn LBNL From: Stephen Turner [EMAIL PROTECTED] Date: April 10, 2007 9:47:46 AM EDT To: Kenneth Crocker [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [rt-users] Scrip question At Monday 4/9/2007 08:13 PM, Kenneth Crocker wrote: To all, I have a question that perhaps the longtime users of RT can answer; I am planning a series of scrips that will evaluate certain Custom Fields (which can only be modified by certain people) and based on that result and the current status of the ticket, CHANGE the current status of said ticket. This will, in essence, allow me to automate the work-flow of a ticket from request to development to QA to Implementeded to Resolved or any other stages of status I desire. My question is this, when a ticket is modified does RT evaluate and attempt to execute any and all user-defined scrips that are applied (by either Queue or Globally) for that ticket? Thanks. Hello Kenn, RT will look at _all_ scrips appropriate to the ticket (queue global) and see whether it should execute them, whether or not they have user defined code. So if you want a user-defined condition to execute only on a status change (for example) you have to code that condition in the custom condition. Also, there's a potential trap you can get caught in when updating ticket fields in scrips - if the update that fires the scrip is triggered from a ticket update screen, the value that is shown on the screen when the submit button is pressed can override your scrip update. For example, if your ticket is open, you make an update to a custom field, and this triggers a scrip that, in custom code, changes the status to 'stalled', the sequence of events that take place may set the ticket back to what it was on the screen (ie open). I haven't found a way round this one - Steve PGP.sig Description: This is a digitally signed message part ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question
At Monday 4/9/2007 08:13 PM, Kenneth Crocker wrote: To all, I have a question that perhaps the longtime users of RT can answer; I am planning a series of scrips that will evaluate certain Custom Fields (which can only be modified by certain people) and based on that result and the current status of the ticket, CHANGE the current status of said ticket. This will, in essence, allow me to automate the work-flow of a ticket from request to development to QA to Implementeded to Resolved or any other stages of status I desire. My question is this, when a ticket is modified does RT evaluate and attempt to execute any and all user-defined scrips that are applied (by either Queue or Globally) for that ticket? Thanks. Hello Kenn, RT will look at _all_ scrips appropriate to the ticket (queue global) and see whether it should execute them, whether or not they have user defined code. So if you want a user-defined condition to execute only on a status change (for example) you have to code that condition in the custom condition. Also, there's a potential trap you can get caught in when updating ticket fields in scrips - if the update that fires the scrip is triggered from a ticket update screen, the value that is shown on the screen when the submit button is pressed can override your scrip update. For example, if your ticket is open, you make an update to a custom field, and this triggers a scrip that, in custom code, changes the status to 'stalled', the sequence of events that take place may set the ticket back to what it was on the screen (ie open). I haven't found a way round this one - Steve ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question
Stephen Turner wrote: Also, there's a potential trap you can get caught in when updating ticket fields in scrips - if the update that fires the scrip is triggered from a ticket update screen, the value that is shown on the screen when the submit button is pressed can override your scrip update. For example, if your ticket is open, you make an update to a custom field, and this triggers a scrip that, in custom code, changes the status to 'stalled', the sequence of events that take place may set the ticket back to what it was on the screen (ie open). I haven't found a way round this one - This just bit me today. I have a scrip that changes a custom field on owner change. When user gives away a ticket from /Ticket/Modify.html, there's also the current value of said custom field selected. What happens is that the scrip changes the value of the custom field just to have it set back in the next transaction. This of course doesn't happen if I change the owner in the ModifyPeople.html, but I don't think I am able to educate my users... I really hope there is a solution to this that does not involve modifying RT. If not, I'll just disable the owner update from Modify.html. But that is, to put it mildly, crude. Any ideas? regards, Borut Mrak. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erm, about scrips:
What the transaction field means anyway?
I'm basing my scrips on
http://wiki.bestpractical.com/index.cgi?AutoCloseOnNagiosRecoveryMessages,
but I want to auto-deal with Nagios and Cron-Apt automatic emails. Can
I create two different scrips and apply to the same 'thing' (onCreate)?
I tried that for the cron-apt emails, with no luck:
# Based on
http://marc.free.net.ph/message/20040319.180325.27528377.en.html
# Modificado por [EMAIL PROTECTED] para uso no cron-apt
# CRON-APT completed on romario [/etc/cron-apt/config]
my $update_host = undef;
my $Transaction = $self-TransactionObj;
my $subject = $Transaction-Attachments-First-GetHeader('Subject');
if ($subject =~ m#CRON-APT completed on (\w+) \[/etc/cron-apt/config\]#) {
# This looks like a nagios recovery message
$update_host = $1;
$RT::Logger-debug(Encontrada atualização relacionada:
$update_host);
} else {
return 1;
}
# Ok, now let's merge this ticket with it's PROBLEM msg.
my $search = RT::Tickets-new($RT::SystemUser);
$search-LimitQueue(VALUE = 'rede');
$search-LimitStatus(VALUE = 'new', OPERATOR = '=', ENTRYAGGREGATOR
= 'or');
$search-LimitStatus(VALUE = 'open', OPERATOR = '=');
if ($search-Count == 0) { return 1; }
my $id = undef;
while (my $ticket = $search-Next) {
# Ignore the ticket that opened this transation (the recovery one...)
next if $self-TicketObj-Id == $ticket-Id;
# Look for nagios PROBLEM warning messages...
if ( $ticket-Subject =~ m#CRON-APT completed on (\w+)
[/etc/cron-apt/config\]# ) {
if ($1 eq $update_host){
# Aha! Found the Problem TICKET corresponding to this RECOVERY
# ticket
$id = $ticket-Id;
# Nagios may send more then one PROBLEM message, right?
$RT::Logger-debug(Merging ticket .
$self-TicketObj-Id . into $id because of OA number match.);
$self-TicketObj-MergeInto($id);
# Keep looking for more PROBLEM tickets...
}
}
}
$id || return 1;
# Auto-close/resolve this whole thing
#$self-TicketObj-SetStatus( stalled );
1;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGG6cEv0TDyic/J4kRAh9kAJ47rTHOgM4rkaVam29vscJCmChrFwCfeVru
Qk/n9Ld83hiTIS/fEnrsKtY=
=2kAI
-END PGP SIGNATURE-
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question
Have you tried setting the scrip stage to TransactionBatch? The scrip will then get triggered only once after all transactions have been generated. You then have to iterate over all the transactions to look for your condition. There is an example in the RT Essentials book. Stephen Turner wrote: Also, there's a potential trap you can get caught in when updating ticket fields in scrips - if the update that fires the scrip is triggered from a ticket update screen, the value that is shown on the screen when the submit button is pressed can override your scrip update. For example, if your ticket is open, you make an update to a custom field, and this triggers a scrip that, in custom code, changes the status to 'stalled', the sequence of events that take place may set the ticket back to what it was on the screen (ie open). I haven't found a way round this one - This just bit me today. I have a scrip that changes a custom field on owner change. When user gives away a ticket from /Ticket/Modify.html, there's also the current value of said custom field selected. What happens is that the scrip changes the value of the custom field just to have it set back in the next transaction. This of course doesn't happen if I change the owner in the ModifyPeople.html, but I don't think I am able to educate my users... I really hope there is a solution to this that does not involve modifying RT. If not, I'll just disable the owner update from Modify.html. But that is, to put it mildly, crude. Any ideas? regards, Borut Mrak. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Scrip question
Karen, Borut, Stephan, Thank you all for your replies. My intent is that once a person has already updated a CF, RT would recognise that a transaction has occurred against the ticket and my user-defined condition would execute, which would modify the ticket status field only. It's crucial to my design. Actually, if the CF goes back to it's previous setting, I won't really care as long as the status change takes place. I was also thinking of using this method for approvals (modify status to rq apprvd) because I think it is less cumbersome than the delivered version (I can more easily control the effect). Thanks again. Kenn LBNL Karen Nyenhuis wrote: Have you tried setting the scrip stage to TransactionBatch? The scrip will then get triggered only once after all transactions have been generated. You then have to iterate over all the transactions to look for your condition. There is an example in the RT Essentials book. Stephen Turner wrote: Also, there's a potential trap you can get caught in when updating ticket fields in scrips - if the update that fires the scrip is triggered from a ticket update screen, the value that is shown on the screen when the submit button is pressed can override your scrip update. For example, if your ticket is open, you make an update to a custom field, and this triggers a scrip that, in custom code, changes the status to 'stalled', the sequence of events that take place may set the ticket back to what it was on the screen (ie open). I haven't found a way round this one - This just bit me today. I have a scrip that changes a custom field on owner change. When user gives away a ticket from /Ticket/Modify.html, there's also the current value of said custom field selected. What happens is that the scrip changes the value of the custom field just to have it set back in the next transaction. This of course doesn't happen if I change the owner in the ModifyPeople.html, but I don't think I am able to educate my users... I really hope there is a solution to this that does not involve modifying RT. If not, I'll just disable the owner update from Modify.html. But that is, to put it mildly, crude. Any ideas? regards, Borut Mrak. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
