[Tickets #2011] Add Virtual Contact Lists

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=2011
-----------------------------------------------------------------------
 Ticket             | 2011
 Updated By         | kevin_myer at iu13.org
 Summary            | Add Virtual Contact Lists
 Queue              | Turba
 Version            | HEAD
 State              | Accepted
 Priority           | 1. Low
 Type               | Enhancement
 Owners             | 
-----------------------------------------------------------------------


kevin_myer at iu13.org (2005-07-10 19:09) wrote:

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.