<br><font size=2 face="sans-serif">While working on my own customizations
of RT 3.6.1, I've noticed</font>
<br><font size=2 face="sans-serif">a bad interaction between the handling
of e-mail addresses and</font>
<br><font size=2 face="sans-serif">ticket creation.</font>
<br>
<br><font size=2 face="sans-serif">The problem arises if a user's e-mail
address has one of the</font>
<br><font size=2 face="sans-serif">fancier forms, like &quot;Last, First
&lt;username@company.com&gt;&quot;, and</font>
<br><font size=2 face="sans-serif">the user creates a ticket through the
web interface.</font>
<br>
<br><font size=2 face="sans-serif">The web interface puts the address in
the Requestor field, and</font>
<br><font size=2 face="sans-serif">the value from this field is passed
to</font>
<br><font size=2 face="sans-serif">RT::User_Overlay::LoadOrCreateByEmail
to get the User object.</font>
<br>
<br><font size=2 face="sans-serif">This works fine for simple addresses
that look like</font>
<br><font size=2 face="sans-serif">&quot;user@organization&quot;.</font>
<br>
<br><font size=2 face="sans-serif">But with a more complicated address
like</font>
<br><font size=2 face="sans-serif">&quot;Last, First &lt;username@company.com&gt;&quot;,
the real address part gets</font>
<br><font size=2 face="sans-serif">extracted, yielding &quot;username@company.com&quot;,
and this part of</font>
<br><font size=2 face="sans-serif">the address is what's passed to the
LoadByEmail method. The look-up</font>
<br><font size=2 face="sans-serif">fails, because the database contains
the full address, not just this</font>
<br><font size=2 face="sans-serif">part. Then, because the look-up failed,
a new user record is created,</font>
<br><font size=2 face="sans-serif">with &quot;Last, First&quot; as the
user name, and &quot;username@company.com&quot;</font>
<br><font size=2 face="sans-serif">as the e-mail address.</font>
<br>
<br><font size=2 face="sans-serif">This is bad in several ways:</font>
<br><font size=2 face="sans-serif">1) An unnecessary user account gets
created.</font>
<br><font size=2 face="sans-serif">2) The user that account is for doesn't
know it exists.</font>
<br><font size=2 face="sans-serif">3) The new ticket is linked to the new
account, not the one</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; the user knows how to
access.</font>
<br><font size=2 face="sans-serif">4) So the user doesn't see the new ticket
under &quot;Open Tickets&quot;,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; and either tries again,
or concludes that the system doesn't work.</font>
<br>
<br><font size=2 face="sans-serif">One work-around I see is to put a CanonicalizeUserInfo
method</font>
<br><font size=2 face="sans-serif">in User_Local.pm that makes sure that
only the real address goes</font>
<br><font size=2 face="sans-serif">into the database. If we strip the extra
info at the entry stage as</font>
<br><font size=2 face="sans-serif">well as the look-up stage, the look-up
will succeed.</font>
<br>
<br><font size=2 face="sans-serif">But it seems to me that the real problem
is that the web interface is</font>
<br><font size=2 face="sans-serif">trying to make use of the API that's
designed for the mail gateway. I</font>
<br><font size=2 face="sans-serif">don't see any reason why the web interface
should be relying on</font>
<br><font size=2 face="sans-serif">looking up the user's email address:
it already knows the user ID,</font>
<br><font size=2 face="sans-serif">and it should be able to pass that ID
to the CreateTicket routine.</font>
<br>
<br><font size=2 face="sans-serif">In fact, a minor side-effect of this
design is that it's easy to forge</font>
<br><font size=2 face="sans-serif">the Creator of a ticket: since the Requestor
field can be edited by</font>
<br><font size=2 face="sans-serif">users, they can change it to anything
they want, including another</font>
<br><font size=2 face="sans-serif">user's address. I just tried this, and
it worked fine. This isn't</font>
<br><font size=2 face="sans-serif">terribly important (and a user who really
wants to can always forge</font>
<br><font size=2 face="sans-serif">an e-mail message as well), but still,
I'd happy with a system that</font>
<br><font size=2 face="sans-serif">always linked a new ticket with the
user who actually created it ...</font>
<br>
<br><font size=2 face="sans-serif">So, am I missing something here?</font>
<br><font size=2 face="sans-serif">Has anyone got a solution in hand?</font>
<br><font size=2 face="sans-serif">Or should I add this to my list of things
to customize?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">-- </font>
<br><font size=2 face="sans-serif">Harry</font>