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
PTSO of Washington
"Shared Technology for Community Health"
(206) 613-8938 Desk
(206) 521-8833 Main
(206) 613-5078 Fax
firstname.lastname@example.orgFrom: Kenneth Crocker [mailto:KFCrocker@lbl.gov]
Sent: Wednesday, April 09, 2008 9:23 AM
To: Stephen Turner
Cc: Aaron Sallade; email@example.com
Subject: Re: [rt-users] imports with the offline tool not taking
You could also just import them into a special queue (or have
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.
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
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:
So when these ‘resolved’ tickets are loaded, RT will first create then
resolve them. When it resolves them, the scrip will cause it to
update the resolved date to what you put in the Starts date. It will
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.
Senior Programmer/Analyst - SAIS
MIT Information Services and Technology (IS&T)
Community help: http://wiki.bestpractical.com
Commercial support: firstname.lastname@example.org
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com