<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Thanks Kevin,<br>
<br>
We've been using the REST API for creating the tickets. We assign
certain critical variables using the values returned by Shibboleth
authentication first:<br>
<br>
<tt>my $your_netid = $ENV{'REMOTE_USER'};</tt><tt><br>
</tt><tt>my $your_full_name = $ENV{'displayName'};</tt><tt><br>
</tt><tt>my $your_phone = $query->param("PHONE");</tt><tt><br>
</tt><tt>my $your_subject = $query->param("SUBJECT");</tt><tt><br>
</tt><tt>my $your_comments = $query->param("COMMENTS");</tt><tt><br>
</tt><tt>my $your_public = $query->param("PUBLIC");</tt><tt><br>
</tt><br>
Set the server and then login using an authorized admin user:<br>
<br>
<tt>my $rt = RT::Client::REST->new(</tt><tt><br>
</tt><tt> server => ($ENV{RTSERVER} ||
'<a class="moz-txt-link-freetext" href="http://our.domain.com">http://our.domain.com</a>'),</tt><tt><br>
</tt><tt> );</tt><tt><br>
</tt><tt><br>
</tt><tt> $rt->login(</tt><tt><br>
</tt><tt> username=> "adminusername",</tt><tt><br>
</tt><tt> password=> "adminpassword",</tt><tt><br>
</tt><tt> );</tt><br>
<br>
Then create the ticket.<br>
<br>
<tt>my $ticket = RT::Client::REST::Ticket->new(</tt><tt><br>
</tt><tt> rt => $rt,</tt><tt><br>
</tt><tt> queue => "General",</tt><tt><br>
</tt><tt> subject => "$your_subject",</tt><tt><br>
</tt><tt> requestor => [$your_netid],</tt><tt><br>
</tt><tt> cf => {</tt><tt><br>
</tt><tt> 'public' => $your_public,</tt><tt><br>
</tt><tt> },</tt><tt><br>
</tt><tt> )->store(text => "$your_comments");</tt><tt><br>
</tt><tt><br>
</tt><tt>my $newticket = $ticket->id;</tt><br>
<br>
To elaborate on the forms further, they were created by someone no
longer with our organization, and modifications were not well
documented (if at all). The action on our old RT instance was as
the "netid" was passed into RT, the account (if it did not already
exist), was created with the username and email set to the netid.
When these forms were moved to the new RT instance, everything was
pretty much the same, except that the email address field was not
filled in. To work around this problem, we tried adding this code
using bin/RT:<br>
<br>
<tt>my $clean_email = $ENV{'mail'};</tt><tt><br>
</tt><tt>$clean_email =~ s/\@/\\@/g; </tt><tt><br>
</tt><tt>$result = `/opt/rt4/bin/rt create -t user add
Name=$your_netid EmailAddress=$clean_email `;</tt><tt><br>
</tt><br>
As I said previously, if you "hard code" in an email for
$clean_email, it works every time as one would expect. If not,
and you pass in the shib variable as shown above, it fails.<br>
<br>
Thanks for any input.<br>
<pre class="moz-signature" cols="72">John
</pre>
On 11/27/12 12:25 PM, Kevin Falcone wrote:<br>
</div>
<blockquote cite="mid:20121127172522.GE1823@jibsheet.com"
type="cite">
<pre wrap="">On Wed, Nov 21, 2012 at 01:24:11PM -0500, John Johnston wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> I've installed RT 4.0.8 on a RHEL 6.2 system and overall it's working fine with one notable
exception. We authenticate users with Shibboleth, and once so authenticated they are able to
create tickets. First time users have their accounts auto-created. We had a previous
instance of RT 3.0.7 and used perl-based forms for ticket creation. Auto-creation of accounts
worked fine, with the displayname, email, and userid returned from Shibboleth and passed to
RT. However, these same forms when used on RT 4.0.8 while they *do* create the account if it
doesn't exist, and it does set the "Name" to the email address, the "EmailAddress" itself and
"RealName" are left blank.
</pre>
</blockquote>
<pre wrap="">
How do your forms create tickets/accounts? Using bin/rt or sending
mail as the user or something else? I can see what you've done with
testing, but knowing how they normally work is helpful.
Unfortunately, without some logs, or a clearer sense of exactly what
runs during the non-debugging form, it's hard to guess at what is
going on.
-kevin
</pre>
<blockquote type="cite">
<pre wrap=""> This means that users cannot get email on their tickets (confirmatory or otherwise), unless an
administrator goes in, selects the account, and manually adds the email address. I've tried
several workarounds, including doing a mysql query to see if the account exists, and if not,
to create it using an RT CLI command encased in backticks. This is contained in our "contact"
ticket creation form. I've experimented with several options, including escaping the "@" in
the email address. Recently, I used Encode to ensure the values obtained from Shibboleth were
converted into UTF-8 before being passed to the RT CLI command, and this *sort of* worked.
Interestingly, it added the account but dropped the letter "e" from the mymail.edu address (to
leave mymail.du). Also interesting, is if I bypass the Shibboleth values and hard code in an
email address like:
my $clean_email = [1]<a class="moz-txt-link-rfc2396E" href="mailto:skippy@mailme.edu">"skippy@mailme.edu"</a>
And pass it to the RT CLI command like:
$result = `/opt/rt4/bin/rt create -t user add Name=$your_netid EmailAddress=$clean_email `;
...again, it works fine.
I've been banging my head on this for awhile. Any insights would be appreciated.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--------
We're hiring! <a class="moz-txt-link-freetext" href="http://bestpractical.com/jobs">http://bestpractical.com/jobs</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>