Easily assigning "requestor" a username rather tha n an email

RT Users
1

address, I’ll be all set. Thanks a bunch for the heads-up.

Not to confuse you with another option, but we ran into the same problem
here. Since we have a known set of users, we prepopulate the Requestor
field with a drop down list that’s generated from an SQL query. The
displayed value is the full name and the value passed to RT is the email
address. No typing, no confusion.

-matt

Matthew Hanley
mhanley@cxtec.com

2

address, I’ll be all set. Thanks a bunch for the heads-up.

Not to confuse you with another option, but we ran into the same problem
here. Since we have a known set of users, we prepopulate the Requestor
field with a drop down list that’s generated from an SQL query. The
displayed value is the full name and the value passed to RT is the email
address. No typing, no confusion.

That’s a pretty painful way to populate it. Especially if there’s a
schema change or something. You could put something right in the
mason page.

% my $UsersObj = RT::Users->new( $RT::SystemUser );
% $UsersObj->LimitToEnabled;
% $UsersObj->LimitToPrivileged;
% while ( my $CurUserObj = $UsersObj->Next ) {
< your html tags ><% $CurUserObj->Name %> < / your html tags >
% }

Then it’s live information, not something prepopulated.

Andy Harrison

3

That’s a pretty painful way to populate it. Especially if
there’s a schema change or something. You could put
something right in the mason page.

Meant to send this out yesterday. . .this should clear up what we’re doing.
Comments are welcome.

— /opt/rt3/local/html/Ticket/Create.html 2004-10-27
09:20:07.000000000 -0400
+++ /opt/rt3/share/html/Ticket/Create.html 2004-07-12
14:00:53.000000000 -0400
@@ -55,7 +55,27 @@
<&|/l&>Requestors</&>:

-<& /Ticket/SelectRequestor, Name => "Requestors", NobodyName => "Nobody", OptionValue => "Id" &> +

SelectRequestor (618 Bytes)