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.
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
create table ih2rt ih_id int,
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. =]
Jim Meyer, Geek at Large email@example.com