[rt-users] imports with the offline tool not taking resolved date

Aaron Sallade asallade at PTSOWA.ORG
Wed Apr 9 12:29:55 EDT 2008


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 at ptsowa.org

-----Original Message-----
From: Kenneth Crocker [mailto:KFCrocker at lbl.gov] 
Sent: Wednesday, April 09, 2008 9:23 AM
To: Stephen Turner
Cc: Aaron Sallade; rt-users at 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

On 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)
> 
> 
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
> 




More information about the rt-users mailing list