Removed PERMS_EDIT stuff, (making vbooks and their contents always 
read-only) and commited.

Argh.  I had a check to only allow drivers with use_shares=true to 
offer the vbook option in an earlier implementation that didn't work 
out.  Must've gotten lost in the shuffle ;)  I'll put those checks in.



After I switched my
Display the share.  In the header the share, you;ll see three 
icons...one for editing the search definition, editing the permissions 
and deleting it.  Just click on the trash can.

Michael,



A couple of issues:



If "use_shares" is not set to true, the driver will go through the 
motions of saving the search but throw an error.  After I switched my 
localsql config to "use_shares", I now have three Virtual Address 
Books that showup, from my three previous saves.



And with that as a backdrop then, how do I delete the three Virtual 
Address Books?

Any objections to me starting to commit these changes so it can be 
tested on a wider scale?



To make a long story short -

Virtual address books implemented for sources that support (and are 
using) Horde_Share.  The vbook information is stored as a share and 
can be assigned permissions independent of the parent source.  Other 
applications that access Turba via the api will see the vbook as a 
seperate source.

I cringe at the word "virtual", but thats just from a long history of 
seeing it overused :)  The need to somehow differentiate or categorize 
different elements has become apparent.  I have a bit of a 
photographic memory, so I probably wouldn't forget which are the 
"virtuals" but thats probably not to be expected of a typical user.  I 
concede the point.



There are a couple of edge cases where the UI (or at least the behind 
the scenes code) does provide the kind of problem you described - for 
instance, if your first address book is not browseable, and you choose 
Browse, Turba will try to load that and will error with a message that 
its not browseable, but will happily return a list of browseable 
address book in the upper right hand corner.  Better to only try 
browsing browseable address books, instead of trying to browse a 
non-browseable one, returning an error a few seconds later, and 
providing a menu of browseables from.  I'll try to catalog these in 
the next few days.

IMO, it would be confusing for a typical user to just see a list of 
"containers" that they have access to, yet in different areas of Turba 
some of those lists would be there, and other times they wouldn't be.   
If you don't differentiate them to the user, he/she would have no way 
of knowing why sometimes the "Building A" list is displayed and 
sometimes it's not.   Your also leaving it up to the user to remember 
on their own which lists are the "virtuals" that they created...
Again, I think this would be much more confusing to the user as to why 
he/she is getting errors when performing tasks on only some sources.   
IMO, this would be like not telling a user that an addressbook is 
readonly until he tries to write to it...when we give him an error.   
He has just wasted time and effort on something the UI should have 
told him wasn't doable from the beginning.

Correct.  Nothing I said changes the fact that there are multiple 
classes of containers.
Right, per above, the fact that different types of containers exist is 
a fact, but can that maybe be handled in code?  I would anticipate 
that Turba would become contextually smart and not show UI elements 
that don't make sense.  In the case where you have to show options in 
a mix of entries, you could throw an error if you tried to perform an 
unsupported event on an item.

Except that they *are* different to the user. Unless you do away with 
non-search-based address books (or folders) entirely, you have two 
classes of containers - ones that magically find things, and ones that 
you can actually put things _into_.



UI components like Add show non-virtual addressbooks; it's meaningless 
to add a contact to a virtual contact list. Same for move to, remove 
from this list, etc. So you have to make a distinction to the user, no?

Well, on one hand, you would be consistent with IMP if you used a 
Virtual Group analogy.



But....



I tend to think that it would be truly innovative to due away with the 
whole Virtual tag and make folders and groups and other virtual 
entities be transparent to the end user.  What is a traditional IMAP 
folder?  Its generally a collection of associated messages in a folder 
(or a single file) on a mail server.  Does a user know that?  Nope - 
they just see a representation of that.  So blur the whole concept of 
folder - move it away from mapping physical units on a mail server, to 
logical grouping of messages - there's no need to draw attention to 
the fact that one is virtual and another is not.



For groups, there's no need to distinguish between a hard coded list 
of addresses, and a list that is dynamically generated real-time, from 
multiple sources by designating one as Virtual and one as You Typed 
These In Yourself :)  The only thing that is needed is a way for a 
user to assign labels to what are effectively search queries.  Again, 
it doesn't matter how the various discrete entries are physically 
stored - we're after the logical representation of them to the user.



I'll explain the context of the request, so you can maybe better 
understand how I ended up with it.



Our legacy email client (legacy is being too kind) supports the 
concepts of Address Books and Address Groups.  An Address Book is 
physically a file, that contains addresses or entires.  An Address 
Group is an entry that contains a collection of addresses.  And its 
fully decentralized - add an entry to whoever is in charge of keeping 
the master copy and send the new file out to all employees, hope they 
install it properly, and too bad if they happen to be using something 
else for email (like, oh, say IMP).



Fast forward to a transition to IMP and Turba on FRAMEWORK_3.   
Paradigm shift the concept of an address book from being a physical 
file, with entries, to being a configured source in turba with hard 
coded search critera.  You end up with the same result as you had 
before, but its fully centralized, real-time and requires no user 
intervention.  Because we are storing additional information about 
people, like titles, building location, etc. we'll also have another 
source that makes available address groups, which are really just 
hard-coded searches based on title, location, etc., that we think will 
be useful to people.



But people will still want a subset of those groups, so thats where a 
"Virtual" Contact list comes in.  It places in their power the ability 
to create an entry with user-definable search criteria.  And they 
don't need to maintain it - when we add a new person in a certain 
building that is a support staff class, for instance, if they have 
that search criteria setup for all support staff in that building, the 
user would be returned with their results.



So thats what spawned the idea and a history of address books here.



Its a continuim:



localsql (w/ personal address books and point n click contact lists) 
-> Sympa mailing lists w/ LDAP queries (for access control - not 
everyone should be able to send their pet messages to all of our 
users, using a simple alias) -> LDAP directory (all employee entries)



The addition of a Virtual Contact list would cover just about every 
possible way that an individual would want to keep or access 
individual or group addresses.  The only thing missing at that point 
would be a bonafide Turba Share, so I could share my logical grouping 
and personal entries with others who might use them, with the end goal 
being non-duplicative address data.



So back to the question, after that ramble.  Its a design decision - 
if you wish to keep distinguishing between virtual and real, then this 
would be implemented as Virtual Contact Lists.  My argument would be 
that everything is just a representation of something else, so take a 
blackbox approach behind the web GUI and present them all as equal to 
the user.  In other words, an alias that a user has setup that 
consists of a search for all staff in building Y who are in department 
X would look no different than a list they built by searching for 
individual addresses and putting them in a contact list.  IMP is blind 
to whether the list is "virtual" or not.  So make it be that way to 
the Turba user as well.

I was thinking of playing around with this request, but want to 
clarify what you want.  Should the virtual contact list be a turba 
group or should it appear as a seperate source (more like imp's 
virtual folders)?

Add ability to allow user to save arbitrary searches and use the 
results of the search to generate a contact list.  This idea is akin 
to the Virtual Folders option in IMP and would let search criteria do 
the work of creating the list, and not have the user need to choose 
each and every member of the list manually.