Dear All,
We have http://support.suretecsystems.com and our partners are about
to install there own RT.
They have accounts on our system and are admins of certain queues when
we do joint support.
The question is how can we get the tickets submitted into our system
into their new one but keep the same subjects, as they want the
history in their new one.
We were thinking about deleting their accounts and having a new user
with the e-mail of their queue, so when a ticket
comes in it sends it over to their RT. If we switch the autoreply
scrip off on their side as the customer will never e-mail them direct,
then that is fine. But their RT will create a new ticket.
Anyone is a similar position or should we just get them to admin in
our queue like we currently do?
Thanks.
http://www.suretecsystems.com/services/openldap/
Gavin,
From a control standpoint, I've always had a real problem with
redundancy unless there was a control to ensure automatic updating of
one by the other. If the method you use now is working, why change it?
Are they gonna use their RT for “other” requests that do not get into
your installation? If they are the Queue Admins of their queues in your
installation, is it their intent to continue that form of management
with those same queues or are they planning to just Admin their own RT
installation from here on in? If they want off your system completely,
then let them set up their RT for CommandByEmail and just have the
customers that send in requests send their new requests to the new
installation, managed by themselves with no redundancy in your system.
If, for some reason, they just want copies of their tickets in your RT,
then I suppose you could set up a scrip for their queues (in your RT) to
created a linked ticket (type=referred to/by) in their system and let
them deal with the redundant info and admin infrastructure. Those are
the only ideas I have on the issue that I feel are acceptable from a
management/responsibility/scapegoat perspective. ;-). Hope this helps.
Kenn
LBNLOn 7/1/2008 2:10 PM, Gavin Henry wrote:
Dear All,
We have http://support.suretecsystems.com and our partners are about
to install there own RT.
They have accounts on our system and are admins of certain queues when
we do joint support.
The question is how can we get the tickets submitted into our system
into their new one but keep the same subjects, as they want the
history in their new one.
We were thinking about deleting their accounts and having a new user
with the e-mail of their queue, so when a ticket
comes in it sends it over to their RT. If we switch the autoreply
scrip off on their side as the customer will never e-mail them direct,
then that is fine. But their RT will create a new ticket.
Anyone is a similar position or should we just get them to admin in
our queue like we currently do?
Thanks.
Gavin,
From a control standpoint, I've always had a real problem with
redundancy unless there was a control to ensure automatic updating of one by
the other. If the method you use now is working, why change it? Are they
gonna use their RT for “other” requests that do not get into your
installation? If they are the Queue Admins of their queues in your
installation, is it their intent to continue that form of management with
those same queues or are they planning to just Admin their own RT
installation from here on in? If they want off your system completely, then
let them set up their RT for CommandByEmail and just have the customers that
send in requests send their new requests to the new installation, managed by
themselves with no redundancy in your system. If, for some reason, they just
want copies of their tickets in your RT, then I suppose you could set up a
scrip for their queues (in your RT) to created a linked ticket
(type=referred to/by) in their system and let them deal with the redundant
info and admin infrastructure. Those are the only ideas I have on the issue
that I feel are acceptable from a management/responsibility/scapegoat
perspective. ;-). Hope this helps.
Thanks Kevin. Plenty to think about.
http://www.suretecsystems.com/services/openldap/