Fri, 10 Apr 2026 11:23:17 +0000 https://bugs.horde.org/ticket/2011 Add Virtual Contact Lists 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. Fri, 20 May 2005 15:58:12 +0000 https://bugs.horde.org/ticket/2011#t8396 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)? Sun, 10 Jul 2005 22:46:36 +0000 https://bugs.horde.org/ticket/2011#t9620 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. Mon, 11 Jul 2005 02:09:55 +0000 https://bugs.horde.org/ticket/2011#t9622 > 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. 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? Mon, 11 Jul 2005 03:21:17 +0000 https://bugs.horde.org/ticket/2011#t9623 > 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_. Correct. Nothing I said changes the fact that there are multiple classes of containers. > 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? 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. Mon, 11 Jul 2005 10:27:05 +0000 https://bugs.horde.org/ticket/2011#t9646 > 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. 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... >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. 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. Mon, 11 Jul 2005 16:27:39 +0000 https://bugs.horde.org/ticket/2011#t9649 > 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... 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. Mon, 11 Jul 2005 20:44:06 +0000 https://bugs.horde.org/ticket/2011#t9659 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. Tue, 15 Nov 2005 06:22:34 +0000 https://bugs.horde.org/ticket/2011#t13715 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? Tue, 15 Nov 2005 14:06:12 +0000 https://bugs.horde.org/ticket/2011#t13739 > 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. 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 > localsql config to "use_shares", I now have three Virtual Address > Books that showup, from my three previous saves. 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. > And with that as a backdrop then, how do I delete the three Virtual > Address Books? Tue, 15 Nov 2005 15:21:42 +0000 https://bugs.horde.org/ticket/2011#t13740 Removed PERMS_EDIT stuff, (making vbooks and their contents always read-only) and commited. Tue, 22 Nov 2005 16:20:02 +0000 https://bugs.horde.org/ticket/2011#t13936