Works as advertised, but the design of the module requires an extreme amount of API requests to fetch ticket information, making its use both slow and producing too much load on the servers of the API provider.
For example, if I want a list of tickets created after some date or all tickets in the queue, the API provides the '/search/ticket' endpoint that returns a list of found ticket IDs together with their subject lines. Pretty useful as the basis to find a ticket you want.
This module, however, discards the subjects and returns only IDs. If you do want those subjects, you have to call another method that makes another API request, *for each ticket.*
The same issue exists with individual tickets too. If I want to read the ticket and all of the replies to it, the API provides the '/ticket/###/history' endpoint that returns all of that information.
The module, however, requires you get_transaction_ids() for IDs of all the individual items on the ticket, which along with comments includes status changes, for example. And once you have those IDs, you have to request each individual transaction using get_transaction().
Consider a single ticket with 5 comments, status change from `new` to `open`, `bug` tag added, and then status changed from `open` to `resolved`. Using the API with `curl`, I can obtain all of that information in a single API request (login credentials can be part of the URL).
But if I use this module, I have to make 1 request to get transaction IDs, then 8 additional requests to get each individual "transaction."
If all I want is a list of all RT tickets with subject lines for perl6 queue, I can't even reasonably use the module, as instead of 1 API request I can do with `curl`, I will have to make one per ticket I want, resulting in over 1300 requests for the full queue.
Despite promising to be the API client, this module is entirely unusable for my simple and non-exotic task.
I loathed integrating with RT until I figured out that my RT install (3.8.1 with lighttpd and FastCGI) wasn't playing nicely on a CentOS system. A vanilla install on FreeBSD 7 worked perfectly so we narrowed the problem down to a bug in the version of perl on CentOS 5.
That is behind me now, but that bug cost me a ton of wasted time loading RT.pm into my application and doing a lot of grep -r in the RT source tree to figure out the right incantations to get, update, and create tickets.
This afternoon I resolved the perl problem and replaced all the RT calls we had painstakingly written against RT.pm with RT::Client::REST. It is faster and far, far easier because the documentation is excellent with plenty of included samples. Great job. Great module. Thank you!