[rt-users] RTGUI, a Graphical User Interface for Best Practical's Request Tracker

[Bob Goldstein]

>Boris Jordanov wrote:
>>
>>>
>>> A quick and simple description of how things are done. All data that 
>>> we get from RT is collected directly from the MySQL database. All 
>>> data that we put back in (create/update tickets) are done through the 
>>> CommandByMail extension.
>>
>> Not very useful in an open environment (internet, public networks). To 
>> make the database accessible from all over the net...
>>
>>
>That's true. I'm not to familiar with global settings MySQL server, but 
>you have the possibility to use wildcards when setting up the user with 
>select rights on the database. That way you can at least restrict the 
>user to only connect from certain IP addresses. I'm guessing you have 
>some of those settings in the server settings also, but I'm not sure.
>
>Since it's a requirement form our "employer" (Gjøvik University College) 
>that this must be a stand-alone application we only had 2 choices. 
>Either try to get the data from the RT web service or get the data 
>directly from the MySQL database. We went for the second one. We have 
>the possibility to do SSL encryption on the SQL connection, but this 
>will still keep your MySQL server accessible......
>
>If you or anyone else have a better solution for the problem we'll take 
>that into consideration and mabye change the way things are done now.
>

I do have a better suggestion, but it's too involved and complicated
to be of short term use to you.  That is, RT needs a network API
that you should use. It does have one, the REST/1.0 code used by
the existing command line interpreter, but that is not extensive
or extendable enough.  I have sketched some thoughts on this here:
  http://tigger.uic.edu/~bobg/rt_api.html
But I haven't had any time to write code and see how well it might work.

The reason the API is needed is not so much for security, but because
the official interpretation of the data _is_ the perl code.  If you
want to write a new java UI, you really want to be manipulating
the perl objects on the server, not the raw data.  (Doesn't
matter they are perl.  A remote machine would think of them
as 'server objects') That way, all the ACLs and other data
interpretation/enforcement are done properly and consistently,
particularly when RT is upgraded.

And, of course, such an API would make it much easier and safer
to integrate RT with other systems.  (My personal need is to
hookup RT with our account provisioning system.  Another is to
connect RT with a non-RTFM Knowledge Database.  I can also
imagine connecting RT with other (RT as well as non-RT) helpdesk
systems to share tickets. ) And, alternate UIs for specialized
purposes.

  bobg