Transferring requests through multiple instances?

Hi,

We haven’t done this yet, but we was wondering if it’s possible to
transfer requests between instances from queue to queue, and not e-mail
forwarding the requests?

URL:http://wiki.bestpractical.com/index.cgi?MultipleInstances

It’s decided that we need multiple instances using RT 3.2.1, since we have
thousands of possible users in different departments who wants to run
their own instances. We guess it’s a need to transfer requests from one
instance to another.

BTW: Thanks to all who has replied on my LDAP questions. We are currently
working and testing our own hack that we will contribute later when it’s
finnished.

Tomas A. P. Olaj, email: tomas.olaj@usit.uio.no, web: folk.uio.no/tomaso
University of Oslo / USIT (Center for Information Technology Services)
System- and Application Management / Applications Management Group

Hi,

We haven’t done this yet, but we was wondering if it’s possible to
transfer requests between instances from queue to queue, and not e-mail
forwarding the requests?

URL:http://wiki.bestpractical.com/index.cgi?MultipleInstances

It’s decided that we need multiple instances using RT 3.2.1, since we have
thousands of possible users in different departments who wants to run
their own instances. We guess it’s a need to transfer requests from one
instance to another.

A separate instance, in the sense of that wiki article,
is a separate mysql database, and at the least, a
separate RT_SiteConfig.pm. So the only way to fully
transfer a request without using email would require
code to read both configs (so as to obtain the mysql
passwords) and then talk to both databases. But you
can’t really do that in a single process, since once
you ‘use RT’, you are commited to a single instance.
You’d have to have a driver process that forked/execed
a process to read the existing ticket info, and some
other fork/exec process to write that into the database
of the second instance. And then probably “resolve”
the ticket in the first instance. Instances are
really independent, so once transferred, any future
appends to the ticket in the second instance would
not be reflected in the data of the first instance.
Without custom fields and a bunch more code, once
the ticket is transferred, you’ve lost the connection
between tickets, so the guy that initiated the
transfer can’t find out what action was taken
on the ticket after the transfer.

If you really need to transfer tickets, I’d suggest
only a single instance. You can give some users
admin privs over some queues and not others. Just
that all users have to share the same code customizations.
(Actually, I suppose that’s not even true. You could
run multiple instances as the wiki suggests, but
have them all use the same mysql database. Wasn’t
my original intent, and I think that is way overkill,
but you could.)

I’ll tell you what I did, though. Some large groups
here use Clarify, but my group and a few others
much prefer RT. To get permission to run RT, I had
to make it easy enough for Clarify users to transfer
tickets to RT. Clarify does not provide source,
but they were able to trigger specially formatted
email to RT when tickets were dispatched to select queues.

I mod’ed RT to parse this email, to find the original
requestors, CC’s, subject, content, and ClarifyID.
Then RT creates a new RT ticket, using that info
to set RT variables, and keeping the ClarifyID
in a custom field. If an append is later posted
to the Clarify ticket, Clarify will send a different
special email to RT, and RT will append that to the
RT ticket.

A reverse transfer would be possible, but a bit
more intricate. Haven’t needed it yet.

I was going to publish those mods to the wiki, but
I’ve been too pressed for time so far. Still on my
list to do so.

   bobg