<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Kevin, hi all.<br>
    <br>
    After a couple of tries I've realised that despite maybe not being
    the most elegant way of doing it, this can be done by modifying
    /opt/rt3/local/plugins/RTx-EmailCompletion/lib/RTx/EmailCompletion/Ldap.pm.
    However I seem to have a "strange" issue.<br>
    <br>
    <br>
    One step at a time. Where it does<br>
    <tt> my @emails = map { $_->get_attribute(
      $RT::EmailCompletionLdapAttrShow ) } $mesg->entries;</tt><br>
    which of course gives for granted  <tt>$RT::EmailCompletionLdapAttrShow</tt>
    to be constituted of one element only,<br>
    <br>
    replace with something like<br>
    <tt>my @emails = ();<br>
          foreach $entry ($mesg->entries) {<br>
              my $outstring = '';<br>
              foreach $attribute ($RT::EmailCompletionLdapAttrShow) {<br>
                      $outstring=$outstring .
      $entry->get_attribute($attribute);<br>
              }<br>
              @emails{$_} = $outstring;<br>
          }</tt><br>
    which basically creates the same output, but after concatenating the
    result of all the attributes. So, for example, rather than having a
    map constituted by only e-mail addresses, it will be e-mail
    addresses + name.<br>
    <br>
    Now, this should work but I have a preliminary problem.<br>
    <br>
    You will remember that the search and show variables are configured
    in RT_SiteConfig.pm. In my case:<br>
    <tt>Set($EmailCompletionLdapAttrSearch, [qw/mail cn/]);<br>
      Set($EmailCompletionLdapAttrShow, [qw/mail cn/]);</tt><br>
    <br>
    I've verified that albeit the search being executed over "mail" and
    "cn", the "show" is ignored. As a debug, I've added file logging to
    /opt/rt3/local/plugins/RTx-EmailCompletion/lib/RTx/EmailCompletion.pm.
    To my understanding, this is the primary "hook" in RT for
    EmailCompletion, and it's the one that calls
    Ldap.pm->search_ldap.<br>
    <br>
    Guess what? If I put a debug print (Dumper) in EmailCompletion.pm to
    show the content of the two variables, I get:<br>
    <tt>This is the dump of EmailCompletionLdapAttrShow = 'cn';<br>
      <br>
      This is the dump of EmailCompletionLdapAttrSearch = [<br>
                'mail',<br>
                'cn'<br>
              ];</tt><br>
    <br>
    Do you know why does it happen? I'm assuming I've overlooked
    something... but can't tell what.<br>
    <br>
    Thanks,<br>
    Giuseppe<br>
    <br>
    PS: Of course, I've tried different variable names and numbers, and
    it's always the very first in <tt>EmailCompletionLdapAttrShow </tt>that
    gets picked, which rules out a default value (that would be 'mail',
    anyway).<br>
    <br>
    On 25/02/11 16:45, Kevin Falcone wrote:
    <blockquote cite="mid:20110225164540.GR95513@jibsheet.com"
      type="cite">
      <pre wrap="">On Fri, Feb 25, 2011 at 04:37:32PM +0000, Giuseppe Sollazzo wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 25/02/11 15:28, Kevin Falcone wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">It shouldn't actually require any JS hacking (or didn't when I last
overrode this extension to do it).

</pre>
        </blockquote>
        <pre wrap="">
Hi Kevin,
thanks - I'll give it a look.

</pre>
        <blockquote type="cite">
          <pre wrap="">You have to hack search in the .pm to return extra data about the user
and the EmailCompletion mason template to print it out.

Be aware that RT considers some data to be sensitive (such as phone
numbers) so it'll refuse to show it unless you mark it as accessible.
</pre>
        </blockquote>
        <pre wrap="">Uhm... how do you mean "mark"?
</pre>
      </blockquote>
      <pre wrap="">
Check the methods in User/User_Overlay named *Accessible to get an
idea, there should be docs there and in DBIx::SearchBuilder about what
is going on.  You'll need a LocalAccessible to declare some fields
'non admin'.

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">In 4.0, this becomes 'write a custom ShowUser option' which isn't
as flexible as I'd like it to be, but is a step forward.
</pre>
        </blockquote>
        <pre wrap="">
I'll check it out - however we'll stay for 3.8 for a while I guess,
but I'll start getting documentation about how to migrate.
</pre>
      </blockquote>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
____________________________________

Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George's, University Of London
Cranmer Terrace
London SW17 0RE

Email: <a class="moz-txt-link-abbreviated" href="mailto:gsollazz@sgul.ac.uk">gsollazz@sgul.ac.uk</a>
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583 

</pre>
  </body>
</html>