Retroactive scrip-ing

I have queues, CFs, scrips and such set up more or less the way i want
them. For now. Until the department heads get back to me again.

While configging things, i collected about 10k tickets into the
General queue in various stages of completeness. Other queues weren’t
set up yet, CFs weren’t being captured, etc. etc., so they remain in
General with empty CFs.

What would be the least-painful way of running all 10k of them thru
the system as if they were being created, i.e. having all scrips apply
to them now that we would have wanted when they came it?

Thanks,
Rob

/chown -R us:us /yourbase

I think I’d write a perl script to read each ticket and then e-mail it back
to RT. Not very elegant and a significant bump in your mail server’s
workload, but you know that they would all be treated as new tickets. This
should be a pretty trivial script to write using the API.

Gene

At 08:14 AM 2/13/2009, Rob Munsch wrote:

I have queues, CFs, scrips and such set up more or less the way i want
them. For now. Until the department heads get back to me again.

While configging things, i collected about 10k tickets into the
General queue in various stages of completeness. Other queues weren’t
set up yet, CFs weren’t being captured, etc. etc., so they remain in
General with empty CFs.

What would be the least-painful way of running all 10k of them thru
the system as if they were being created, i.e. having all scrips apply
to them now that we would have wanted when they came it?

Thanks,
Rob


/chown -R us:us /yourbase


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

Gene LeDuc, GSEC
Security Analyst
San Diego State University

forgot to cc the list again :stuck_out_tongue: itchy send finger, sorry Gene.On Fri, Feb 13, 2009 at 11:41 AM, Gene LeDuc gleduc@mail.sdsu.edu wrote:

I think I’d write a perl script to read each ticket and then e-mail it back
to RT. Not very elegant and a significant bump in your mail server’s
workload, but you know that they would all be treated as new tickets. This
should be a pretty trivial script to write using the API.

Mail server’s not working very hard right now, so that shouldn’t be a problem.

If i follow this right, this will create a new set of tickets with
what i want, but the originals will still remain as-is, yes? I
suppose i could destroy the originals after i verify it worked.

Thanks, i’ll take a poke at this.

/chown -R us:us /yourbase

If i follow this right, this will create a new set of tickets with
what i want, but the originals will still remain as-is, yes? I
suppose i could destroy the originals after i verify it worked.
Better to merge I should think, if you’re going this route.
Especially since you’re also going to be sending out lots of
requestor notifications, which could be potentially confusing
e.g; “It’s already done, why are you bugging me again?” or
replying to an old message with the old ticket ID.

Cambridge Energy Alliance: Save money. Save the planet.

In the latest RT rt-crontool can be used for this. It has transaction
and transaction-type arguments that can be very helpful, for example
you can apply an action on all corresponds in tickets matching some
search query and/or condition.

However, you must understand that if your action changes a ticket then
dates will be updated what can be undesired. I think linear escalation
action in RT can give you hints on silencing updates.On Fri, Feb 13, 2009 at 7:14 PM, Rob Munsch rob.munsch@gmail.com wrote:

I have queues, CFs, scrips and such set up more or less the way i want
them. For now. Until the department heads get back to me again.

While configging things, i collected about 10k tickets into the
General queue in various stages of completeness. Other queues weren’t
set up yet, CFs weren’t being captured, etc. etc., so they remain in
General with empty CFs.

What would be the least-painful way of running all 10k of them thru
the system as if they were being created, i.e. having all scrips apply
to them now that we would have wanted when they came it?

Thanks,
Rob


/chown -R us:us /yourbase


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

Best regards, Ruslan.

Disable all scrips that send correspondence, go one step further and
shut down your MTA (so that mail sent in will try again later), use the
API to re-run those transactions, re-enable scrips, start the MTA back
up. No emailings, no fuss.

Jerrad Pierce wrote:

If i follow this right, this will create a new set of tickets with
what i want, but the originals will still remain as-is, yes? I
suppose i could destroy the originals after i verify it worked.

Better to merge I should think, if you’re going this route.
Especially since you’re also going to be sending out lots of
requestor notifications, which could be potentially confusing
e.g; “It’s already done, why are you bugging me again?” or
replying to an old message with the old ticket ID.

Drew Barnes
Applications Analyst
Network Resources Department
Raymond Walters College
University of Cincinnati

use the API to re-run those transactions

I have to confess, after some time googling and looking over the wiki,
that i cannot figure out how to do that :(.

/chown -R us:us /yourbase

If you speak perl, I’ll be happy to send you a copy of a script we use that
would illustrate getting ticket info using the API. If you don’t speak
perl, then I wouldn’t recommend learning it with this script or this project.

At 02:17 PM 2/13/2009, Rob Munsch wrote:>On Fri, Feb 13, 2009 at 1:48 PM, Drew Barnes barnesaw@ucrwcu.rwc.uc.edu wrote:

use the API to re-run those transactions

I have to confess, after some time googling and looking over the wiki,
that i cannot figure out how to do that :(.


/chown -R us:us /yourbase

Gene LeDuc, GSEC
Security Analyst
San Diego State University

I speak it well enough to modify things, so far. I wouldn’t call
myself fluent, but i can more than copy-paste code. I’d love to see
it. This system isn’t in production yet, so i don’t mind potential
breakage trying to get something to work. Thanks!On Fri, Feb 13, 2009 at 6:18 PM, Gene LeDuc gleduc@mail.sdsu.edu wrote:

If you speak perl, I’ll be happy to send you a copy of a script we use that
would illustrate getting ticket info using the API. If you don’t speak
perl, then I wouldn’t recommend learning it with this script or this
project.

At 02:17 PM 2/13/2009, Rob Munsch wrote:

On Fri, Feb 13, 2009 at 1:48 PM, Drew Barnes barnesaw@ucrwcu.rwc.uc.edu wrote:

use the API to re-run those transactions

I have to confess, after some time googling and looking over the wiki,
that i cannot figure out how to do that :(.


/chown -R us:us /yourbase


Gene LeDuc, GSEC
Security Analyst
San Diego State University

/chown -R us:us /yourbase