[Rt-devel] Porting data from in-house solution to RT

[Jim Meyer]

Hello!

On Wed, 2006-03-08 at 10:06 -0500, Stephen Turner wrote:
> At Tuesday 3/7/2006 07:34 PM, Jim Meyer wrote:
> >1. Is there a good, general way to construct and manipulate
> >    those object-type-and-id references (cf the Attributes table,
> >    with objecttype of "RT::User" and objectid matching the id in
> >    the Users table, for example) in the API? I've not stumbled
> >    upon it yet, but I've not spent a lot of time in those portions
> >    of the code.
> 
> We've managed by just mapping old-system-ticket-number to RT ticket number 
> - would that not suffice? How many different object types are you thinking 
> of working with?

I intend to map IH user to RT user, IH ticket to RT ticket, and even IH
transaction to RT Transaction. This allows me to do a warm start of IH
data into RT where people play with it while continuing to work the
issue in IH ... and then I can grab only updated transactions from IH
for a given ticket without stepping on any RT-only transactions. I also
can't help but think I'll gain benefits I don't immediately recognize by
making the correspondence between IH and RT as fine-grained as possible.

One complexity I considered irrelevant earlier is that, while the IH
interface is single queued, we run multiple instances all of whose data
is stored in a single database. Adoption of RT and thus migration from
IH to RT will go queue by queue, so this process needs to be repeatable.
Additionally, we've got multiple databases, so I can't guarantee that a
given user's id number is the same in both databases.

That said, would you disagree? You have concrete experience in this
which I sorely lack. I'd truly enjoy the benefit of your thoughts on
this.

> >2. Any secrets for disabling all notifications without disabling
> >    all scrips? For that matter, any secrets for disabling all
> >    scrips for a given transaction?
> 
> We did this by introducing a new RT config variable 'MailSendingOff' and 
> making the outgoing-mail part of the API recognize this flag. Our data load 
> scripts always set this flag to true so that mail is never sent when data 
> is loaded, while the regular web/email interface sends mail as normal.
> 
> I'll put this code up on the wiki if you're interested.

I'd be very interested in that code for reasons extending beyond this
challenge, so if you've the time, please do. Meanwhile, I got this from
Alexander Finger:

On Wed, 2006-03-08 at 09:44 +0100, Alexander Finger <af at syd.de> wrote: 
> I had to receive tickets from Lotus Notes from an external supplier, 
> facing similar situations;
> 
> > The two biggest challenges for me in this are (1) load all the data
> > through the API generating no notifications; and, (2) don't load the
> 
> I had notifications not activated on the respective queues. "On Create" 
> is the one which is significant for you and afaik it's not set for 
> queues by default anyways.

This suggested an alternative approach which could work for me: load
into a queue which has no notifications, then silently change the queue
setting. Much more straightforward than silencing everything, I think,
and we have a CF that tracks queue of origin which I could (ab)use in
this case by setting it to the destination queue. From there it's a
trivial operation to quietly move everything in the migration queue to
its queue of origin. =]

Thanks, Alexander and Stephen!

--j
-- 
Jim Meyer, Geek at Large                                    purp at acm.org