Resolved versus Closed


#1

Greetings,

Is it possible to configure RT to send an automatic “template” to the
"requester" when the ticket is closed notifying them that the request has
been closed by the engineer/owner and giving them the opportunity to reopen
the ticket if they are not satisfied with the result.

I once evaluated a product from Intel called REQADM, it had this feature and
also automatically marked the ticket as closed after a predetermined period
of time - forcing a new ticket to be opened if the end user corresponded on
the existing request/ticket number

Any and all comments are always welcome.

Regards
Jens

FYI - REQADM, is a very comprehensive “active” support/request tracking
system with an excellent reporting language/tool - I however, found it far
to verbose and rigid to use in our environment…


#2

Greetings,

Is it possible to configure RT to send an automatic “template” to the
"requester" when the ticket is closed notifying them that the request has
been closed by the engineer/owner and giving them the opportunity to reopen
the ticket if they are not satisfied with the result.

Not with RT1. One of the neat things about RT2 is the Scrips system.
With Scrips, it’s easy to add your own custom logic to do things like that.

I once evaluated a product from Intel called REQADM, it had this feature and
also automatically marked the ticket as closed after a predetermined period
of time - forcing a new ticket to be opened if the end user corresponded on
the existing request/ticket number

The “automated actions based on time passing” thing is one that would be
really cool to have for RT2. Deborah had mentioned a while ago that she might
need to put something like that together for work, but I don’t know if she
ever had time to get it working.

    -j

Any and all comments are always welcome.

Regards
Jens

FYI - REQADM, is a very comprehensive “active” support/request tracking
system with an excellent reporting language/tool - I however, found it far
to verbose and rigid to use in our environment…


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
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
There are no supercomputer applications that are solvable that cannot be solved
in finite time using a fucking TRS-80 with approprite disk/tape drives. Zero.
-Tanj


#3

Greetings,

Is it possible to configure RT to send an automatic “template” to the
"requester" when the ticket is closed notifying them that the request has
been closed by the engineer/owner and giving them the opportunity to reopen
the ticket if they are not satisfied with the result.

Not with RT1. One of the neat things about RT2 is the Scrips system.
With Scrips, it’s easy to add your own custom logic to do things like that.

I once evaluated a product from Intel called REQADM, it had this feature and
also automatically marked the ticket as closed after a predetermined period
of time - forcing a new ticket to be opened if the end user corresponded on
the existing request/ticket number

The “automated actions based on time passing” thing is one that would be
really cool to have for RT2. Deborah had mentioned a while ago that she might
need to put something like that together for work, but I don’t know if she
ever had time to get it working.

I’ve hacked RT 1.0.2 so that resolved tickets are watched by a perl script
running via cron every few minutes until they have been resolved for 2 days.
It then moves them to a queue called closed and then sends the requestor a
survey about the work order.

A few things that would be nice to have in RT is another permission level
between Admin and Manipulate that gives you Admin power, but doesn’t send
you all those emails (as if you were set to the Display level). The other
is the ability to select what emails go back to the requestor. Some of our
users are complaining about the number of emails they get from RT. Just
being able to not have the transactions sent to them would be nice.

-Grant Miller grant@pico.apple.com
Unix Systems Admin, Engineering Compute Services