[Kolab-devel] distributionlists testing
Gunnar Wrobel
wrobel at pardus.de
Thu Apr 24 15:26:15 CEST 2008
Hi Mike,
Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
> hi gunnar, hi others,
>
> Quoting Gunnar Wrobel <wrobel at pardus.de>:
>
>> Hi Mike,
>>
>> Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
>>
>>> hi gunnar,
>>>
>>> i would like to test your distlist code, but i am not sure how to set
>>> the jigsaw together.
>>>
>>> your external-horde script + patches (which?)???
>>
>> let me commit the stuff to Horde CVS that will be easier. Give me a
>> few minutes ;)
>>
>
> apart from some problems with the current horde/imp CVS and the minor
> bug reported the distlist patch seems to work really fine.
What held it up for me was the fact that adding users did not seem to
work correctly when I tested last time. When I returned to distlists
today I realized that this problem originated from the fact that some
of the users I was trying to add did not have an email-adress.
So I actually implemented part of what you suggest below (the optional
"uid" attribute) since it is required for Turba to work
correctly. Otherwise I get the message "4 users added successfully"
and wonder where they actually are in my contact list :)
This highlights a conceptional problem though: As Bernhard mentioned
in his other mail the Kolab concept of a distribution list is a list
you can send mail to. Turba currently only has the concept of a
general group of contacts. This is of course useful, too, but it is
without a question a different concept.
So if you edit distribution lists in other clients at the moment you
might experience some incompatibilities.
> i would
> like to discuss a feature list around private distribution lists and
> see what is desired, what can be applicable, etc.
>
> o do we want to allow cross address book references in privdistlists? (userA
> in abookA and userB in abookB can both be added to distlistB in abookB or
> distlistA in abookA
The Kolab UID does not allow cross referencing between IMAP
folders. For a globally unique UID that could be used for referencing
you'd need something like
123456 at user/wrobel/Contacts at kolab.example.org which we don't have and
which would turn out to be a really complex topic.
> o move distlistA from abookA to abookB (including users from both abooks?)
> o how about if userA is in distlistA and userA is deleted???
> o kolab format proposal for cascaded distlists and uniquely identifiable
> members:
>
> <!-- Distribution-list specific fields -->
> <display-name>(string)</display-name>
> {<member>
> <display-name>(string)</display-name>
> <smtp-address>(string)</smtp-address>
> <uid>{string, optional}</uid>
> </member>}
> {<distribution-list>
> <display-name>(string)</display-name>
> <uid>(string, not optional)</uid>
> </distribution-list>}
>
> with the kolab format change, we could discuss further issues like:
>
> o add people to privdistlists, that do not have an email address (yet)
Implemented, albeit with the possible cross-client difficulties
mentioned above.
> o remove contacts from an address book, but keep the contact in the
> distribution list (i know, this will be difficult with horde/turba's
> internal abook structure, but other clients like outlook support this)
> o the uid in the member tag and the distribution-list tag would make cross
> abook references much easier to handle as well, same with people having
> multiple emailaddresses
>
> TYK: my basic intent is the following: where i am employed, people
> work with another groupware using outlook clients. i would actually
> like to avoid the next product upgrade of our groupware, but it is
> actually really due. i would be much happier to setup kolab at work,
> but the great hurdle is the - until now - rather weak private
> distribution list support in kolab clients.
Question is if you will be able to get enough overlap between the
concepts of the different clients. Turba sees the list as a group of
existing contacts. This is something different than a list of emails.
If you want a clean solution for this you'll probably need to
implement turba/lib/Object/List.php instead of
turba/lib/Object/Group.php. It would probably be quite similar in a
lot of places but you could ensure that this is really just a list of
Names and E-Mails without being attached to Turba UID's.
Cheers,
Gunnar
>
> for setting up kolab we will need a webmailer, that supports
> privdistlist feature and the privdistlist handling of the webmailer
> should be fully compatible to what people can do with outlook/toltec.
> outlook supports two different kinds of entries in private dist lists:
> object references vs. name+mailaddress entry.
>
> in terms of privdistlists i favourize kolab to catch up with what
> (unfortunately) the majority of groupware (outlook) users is used to...
>
> curious on your feedback,
> mike
>
> --
>
> das netzwerkteam
> mike gabriel, hamburger chaussee 240, 24113 kiel
>
> fon: +49 431 64 74 196
> voip/voicemail: +49 431 643 643 6
> fax: +49 431 64 74 276
> mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
> freeBusy:
> https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list