<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

Bob Goldstein wrote:

<blockquote cite="mid200509261534.j8QFYMAx020497@remora.cc.uic.edu"

 type="cite">

  <blockquote type="cite">

    <pre wrap="">   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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->   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.

  </pre>

</blockquote>

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! :) :)<br>

<br>

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. <br>

<br>

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

user.<br>

<br>

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.<br>

<br>

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.<br>

<br>

Tickets would regularly probably 'escalate' and 'return' from XYZ or

ABC to the Primary Queues (just called say, Admin and Support with no

prefixes). <br>

<blockquote cite="mid200509261534.j8QFYMAx020497@remora.cc.uic.edu"

 type="cite">

  <pre wrap="">

   If you want the RT items (users, tickets, queues, ...)

   separate, but you just want to minimize the admin cost of

   maintaining RT, then why not use different mysql databases

   (within the same mysql server/engine)? You would have each

   database dealt with by a separate set of fcgi processes, all

   running from the same code base on the same apache server. The

   "virtual" part would mean one apache install, one RT code

   install, one mysql install, but a separate RT_SiteConfig and

   separate mysql database per virtual RT. (After all, each

   virtual RT has to have something that is different.)

   However, if you don't want everything separate, then

   I'm really not clear on what parts are common and what parts

   are not.  For example, if the tickets are to be common,

   then are you suggesting that ticket #10 (uniquely identified

   among all virtual RTs) might be in Queue_xyz in RT_A

   and in Queue_abc in RT_B ?   If an admin for RT_A wanted

   to restrict privs to view a given queue, would that stop

   the admin for RT_B from assigning tickets in this queue

   to some public queue visibile in his virtual RT?

   I suppose this is idle curiosity, I'm just trying to

   understand what you are asking.

      bobg

  </pre>

  <blockquote type="cite">

    <pre wrap="">   Virtual infers you can run a common and SINGLE backend (ala say 

Apache) yet had numerous complete and independant configurations that 

all interact with that same common backend (just like <Virtual> tags 

inside that Apache config).

   Now, configuring FastCGI and setting lots of instances with slightly 

different RT_SiteConfigs etc is *not* a 'Virtual' solution, becuase the 

Database backend is common, and thus, the Queues, Users (Privelged, and 

worse Unprivliged) and Customer Fields etc etc are common.

   I have a classic scenario where I have techs working two completly 

seperately branded ISPs. This results in two completly seperate installs 

of RT due to the differing requirements for 

Signatures/Priorities/Templates . There is no way to maintain a common 

single database backend yet maintain seperate versions of these/

   Can you imagine having to setup complete independant versions of 

Apache for each Virtual Server??? Thats the difference between 

'multiple' and 'virtual'.

   Just my experience with RT. I ended up discussing this with Jesse at 

length, and it would in fact cost money (in the order of $1000's) to 

have such a system to support multiple signatures and multiple queues 

and privleges within one database instance (which it must do to be 

considered 'virtual').

Cheers

Adrian

Laurent GAUTROT wrote:

    </pre>

    <blockquote type="cite">

      <blockquote type="cite">

        <pre wrap="">Jerry <a class="moz-txt-link-rfc2396E" href="mailto:Jerry@cockatoos.com"><Jerry@cockatoos.com></a> wrote :

Is it possible to configure RT in such a way that one installation can

be virtual for many domains, such as you might do for an ISP, with

separate administrators and users for each domain?

        </pre>

      </blockquote>

      <pre wrap="">In fact, yes, it is.

Maybe you should give this page a read :

<a class="moz-txt-link-freetext" href="http://wiki.bestpractical.com/index.cgi?MultipleInstances">http://wiki.bestpractical.com/index.cgi?MultipleInstances</a>

      </pre>

      <blockquote type="cite">

        <pre wrap="">Alternatively, could it be configured that you could have separate

administrators and users for hundreds or groups at one domain? Would

these be queues? If so, can they be managed with conditional code, or

does each one have to be setup at the mail server and/or other areas?

        </pre>

      </blockquote>

      <pre wrap="">With FastCGI you can have separate environments, so you can setup variables.

By this mean, each RT site can have its own customisations.

The databases are independant. Notice that if you use MySQL you should take 

care of the naming of the databases.  « - » in database names will lead 

rt-setup-database to fail (only for MySQL).

_______________________________________________

<a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a>

Be sure to check out the RT Wiki at <a class="moz-txt-link-freetext" href="http://wiki.bestpractical.com">http://wiki.bestpractical.com</a>

Buy your copy of our new book, RT Essentials, today! 

Download a free sample chapter from <a class="moz-txt-link-freetext" href="http://rtbook.bestpractical.com">http://rtbook.bestpractical.com</a>

      </pre>

    </blockquote>

    <pre wrap="">-- 

Adrian Carter

Technical Manager

Leading Edge Internet

Web      <a class="moz-txt-link-freetext" href="http://www.lei.net.au">http://www.lei.net.au</a> <a class="moz-txt-link-freetext" href="http://support.lei.net.au">http://support.lei.net.au</a>

Direct    +61 2 6163 6162  Support 1 300 662 415

E-mail    <a class="moz-txt-link-abbreviated" href="mailto:cartera@lei.net.au">cartera@lei.net.au</a>

--------------050707070605030201040206

Content-Type: text/html; charset=ISO-8859-15

Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

 <meta content="text/html;charset=ISO-8859-15"

http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

    I just wanted to add something regarding my interpretations here.<br>

    Yes, you can run Multiple Instances, *BUT*, and this is a

*BIIIIIGGGGGG* but... Its *NOT* Virtual.<br>

<br>

    Virtual infers you can run a common and SINGLE backend (ala say

Apache) yet had numerous complete and independant configurations that

all interact with that same common backend (just like &lt;Virtual&gt;

tags inside that Apache config).<br>

<br>

    Now, configuring FastCGI and setting lots of instances with

slightly different RT_SiteConfigs etc is *not* a 'Virtual' solution,

becuase the Database backend is common, and thus, the Queues, Users

(Privelged, and worse Unprivliged) and Customer Fields etc etc are

common.<br>

<br>

    I have a classic scenario where I have techs working two completly

seperately branded ISPs. This results in two completly seperate

installs of RT due to the differing requirements for

Signatures/Priorities/Templates . There is no way to maintain a common

single database backend yet maintain seperate versions of these/<br>

<br>

    Can you imagine having to setup complete independant versions of

Apache for each Virtual Server??? Thats the difference between

'multiple' and 'virtual'.<br>

<br>

    Just my experience with RT. I ended up discussing this with Jesse

at length, and it would in fact cost money (in the order of $1000's) to

have such a system to support multiple signatures and multiple queues

and privleges within one database instance (which it must do to be

considered 'virtual').<br>

<br>

Cheers<br>

<br>

Adrian<br>

<br>

<br>