We have an issue with the REST API : afaik it’s not possible to get the
list of queues available on a RT server.
It makes it very inconvenient to raise a new ticket : usually entering
a valid queue name is mandatory (like on rt.cpan.org), but without a
list of possible ones, it’s difficult for the user to pick one properly.
Is there any way to get the list of available queues on the RT server ?
It is the same with custom fields, but that’s less of an issue for now.
I tested it on our installation. A first problem raised
up. If I try to open a merged ticket (“A” merged in "B"
I try to open “A”), the script crashed.
best regards and thank you for this promising tool.
sven
Constant subroutine RT::Client::Console::Session::OBJECT
redefined
at /usr/local/share/perl/5.8.8/RT/Client/Console/Session/Ticket.pm line
12
Constant subroutine RT::Client::Console::Session::Header::OBJECT
redefined at /usr/share/perl5/POE/Session.pm line 146.
Constant subroutine
RT::Client::Console::Session::CustFields::OBJECT redefined
at /usr/share/perl5/POE/Session.pm line 146.
Constant subroutine RT::Client::Console::Session::Links::OBJECT
redefined at /usr/share/perl5/POE/Session.pm line 146.
Constant subroutine RT::Client::Console::Session::OBJECT redefined
at /usr/local/share/perl/5.8.8/RT/Client/Console/Session.pm line 16
Constant subroutine RT::Client::Console::Session::Root::OBJECT redefined
at /usr/share/perl5/POE/Session.pm line 146.
Constant subroutine RT::Client::Console::Session::Status::OBJECT
redefined at /usr/share/perl5/POE/Session.pm line 146.
Constant subroutine RT::Client::Console::Session::KeyHandler::OBJECT
redefined at /usr/share/perl5/POE/Session.pm line 146.
We have an issue with the REST API : afaik it’s not possible to get the
list of queues available on a RT server.
Hm. Indeed this doesn’t seem to be possible via the REST API. I’d love
a patch to make it possible. (For any/all object types)
FWIW, I had written up some ruminations on revising the REST API
a year ago, but never had time to work on it. The idea was to
set up a framework in which new kinds of queries like this
could be dropped in in an easy and structured way. Wouldn’t surprise me
that developments in the past year have made this obsolete, but
if you’re interested: