On 09/20/2012 10:21 PM, Tom Robinson wrote: > 1. Use a new queue for the new department, isolating administration and users > for that department to > that queue.
A very reasonable option that works Right Now without much additional effort. Consider if the new department is going to want lots of queues down the road, or custom visual branding, etc. Anything you do in a single RT will affect all departments using it, so you need flexibility from your users. The question to answer to determine between 1 and 3 (2 is right out) is "How customized do you predict the new department is going to need their RT?" (i.e. why do they want a separate database). > 2. Run two instances by following > http://requesttracker.wikia.com/wiki/MultipleInstances (requires > hacking the code to make this work on 4.0.7). The hacks described in that wiki page lead to more complications than they are ever worth. > 3. Run two installations side by side having compiled with different > configuration options. This is the dead simple option, and completely reasonable. Upgrades within the 4.0 stable series are intentionally small and designed to be safe. When you do a larger upgrade to 4.2 down the road, you can upgrade one install and use what you learned to upgrade the other that much quicker. If you keep local customizations clean, upgrades are pretty painless (esp. starting from 4.0.7). FWIW, Best Practical uses option #3. The RT source code is tiny, and it gives us clean separation between public facing RT and internal RTs. The added overhead of administering more than one install is not much once you have processes set down for doing it to a single RT. -------- Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
