The offline tool sets the Closed/Resolved timestamp to Now, instead of
taking the value from the import file. Any known work arounds?
Aaron Sallade’
Application Manager
PTSO of Washington
“Shared Technology for Community Health”
(206) 613-8938 Desk
(206) 521-8833 Main
(206) 613-5078 Fax
asallade@ptsowa.org
At Tuesday 4/8/2008 07:29 PM, Aaron Sallade wrote:
The offline tool sets the Closed/Resolved timestamp to Now, instead
of taking the value from the import file. Any known work arounds?
This is happening for tickets marked ‘resolved’ in the import file,
right? It appears that RT will set the resolved date to Now when it
sets the status to resolved, overriding any value you specify in the file.
We came up with a kludgey workaround, but it’s only good if a) this
is a one-time load process, not a regular event, and b) you don’t use
the ticket Starts date for anything.
Anyway, what we did is:
In the upload file, put the ‘resolved’ date in the Starts field
instead of Resolved.
For each queue you are loading, create the following scrip:
In the scrip’s “Custom action preparation code:” box, put:
return 0 unless $self->TicketObj->Starts;
In the scrip’s “Custom action cleanup code:” box, put:
$self->TicketObj->SetResolved($self->TicketObj->Starts);
$self->TicketObj->SetStarts(' ');
So when these ‘resolved’ tickets are loaded, RT will first create then
resolve them. When it resolves them, the scrip will cause it to immediately
update the resolved date to what you put in the Starts date. It will then
clear out the Starts date.
As I say, this really is only useful for a one-time load, for a queue
that isn’t “live” yet. You wouldn’t want this scrip to be active when
you are working with tickets day-to-day.
Steve
Stephen Turner
Senior Programmer/Analyst - SAIS
MIT Information Services and Technology (IS&T)
Stephen, Aaron,
You could also just import them into a special queue (or have some
other way of identifying them), then run a bulk update on them. After
that, you could put them wherever you want. That might be easier than
creating, testing, and then disableiing a scrip.
Kenn
LBNLOn 4/9/2008 6:25 AM, Stephen Turner wrote:
At Tuesday 4/8/2008 07:29 PM, Aaron Sallade wrote:
The offline tool sets the Closed/Resolved timestamp to Now, instead
of taking the value from the import file. Any known work arounds?This is happening for tickets marked ‘resolved’ in the import file,
right? It appears that RT will set the resolved date to Now when it
sets the status to resolved, overriding any value you specify in the file.We came up with a kludgey workaround, but it’s only good if a) this
is a one-time load process, not a regular event, and b) you don’t use
the ticket Starts date for anything.Anyway, what we did is:
In the upload file, put the ‘resolved’ date in the Starts field
instead of Resolved.For each queue you are loading, create the following scrip:
- Condition: On Resolve
- Action: User Defined
- Template: Global template: Blank
In the scrip’s “Custom action preparation code:” box, put:
return 0 unless $self->TicketObj->Starts;In the scrip’s “Custom action cleanup code:” box, put:
$self->TicketObj->SetResolved($self->TicketObj->Starts); $self->TicketObj->SetStarts(' ');So when these ‘resolved’ tickets are loaded, RT will first create then
resolve them. When it resolves them, the scrip will cause it to immediately
update the resolved date to what you put in the Starts date. It will then
clear out the Starts date.As I say, this really is only useful for a one-time load, for a queue
that isn’t “live” yet. You wouldn’t want this scrip to be active when
you are working with tickets day-to-day.Steve
Stephen Turner
Senior Programmer/Analyst - SAIS
MIT Information Services and Technology (IS&T)
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
I hacked the CreateTicket code. At the end of the subroutine it updates
dependencies for any links specified in the import template, then sets
the Status a second time. It does this because there may be unresolved
dependencies. Since none of the tickets we are importing have
dependencies, I commented out the second Status update in that section.
We now have Status = resolved and a Resolved date that is correct (not
== Now())
Aaron Sallade’
Application Manager
PTSO of Washington
“Shared Technology for Community Health”
(206) 613-8938 Desk
(206) 521-8833 Main
(206) 613-5078 Fax
asallade@ptsowa.orgFrom: Kenneth Crocker [mailto:KFCrocker@lbl.gov]
Sent: Wednesday, April 09, 2008 9:23 AM
To: Stephen Turner
Cc: Aaron Sallade; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] imports with the offline tool not taking
resolved date
Stephen, Aaron,
You could also just import them into a special queue (or have
some
other way of identifying them), then run a bulk update on them. After
that, you could put them wherever you want. That might be easier than
creating, testing, and then disableiing a scrip.
Kenn
LBNL
At Tuesday 4/8/2008 07:29 PM, Aaron Sallade wrote:
The offline tool sets the Closed/Resolved timestamp to Now, instead
of taking the value from the import file. Any known work arounds?This is happening for tickets marked ‘resolved’ in the import file,
right? It appears that RT will set the resolved date to Now when it
sets the status to resolved, overriding any value you specify in the
file.We came up with a kludgey workaround, but it’s only good if a) this
is a one-time load process, not a regular event, and b) you don’t use
the ticket Starts date for anything.Anyway, what we did is:
In the upload file, put the ‘resolved’ date in the Starts field
instead of Resolved.For each queue you are loading, create the following scrip:
- Condition: On Resolve
- Action: User Defined
- Template: Global template: Blank
In the scrip’s “Custom action preparation code:” box, put:
return 0 unless $self->TicketObj->Starts;In the scrip’s “Custom action cleanup code:” box, put:
$self->TicketObj->SetResolved($self->TicketObj->Starts); $self->TicketObj->SetStarts(' ');So when these ‘resolved’ tickets are loaded, RT will first create then
resolve them. When it resolves them, the scrip will cause it to
immediately
update the resolved date to what you put in the Starts date. It will
then
clear out the Starts date.As I say, this really is only useful for a one-time load, for a queue
that isn’t “live” yet. You wouldn’t want this scrip to be active when
you are working with tickets day-to-day.Steve
Stephen Turner
Senior Programmer/Analyst - SAIS
MIT Information Services and Technology (IS&T)
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Sorry, I know this is an older email Carbon60: Cloud Consulting - Services and Solutions
but I am trying to do this and have a question about what the last person suggests. I can’t find that code in the CreateTicket code like suggested, I am sure I just don’t know what I am looking at. Using RT 3.8.9.
Thanks for any help.