Porting data from in-house solution to RT

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@acm.org

At Tuesday 3/7/2006 07:34 PM, Jim Meyer wrote:

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.

Hello Jim,

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?
  1. 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.

Steve

Hello!

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.

  1. 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@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@acm.org

At Wednesday 3/8/2006 12:08 PM, Jim Meyer wrote:

I’d be very interested in that code for reasons extending beyond this
challenge, so if you’ve the time, please do.

Jim,

I posted this contrib to the wiki:

http://wiki.bestpractical.com/index.cgi?SuppressOutgoingMail

Steve

Is it possible to add History to the various fields returned when you do a
search using Query Builder? We are trying to dump this info to a
spreadsheet using the spreadsheet link.

This is for RT version 3.4.1

Regards,

Marco A Moreno

At Wednesday 3/8/2006 12:08 PM, Jim Meyer wrote:

I’d be very interested in that code for reasons extending beyond this
challenge, so if you’ve the time, please do.

Jim,

I posted this contrib to the wiki:

http://wiki.bestpractical.com/index.cgi?SuppressOutgoingMail
This only needed when you couldn’t stop RT, but when you can stop it
you just can change config options $MailCommand to “sendmailpipe” and
$SendmailPath to “/bin/true”.

Steve


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Best Practical is hiring! Come hack Perl for us: http://bestpractical.com/about/jobs.html

Best regards, Ruslan.

At Wednesday 3/8/2006 12:08 PM, Jim Meyer wrote:

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.

Hello Jim,

Our transfers of data from our legacy system to RT have been one-time
processes. In other words, once we transfer a ticket to RT, it’s live in
RT and “frozen” or inactive in the old system. We haven’t had a need to
keep the two systems in synch, so we don’t have any experience that would
help you in that regard.

Our mapping of old to new ticket id is just so when an email reply is sent
to a ticket that originated in the old system, we can append it to the
correct new RT ticket.

Good luck!
Steve

Hello!

Our transfers of data from our legacy system to RT have been one-time
processes. In other words, once we transfer a ticket to RT, it’s live in
RT and “frozen” or inactive in the old system. We haven’t had a need to
keep the two systems in synch, so we don’t have any experience that would
help you in that regard.

Good to hear. We like to dip our toes until someone pushes us into the
pond around here. ;]

Our mapping of old to new ticket id is just so when an email reply is sent
to a ticket that originated in the old system, we can append it to the
correct new RT ticket.

I’m somewhat fortunate in that our old system didn’t allow incoming
email correspondence, so once we shut down the web UI we’re done.
However, you’ve made me consider what it still honor the old systems’
URLs (which are included in each email it sends) … and which shouldn’t
be too hard to manage.

Thanks again!

–j
Jim Meyer, Geek at Large purp@acm.org