Okay, this is implemented now in IMP (HEAD and FRAMEWORK_3), and Turba 
has an option per-source to restrict browsing (which we'll consider 
the same as a blank search) seperate from the export setting.

I would totally agree that the functionality should exist in Turba.   
How about something, similar to the 'export' options in the source.php 
file?  Something like 'allownullsearches', which is either true or 
false.  Leave the behaviour of IMP the way it is, including 
'display_contacts' as a preference, because even if you do want to 
allow searches which return all results, you may not want them being 
done by default, as is in our case.



My patch is more of a hack, which I think we'll use short term, until 
Turba has an option for this.

The problem is that this then leaves admins with no way to 
definitively lock down blank searches. I'd like to see a way of either 
adding a "List" button, enabled if an address book is browseable, or 
at least an implicit check of whether or not an address book is 
browseable when an empty search is submitted.



I could easily be convinced that that latter check should be in Turba.

Hello,



This simple patch allows a user to search and return all results from 
an addressbook, while honoring a default setting of 
'display_contacts'=0 for the initial invocation of contacts.php.



As its worded, the 'display_contacts" preference controls whether an 
initial search is done when a user invokes contacts.php from the 
compose window.  It is stated that you might want to disable and lock 
this, if you have large addressbooks (which we do and which we had 
done).  This reduces creating unecessary load on our LDAP server.



However, if someone does want to search through all entries (maybe 
they want to compose a message with a lot of recipients and prefer to 
choose the receipients all from one list, instead of doing a search to 
find each recipient), they can't do it, because the current 
contacts.php logic is such that if they do a search for a blank entry, 
$search is null and we have locked 'display_contacts" to disable it 
and this prevents the search call from ever being executed.



What I did is simply to modify the formname value and set it to 
contacts.  The first time, contacts.php is called, formname is 
compose, so a blank search will not be permitted unless 
display_contacts is set to 1.  However, if at this point, a user 
decides to do a search with no values, formname is now set to 
contacts, and the user is able to search for and return all entries.



This is an important feature for us, because our legacy email 
application, which we are migrating from, displayed all users by 
default, in its addressbook.  So our users are accustomed to selecting 
addresses from a list.  Our goal is to have them use Expand Names, or 
tab auto-expansion, but for backwards compatibility, we do need to 
have a way to display all addresses.  We don't want to do that by 
default, for load purposes on the LDAP server, but we do want to make 
it available, to help ease migration anxieties.