In terms of "healing", right now lists will automatically remove any 
contact from a source that no longer exists. I didn't have it remove 
others because they could just be transitory errors. Of course, the 
source could just be commented out, too, so I'm not even convinced 
that's a good idea.



I think that's it on the issues for this ticket. Let me know if 
there's anything else.

Last column display values are now fixed.

Thats perfect.  I caught the update right after you committed it and 
tested it and it works fine.  Much better than the workarounds we were 
planning on using.

About the Add To ... not being visible problem; now the list appears 
as long as there is at least one source that supports lists that you 
have write access to. You get a create ... option for each one. How's 
that?

Yes, and all the entries are coming from the same source.

For attributes - are you sure that you've set up that you want to see 
the fields that are missing for those sources?



In the Options screen, try Column Options.

undefined edit_url is fixed.

Fix for the undefined edit_url attached - just mimics the code in the 
contactrow.inc template from FRAMEWORK_3.

Couple more problems:



The Edit link is drawn for all entries, even if viewing a read-only 
addressbook.



For all users who are not in the admin array in sources.php, the 
following is returned:

Undefined variable:  edit_url in /horde/turba/templates/browse/row.inc 
on line 37

Further refinement on the disappearing attributes:



For the first entry returned, all attributes are present.



For all remaining entries, all attributes are displayed, EXCEPT for 
the values for the last column.

For browsing list members, it appears the first entry is displaying 
all attributes properly and all other entries, its just pulling in the 
user's name.  I thought originally it was depending on the source, but 
I converted all my contact lists to the new format (which enabled me 
to delete forty duplicated entries from My Addressbook that are in our 
directory).  So the contact lists are SQL based, but contain LDAP-only 
entries and only the first entry is displaying all attributes properly.

I've added the user notifications.



I can't reproduce the problem you're seeing with email addresses - it 
works fine for me.



Also, this isn't perhaps ideal, but adding to new lists (i.e., 
creating a new list) requires you to be viewing an address book that 
supports lists. So if you're viewing an LDAP directory that doesn't 
have the __members and __type elements, you won't see it, but once 
you're browsing a SQL address book, you will. The address book you're 
currently in is the one the list is added to, which is why this is 
necessary.

s/Contact list deleted/Contact entry deleted/ on that last patch 
(didn't realize it was any object it was deleting)

Nevermind on the last one.  It looks like it works with existing 
groups.  Guess I didn't dig far enough in tracing the code.



One more item - when you add one or members to a list, it would be 
helpful to push a notification up the stack (same for list creation).   
The attached patch, browse.patch, provides some feedback to the user, 
beyond a screen redraw :)

Looks good, just a few comments, observations:



Display of lists not pulling in email address.  localsql (My 
Addressbook) and localdap (Shared Directory).  Accounts from localsql 
show email when in list browse mode, but accounts from localldap do 
not.  Expansion of list from within IMP composition window works fine, 
pulling in email addresses from both.



The Add to list option isn't available until you create a list with at 
least one member from your localsql addressbook.



What happens if you delete an entry from another source?  Will the 
list eventually heal itself if it detects that the remote entry is 
gone, perhaps when you save the data?  Would it be useful to have a 
verify contact list feature, to make sure that you don't grow a 
contract group with a large number of dead entries?  Maybe a 
maintenance task could handle this?



How is backwards compatibility with Turba 2.0.X contact groups 
handled?  Are they auto-converted to the new source:uid format?   
Assumed that if no source is specified that it defaults to your 
default addressbook (I'm thinking thats not the case after a quick 
skim over the source).

Implemented in HEAD.

Looking at that code, that's pretty far from committable, plus Turba 
has of course changed some since then. So I wouldn't necessarily use 
that as a base, but it'd be nice to be able to do this, certainly. A 
patch would be great; you could also sponsor a bounty if you'd like to 
help see this done.

About a year and a half ago, Jonathan Soong created a patch that 
allowed a user with a local addressbook (i.e. localsql) to create 
lists/groups of users from multiple sources, including LDAP directory 
servers.  This patch was against Turba 1.2 and is referenced here:



http://lists.horde.org/archives/turba/Week-of-Mon-20030818/003059.html



The current way of creating a list assumes (or actually requires) that 
a user's email address be stored as an entry in the local addressbook. 
  This means needing to replicate data that already exists in a 
corporate directory addressbook and is somewhat unintuitive for 
end-users.



I would like to know if its feasible that Jonathan's original patch 
could be ported to the current release without too much difficulty.   
If it could, would this be a patch that would be feasible for 
including in Turba?  Or is this a bad idea?  The last thing I tried 
was not viewed as a good idea and before I invest any additional 
effort in possibly making this idea work, I'd like to have it 
validated first.



Thanks,

Kevin