[rt-users] rt hard to use

[Max Bowsher]

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
> last.
>
> 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" 
statuses.

Here's my code:

my $u = RT::User->new($RT::SystemUser);
$u->Load($self->TransactionObj->CreatorObj->Id);
$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 
easily.

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

Max.