HELP with RT API

To all,

I’m in a mess trying to figure out why RT:API will NOT put dates in the
Ticket record when I read an input file.

The dates are formatted as “yyyy-mm-dd 0:00:00”. I get no errors in the log.
The Date fields “Created”, “Started”, “Resolved” get nada and the field
"LastUpdated" get current date, not the data I’m trying to put in it.

This is the code:

process all requests into tickets

sub Read_Temp_File
{
my ( $fh ) = @_;

my
(
    $in,
    $objectId
);

while ( $in = <$fh> )
{
    chomp $in;
    $objectId = New_Ticket( $in );    #ObjectId = Ticket.id
}

}

create Ticket for one request

sub New_Ticket
{
my ( $in ) = @_;

my
(
    $ticket,
    $mimeObj,
    $ticketid,
    $transaction_object,
    $err,
    $rc,
    $NUMBER,
    $DATE_OPENED,
    $DATE_RESOLVED,
    $REQUEST_TYPE,
    $SYSTEM_AREA,
    $ISSUE_DESCRIPTION,
    $RESOLUTION,

@parts,

$new_date,

    %ticket_vals
);


(  $NUMBER, $DATE_OPENED, $DATE_RESOLVED, $REQUEST_TYPE, 

$SYSTEM_AREA, $ISSUE_DESCRIPTION, $RESOLUTION ) = split( “\t”, $in );
#your field names for your data
$ticket = RT::Ticket->new( $RT::SystemUser );
$mimeObj = MIME::Entity->build(Data => $ISSUE_DESCRIPTION, Type =>
‘text/plain’); #whatever field has descr

re-format date fields in a ticket

if ( $DATE_OPENED )

{

@parts = split(/[/-]/, $DATE_OPENED);

my $new_date = RT::Date->new($RT::SystemUser);

$new_date = sprintf("%d-%02d-%02d 0:00:00", $parts[2] + 2000,

$parts[0], $parts[1]);

$DATE_OPENED = $new_date->ISO;

$DATE_OPENED->Set(Format=>‘unix’, Value=>$new_date);

$DATE_OPENED = $new_date;

}

print "Opened Date - ", $DATE_OPENED, ’ '; #debug

if ( $DATE_RESOLVED )

{

@parts = split(/[/-]/, $DATE_RESOLVED);

my $new_date = RT::Date->new($RT::SystemUser);

$new_date = sprintf("%d-%02d-%02d 0:00:00", $parts[2] + 2000,

$parts[0], $parts[1]);

$DATE_RESOLVED = $new_date->ISO;

$DATE_RESOLVED->Set(Format=>‘unix’, Value=>$new_date);

$DATE_RESOLVED = $new_date;

}

print "Resolved Date - ", $DATE_RESOLVED, ’ '; #debug

build ticket values

%ticket_vals =
(
    Subject => $ISSUE_DESCRIPTION,
    MIMEObj => $mimeObj,
    Creator => 4233,   #API bug won't look up corresponding id for name
    Owner => 4233,
    Requestor => 4233,
    Queue => 14,
    Priority => 3,
    InitialPriority => 3,
    FinalPriority => 3,
    Created => $DATE_OPENED,
    Started => $DATE_OPENED,
    LateUpdated => $DATE_RESOLVED,
    Resolved => $DATE_RESOLVED,
    Status => ( "resolved" )
);

( $ticketid, $transaction_object, $err ) = $ticket->Create( 

%ticket_vals );
print “New_Ticket request=”, $NUMBER, " $err \n"; #debug
die “New_Ticket Error: $err \n” unless $ticketid;

( $rc, $err ) = $ticket->AddCustomFieldValue( Field => 

‘Description’, Value => $ISSUE_DESCRIPTION );
( $rc, $err ) = $ticket->AddCustomFieldValue( Field => ‘Reference
Number’, Value => $NUMBER );
( $rc, $err ) = $ticket->AddCustomFieldValue( Field => ‘Travel-Area
of System’, Value => $SYSTEM_AREA );
( $rc, $err ) = $ticket->AddCustomFieldValue( Field => ‘Work-State’,
Value => “Resolved” );
( $rc, $err ) = $ticket->AddCustomFieldValue( Field => ‘Resolution
Type’, Value => $REQUEST_TYPE );
( $rc, $err ) = $ticket->AddCustomFieldValue( Field => ‘Resolution
Description’, Value => $RESOLUTION );

return $ticketid;     #Ticket.id

}

main

my
(
$fh,
$fname
);

RT::LoadConfig();
RT::Init();

$fname = ‘/var/tmp/rt-travel-data.txt.20090817.001.12rec’; #your
input file name here
$fh = IO::File->new( “$fname” ) or die “cannot open $fname $!\n”;
Read_Temp_File( $fh );
$fh->close();

I can’t, for the life of me, see the problem. Of course, you can see by
the “Date Re-formatting” code that is commented out, that I just may not
know what the hell I am doing.

Can anyone PLEASE help me?

Thanks.

Kenn
LBNL

I’m in a mess trying to figure out why RT:API will NOT put dates in the
Ticket record when I read an input file.
It’s a known “feature” of RT e.g;
Carbon60: Managed Cloud Services

I’m in a mess trying to figure out why RT:API will NOT put dates in the
Ticket record when I read an input file.
It’s a known “feature” of RT e.g;
Carbon60: Managed Cloud Services

You absolutely can set dates on tickets during import, otherwise the
RT2-to-RT3 and RT1-to-RT3 importers wouldn’t be able to backdate
history. You’re talking about changing an existing Transaction, which
is indeed blocked but worked around rather trivially as needed.

-kevin

Kevin,

If I understand what you and Jerrad are saying is that RT/API NORMALLY
puts a date in those fields and if I am going to override, I need to
code a work-around. Thank you. AT least I Know I’m not going crazy
(yet). So, any hints (like code-type stuff :wink: on that work-around?

Kenn
LBNLOn 8/26/2009 6:35 AM, Kevin Falcone wrote:

On Tue, Aug 25, 2009 at 07:25:00PM -0400, Jerrad Pierce wrote:

I’m in a mess trying to figure out why RT:API will NOT put dates in the
Ticket record when I read an input file.

It’s a known “feature” of RT e.g;
Carbon60: Managed Cloud Services

You absolutely can set dates on tickets during import, otherwise the
RT2-to-RT3 and RT1-to-RT3 importers wouldn’t be able to backdate
history. You’re talking about changing an existing Transaction, which
is indeed blocked but worked around rather trivially as needed.

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

If I understand what you and Jerrad are saying is that RT/API NORMALLY puts a date in those
fields and if I am going to override, I need to code a work-around. Thank you. AT least I Know
I’m not going crazy (yet). So, any hints (like code-type stuff :wink: on that work-around?

Kenn

What I said was that what you’re trying to do is absolutely doable and
I pointed you to two programs that already do it and have the proper
formatting code (namely the rt1-to-rt3 and rt2-to-rt3 converters, both
available on cpan, the rt1 converter may be a bit cleaner)

Also, you don’t have to CC, I read the list and set Reply-To
explicitly

-kevin

Kevin,

Got it. Thanks.

Kenn
LBNLOn 8/26/2009 8:30 AM, Kevin Falcone wrote:

On Wed, Aug 26, 2009 at 08:25:40AM -0700, Ken Crocker wrote:

If I understand what you and Jerrad are saying is that RT/API NORMALLY puts a date in those
fields and if I am going to override, I need to code a work-around. Thank you. AT least I Know
I’m not going crazy (yet). So, any hints (like code-type stuff :wink: on that work-around?

Kenn

What I said was that what you’re trying to do is absolutely doable and
I pointed you to two programs that already do it and have the proper
formatting code (namely the rt1-to-rt3 and rt2-to-rt3 converters, both
available on cpan, the rt1 converter may be a bit cleaner)

Also, you don’t have to CC, I read the list and set Reply-To
explicitly

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Kevin,

I hate to bug you, but I went to your link and saw some code. I’m not a
big perl guy (I can code some simple scrips, etc.) so some of it
confuses me. Attached is the program I’ve been speaking of. I put what I
thought would be the correct code in it (“set Date Fields”).
It is not working. Before I added that “set Date Fields” section, the
program would run, but the date fields remained empty, except the
resolved date and that would have today’s date.
Could you please look at it and show me what I did wrong? Thanks.

Kenn
LBNLOn 8/26/2009 6:35 AM, Kevin Falcone wrote:

On Tue, Aug 25, 2009 at 07:25:00PM -0400, Jerrad Pierce wrote:

I’m in a mess trying to figure out why RT:API will NOT put dates in the
Ticket record when I read an input file.

It’s a known “feature” of RT e.g;
Carbon60: Managed Cloud Services

You absolutely can set dates on tickets during import, otherwise the
RT2-to-RT3 and RT1-to-RT3 importers wouldn’t be able to backdate
history. You’re talking about changing an existing Transaction, which
is indeed blocked but worked around rather trivially as needed.

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

RT-TravelConversion_pgm.plx (4.46 KB)

Kevin,

I hate to bug you, but I went to your link and saw some code. I’m not a big perl guy (I can
code some simple scrips, etc.) so some of it confuses me. Attached is the program I’ve been
speaking of. I put what I thought would be the correct code in it (“set Date Fields”).
It is not working. Before I added that “set Date Fields” section, the program would run, but
the date fields remained empty, except the resolved date and that would have today’s date.
Could you please look at it and show me what I did wrong? Thanks.

Ken

You’re not providing any data or logging or error messages
I suggest you warn out the original date, the processed date, the ISO
date and turn your debugging logs on. You also probably want to start
by getting ticket Create working with hardcoded date strings and then
move on to processing your data.

-kevin

Kevin,

My log has been on and it gives no errors. This is it (for a small file
for testing):

-bash-3.00$ ./RT-TravelConversion.pl
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 35.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Subroutine Connect redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 90.
Subroutine BuildDSN redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line
121.
New_Ticket request=1 Ticket 87287 created in queue ‘FS-Travel’
New_Ticket request=2 Ticket 87288 created in queue ‘FS-Travel’
New_Ticket request=4 Ticket 87289 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87290 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87291 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87292 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87293 created in queue ‘FS-Travel’
New_Ticket request=6 Ticket 87294 created in queue ‘FS-Travel’
New_Ticket request=7 Ticket 87295 created in queue ‘FS-Travel’
New_Ticket request=8 Ticket 87296 created in queue ‘FS-Travel’
New_Ticket request=9 Ticket 87297 created in queue ‘FS-Travel’
New_Ticket request=10 Ticket 87298 created in queue ‘FS-Travel’
-bash-3.00$

Nothing in those messages syas I have a code problem or anything. You
have the code (attached in last note). The code seems simple enough, I
just can’t seem to see the problem.

Kenn
LBNLOn 8/27/2009 7:14 AM, Kevin Falcone wrote:

On Wed, Aug 26, 2009 at 01:50:36PM -0700, Ken Crocker wrote:

Kevin,

I hate to bug you, but I went to your link and saw some code. I’m not a big perl guy (I can
code some simple scrips, etc.) so some of it confuses me. Attached is the program I’ve been
speaking of. I put what I thought would be the correct code in it (“set Date Fields”).
It is not working. Before I added that “set Date Fields” section, the program would run, but
the date fields remained empty, except the resolved date and that would have today’s date.
Could you please look at it and show me what I did wrong? Thanks.

Ken

You’re not providing any data or logging or error messages
I suggest you warn out the original date, the processed date, the ISO
date and turn your debugging logs on. You also probably want to start
by getting ticket Create working with hardcoded date strings and then
move on to processing your data.

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Kevin,

My log has been on and it gives no errors. This is it (for a small file for testing):

-bash-3.00$ ./RT-TravelConversion.pl
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 35.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Subroutine Connect redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 90.
Subroutine BuildDSN redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 121.
New_Ticket request=1 Ticket 87287 created in queue ‘FS-Travel’
New_Ticket request=2 Ticket 87288 created in queue ‘FS-Travel’
New_Ticket request=4 Ticket 87289 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87290 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87291 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87292 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87293 created in queue ‘FS-Travel’
New_Ticket request=6 Ticket 87294 created in queue ‘FS-Travel’
New_Ticket request=7 Ticket 87295 created in queue ‘FS-Travel’
New_Ticket request=8 Ticket 87296 created in queue ‘FS-Travel’
New_Ticket request=9 Ticket 87297 created in queue ‘FS-Travel’
New_Ticket request=10 Ticket 87298 created in queue ‘FS-Travel’
-bash-3.00$

Nothing in those messages syas I have a code problem or anything. You have the code (attached
in last note). The code seems simple enough, I just can’t seem to see the problem.

Kenn

What happened when you started warning out your data and the converted
data that you’re handing to Create? What happened when you modified
your code to use a hardcoded date in a known-good format? (As
suggested in my response)

You’re not providing any data or logging or error messages
I suggest you warn out the original date, the processed date, the ISO
date and turn your debugging logs on. You also probably want to start
by getting ticket Create working with hardcoded date strings and then
move on to processing your data.

-kevin

Kevin,

When I used “hard-coded” dates this is what I get:

-bash-3.00$ ./RT-TravelConversion.pl
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 35.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Subroutine Connect redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 90.
Subroutine BuildDSN redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line
121.
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=1 Ticket 87299 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=2 Ticket 87300 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=4 Ticket 87301 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=5 Ticket 87302 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=5 Ticket 87303 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=5 Ticket 87304 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=5 Ticket 87305 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=6 Ticket 87306 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=7 Ticket 87307 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=8 Ticket 87308 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=9 Ticket 87309 created in queue ‘FS-Travel’
Open Date - 2009-08-27 0:00:00 Resolved Date - 2009-08-01
0:00:00New_Ticket request=10 Ticket 87310 created in queue ‘FS-Travel’
-bash-3.00$

The relevant code was:

Set Dates

 $opened = '2009-08-27 0:00:00';
 $resolved = '2009-08-01 0:00:00';

AND

%ticket_vals =
(
    Subject => $ISSUE_DESCRIPTION,
    MIMEObj => $mimeObj,
    Creator => 4233,   #API bug won't look up corresponding id for name
    Owner => 4233,
    Requestor => 4233,
    Queue => 14,
    Priority => 3,
    InitialPriority => 3,
    FinalPriority => 3,
    Started => $opened,
    Resolved => $resolved,
    Status => ( "resolved" )
);

( $ticketid, $transaction_object, $err ) = $ticket->Create( 

%ticket_vals );
print "Open Date - ", $opened, " Resolved Date - “, $resolved;
print “New_Ticket request=”, $NUMBER, " $err \n”; #debug
die “New_Ticket Error: $err \n” unless $ticketid;

The resulting tickets had nothing in the two date fields I was trying to
set and the current date in “Created” & “LastUpdated”. In my code, you
can see I “hard-coded” a date/time and it displayed from $opened &
$resolved, yet nothing in the record.

I don’t know what you mean by “warning out”. Do you mean just not put
anything in the fields with code?

Kenn
LBNLOn 8/27/2009 9:18 AM, Kevin Falcone wrote:

On Thu, Aug 27, 2009 at 08:52:21AM -0700, Ken Crocker wrote:

Kevin,

My log has been on and it gives no errors. This is it (for a small file for testing):

-bash-3.00$ ./RT-TravelConversion.pl
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 35.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Subroutine Connect redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 90.
Subroutine BuildDSN redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 121.
New_Ticket request=1 Ticket 87287 created in queue ‘FS-Travel’
New_Ticket request=2 Ticket 87288 created in queue ‘FS-Travel’
New_Ticket request=4 Ticket 87289 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87290 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87291 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87292 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87293 created in queue ‘FS-Travel’
New_Ticket request=6 Ticket 87294 created in queue ‘FS-Travel’
New_Ticket request=7 Ticket 87295 created in queue ‘FS-Travel’
New_Ticket request=8 Ticket 87296 created in queue ‘FS-Travel’
New_Ticket request=9 Ticket 87297 created in queue ‘FS-Travel’
New_Ticket request=10 Ticket 87298 created in queue ‘FS-Travel’
-bash-3.00$

Nothing in those messages syas I have a code problem or anything. You have the code (attached
in last note). The code seems simple enough, I just can’t seem to see the problem.

Kenn

What happened when you started warning out your data and the converted
data that you’re handing to Create? What happened when you modified
your code to use a hardcoded date in a known-good format? (As
suggested in my response)

You’re not providing any data or logging or error messages
I suggest you warn out the original date, the processed date, the ISO
date and turn your debugging logs on. You also probably want to start
by getting ticket Create working with hardcoded date strings and then
move on to processing your data.

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Nothing in those messages syas I have a code problem or anything. You
have the code (attached
in last note). The code seems simple enough, I just can’t seem to see the
problem.
No he means using warn($data) so that it gets logged

Cambridge Energy Alliance: Save money. Save the planet.

Jerrad,

I still do not understand. I’m not much at Perl, so I don’t know how to
translate that term into a line of code. I printed out the values but I
have no idea of how to “warn” a data field.

Kenn
LBNLOn 8/27/2009 11:02 AM, Jerrad Pierce wrote:

Nothing in those messages syas I have a code problem or anything. You
have the code (attached
in last note). The code seems simple enough, I just can’t seem to see the
problem.

No he means using warn($data) so that it gets logged

Kevin, Jerrad,

In the beginning of my program, I have this:

use strict;

use lib “/apps/rt/rt/perl/lib”;
use lib “/apps/rt/rt/lib”;

use RT;
use RT::Ticket;
use RT::Transaction;
use RT::Attachment;
use MIME::Entity;

Do I need something else? Like :use RT::Date;" or something like that?

Kenn
LBNLOn 8/27/2009 9:18 AM, Kevin Falcone wrote:

On Thu, Aug 27, 2009 at 08:52:21AM -0700, Ken Crocker wrote:

Kevin,

My log has been on and it gives no errors. This is it (for a small file for testing):

-bash-3.00$ ./RT-TravelConversion.pl
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 35.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Use of uninitialized value in concatenation (.) or string at
/apps/rt/rt-3.6.4/etc/RT_SiteConfig.pm line 47.
Subroutine Connect redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 90.
Subroutine BuildDSN redefined at /apps/rt/rt/lib/RT/Handle_Local.pm line 121.
New_Ticket request=1 Ticket 87287 created in queue ‘FS-Travel’
New_Ticket request=2 Ticket 87288 created in queue ‘FS-Travel’
New_Ticket request=4 Ticket 87289 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87290 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87291 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87292 created in queue ‘FS-Travel’
New_Ticket request=5 Ticket 87293 created in queue ‘FS-Travel’
New_Ticket request=6 Ticket 87294 created in queue ‘FS-Travel’
New_Ticket request=7 Ticket 87295 created in queue ‘FS-Travel’
New_Ticket request=8 Ticket 87296 created in queue ‘FS-Travel’
New_Ticket request=9 Ticket 87297 created in queue ‘FS-Travel’
New_Ticket request=10 Ticket 87298 created in queue ‘FS-Travel’
-bash-3.00$

Nothing in those messages syas I have a code problem or anything. You have the code (attached
in last note). The code seems simple enough, I just can’t seem to see the problem.

Kenn

What happened when you started warning out your data and the converted
data that you’re handing to Create? What happened when you modified
your code to use a hardcoded date in a known-good format? (As
suggested in my response)

You’re not providing any data or logging or error messages
I suggest you warn out the original date, the processed date, the ISO
date and turn your debugging logs on. You also probably want to start
by getting ticket Create working with hardcoded date strings and then
move on to processing your data.

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Kevin,

When I used “hard-coded” dates this is what I get:

Kenn

I just wrote and ran this:

my ($id, $msg) = $Ticket->Create( Queue => ‘General’,
Subject => ‘test manual creation’,
Started => ‘2009-08-01 06:10:11’,
Resolved => ‘2009-08-02 06:12:13’,
Created => ‘2009-08-01 05:00:00’ );

(4 hour offset caused by the internal GMTness of the API)

Created: Sat Aug 01 01:00:00 2009
Starts: Not set
Started: Sat Aug 01 02:10:11 2009
Last Contact: Not set
Due: Not set
Closed: Sun Aug 02 02:12:13 2009

LastUpdated is special cased and you’ll have to bludgeon it a bit with
__Set, but you should concentrate on what your Resolved isn’t working

-kevin

Kevin,

OK. I changed the code to this:

build ticket values

%ticket_vals =
(
    Subject => $ISSUE_DESCRIPTION,
    MIMEObj => $mimeObj,
    Creator => 4233,   #API bug won't look up corresponding id for name
    Owner => 4233,
    Requestor => 4233,
    Queue => 14,
    Priority => 3,
    InitialPriority => 3,
    FinalPriority => 3,
    Started => '2009-08-01 0:00:00',
    Resolved => '2009-08021 0:00:00',
    Status => ( "resolved" )
);

( $ticketid, $transaction_object, $err ) = $ticket->Create( 

%ticket_vals );

print "Open Date - ", $opened, " Resolved Date - ", $resolved;

print "New_Ticket request=", $NUMBER, " $err \n";  #debug
die "New_Ticket Error: $err \n"   unless $ticketid;

return $ticketid;     #Ticket.id

}

I put literal “hard-coded” values in it instead of in an object and that
didn’t work either.

Still nulls in both the date fields (Started, Resolved) I’m trying to
fill and no errors.

Kenn
LBNLOn 8/27/2009 11:27 AM, Kevin Falcone wrote:

On Thu, Aug 27, 2009 at 10:58:52AM -0700, Ken Crocker wrote:

Kevin,

When I used “hard-coded” dates this is what I get:

Kenn

I just wrote and ran this:

my ($id, $msg) = $Ticket->Create( Queue => ‘General’,
Subject => ‘test manual creation’,
Started => ‘2009-08-01 06:10:11’,
Resolved => ‘2009-08-02 06:12:13’,
Created => ‘2009-08-01 05:00:00’ );

(4 hour offset caused by the internal GMTness of the API)

Created: Sat Aug 01 01:00:00 2009
Starts: Not set
Started: Sat Aug 01 02:10:11 2009
Last Contact: Not set
Due: Not set
Closed: Sun Aug 02 02:12:13 2009

LastUpdated is special cased and you’ll have to bludgeon it a bit with
__Set, but you should concentrate on what your Resolved isn’t working

-kevin


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

You resolved date has a typo (zero instead of dash)

But maybe try banging around with it for awhile rather than giving us
the play by play?

As for warning out, reread my previous message, I explained what I was
and gave you
code to do it. It’s not high-tech, but liberal prints (or warns for
stuff running under Apache)
are a good way to track down problems.
Cambridge Energy Alliance: Save money. Save the planet.

Jerrad,

DUH!! I changed it, same results.

By the way, When I look for results, I use both SQL Navigator to look at
the records in the database (dates always show January 1970) AND I also
use RT Query and the dates are alway “Not Set”.

Kenn
LBNLOn 8/27/2009 11:44 AM, Jerrad Pierce wrote:

You resolved date has a typo (zero instead of dash)

But maybe try banging around with it for awhile rather than giving us
the play by play?

As for warning out, reread my previous message, I explained what I was
and gave you
code to do it. It’s not high-tech, but liberal prints (or warns for
stuff running under Apache)
are a good way to track down problems.