[rt-users] some basic "getting started" questions

[Kelly F. Hickel]

(Ruslan was kind enough to reply, but I must have deleted it somewhere
along the road, so I've cut the text from the mailing list archive so
that I could respond...)


<snip>
>> 1) "integration with Bugzilla".  I've seen on the list where people
seem
>> to think that RT and Bugzilla work well together, I'd like to get
some
>> more details on exactly how people are using these products with each
>> other. Is it all manual (put a link in an RT ticket to a BZ), or is
>> there something deeper?
>I don't know.
Fair enough.
>> 
>> 
>> 2) I'd like to have a web form set up for customers to open tickets,
>> that would require certain information be entered up front, and have
>> that information be pulled out by the incoming mail gateway (or the
>> command line tool) and used to populate some Custom Fields.  Any tips
on
>> this? I'm not much of an HTML form person....
>Hire HTML/Perl person...
Well, I may not be much of an HTML form person, but I think I can handle
that part of it.  I probably should have been more clear, What I want to
know is how can I code values into an email message that will
automatically be used to fill in portions of the newly created ticket,
including custom fields.  I've reviewed the doc again today, and can't
find any information that this is even possible (maybe it isn't), much
less how to do it.
>> 
>> 
>> 3) Some of our customer's want to be able to see their own tickets.
The
>> obvious way to do this seems to be to run RT in the DMZ and give
>> customers access to their own (and only their own) tickets.  To
start,
>> I'm a bit leery of running out support ticket setup in the DMZ, but
>> let's say that's OK.  I don't see an obvious way to limit access of a
>> user to only tickets for which they are the requestor (maybe I'm
missing
>> it), and to make sure they can't see comments, only replies.
>SelfService
>Try to use 'RT::BaseURL/SelfService/' as URL
>OR
>Try to change password for email created user and login with his
account.
>For users which have right to access RT, but not preveleged SelfService

>is default UI.
Cool, that works for me.
>> 
>> 4) Same sort of question as #3, but for RTFM articles.  I think it's
a
>> little simpler here, I could just have a public (https) RTFM server,
and
>> presumably I can push the RTFM database every week or so from the
>> internal RTFM out to the "public" one.  Any obvious problems with
this?
>Don't know a lot about RTFM.
>> 
>> 5) This one is more about customer contact information.  It breaks
down
>> into a few related questions:
>>    A)  When I'm viewing a ticket, if I want to see information about
the
>> requestor (company name etc), it seems I have to go search for the
user.
>> Shouldn't there be a link that I can click on to see their info?
Better
>> yet, shouldn't I be able to pick what I want to see right on the
basic
>> view (I dimly remember that I may be able to change what shows up by
>> editing the presentation template, but I'm not sure).
>Attached file(ShowPeople) is my lazy way to solve first problem.
>This adds direct links to user prefs on ticket Display page.
Cool! That did exactly what I wanted (after I replaced $WebBaseURL with
$WebURL).
>> 
>>    B) Our support folks want a way to store various information about
a
>> customer's organization (how many copies of the product are deployed,
>> what versions etc), and be able to review that with a customer when
>> they're on the phone, and not have to type it in for each ticket.
This
>> seems to be outside the realm of RT, but it would be great if I'm
wrong.
>You are right here. You can develop it or pay for it to BP Solutions.
Is anyone out there using an open source tool to do this?
>> 
>> 6) Support wants different status values than what are in the
product,
>> is the functioning of the product tied to any of those values?
Should I
>> change the current value set, or create a custom field for our
values?
>Look in archives(august-september).
Yep, OK, we won't use status for that, we'll get along with a custom
field and different queues.
<snip>

Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677
kfh at mqsoftware.com