[rt-users] RT 4

[Jan Grant]

On Tue, 1 May 2007, Jesse Vincent wrote:

> If, for the sake of argument, Best Practical were to rewrite RT, what would
> you want to see in the new product?

Keep the decent layered architecture.


(Obviously) a _complete_ REST or other remote api. (I like the 
simplicity of the REST model.)


Extend externally pluggable authnz: in two minds about that. I'd like to 
get closer integration of the group management in particular with our 
LDAP service here (which is built around the OID provisioning tools). 
However, there'd be nothing to stop me from integrating closely already 
using the existing capabilities of OID's provisioning tools, IF group 
membership were manageable via a remote API. The external authn is 
already good.


Query model: it'd be nice to get full text search out of the box. The 
stock query builder is the thing we get most complaints about from our 
users, and is the thing that'd benefit most from closer web-client 
integration.


Tidy up some of the loose ends: better integration of custom fields with 
the mailgate, for instance.


Namespace management: eg, being able to configure per-queue custom 
fields in a per-queue namespace.

Perhaps "queue groups" for the above.


Some finer-grained SeeQueue/QueryQueue rights. We typically turn off 
"SeeQueue" for our users in order to manage the front-page clutter (a 
hundred queues is a lot) - but we'd really like them to be able to raise 
tickets and query across all queues. So, some approach to this - possibly 
using UI-specific rights on queues to manage the default home-page 
widgets; possibly just having some better parameterisable UI widgets. 
"Queue groups" might help here.


> Think big.

When and only when the above are addressed :-) the "think big": we're 
using RT in anger here - the application of technology to solve people 
problems :-) - to stop requests between teams from dropping on the 
floor; looking at it to manage requests for access to e-science grid 
systems; and a whole bunch of other kinds of things. Lots of folks want 
RT set up in different ways - eg, a "closed shop" where users are all 
preregistered or a more traditional outward-facing setup.

That typically means multiple RT instances. However, by having lots of 
RT instances, you lose a lot of the benefit of having all your queues 
under one system. I don't have a design for this, or even more than a 
vague "it'd be nice" feeling, but it'd be nice to have some kind of 
inter-RT-instance capability: even if that just means divorcing the UI 
from the instance and having one UI capable of fronting several RT 
instances together.

Cheers,
jan

-- 
jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661   http://ioctl.org/jan/
There's no convincing English-language argument that this sentence is true.