hi pieter,
thanks for the feedback :-)
I've found one bug! When there is only one server, the server-dropdown list is not displayed. This is fine. But, the javascript filling the searchfield requires this dropdownlist! So, when there is only one server, the searchfields are not filled and the searchfunction does not work!!
good catch - fix committed to cvs.
Another thing that confused me, was the $rcmail_config['ldap_public'] config. The default value is false. But I wanted to enable it, so I set it to true. But this doesn't work. It appears that you can set it to false for disabling it, OR specify servers to enable it. I know this is just the way PHP works, but it did confuse me... Maybe a better way, to solve this, is not specify the $rcmail_config['ldap_public'] = false; option in the default config, and that this option is disabled because there aro no servers defined.
or just add a note explaining that in the config file? i don't mind either way.
what do others think?
Few suggestions:
- Could the interface be more integrated with the
addressbookinterface? (Listing the results on the left)
there's a good chance that most of the results returned from a search of a large public ldap server wont be of any interest (eg - typing 'justin' to get my details from our public ldap server returns 11 results, only one of which is me), so automatically adding all results to the list on the left is probably not going to be that useful. i think its better to make it easy to act on the returned results (add to private addressbook or compose mail to) rather than just add them to the list on the left.
its likely that i'm just missing a better way to do it, so i'd be happy if someone could suggest how to get around problems like the one above.
- Could there be a "List all" option?
if the ldap server you are hitting will give you a list of all contacts. this will not be possible for all servers though, and could return very large results, so we would need to page them.
do other people want this as well?
- I do no realy like the Searchfield dropdown. Could there be an
option so that automaticly all fields are searched?
yep, we could even have it so that this is configurable by admins - they can have a choice, or they can set it to automatically search all fields. i'm prepared to implement that if people think it would be useful.
what do others think?
- The searchfields could use aliasses...
could you give me more detail on this point?
- Optional integration with the Autocompletion feature would be great!
this is a tricky one, because the autocomplete works on a javascript array, not by sending keystrokes over the network. i think that the autocomplete would be too slow (even on a quick setup) if it wasn't operating on an in-memory array.
as soon as any returned results are added to the private addressbook, they are available in the autocomplete for composing mail.
one thing that occurred to me: maybe we should make an autocomplete for the private addressbook available in the contacts page. what do other people think?
again, thanks for the feedback. justin
On Sunday 08 January 2006 16:45, justin randell wrote:
- The searchfields could use aliasses...
could you give me more detail on this point?
I've come across a similar thing. I am using two LDAP servers. This means that when the LDAP server is changed "function updateLdapSearchFields(element) " in skins/default/includes/ldapscripts.html is executed, which changes the searchfields options. On lines 37 and 38 of ldapscripts.html: new_option.text = server_fields[i]; new_option.value = server_fields[i];
This means that the text of the options turns to the same as the value, which in my case is "cn" and "mail" However, to most users, "cn" isn't going to mean much. It needs to be instead "Name"
hi jacob,
thanks for the report.
i've committed a fix to cvs - please test it (although it may take a while to reach public cvs).
if you want to test before then, here are the changes:
in program/steps/addressbook/ldapsearchform.inc, change lines 106-109 to:
// store the search fields in a js array for each server $js = ''; foreach ($server['search_fields'] as $search_name => $search_value) $js .= "['$search_name', '$search_value'], ";
in skins/default/includes/ldapscripts.html, change lines 37-38 to:
new_option.text = server_fields[i][0]; new_option.value = server_fields[i][1];
cheers justin
Jacob Brunson wrote:
On Sunday 08 January 2006 16:45, justin randell wrote:
- The searchfields could use aliasses...
could you give me more detail on this point?
I've come across a similar thing. I am using two LDAP servers. This means that when the LDAP server is changed "function updateLdapSearchFields(element) " in skins/default/includes/ldapscripts.html is executed, which changes the searchfields options. On lines 37 and 38 of ldapscripts.html: new_option.text = server_fields[i]; new_option.value = server_fields[i];
This means that the text of the options turns to the same as the value, which in my case is "cn" and "mail" However, to most users, "cn" isn't going to mean much. It needs to be instead "Name"
Justin, I just got the updates from the public cvs and it seems to work now. Thanks a bunch, both for this fix, and for the whole LDAP feature. I'm the webmaster for the Chemistry Department at Brigham Young University, and we were waiting on LDAP integration before rolling Roundcube out (for testing), so this is really great for us. :-) --Jacob
On Tuesday 17 January 2006 16:57, justin randell wrote:
hi jacob,
thanks for the report.
i've committed a fix to cvs - please test it (although it may take a while to reach public cvs).
if you want to test before then, here are the changes:
in program/steps/addressbook/ldapsearchform.inc, change lines 106-109 to:
// store the search fields in a js array for each server $js = ''; foreach ($server['search_fields'] as $search_name => $search_value) $js .= "['$search_name', '$search_value'], ";
in skins/default/includes/ldapscripts.html, change lines 37-38 to:
new_option.text = server_fields[i][0]; new_option.value = server_fields[i][1];
cheers justin
Jacob Brunson wrote:
On Sunday 08 January 2006 16:45, justin randell wrote:
- The searchfields could use aliasses...
could you give me more detail on this point?
I've come across a similar thing. I am using two LDAP servers. This means that when the LDAP server is changed "function updateLdapSearchFields(element) " in skins/default/includes/ldapscripts.html is executed, which changes the searchfields options. On lines 37 and 38 of ldapscripts.html: new_option.text = server_fields[i]; new_option.value = server_fields[i];
This means that the text of the options turns to the same as the value, which in my case is "cn" and "mail" However, to most users, "cn" isn't going to mean much. It needs to be instead "Name"
hi jacob,
great - i'm glad to hear it.
does your department want/need private ldap? that's one of the things on my todo list, and i'd be glad for some help :-)
it would be nice if rcube had the option to use either mysql/postgres or ldap to store contacts.
anyways, good luck with the roll out, and let us know how it goes.
cheers justin
Jacob Brunson wrote:
Justin, I just got the updates from the public cvs and it seems to work now. Thanks a bunch, both for this fix, and for the whole LDAP feature. I'm the webmaster for the Chemistry Department at Brigham Young University, and we were waiting on LDAP integration before rolling Roundcube out (for testing), so this is really great for us. :-) --Jacob
On Tuesday 17 January 2006 16:57, justin randell wrote:
hi jacob,
thanks for the report.
i've committed a fix to cvs - please test it (although it may take a while to reach public cvs).
if you want to test before then, here are the changes:
in program/steps/addressbook/ldapsearchform.inc, change lines 106-109 to:
// store the search fields in a js array for each server $js = ''; foreach ($server['search_fields'] as $search_name => $search_value) $js .= "['$search_name', '$search_value'], ";
in skins/default/includes/ldapscripts.html, change lines 37-38 to:
new_option.text = server_fields[i][0]; new_option.value = server_fields[i][1];
cheers justin
Jacob Brunson wrote:
On Sunday 08 January 2006 16:45, justin randell wrote:
- The searchfields could use aliasses...
could you give me more detail on this point?
I've come across a similar thing. I am using two LDAP servers. This means that when the LDAP server is changed "function updateLdapSearchFields(element) " in skins/default/includes/ldapscripts.html is executed, which changes the searchfields options. On lines 37 and 38 of ldapscripts.html: new_option.text = server_fields[i]; new_option.value = server_fields[i];
This means that the text of the options turns to the same as the value, which in my case is "cn" and "mail" However, to most users, "cn" isn't going to mean much. It needs to be instead "Name"