Non perl-based RT access

RT Developers
1

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
tool.

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
tool.

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
numbers.

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 :slight_smile:

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
creation.

My questions therefor are :slight_smile:

  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? :stuck_out_tongue:

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 :slight_smile:

Thanks
Iain Price
Intranet Developer/Wan Engineer

2

Hi there,

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.

Right. We don’t support that. or recommend that you do it. Not using the
API will cause you to hurt yourself rather badly.

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.

As mentioned on the list yesterday, a beta version fo the CLI will
appear in the next release of RT (3.0.5) and is already in the
repository.

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 :slight_smile:

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.

Why not write a simple perl program that uses the API to create a user?

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
creation.

My questions therefor are :slight_smile:

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

See above.

  1. 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

Not in a form that would be useful to you.

  1. 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

No. Patches are welcome.

  1. Any better ideas for getting users into RT for now than this ‘ticket
    submission’ thing? :stuck_out_tongue:

Yep. see above.

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 :slight_smile:

Thanks
Iain Price
Intranet Developer/Wan Engineer

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.