RT questions

Hello,

We are moving from req to RT and have some questions.

RT1.0.3pre1, Solaris 2.6.

Can we use these in any way in RT?

  1. An “extra alias” to the queue so that mail gets sended to this address too
    $mailing_list_dist = “noc-dist”;

  2. Can I log all of queue’s maillog to one file?

  3. What about killfile, ie. mail from specified address goes not to queue and
    gets no ticket number
    $kill_file = “killfile”;

  4. And silent-users; the sender gets no autoreply
    SILENT=silent-users

  5. Can I use similar to this “X-Request-Do: Resolve” in header, so that ticket
    automatically gets resolved?
    %RT RESOLVE doesn’t work because I don’t know the ticket number when sending

     > %RT RESOLVE
     RT: Batching resolve of .
     RT: You don't have permission to modify request # (0)
    
  6. When user replies or resolves a ticket it should also be taken by that user.
    How to change that?

  7. We’d like to be able to select the specific queues to the view not just all
    or just one.

  8. Can we specify which transaction get mailed to requestor? The only useful is
    “take”.

  9. If I want serial number to begin at #10000, what should I do?

Riku Hakkarainen
hakke@iki.fi

Hello,

We are moving from req to RT and have some questions.

RT1.0.3pre1, Solaris 2.6.

Back down to RT 1.0.2. Trust me.

Can we use these in any way in RT?

  1. An “extra alias” to the queue so that mail gets sended to this address too
    $mailing_list_dist = “noc-dist”;

Um, I’d suggest a meta-user in RT with manipulate access and hat as their email address

  1. Can I log all of queue’s maillog to one file?

I’d suggest procmail

  1. What about killfile, ie. mail from specified address goes not to queue and
    gets no ticket number
    $kill_file = “killfile”;

I’d suggest procmail

  1. And silent-users; the sender gets no autoreply
    SILENT=silent-users

This is only configurable per-queue

  1. Can I use similar to this “X-Request-Do: Resolve” in header, so that ticket
    automatically gets resolved?
    %RT RESOLVE doesn’t work because I don’t know the ticket number when sending

     > %RT RESOLVE
     RT: Batching resolve of .
     RT: You don't have permission to modify request # (0)
    

Not for create, I guess. I’d happily take a patch

  1. When user replies or resolves a ticket it should also be taken by that user.
    How to change that?

Never looked at it

  1. We’d like to be able to select the specific queues to the view not just all
    or just one.

In the CLI that works. In the web ui, you can’t right now

  1. Can we specify which transaction get mailed to requestor? The only useful is
    “take”.

Nope. 2.0 should support this

  1. If I want serial number to begin at #10000, what should I do?

Create a ticket. In MySQL, change it’s serial_num to 9999


Riku Hakkarainen
hakke@iki.fi


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

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Pelcgb-serrqbz abj!

Hi,

I have some question about RT.

1.Can you get a graphic chart?

2.Can you attach any type of file (ascii,binary) to a bug report?

3.Is it possible to add a new field to form of a bug report? (ex. FREQUENCY,VERSION,)

Thanks

You might want to take a look at bugzilla (http://bugzilla.mozilla.org/), as
it sounds like
you’re using rt for tracking bugs, and not in a helpdesck/crm application.

RT is great, but I wouldn’t use it for tracking bugs.

As for each of your questions. You might want to check out contributed code
at
http://www.fsck.com/pub/rt/contrib/

I don’t recall whether any of the stats packages generated graphical output,
but it should be easy enough to do with GD.

Check out the stripmime contributed code in order to access customer
attachments.

I’m unsure whether you can attach files to emails to a customer, but my
initial thought is that this functionality doesn’t exist yet. Jesse, is it
on the TODO list?

-rob-----Original Message-----
From: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com]On Behalf Of sakou@jp.fujitsu.com
Sent: Wednesday, January 31, 2001 4:24 PM
To: rt-users@lists.fsck.com
Subject: [rt-users] RT questions

Hi,

I have some question about RT.

1.Can you get a graphic chart?

2.Can you attach any type of file (ascii,binary) to a bug report?

3.Is it possible to add a new field to form of a bug report? (ex.
FREQUENCY,VERSION,)

Thanks

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

Hi,

I have some question about RT.

1.Can you get a graphic chart?

I’ve generated graphical charts of RT statistics using the rtstats tool (two versions are available. one from http://fsck.com/pub/rt/contrib and one from http://fsck.com/~jesse/projects/)

2.Can you attach any type of file (ascii,binary) to a bug report?

With RT 1.0.x, you’ll need the stripmime package from http://fsck.com/pub/rt/contrib. With RT2 (which is currently in development and available in snapshot
release form at http://fsck.com/pub/rt/devel/), binary files can be attached
to any incoming message natively.

3.Is it possible to add a new field to form of a bug report? (ex. FREQUENCY,VERSION,)

There isn’t really an easy way to do this in RT1. RT2 has support for things
like this.

    Jesse

Thanks


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

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

T'waS br|ll1G 4|||> 7#e sl1T#Y T0v3s D1|> gYR3 4nd Gimb@1 1|| 7#E //A83
all |/|1|/|53Y W3R3 d4 60r0GR0V3s @|||> |>4 M0MES wr47H oUTGR4b3.

3.Is it possible to add a new field to form of a bug report? (ex. FREQUENCY,VERSION,)
There isn’t really an easy way to do this in RT1. RT2 has support for things
like this.

This is currently the major obstacle I have to adopting RT1.
Ummm… how stable is RT2? :slight_smile: I’ve looked at the buglist,
and I don’t see any real showstoppers. However, a lot of the
bugs are not not really clear to someone (like me) who isn’t
current on the development. Is there an update to be made to
the “status.html” page? Any idea on when RT2 will be feature
complete? Will there be a non-“feature complete” release which
will have bugfixes?

In short (and now I’m not asking Jesse to commit to anything,
but only for the opinions of people who test/use RT2), if I also
save all incoming and outgoing mail to a seperate maildir, what
are the risks I’m taking in using RT2 in a big production
environment that desperately needs a request tracker?

BTW, slight feature request (for RT3 ;-)): I think it would be
nice, when you’re consulting things in one queue, to have the
default selection of “New ticket” set to the queue you’re on.

#include <std_disclaim.h> Lorens Kockum

This is currently the major obstacle I have to adopting RT1.
Ummm… how stable is RT2? :slight_smile:

I use it daily. and it’s actually feeling pretty solid these days.
There’s a bit of robustifaction that needs to happen to the mail
gateway to make absolutely sure we don’t lose any mail.

I’ve looked at the buglist,
and I don’t see any real showstoppers. However, a lot of the
bugs are not not really clear to someone (like me) who isn’t
current on the development.

The closest things to showstoppers right now are the fact that
an administrator who isn’t careful can still break referential integrity
on some database objects. Big impediments to day-to-day use
include the fact that merge hasn’t been implemented yet, and that
RT still does all its time handling in GMT. Ivan’s been hacking on
an RT1 import tool, but it’s not quite there yet. (though this isn’t an
issue for you)

Is there an update to be made to
the “status.html” page?
Yep. I’ve been a bit busy with other things. Sorry about that.

Any idea on when RT2 will be feature complete?

That day gets closer and closer. I’m hoping to get alpha 4 out the door
next week. That should have a fully functional admin cli and fixes
for the nastiest of the bugs I know about right now (the ref. integrity
stuff)

Will there be a non-“feature complete” release which
will have bugfixes?

The goal of each milestone release is to be more stable and complete
than the last. Generally, the point releases between each milestone
have improved stability too.

In short (and now I’m not asking Jesse to commit to anything,
but only for the opinions of people who test/use RT2), if I also
save all incoming and outgoing mail to a seperate maildir, what
are the risks I’m taking in using RT2 in a big production
environment that desperately needs a request tracker?

If you’re the daring sort, you probably want to save copies of all
incoming and outgoing mail and turn on SQL logging on your mysql
instance. If you do that, you should be pretty ok.

BTW, slight feature request (for RT3 ;-)): I think it would be
nice, when you’re consulting things in one queue, to have the
default selection of “New ticket” set to the queue you’re on.

Getting a bunch of the web ui’s selectors, etc to have ‘sticky’ preferences
within a session shouldn’t actually be too hard :slight_smile: if you’re really interested,
I can give you pointers and will take a patch :wink:

Hope this answers some of your questions.

    Jesse


#include <std_disclaim.h> Lorens Kockum


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

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

T'waS br|ll1G 4|||> 7#e sl1T#Y T0v3s D1|> gYR3 4nd Gimb@1 1|| 7#E //A83
all |/|1|/|53Y W3R3 d4 60r0GR0V3s @|||> |>4 M0MES wr47H oUTGR4b3.

This is currently the major obstacle I have to adopting RT1.
Ummm… how stable is RT2? :slight_smile:
I use it daily. and it’s actually feeling pretty solid these days.

That’s nice.

There’s a bit of robustifaction that needs to happen to the mail
gateway to make absolutely sure we don’t lose any mail.

OK.

I’ve looked at the buglist,
and I don’t see any real showstoppers. However, a lot of the
bugs are not not really clear to someone (like me) who isn’t
current on the development.

The closest things to showstoppers right now are the fact that
an administrator who isn’t careful can still break referential integrity
on some database objects.

Just have to be careful, then :slight_smile:

Big impediments to day-to-day use include the fact that merge
hasn’t been implemented yet,

That’s very probably a showstopper for me :frowning: Absence on
incident merging is the major problem with the system we have
today. Can’t supertickets and subtickets be used to work around
that?

and that RT still does all its time handling in GMT.

Haven’t really seen the need for time handling yet, so that’s
cool.

Ivan’s been hacking on an RT1 import tool, but it’s not quite
there yet. (though this isn’t an issue for you)

Would be if I decided to run with RT1 until merge comes around
:slight_smile:

Is there an update to be made to the “status.html” page?
Yep. I’ve been a bit busy with other things. Sorry about that.

Don’t be! I’m sure everybody prefers (say) a bug less in RT to
an up-to-date status page :slight_smile: Gee, next you’ll be saying people
have expectations of you and of a project they haven’t paid for
:wink:

Any idea on when RT2 will be feature complete?

That day gets closer and closer. I’m hoping to get alpha 4 out the door
next week. That should have a fully functional admin cli and fixes
for the nastiest of the bugs I know about right now (the ref. integrity
stuff)

OK, but not the merge?

Hope this answers some of your questions.

More so than I dared hope :slight_smile:

#include <std_disclaim.h> Lorens Kockum

Big impediments to day-to-day use include the fact that merge
hasn’t been implemented yet,

That’s very probably a showstopper for me :frowning: Absence on
incident merging is the major problem with the system we have
today. Can’t supertickets and subtickets be used to work around
that?

In cases where you’re trying to do incident aggregation, this
works just great. The issue is when a user screws up and
submits a second ticket about the same problem…

Gee, next you’ll be saying people
have expectations of you and of a project they haven’t paid for
:wink:

laugh That never happens :wink:

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

“If IBM wanted to make clones, we could make them cheaper and faster than
anyone else!” - An IBM Rep. visiting Vassar College’s Comp Sci Department.

|
|
| On Fri, Feb 02, 2001 at 11:46:06AM +0100, Lorens Kockum wrote:
| > > Big impediments to day-to-day use include the fact that merge
| > > hasn’t been implemented yet,
| >
| > That’s very probably a showstopper for me :frowning: Absence on
| > incident merging is the major problem with the system we have
| > today. Can’t supertickets and subtickets be used to work around
| > that?
|
| In cases where you’re trying to do incident aggregation, this
| works just great. The issue is when a user screws up and
| submits a second ticket about the same problem…
±–>8

“screws up”? Some users around here adamantly refuse to reply to messages,
but instead send new messages every time. I think they haven’t figured out
the purpose of the Reply button yet…

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]

| In cases where you’re trying to do incident aggregation, this
| works just great. The issue is when a user screws up and
| submits a second ticket about the same problem…
±–>8

“screws up”? Some users around here adamantly refuse to reply to messages,
but instead send new messages every time. I think they haven’t figured out
the purpose of the Reply button yet…

And then there’s the support techs who use “forward” instead of
“redirect”… and then there’s the Network Solutions form processor…
and then there’s the ones who segue off into a seperate topic in the
middle of a ticket…

Hmmmm…

Is there any way…

  • …to not auto-respond to mail from a particular address?
  • …to “split” a ticket (assign a new ticket number to everything
    beyond a certain point in the ticket)? -rt

Ryan Tucker rtucker@netacc.net Network Operations Manager
NetAccess, Inc. Phone: +1 716 419-8200
1159 Pittsford-Victor Road, Pittsford NY 14534 http://www.netacc.net/
“Wouldn’t you rather help make history than watch it on TV?” - Jello Biafra