Some basic "getting started" questions

Hi,
I was going to send each of these as a separate email so people
could ignore the ones they didn’t have input on, but I decided that it
would be better to have people be able to ignore the whole thread,
rather than annoying everyone with a bunch of posts.

OK, I have RT 3.0.6 up and running with RTFM, and I’ve been pushing our
support folks to look at it, and we’re getting close to having a plan to
put it in place. We’ve run into some things that have been requested
that I think are outside the scope of RT, and some that aren’t. I
wanted to get some feedback on how other people are accomplishing some
of these things:

  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?

  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…

  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.

  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?

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

    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.

  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?

Well, I think that’s it for now, but I’m sure I’ll have more
questions…

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

Kelly F. Hickel wrote:

Hi,
I was going to send each of these as a separate email so people
could ignore the ones they didn’t have input on, but I decided that it
would be better to have people be able to ignore the whole thread,
rather than annoying everyone with a bunch of posts.

OK, I have RT 3.0.6 up and running with RTFM, and I’ve been pushing our
support folks to look at it, and we’re getting close to having a plan to
put it in place. We’ve run into some things that have been requested
that I think are outside the scope of RT, and some that aren’t. I
wanted to get some feedback on how other people are accomplishing some
of these things:

  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.

  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…

  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.

  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.

    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.

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

ShowPeople (2.22 KB)

(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…)

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

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

  2. 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?

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

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

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.

At Jesse’s suggestion, I’ve been hacking on enhanced-mailgate
from RT2, trying to fit it into RT3. This can be used
to send extra info in email when creating tickets,
or to give commands via email for existing tickets.

I have it doing exactly what you want – populating a custom
field upon ticket creation. Basically,
RT::Interface::email::Gateway() gets some new internals to
parse and deal with specially formatted lines at the top of an
email.

But I haven’t tested all of the functionality yet, and
there are some pieces that need more cleaning up before I
submit the diffs. If I can shake loose the time, maybe
a few more days to a week.

  bobg

-----Original Message-----
From: Bob Goldstein [mailto:bobg@uic.edu]
Sent: Wednesday, December 31, 2003 3:21 PM
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] some basic “getting started” questions

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.

At Jesse’s suggestion, I’ve been hacking on enhanced-mailgate
from RT2, trying to fit it into RT3. This can be used
to send extra info in email when creating tickets,
or to give commands via email for existing tickets.

I have it doing exactly what you want – populating a custom
field upon ticket creation. Basically,
RT::Interface::email::Gateway() gets some new internals to
parse and deal with specially formatted lines at the top of an
email.

But I haven’t tested all of the functionality yet, and
there are some pieces that need more cleaning up before I
submit the diffs. If I can shake loose the time, maybe
a few more days to a week.

  bobg

That would be fantastic, we’re not likely to flip the switch on RT for a
month or so yet, even though I’m pushing, so that would fit in very
well.
Sounds like I could set it up so a user could send a command like “list
tickets” and get back a list of tickt ids, summaries and status too!

Thanks,
Kelly


rt-users mailing list
rt-users@lists.fsck.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm

That would be fantastic, we’re not likely to flip the switch on RT for a
month or so yet, even though I’m pushing, so that would fit in very
well.
Sounds like I could set it up so a user could send a command like “list
tickets” and get back a list of tickt ids, summaries and status too!

That’s not part of the functionality I’m working on,
although you could enhance it. I don’t want to give you
a false sense of what I can provide.

Right now, the way RT works, a consultant does something
to a ticket on the web (create, append, resolve, assign, etc)
and RT then notifies requestors and watchers via email.
The mail interface I’m working on lets a consultant “do
something to a ticket” via email instead of the web,
and then the normal RT processes notify the usual suspects
by email. But there are no normal processes that email
lists of ticket ids, summaries, and status in response
to a query; rather only info about a transaction to a single ticket.

The way we will use it here is this:

 1. Consultant A is a member of the systems group, which is
    a watcher of the systems queue.

 2. A ticket is created (or modified) in the systems queue,
    and notification is sent everyone in the systems group.

 3. Consultant A sees the email.  Instead of opening a browser
    and finding the ticket, he just hits "reply" to the email,
types in "close\nThis is covered in the FAQ" and sends
the reply.

 4. A mail pre-processor turns this into:
     "RT-status: resolved\n\nThis is covered in the FAQ"
 and sends it on.

 5. The new RT funtions parse this, add the append and
    change the status to "resolved."

However, if Consultant A wants to see a list of his open problems,
or to take any other action on multiple tickets, he has to
use the web.

Our use of custom fields stem from the fact that other parts
of the university use other ticket systems. In order to
transfer tickets from a “foreign” system to RT, I need to
fish out the foreign ticket-id and store that in a custom field,
by the same mechanism.

    bobg