[rt-users] Virtual RT

[Jerry]

Many thanks for your response. What I was getting at was utilizing a single
DB for multiple Request instances, as opposed to apache instances. I was
thinking along the lines of a membership view where groups of members could
have their own "queue" I guess you would call it, and it could be managed
reasonably. I am thinking like a list server I am familiar with (lyris)
where any number of lists can be associated with a user and various domains
and email addresses can be used to manage the lists. When a list owner logs
in they see their lists, unique global and list configurations, etcetera.
List (queue) delivery is handled by the list application and not by the MTA.
That sort of thing. It looks like you have addressed all of this and more.
Jerry.

 

  _____  

From: rt-users-bounces at lists.bestpractical.com
[mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Adrian Carter
Sent: Monday, September 26, 2005 8:57 AM
To: Bob Goldstein; rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Virtual RT

 

Bob Goldstein wrote: 

   I just wanted to add something regarding my interpretations here.
   Yes, you can run Multiple Instances, *BUT*, and this is a 
*BIIIIIGGGGGG* but... Its *NOT* Virtual.
    

   I'm curious what you're driving at, and I'm not clear what
   "virtual" means in your context.
 
   You said you want different Signatures/Priorities/Templates
   between the virtual RTs.  I think you said you wanted
   different queues, users, and customer fields, too.
 
   You didn't say if you wanted completely independent *tickets*.
   Nor did you say if anything in the database should be held
   in common, or if you ever need to transfer tickets between
   virtual RTs.
  

Yeah, I realised that, and I also realised I sounded a bit like a demanding
person. I totally understand I have a bit of a unique proposal, hence why I
went to the length of getting Jesse to have an engineer look at it
commercially. I realise I could cobble it together using lots of nasty
hacks, but the multiple signature bit but common tickets and better 'access'
control is a bit of a major hack. Hence my attempts at getting the funds
authorised! :) :)

To try and clarify, I would have one mysql database with common tickets.
This also extends to a common RTFM, and for most Operators, (admins, which
we will call 'Operators') global access to queus labelled as (XYZ_Support,
XYZ_Admin, ABC_Support, ABC_Admin). They also require different signatures
based on which queue they are responding to or creating a ticket in.. XYZ or
ABC. If a ticket was to be 'migrated' to an alternative queue, previous
history can remain the same but obviously new responses can utilise the
appropriate signature. Then there is a subest of these operators, well call
them SecondaryOperators. These guys have privlidged access only to XYZ_* or
ABC_* independantly, but not both. They also need only their 'own' signature
(just one). Then there is 'Users', who can access their own tickets, and
only their own, regardless of what Queue it lives in. They also dont have
any signature, as their tickets are created via e-mail and their access is
designed soely for status checking and RTFM reference. 

RTFM Articles can be referenced by any operators, and accessed by any user.

Logo's also change based on SecondaryOperators (XYZ see's XYZ logo, ABC
see's ABC logo) but Operators need only see the 'primary' logo.

As stated, tickets would be 'global', so that searching for ticket contents
could be done globally by Operators, but searches by SecondaryOperators was
limited within XYZ or ABC queues.

Tickets would regularly probably 'escalate' and 'return' from XYZ or ABC to
the Primary Queues (just called say, Admin and Support with no prefixes). 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20050926/cbb1f2d2/attachment.htm>