<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="http://bugs.horde.org/themes/feed-rss.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
 <channel>
  <title>Compose Address-Book blank search patch</title>
  <pubDate>Tue, 06 Jan 2009 21:10:53 -0500</pubDate>
  <link>http://bugs.horde.org/ticket/1854</link>
  <atom:link rel="self" type="application/rss+xml" title="Compose Address-Book blank search patch" href="http://bugs.horde.org/ticket/1854/rss" />
  <description>Compose Address-Book blank search patch</description>

  
  
  <item>
   <title>Hello,

This simple patch allows a user to search and retu</title>
   <description>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&quot; 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&quot; 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.

 </description>
   <pubDate>Sat, 23 Apr 2005 15:47:18 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/1854#t7624</link>
  </item>
  <item>
   <title>The problem is that this then leaves admins with no way to d</title>
   <description>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 &quot;List&quot; 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.</description>
   <pubDate>Sun, 24 Apr 2005 19:59:13 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/1854#t7646</link>
  </item>
  <item>
   <title>I would totally agree that the functionality should exist in</title>
   <description>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.</description>
   <pubDate>Mon, 25 Apr 2005 07:30:45 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/1854#t7660</link>
  </item>
  <item>
   <title>Okay, this is implemented now in IMP (HEAD and FRAMEWORK_3),</title>
   <description>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.</description>
   <pubDate>Thu, 12 May 2005 16:20:50 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/1854#t8151</link>
  </item>
  

 </channel>
</rss>
