Summary | Add Virtual Contact Lists |
Queue | Turba |
Queue Version | HEAD |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | mrubinsk (at) horde (dot) org |
Requester | kevin_myer (at) iu13 (dot) org |
Created | 05/20/2005 (7373 days ago) |
Due | |
Updated | 11/22/2005 (7187 days ago) |
Assigned | 08/23/2005 (7278 days ago) |
Resolved | 11/22/2005 (7187 days ago) |
Milestone | |
Patch | No |
State ⇒ Resolved
read-only) and commited.
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.
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
Books that showup, from my three previous saves.
icons...one for editing the search definition, editing the permissions
and deleting it. Just click on the trash can.
Address Books?
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?
New Attachment: turba.vbooks.patch
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.
State ⇒ Assigned
Assigned to
"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...
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.
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.
"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...
a mix of entries, you could throw an error if you tried to perform an
unsupported event on an item.
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.
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_.
classes of containers.
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?
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.
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?
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.
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)?
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Add Virtual Contact Lists
Queue ⇒ Turba
State ⇒ New
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.