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. _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
