[rt-devel] Non perl-based RT access

Iain Price iain.price at post.serco.com
Tue Jul 15 04:39:48 EDT 2003

Hi there,

Just joined this list, did do a quick trawl over the last few months and 
noticed a few other threads about Java access, SOAP and the command line 

Have been using RT for some time now (probably about a year), and 
developed a basic Java interface for RT2 that just used the command line 

The absence of this in RT3 has become a real thorn in my side.  I've 
started to connect to the database and manually update things, but this is 
clearly not a great idea.

Firstly, any real ETAs on getting even beta access to some command line 
tool or anything, particularly something that will either add users or 
support the auto-create-user on ticket submission thing.

Is there any useful technical information available about the database 
structure, having stumbled onto cachedgroupmemebers while writing ticket 
creation code I've realised that there appears to be a lot of 'duplicated' 
data (probably for search speeds), and that not updating the tables 
correctly is rather disasterous.  Having "worked out" how to create a 
ticket (using mysqldump diffs :S) and never really understood the 
cachedgroupmembers table simply cloned the other entries and tweaked the 

My current sticking issue is User creation.  Having analysed various diffs 
I still end up with RT thinking my user is a group.  Probably something to 
do with not creating the Group Equiv entry... but again its not clear to 
me how the entire database holds together... each table is reasonably 
understandable, however there appear to be a *lot* more groups than i 
would have ever expected :)

Basically having screwed up the test RT development platform we have here 
several times I've realised even if i made a user creation routine that 
seemed to work I wouldn't trust it to not come back and bite me in the ass 
in a few weeks... and recovering the db when i dont understand the 
structure is not something i want to do.

So i'm considering forging a message to the mail receiver from the user, 
then finding and 'hiding' the ticket, so the perl RT api does the user 

My questions therefor are :)

1) Any ETA on any kind of non-perl access to RT

2) Any technical information on the database structure, theoretical 
'algorithms' for adding users to the databases etc - more the 
relationships between the tables than the individual table structure

3) When / if i break tables like the cachedgroupmembers table, or I forget 
to add a group entry for a user (hence making RT think a user is a messy 
group or similar :S) are there any repair tools for reconstructing some of 
the 'duplicated' data

4) Any better ideas for getting users into RT for now than this 'ticket 
submission' thing? :P

Apologies if this is all old junk or i've missed something important, just 
point me in a direction and i'll get on with reading/experimenting :)

Iain Price
Intranet Developer/Wan Engineer

More information about the Rt-devel mailing list