> >If, for the sake of argument, Best Practical were to rewrite RT, what >would you want to see in the new product? >
1. Full functional API, both local and network accessible. I have in mind integrating RT with other apps, possibly point-to-point, or with some SOA/message bus. This could mean RT-to-RT sync, account provisioning-to-RT, RT-to-other helpdesk, extra funtionalities like AT, and so on. Do I remember correctly that some RT-ness (like checks for privilege) take place in the mason components? If so, that should be moved to the perl modules, so that the API would contain all this goodness. In particular, it should be possible to write an entirely new UI, at whatever complexity the author wishes, and have it safely interoperate with the official RT UI on the same RT instance. 2. Better development docs. Maybe I just want the API above to be well documented, I'm not sure. But I want to understand the code architecture and data model at something higher than the subroutine or file level, and lower than the UI. 3. Other features could be built on top, by you or others. Ad hoc reports, adjustment of cron jobs from the UI (e.g. send mail to ticket owners if the consultant hasn't responded in 2 days, ...), project tracking (maybe integrate RT into Trac), more formal change management, calendar integration (an RT ticket might be linked to, or create, a meeting on a calendar, or sync RT todo list with a calendar/pda). bobg _______________________________________________ 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