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

[Jim Meyer]

Hello!

Two questions:

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.

2. Any secrets for disabling all notifications without disabling
   all scrips? For that matter, any secrets for disabling all
   scrips for a given transaction?

If your first response is, "It depends ..." or "What are you trying to
accomplish, please read further. Otherwise, please stop here. =]

I'm looking at how we'd port data from an in-house tracking system
(we'll call it IH for short) to RT. Fortunately, the schema for IH is
very straightforward, using tables which are loosely analogous to
Tickets, Transactions, and Users. Unfortunately I'll need to pull some
of the data into the live instance so people can play with it, then more
when they like what they see.

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
same data twice. To accomplish the latter, I expect to create a table
used for caching correlations between any given IH object (e.g. a user,
a ticket, etc.) and its RT equivalent. I'm hoping it'll look something
like this:

  create table ih2rt ih_id int, 
                     ih_inst int,
                     ih_table varchar(32),
                     rt_objectid int, 
                     rt_objecttype varchar(25);

The "ih_+*" columns are what it would take to uniquely identify a thing
(e.g. ticket, transaction, or user) in IH; the rt_* columns are meant to
emulate the Attributes and CustomFields tables' method of referencing an
RT object. This way I can cache the correspondence between unique
entities in IH and RT and choose to update the existing RT object rather
than create a new one.

And now you know. =]

Thanks!

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