Lance Davis wrote:
Unless I am missing something fundamental, having been trialling rt for a
couple of weeks there seem to be some obvious things missing / wrong .
Maybe someone could point me in the right direction …
Well, one of the good things about RT is that it is massively customizable,
and indeed, AFAICS intended to be moulded into the specific workflow you
wish to use it in.
Firstly and most important there doesnt seem to be a way to differentiate
between tickets that we last updated and tickets that clients have
responded to. We need to see ones that clients have responded to and
answer their response, but dont need to look at ones that we responded to
In a system that we last used there were two distinct ‘open’ statuses for
this purpose - ‘open support’ and ‘open customer (requestor)’
Otherwise we either have to follow the email threads to see responses and
then find the ticket in rt, or look through all of the tickets, or somehow
hope to remember all the tickets …
An “On Correspond/User defined action” scrip can help here. For example, I’m
doing more-or-less what you suggest above, using the “new” and "open"
Here’s my code:
my $u = RT::User->new($RT::SystemUser);
$self->TicketObj->SetStatus( $u->Privileged() ? ‘open’ : ‘new’ );
Secondly if we want to create a ticket in rt and have an email sent to a
customer that seems hard to do.
Well, you could copy the requestor email address into the “Cc:” box - not
amazingly elegant, but it works.
The other gripes are to do mainly with the user interface and where you
are left after doing things, I think it could be made a lot more user
friendly / intuitive with a little bit of work.
For example if you have merged two tickets, what is the point of leaving
you on the merged away from ticket that doesnt exist any more ??
True enough, I suppose that should go into RT’s own RT as an enhancement
request - assuming it’s not already there, of course.
Similarily if you have deleted a ticket …
Then where would it be sensible for it to take you?
Also I would like to see a ‘delete’ header like the resolve one to make it
easier to get rid of spam.
If you are prepared to do a little work with Perl, you can add one quite
Another minor niggle that is probably easily fixed is that bulk update
starts with all selected, but there is no ‘deselect all’ button, otherwise
I feel that it should start with none selected … or allow you to select
which tickets you sent through to bulk update.
Ditto, enhancement request.