We’ve used RT as our service desk ticketing system for some years now, but we’ve also used RT as the basis for a completely different system: a means of managing identities of visitors and partners on the University campus we’ve called ALMS.
I’ve knocked up a high level description in case any of you are interested in how RT can be leveraged for different use cases. If nothing else it will possibly make Best Practical folk cry reading with what we’ve done with their product.
The ALMS system workflow is fairly specific to our organisation, we’ve done quite a bit of hacking on the RT system and added a load of custom UIs, so we’re not planning on releasing any of the custom stuff, but the RT architecture makes this relatively easy and mostly painless, especially custom lifecycles and callbacks.
When we get asked for new system designs now the (semi-) joking response is “maybe RT could do it?”. When you’ve got used to RT it’s amazing how everything starts to look like a queue or a ticket.
Hey there, I’ve read your blog items in the past as it’s one of the few places on the Internet blogging about RT usage…
Thanks for publishing that use case, I’m using RT for a services business and I manage customer tickets, incident response, through to “invoice” tickets that are responsible for the workflow collate, report and create invoicing in external systems, along with forward/reverse linking between invoice system (SaaS) and RT.
I’ve heavily (mis)used other open source systems to extend them far beyond what the original developers ever envisaged, and I enjoy reading others doing similar things… Thanks again for sharing!
I’m glad to hear it’s been interesting. I think RT has great potential to be used as the basis of such systems - the framework it provides is excellent for extending and customisation.
