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

[Torbjørn Moen]

Bob Goldstein wrote:
>> 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

An API would be the best way to do this, but given that we need to 
produce a working application for the IT Service on 21st of May this 
probably won't happen from us until after that time.

Just to clear things up, we are not doing anything with the database 
except reading data. All updates and creation of new tickets are done 
through the CommandByMail extension. And from what I've seen from the 
changelogs, there have only been minor updates to the database in RT3.

-- 
Best Regards
Torbjørn Moen on behalf on the RTGUI developers
http://hovedprosjekter.hig.no/v2007/imt/in/rtgui/
Bugtracker: http://mantis.hig.no