RTGUI, a Graphical User Interface for Best Practical's Request Tracker

RT Users
1

Hi everyone.

We are a group of 4 bachelor students doing our final project in
informatics/computer science. Our project is to make a java-based GUI
for Request Tracker. The project will be handed in at the end of May,
but development may continue after this date.

Our primary goal is to make an OS-independant application for ticket
handling (creating and updating tickets) that will be used by the
students employed by our school to help other students.

We would be very happy if some of you, the potential future users of
RTGUI to give your opinions on how the application works, any unknown
bugs, how things are placed and what you would have done different.

The application is available from our webside at
http://hovedprosjekter.hig.no/v2007/imt/in/rtgui/files.html .

A little copy&paste from the README.

RTGUI, a Graphical User Interface for Best Practical’s Request Tracker

RTGUI [artee-gooey] is a new alternative graphical user interface for
Best Practical’s Request Tracker. RTGUI will work as a alternate user
interface for the consultants working with resolving tickets. RTGUI will
only
have features regarding ticket handling. Configuration of users and RT
is not
planned implemented as of now.

This is just a milestone/preview release and is not a fully functioning
product. USE FOR TESTING ONLY!

Missing features / Known bugs:

  • The use of RTs ACL. (A user may see tickets he’s not supposed to, but
    changes will be discarded by RT)

  • Queue Selection. (The program displays all queues, but selecting/
    deselecting doesn’t do anything)

  • User preferences. (Set users mail address and signature)

  • Merge ticket. (The button exsist, but do nothing)

  • UTF-8 support.

  • Internationalization (The source is set up for
    internationalization, but
    this has not yet been implementet fully yet)

REQUIREMENTS:

o Request Tracker 3.6.2 or later

  Request Tracker 3.4 and Request Tracker 3.6 prior to 3.6.2 may be
  patched to support RT-commandbymail extionsion. Request Tracker 3.6.2
  and later does not need patching

o Request Tracker running a MySQL database
o Commandbymail extension for RT by Jesse Vincent of Best Practical
o All queues in RT must have the correct Reply and Comment Address

We have a mailing list at rtgui-user@list.hig.no for user inputs, more
info about that on http://list.hig.no

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

2

Hi everyone.

We are a group of 4 bachelor students doing our final project in
informatics/computer science. Our project is to make a java-based
GUI for Request Tracker. The project will be handed in at the end
of May, but development may continue after this date.

Torbjørn,

I’m really excited to see your prject get started. How usable is the
Alpha right now? What features should we play with? Which features
should we avoid for now?

Best,

Jesse

PGP.sig (186 Bytes)

3

Jesse Vincent wrote:

Hi everyone.

We are a group of 4 bachelor students doing our final project in
informatics/computer science. Our project is to make a java-based GUI
for Request Tracker. The project will be handed in at the end of May,
but development may continue after this date.

Torbj�rn,

I’m really excited to see your prject get started. How usable is the
Alpha right now? What features should we play with? Which features
should we avoid for now?

Best,

Jesse
Hi Jesse,
sorry for the late reply, but we had a “release party” last night. :slight_smile:

A quick list of what does work:

  • authentication against RT
  • Displaying tickets
  • Updateing tickets
  • Creating new tickets
  • Mabye more that I don’t remember…

As far as we know (hehe) all features that is enabled should be working.
So there is no features you should stay away from. But as stated
earlier, there is no check against the ACL yet, so all users will be
able to see and read all tickets of all queues in the database. All
users will also be able to reply to all tickets (with no check against
ACL), but the RT-system will discard all these.

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.

Hope this answered most of your questions.

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

4

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.

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

5

Chris Dunning wrote:

Torbj�rn -

Depending on the definition of "stand alone application," my

suggestion may or may not work, but I would look into using the REST
interface that comes with RT. You would be limited in that not all
actions are supported but you can do basic things like pulling
information about a ticket and replying to it. This is dependent on
having an HTTP connection to the server, which makes it not
“standalone,” but if you’re dependent on a connection to the MySQL
database that’s not much different. An advantage to this option is that
RT handles the ACL checks for you. If you handle the connection over
HTTPS I think it would be very secure - at least as much as logging in
directly to the ticket system through a browser.

Hi

By “stand alone application” I mean an application that you start on
your computer and not a web interface.

I’ll take a look on the REST interface either at work or when I get
home, but it sounds interesting. My only concern is whether it will be
able to get all the information that we need in an OK way. I would say
my first concern regarding this is queue handling and updating the view
of tickets in main window.

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

6

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

7

At Friday 4/20/2007 09:15 AM, Torbjørn Moen wrote:

Hi

By “stand alone application” I mean an
application that you start on your computer and not a web interface.

I’ll take a look on the REST interface either at
work or when I get home, but it sounds
interesting. My only concern is whether it will
be able to get all the information that we need
in an OK way. I would say my first concern
regarding this is queue handling and updating
the view of tickets in main window.

Hi Torbjørn,

You should definitely replace the direct database
access with RT API calls. For one thing, not
everyone uses mysql with RT, so building that dependency in is a problem.

But more importantly, even if you abstract the
database interface, it’s not just acls that
you’re bypassing by going directly to the
database - it’s the whole “business” logic built
into RT. To make a usable app, you’re going to
have to replicate RT in your app. When RT
changes, you’re app will likely break and you’ll
have to replicate the RT changes in your app.
It’s not really a sustainable approach.

Steve

8

Yes, an API would be the best thing, so RT will become an “engine”, a
midleware. Hence the possibilities to extend it with User Interfaces,
integration with anything you need…

9

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

10

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.

The existing REST webservices API should have what you need. What
doesn’t it have?

Best,
Jesse

PGP.sig (186 Bytes)

11

Stephen Turner wrote:

At Friday 4/20/2007 09:15 AM, Torbj�rn Moen wrote:

Hi

By “stand alone application” I mean an application that you start on
your computer and not a web interface.

I’ll take a look on the REST interface either at work or when I get
home, but it sounds interesting. My only concern is whether it will
be able to get all the information that we need in an OK way. I would
say my first concern regarding this is queue handling and updating
the view of tickets in main window.

Hi Torbj�rn,

You should definitely replace the direct database access with RT API
calls. For one thing, not everyone uses mysql with RT, so building
that dependency in is a problem.

But more importantly, even if you abstract the database interface,
it’s not just acls that you’re bypassing by going directly to the
database - it’s the whole “business” logic built into RT. To make a
usable app, you’re going to have to replicate RT in your app. When RT
changes, you’re app will likely break and you’ll have to replicate the
RT changes in your app. It’s not really a sustainable approach.

Steve

I’m aware of the “MySQL problems”. The reason we’re using MySQL only is

  1. This is a milestone/preview release. Since none of us ever used RT,
    we need feedback on how things look and feel. Therefore this release
  2. Our main priority until 21st of May is creating a product that works
    for the IT Service at Gj�vik University College, They use MySQL. Given
    that we still are missing some important features and have a 100+ page
    report to write, time could become an issue:p

About RT changes … From what I can see there has only been minor
changes to the database since RT3-release.

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

12

Using REST Web Services:
http://XXXX/REST/1.0/Forms/ticket/default?user=XXXX&pass=XXXX&id=249

I receive the following error:
Can’t use an undefined value as a HASH reference at /opt/rt3/share/html/REST/1.0/Forms/ticket/default line 178.

Stack:
  [/opt/rt3/share/html/REST/1.0/Forms/ticket/default:178]
  [/opt/rt3/share/html/REST/1.0/autohandler:52]
  [/opt/rt3/share/html/autohandler:292]

When I look at line 178 it is performing the following:
push @data, [ Queue => $ticket->QueueObj->Name ]

Any suggestions on what may be causing this? I am passing a valid ticket id in.

-Stark-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Jesse Vincent
Sent: Friday, April 20, 2007 2:22 PM
To: Torbjørn Moen
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RTGUI,a Graphical User Interface for Best Practical’s Request Tracker

On Apr 20, 2007, at 2:16 PM, Torbjørn Moen wrote:

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.

The existing REST webservices API should have what you need. What doesn’t it have?

Best,
Jesse

13

Sorry I see now that I need to use search

http://XXXX/REST/1.0/search/ticket/?user=XXXX&pass=XXXX&query=%20id%20%3D%2048&format=l

Jeff Stark, Sr Systems Administrator
SumTotal Systems, Inc. (Nasdaq; SUMT)

OFFICE +1 919 326 7548
MOBILE +1 919 622 0418

EMAIL jstark@sumtotalsystems.comFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Jeff Stark
Sent: Friday, April 20, 2007 3:16 PM
To: Jesse Vincent; Torbjørn Moen
Cc: rt-users@lists.bestpractical.com
Subject: RE: [rt-users] RTGUI,a Graphical User Interface for Best Practical’s Request Tracker

Using REST Web Services:
http://XXXX/REST/1.0/Forms/ticket/default?user=XXXX&pass=XXXX&id=249

I receive the following error:
Can’t use an undefined value as a HASH reference at /opt/rt3/share/html/REST/1.0/Forms/ticket/default line 178.

Stack:
  [/opt/rt3/share/html/REST/1.0/Forms/ticket/default:178]
  [/opt/rt3/share/html/REST/1.0/autohandler:52]
  [/opt/rt3/share/html/autohandler:292]

When I look at line 178 it is performing the following:
push @data, [ Queue => $ticket->QueueObj->Name ]

Any suggestions on what may be causing this? I am passing a valid ticket id in.

-Stark

14

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.

The existing REST webservices API should have what you need. What
doesn’t it have?

Best,
Jesse

Not had the time to really look things over, but I see a potential
problem is queue handling. We have a requirement that says that “a user
shall have the opportunity to select the queues he or she wish to see”.

Anyways, this will definitely be something I’ll put my head into during
this weekend.

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