CLI RT Questions

I have been looking at the ‘rt’ command and have a few questions.

  1. When I use the CLI ‘rt’, it requires that a few environment variables
    are set RTUSER, RTPASSWD, RTSERVER. Even with ‘Everyone’ having
    permission to create a ticket in a given queue, I have been unable to
    get it to create the ticket without specifying an existing RT user. Can
    I not just set the RTUSER to be the requestor’s email address and leave
    the password blank?

  2. If I have custom fields for a queue, how can I set them through using
    the command line? I saw the ‘set field=val’ parameter, but when I try
    to set a custom field using that method, it says that it is an ‘Unknown
    field.’

Thanks,

Ryan Roland

Application Developer
Information Technology
Division of Recreational Sports
Indiana University

812.855.9617
rmroland@indiana.edu

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 …

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 …

Secondly if we want to create a ticket in rt and have an email sent to a
customer that seems hard to do.

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

Similarily if you have deleted a ticket …

Also I would like to see a ‘delete’ header like the resolve one to make it
easier to get rid of spam.

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.

Regards
Lance

uklinux.net - The ISP of choice for the discerning Linux user.

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.

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’ );

so effectively if I understand right when the customer responds the status
gets set to ‘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.

but then wouldnt the requestor get a copy of any email he sends as well as
2 copies of further correspondence ?? presumably you would need to delete
him as a cc after creating the ticket ??

Similarily if you have deleted a ticket …

Then where would it be sensible for it to take you?

back to the list of tickets you last looked at ??

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.

I’ll look into that …

Thanks for your input :slight_smile:

Lance

uklinux.net - The ISP of choice for the discerning Linux user.

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)’

G’day Lance,
I’ve created additional statuses to handle workflow.

new - Tickets that have been created
replied - Tickets that have been responded to by us
open - Tickets that have been responded to by the client
closed - Tickets that we believe to be finished
resolved - Tickets that the client agrees are resolved

To do this, I adjust the options on the bar at the top of the page when
viewing the ticket. Now when we hit ‘reply’ the status defaults to
’replied’. When they hit ‘reply’ it’s changed to ‘open’. When we hit
resolve it defaults to closed and when they hit resolve it defaults to
resolved.

I can share stuff if you want but it is a simple hack.

Cheers!
Rick

signature.asc (189 Bytes)

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.

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)’

G’day Lance,
I’ve created additional statuses to handle workflow.

new - Tickets that have been created
replied - Tickets that have been responded to by us
open - Tickets that have been responded to by the client
closed - Tickets that we believe to be finished
resolved - Tickets that the client agrees are resolved

To do this, I adjust the options on the bar at the top of the page when
viewing the ticket. Now when we hit ‘reply’ the status defaults to
’replied’. When they hit ‘reply’ it’s changed to ‘open’. When we hit
resolve it defaults to closed and when they hit resolve it defaults to
resolved.

I can share stuff if you want but it is a simple hack.

I would be very grateful …

Regards
Lance

Cheers!
Rick

uklinux.net - The ISP of choice for the discerning Linux user.

Is there any way to make it default to descending instead of ascending
when first opening a queue? Thats the only thing that really annoys me
about the interface

rt 2.0.15 rh 7.3

Rick Measham wrote:>On Wed, 2004-11-03 at 10:07, Lance Davis wrote:

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)’

G’day Lance,
I’ve created additional statuses to handle workflow.

new - Tickets that have been created
replied - Tickets that have been responded to by us
open - Tickets that have been responded to by the client
closed - Tickets that we believe to be finished
resolved - Tickets that the client agrees are resolved

To do this, I adjust the options on the bar at the top of the page when
viewing the ticket. Now when we hit ‘reply’ the status defaults to
’replied’. When they hit ‘reply’ it’s changed to ‘open’. When we hit
resolve it defaults to closed and when they hit resolve it defaults to
resolved.

I can share stuff if you want but it is a simple hack.

Cheers!
Rick



http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

Matthew D. Stevens
Sales and Purchasing
matt@netjam.net

Netjam, LLC http://www.netjam.net
333 Texas St. VISA/MC/AMEX/COD
Suite 1401 90 day warranty
Shreveport, LA 71101

p: 318-212-0245
f: 318-212-0246
Toll Free: 866-2-NETJAM
AIM: Matt At Netjam

matt.vcf (295 Bytes)

Hello Lance,

–Am Dienstag, 2. November 2004 23:07 Uhr +0000 schrieb Lance Davis
lance@uklinux.net:

Secondly if we want to create a ticket in rt and have an email sent to a
customer that seems hard to do.

look here for a ScripCondition that can distinct between inbound and
customer created tickets:

http://wiki.bestpractical.com/index.cgi?AnyTransactionSource

Dirk.

Hello Lance,

–Am Dienstag, 2. November 2004 23:07 Uhr +0000 schrieb Lance Davis
lance@uklinux.net:

Secondly if we want to create a ticket in rt and have an email sent to a
customer that seems hard to do.

look here for a ScripCondition that can distinct between inbound and
customer created tickets:

http://wiki.bestpractical.com/index.cgi?AnyTransactionSource

Thanks - I didnt look in the wiki for stuff - I had looked through the
contrib …

Regards
Lance

uklinux.net - The ISP of choice for the discerning Linux user.

Lance Davis wrote:

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.

I did this last week.
Copy Search/Bulk.html to Search/Bulk2.html.
Search i Bulk2.html and remove CHECKED.
Edit Search/Results.html and add a link beside Bulk.html to Bulk2.html.
/nisse

<±-// \–+>
Datorcentralen Luel� tekniska universitet
Name: Nils-Erik Svang�rd e-mail: nisse@dc.ltu.se
Ph: +46-920-49244 URL:http://www.dc.ltu.se
<±-\ //–+>

Is there any way to make it default to descending
instead of ascending
when first opening a queue? Thats the only thing
that really annoys me
about the interface

rt 2.0.15 rh 7.3

There might be an easier way, but here’s what I did in
RT 2.0.15 to default to descending:

Make changes in 2 places:
/opt/rt2/WebRT/html/Elements/SelectSortOrder
/opt/rt2/WebRT/html/Elements/Quicksearch

In SelectSortOrder:
swap current DESC with ASC, and change order of
"Descending Ascending" in the following:

my @order_names = qw (Descending Ascending);

This simply makes the default page come up with the
new default values.

In Quicksearch:
Modify this line to contain the following 2 items:
&TicketsSortBy=id
and
TicketsSortOrder=DESC

<%$queue->Name%>

Do you Yahoo!?
Check out the new Yahoo! Front Page.