Summary | Add turba preference to set which addressbooks to display |
Queue | Turba |
Queue Version | 2.0.2 |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | |
Requester | kevin_myer (at) iu13 (dot) org |
Created | 03/30/2005 (7408 days ago) |
Due | |
Updated | 06/09/2005 (7337 days ago) |
Assigned | |
Resolved | 06/09/2005 (7337 days ago) |
Milestone | |
Patch | No |
compatibility break with the possibility to be very subtle and
annoying. I think what you should do, and even perhaps what we should
do by default or recommend, is to lock the existing preferences in
IMP and Kronolith and use a preferences hook to retrieve the Turba
default_dir value when those prefs are requested.
non-existent Tabbed Browsing feature of Whups to reference back to
your comment and lost it all :)
Even though you do that, you still have the issue that your
'add_source' in IMP is weighted higher than the order you've selcted
for 'addressbooks' in Turba. In my mind, add_source is only defining
which addressbook you want to save addresses to and it should not be
the default selection. In fact, you may not even have it selected as
an addressbook to display. The first addressbook in the Turba
'addressbooks' option should be selected. That's what users expect,
because I had configured localsql to be first and _everyone_ wanted
our main directory first in Turba. And they want that in IMP too.
Thats also where the idea that all Address Book related stuff should
be set in Turba and then the only option set within each module that
uses Turba would be exactly how the data made available from those
sources is used (like what fields to search, for IMP). I myself
thought that the address books selected in IMP controlled what showed
up in the Address Book available from the IMP compose screen but they
only control name expansion functions.
was the original spirit of the ticket resolved? If IMP's contacts
screen behaves properly, I'd say yes. ;)
Kronolith. IMP's got a 'add_source', which in my mind is going to be
the same as Turba's 'default_dir'. IMP and Kronolith both have
address book selection widgets. Would it be a stretch to fold all
address book selection into Turba, and leave IMP's address book
option simply be what columns out of the selected addressbook(s) do
you want searched for address expansion? And do away with address
book selection in Kronolith altogether?
compatibility break with the possibility to be very subtle and
annoying. I think what you should do, and even perhaps what we should
do by default or recommend, is to lock the existing preferences in IMP
and Kronolith and use a preferences hook to retrieve the Turba
default_dir value when those prefs are requested.
Think we can resolve this ticket?
'add_source' as the selected addressbook, although it pulls them in
from Turba in the proper order.
reasonable behavior to me...
'add_source' as the selected addressbook, although it pulls them in
from Turba in the proper order.
compatibility, and lets you move forward as well.
Now addressbooks are also options that can be set in IMP and in
Kronolith. IMP's got a 'add_source', which in my mind is going to be
the same as Turba's 'default_dir'. IMP and Kronolith both have
address book selection widgets. Would it be a stretch to fold all
address book selection into Turba, and leave IMP's address book option
simply be what columns out of the selected addressbook(s) do you want
searched for address expansion? And do away with address book
selection in Kronolith altogether?
If the answer to the question of "when would you need a smaller subset
of your choices in Turba, within an application?" is never, then it
makes sense :) And I know it makes sense in our environment but I
hate to generalize that, because there's always something that I
didn't consider.
should control the order of and which addressbooks are displayed.
'default_dir" should control where you save your stuff (or at least
that was how I was expecting it to behave originally). That
accomodates the situation where 'default_dir' is not included in the
'addressbooks' list, which would cause my earlier assumption about
having the first one be 'default_dir', to break. And you're right,
its not intuitive that the first one is 'default_dir'.
State ⇒ Feedback
default "add" addressbook.
So, how about we move the preference to the new addressbook selection
page, word it so it's clear that it'll be the default address book for
adding contacts to, and make sure that default_dir doesn't affect the
order of any dropdowns?
(thanks to vi's syntax highlighting" but thought nothing of it :)
I think I got the display and selection of addressbooks figured out.
I was assuming that default_dir had to be an addressbook you had to
have write access to, based on the wording (since you can't create
contact lists, for example, in a read-only LDAP directory). Just my
opinion but that should be folded into the addressbook preferences
group and maybe even be made part of the selection code. Whatever you
select as your first addressbook becomes your default_dir, because I
think its kind of redundant to choose the order and which addressbooks
to display, and then to separately choose a default address book.
'addressbooks'? I tried doing 'book1\nbook2', which is what it
appears to be in the horde_prefs table after I set the preference
manually.
them in, for any menu that displays addressbooks, the localsql
addressbook is always the default selection. The addressbooks are in
the right order but the first one is not selected.
options section of the prefs. This definitely needs to be put in a
better place - suggestions?
#2but when I invoke the addressbookfrom IMP, the order of the addressbooks is correct, but the localsql
entry is always selected. What I was anticipating is that if a user
selected the directory server entry first, then any app that used the
addressbook would default to using that first as well.
1) What's the syntax for setting a default preference for
'addressbooks'? I tried doing 'book1\nbook2', which is what it
appears to be in the horde_prefs table after I set the preference
manually. But when I go to the preference screen in Turba, both
addressbooks show as being unselected (although per your note, they do
show up in browse or search mode). I think thats good and preserves
backwards compatibility.
2) Regardless of which addressbooks I select and the order I put them
in, for any menu that displays addressbooks, the localsql addressbook
is always the default selection. The addressbooks are in the right
order but the first one is not selected.
3) Probably the same issue as
#2but when I invoke the addressbookfrom IMP, the order of the addressbooks is correct, but the localsql
entry is always selected. What I was anticipating is that if a user
selected the directory server entry first, then any app that used the
addressbook would default to using that first as well.
State ⇒ Feedback
it's complete/as expected or if anything else needs to be done.
Note that if a user doesn't set this preference, they'll be shown all
address books, to avoid confusing them by showing them nothing.
We want to be able to:
1) sort the order of the addressbook display and,
2) choose which addressbooks to display
Hence "order of and names of available addressbooks". Item 1 affects
the order and Item 2 affects which names display.
We definitely do not want users to be able to rename addressbooks.
be able to customize the name they see for each addressbook? I
understand controlling the order and which, but I'm not sure about
letting people "rename" them.
in all contact/sources. In a setting like ours, it starts to get
computationally expensive to search all sources for FBurl info. So
limiting searches to the preference set in turba would Be A Good Thing.
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Add turba preference to set which addressbooks to display
Queue ⇒ Turba
State ⇒ New
http://lists.horde.org/archives/imp/Week-of-Mon-20050328/041522.html
Add a user preference so that the order of and names of available
addressbooks can be customized and saved. This would affect the Turba
search screen and the IMP contacts screen in the compose window (at
least thats all I'm aware of currently).