On 3/30/10 6:02 AM, "A.L.E.C" alec@alec.pl wrote:
Yes, but there also could be e.g. addressbooks with disabled groups creation. Mixing members of SQL and LDAP addressbooks could be problematic. So, after thinking, we should implement groups "per addressbook". Then, would be nice to see groups list below the selected addressbook, like this:
- My Addressbook
- Group 1
- Group 2
- Shared Addressbook
- Group 3
- Group 4
We have a variety of address books - a large read-only campus LDAP directory, the built-in SQL contacts, and a read-only import of contacts from our legacy webmail. I imagine that our users would want to mix and match contacts from any of these sources, so it would be nice if the groups weren't restricted to a single parent resource.
I would actually be fine with groups being somewhat static, in that adding a contact could unlink it from the source address book. Our existing webmail app works like that - groups are simple lists of contacts that have no relation to the contents of the address book. It's not necessarily something to strive for, but the users seem to be OK with it.
-Brad
List info: http://lists.roundcube.net/dev/