Hi Kevin, hi all.
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.
One step at a time. Where it does
my @emails = map { $_->get_attribute( $RT::EmailCompletionLdapAttrShow
) } $mesg->entries;
which of course gives for granted $RT::EmailCompletionLdapAttrShow to be
constituted of one element only,
replace with something like
my @emails = ();
foreach $entry ($mesg->entries) {
my $outstring = '';
foreach $attribute ($RT::EmailCompletionLdapAttrShow) {
$outstring=$outstring . $entry->get_attribute($attribute);
}
@emails{$_} = $outstring;
}
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.
Now, this should work but I have a preliminary problem.
You will remember that the search and show variables are configured in
RT_SiteConfig.pm. In my case:
Set($EmailCompletionLdapAttrSearch, [qw/mail cn/]);
Set($EmailCompletionLdapAttrShow, [qw/mail cn/]);
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.
Guess what? If I put a debug print (Dumper) in EmailCompletion.pm to
show the content of the two variables, I get:
This is the dump of EmailCompletionLdapAttrShow = 'cn';
This is the dump of EmailCompletionLdapAttrSearch = [
'mail',
'cn'
];
Do you know why does it happen? I'm assuming I've overlooked
something... but can't tell what.
Thanks,
Giuseppe
PS: Of course, I've tried different variable names and numbers, and it's
always the very first in EmailCompletionLdapAttrShow that gets picked,
which rules out a default value (that would be 'mail', anyway).
On 25/02/11 16:45, Kevin Falcone wrote:
On Fri, Feb 25, 2011 at 04:37:32PM +0000, Giuseppe Sollazzo wrote:
On 25/02/11 15:28, Kevin Falcone wrote:
It shouldn't actually require any JS hacking (or didn't when I last
overrode this extension to do it).
Hi Kevin,
thanks - I'll give it a look.
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.
Uhm... how do you mean "mark"?
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'.
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.
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.
--
____________________________________
Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George's, University Of London
Cranmer Terrace
London SW17 0RE
Email: gsoll...@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583
