Feature request or "how to do this"

We have an MSP group that’s using dcl for their ticketing system and one
feature they have that my guys have asked for is a sort of holding queue for
tickets to go first before deciding if they are actual ticketable items.

We get a lot of automated alerts to RT (by design) and not all of them need
to be ticketable. If there was a way to hold items for the NOC to review
and select which ones to discard and which ones to accept, that’d be great.

Or perhaps there’s already a way to do this?

matthew zeier | “Nothing in life is to be feared.
InteleNet Communications, Inc. | It is only to be understood.”
(949) 784-7904 | - Marie Curie

  • matthew zeier [2003-01-23 13:38]:

We get a lot of automated alerts to RT (by design) and not all of them
need to be ticketable. If there was a way to hold items for the NOC
to review and select which ones to discard and which ones to accept,
that’d be great.

You could simply designate a default queue as the temporary queue, and
then the NOC could either move requests from it into “regular” queues or
kill them.

(darren)

Maybe that’s the only truth in the world. Not the Bibles or poetry or
philosophy but just the old jokes.
– Robert Shea and Robert Anton Wilson

  • matthew zeier [2003-01-23 13:38]:

We get a lot of automated alerts to RT (by design) and not all of them
need to be ticketable. If there was a way to hold items for the NOC
to review and select which ones to discard and which ones to accept,
that’d be great.

You could simply designate a default queue as the temporary queue, and
then the NOC could either move requests from it into “regular” queues or
kill them.

I do that now but I have several thousand tickets that didn’t really need to
be tickets at all.

  • mz
  • matthew zeier [2003-01-23 14:35]:
  • matthew zeier [2003-01-23 13:38]:

We get a lot of automated alerts to RT (by design) and not all of
them need to be ticketable. If there was a way to hold items for
the NOC to review and select which ones to discard and which ones
to accept, that’d be great.

You could simply designate a default queue as the temporary queue,
and then the NOC could either move requests from it into “regular”
queues or kill them.

I do that now but I have several thousand tickets that didn’t really
need to be tickets at all.

Ah, I see what you mean. As an alternative, you could (a) modify
mailgate such that, instead of creating a new ticket (when it doesn’t
find a [$sitename #foo] in the subject), it forwards the message to a
particular email address, and (b) modify the Create A New Ticket page to
send an email to that address instead of creating the ticket. Then, the
NOC folks could monitor that email account (shared IMAP folder, or
something).

(darren)

If I had an infinite amount of monkeys, the first thing I’d do is
delegate a committee of monkeys to figure out how to clean and feed an
infinite amount of monkeys, ‘cause I sure as hell ain’t doin’ it.
– Josh Penn

  • matthew zeier [2003-01-23 13:38]:

We get a lot of automated alerts to RT (by design) and not all of
them need to be ticketable. If there was a way to hold items for
the NOC to review and select which ones to discard and which ones
to accept, that’d be great.

Ah, I see what you mean. As an alternative, you could (a) modify
mailgate such that, instead of creating a new ticket (when it doesn’t
find a [$sitename #foo] in the subject), it forwards the message to a
particular email address,

Put the public RT address ( that the automated alerts send to )behind your
favourite mailing list manager. Juggle the taboo headers setting (or
equivilant) to match subjects without a ticket number. Use your favourite
list manager tools to approve ‘bounced’ postings.

and (b) modify the Create A New Ticket page to
send an email to that address instead of creating the ticket. Then, the
NOC folks could monitor that email account (shared IMAP folder, or
something).

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security

Here’s my take on solving this - readme file is tacked on below. I’d be
interested in any feedback or improvements.

http://www.intelenet.net/contrib/rt-mesage-broker.tgz

//

// Distributed under Version 2 of the GNU General Public License.
//

Introduction

RT Message Broker is meant as a holding ground for incoming messages
from automated sources (HP Openview, for instance) before items become
actual tickets. The NOC’s responisibility is to watch this window and
discard any non-ticketable events or create tickets.

In my environment, HPOV and other automated systems email
rt-mb@intelenet.net. The Message Broker logs into the rt-mb IMAP
account and acts simply as a method to bounce real ticketable items to
RT and discard those that aren’t. This has an added benefit of letting
the NOC discard spam before creating tickets.

I acknowledge there may be a better way to do this. This was tossed
together in a couple hours and could stand some improvements.From: “matthew zeier” mrz@intelenet.net
To: rt-users@lists.fsck.com
Sent: Thursday, January 23, 2003 10:36 AM
Subject: [rt-users] feature request or “how to do this”

We have an MSP group that’s using dcl for their ticketing system and one
feature they have that my guys have asked for is a sort of holding queue
for
tickets to go first before deciding if they are actual ticketable items.

We get a lot of automated alerts to RT (by design) and not all of them
need
to be ticketable. If there was a way to hold items for the NOC to review
and select which ones to discard and which ones to accept, that’d be
great.

Or perhaps there’s already a way to do this?


matthew zeier | “Nothing in life is to be feared.
InteleNet Communications, Inc. | It is only to be understood.”
(949) 784-7904 | - Marie Curie


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

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