Gruppeneinteilung für Adressbuch?

    Edit: Es ist nicht sinnvoll, sich an einen Thread zu hängen, der eine nur ähnliche oder sogar andere Thematik behandelt bzw. bezüglich der Ausgangsvoraussetzungen veraltet ist ( :arrow: Erstellen neuer Themen). Ich habe deshalb mit deinem Beitrag diesen neuen Thread eröffnet. Ursprünglicher Thread: Adressbuch - Anzeige in Gruppen?Mod. graba


    Ich finde das eine schlechte Lösung.

    Bei der Synchronisation mit owncloud und Smartphones gibt es Probleme, weil alle gängigen Adressprogramme und -apps Gruppen beherrschen, nur Thunderbird nicht.

    Auch die Suche nach einem bestimmten Adresseintrag gestaltet sich umständlich, wenn man x Adressbücher durchsuchen muss.

    Also ich würde vorschlagen, dass die nächste Thunderbird-Version auch Gruppen unterstützen sollte.

    Hallo,

    Zitat

    Bei der Synchronisation mit owncloud und Smartphones gibt es Probleme, weil alle gängigen Adressprogramme und -apps Gruppen beherrschen, nur Thunderbird nicht.


    Na "Gruppen" heißt das in Thunderbird nicht sondern "Verteiler-Liste" und die gab es auch schon in Thunderbird 1.0 .
    Datei > Neu > Verteiler-Liste.

    Gruß

    Hallo zusammen.

    Das Thema ist zwar alt, aber noch immer aktuell.
    Die "Verteiler Liste"n von Thunderbird haben mit den "Gruppen" der Telefon-Adressbücher nicht das geringste zu tun. Bei der Synchronisation per CardDAV erscheinen weder die angelegten "Gruppen" vom Telefon in Thunderbird, noch werden die "Verteiler Liste"n von Thunderbird im Telefonbuch sichtbar.
    Thunderbird unterstützt nach wie vor diese "Gruppen", wie sie in den Telefonbüchern dieser Welt üblich und gebräuchlich sind, nicht.
    Es sei denn, ich übersehe etwas. Dann bitte ich um Aufklärung.

    MfG, Penni d:-)

    11. Mai 2017

    Debian GNU/Linux 8 (jessie) 64-Bit, Gnome

    OwnCloud 9.1.4 (stable)

    Thunderbird 45.8.0

    Eben habe ich in Thunderbird das Adressbuch von OwnCloud eingerichtet:

    - Verteiler werden als Kontakt übernommen.

    - Gruppen werden gelöscht.

    Ich arbeite mit den Verteilern und den Gruppen und hielt diese Funktionen bisher für normalen Standard.

    » Gibt es hier bereits eine Lösung in Thunderbird?

    » Oder gibt es tolle Alternativprogramme die ihr empfehlen könnt?

    Ich will Evolution ablösen, da Evolution bei mir zwischendurch E-Mails verliert, bzw. beim senden dann nicht speichert. Zudem empfinde ich Evolution als spürbar langsam und (als kleineren Minuspunkt) weil ich die Kalenderdarstellung sehr unschön finde (ich mag es schlicht) und es dazu keine entsprechenden Einstellungsmöglichkeit gibt.

    Danke und Gruss, Poke

    Davon abgesehen, dass dieser Thread uralt ist, verstehe ich schon nicht, was hier mit Gruppe gemeint ist. Mir scheint, hier liegen unterschiedliche Vorstellungen vor.

    Nach meinem Verständnis ist es so:


    Es gibt die eigentlichen Verteilerlisten (Mailing lists, Distribution Lists, Aliase). Das ist jeweils nur eine E-Mail-Adresse, z.B. Mitareiter@Firma.de

    . Der Absender versendet nur eine E-Mail. Die eigentliche Liste und deren Mitglieder werden auf dem Mailserver von Firma.de verwaltet. Dort wird die E-Mail dann entsprechend weiterverteilt. Darauf habe ich als Sender gar keinen Einfluss. Für mich ist das eine einzige Adresse. Im Unterschied dazu gibt es Listen, die nur auf dem jeweiligen Client existieren. Wenn man eine solche Liste benutzt, muss der Client diese in lauter einzelne Adressen auflösen und die E-Mails einzeln versenden.

    Dies sind die Verteilerlisten, wie sie der TB , oder auch andere Clients unterstützen. Das sind aber jeweils eigenständige Lösungen, die nicht untereinander kompatibel sind bzw. sein müssen. In den vCards lassen sich ab vCard 4.0 gemäß RFC 6350 per KIND und MEMBER Groups definieren. Dahinter steckt dann eine vCard pro Gruppe, in der Verweise auf die jeweilgen Mitglieder der Gruppe stecken. Das ähnelt den Listen aus Punkt 2 und kommt vermutlich dem Gewünschten nahe.

    Der TB unterstützt das nicht. Der kennt nicht einmal den vCard-Standard.

    CardBook unterstützt es laut Autor. Sofern man vCard 3.0 benutzt, muss man das aber über benutzerdefinierte Einstellungen erledigen, siehe entsprechenden Tab.

    Ich habe das noch nicht benutzt. Näheres könnt ihr aber sicher beim Entwickler erfahren. Er antwortet in der Regel seht schnell.

    Zuvor solltet ihr aber prüfen, ob sich die anderen Telefonbücher dieser Welt überhaupt an diesen Standard halten. Ansonsten habt ihr lauter Lösungen wie unter Punkt 2 und nichts wäre gewonnen.

    Ich weiß nicht, ob sich z.B. Outlook an diesen Standard hält. Android unterstützt meines Wissens von Haus nicht einmal CardDav oder CalDav ansich sondern benötigt zusätzliche Apps. Die wären dann jeweils einzeln zu prüfen.

    Zitat von SusiTux

    Android unterstützt meines Wissens von Haus nicht einmal CardDav oder CalDav ansich sondern benötigt zusätzliche Apps.

    Nur dazu vielleicht als Ergänzung: Android unterstützt zwar nicht vCard, hat aber einen echten Gruppenbegriff (man kann Kontakten also Gruppen zuordnen). Die Oberfläche dazu ist jedoch uneinheitlich, so kann z.B. die offizielle Kontakte-App erst dann Gruppen anlegen, wenn ein Adressbuch bereits Gruppen enthält.

    Ein Synchronisationstool kann also Thunderbird-Mailinglisten als Android-Gruppen bereitstellen (und umgekehrt), auch wenn es in Thunderbird Beschränkungen gibt: Kontakte ohne E-Mail-Adresse oder mit einer in der Gruppe bereits existierenden E-Mail-Adresse können nicht als Mitglieder einer Mailingliste dargestellt werden. So funktioniert das zumindest mit GeneralSync, wie weit andere Tools entsprechende Funktionen für das Standard-Adressbuch bieten habe ich nicht im Kopf.

    Zitat von generalsync

    Android unterstützt zwar nicht vCard, hat aber einen echten Gruppenbegriff ...

    Lass mich raten: Das Ganze hat, im Gegensatz zu vCard, ein android-proprietäres Format. Der Nutzer hat dann das Nachsehen. Er muss sich nach Sync-Tools umsehen, die damit umgehen können, und wenn Google mal etwas ändert oder der Nutzer gar wechseln möchte, macht er dicke Backen.

    Zitat von SusiTux

    Lass mich raten: Das Ganze hat, im Gegensatz zu vCard, ein android-proprietäres Format.

    Jein. Letztendlich ist es ja ein Implementierungsdetail, wie die Daten intern repräsentiert werden. vCard ist ja kein geeigneter Standard für eine Datenbank, sondern ein Standard für ein Austauschformat.

    Die Kontakte-Datenbank von Android ist für Android-Verhältnisse erstaunlich angenehm umgesetzt, wird allerdings selbst von den Standard-Apps nicht vollständig unterstützt (so deaktiviert die Standard-Kontakte-App z.B. alle Bearbeitungsfunktionen, wenn man in der Deklaration von editierbaren Bestandteilen zu stark von der Funktionalität von Exchange oder Google abweicht). Dort sehe ich viel eher das Problem als in einem fehlenden nativen Austauschformat; letzteres lässt sich ja trivial nachrüsten.

    Man könnte ja auch über Lightning lästern, dass es eine proprietäres Datenbankformat nutzt, und nur beim Im-/Export und dem Austausch mit CalDav-Servern in iCal wandelt.

    Zitat von generalsync

    Die Kontakte-Datenbank von Android ist für Android-Verhältnisse erstaunlich angenehm umgesetzt, wird allerdings selbst von den Standard-Apps nicht vollständig unterstützt ...

    Ja, aus Deiner Sicht, der eines Entwicklers, verstehe ich die Annehmlichkeit durchaus. Aus der Sicht das Anwenders steckt hier aber m.E. das Übel. Ich kann mich nicht darauf verlassen, welche App welche Funktionen umsetzt. Bei einem Wechsel oder einer Änderung habe ich evtl. das Nachsehen.

    An der Steckdose müssen rund 240V anliegen - darauf muss ich mich verlassen können, egal ob der Strom aus Isar 2 stammt, einem Windkraftwerk in Norddeutschland oder der Solaranlage des Bauern nebenan. Ideologisch mag das einen Unterschied ausmachen - technisch darf es das nicht. Deshalb haben wir die Normierung bzw. im Internet das Schichtenmodell mit einheitlichen Protokollen und Austauschformaten.

    Aus Sicht des Anwenders sind die Datenbank und dessen Format daher sekundär. Von denen sollte ich gar nichts spüren. Wenn mein Provider morgen den Mailserver austauscht oder eine andere Datenbank verwendet, bemerke ich davon nichts. Ich kann meine Geräte und Programme ganz normal weiter benutzen.

    Probleme entstehen immer dann, wenn die großen Konzerne ihr eigenes Süppchen kochen und sich einen eigenen Kosmos schaffen.

    Um auf das Ausgangsproblem zurückzukommen, das Format vCard sieht neben den Kategorien auch eine Gruppierungsfunktion vor. Mit CardBook gibt es zumindest für den TB eine Möglichkeit (von mir noch nicht getestet), diesen Standard umzusetzen und die vCards über das Standardprotokoll CardDav (also http) auszutauschen.

    Aus meiner sich erwähnenswert ist noch, dass Apple und Microsoft auf ihren Smartphones CardDav und vCard von Haus aus unterstützen. Ob deren Apps auch von der Gruppierung Gebrauch machen, weiß ich nicht. Aber immerhin halten sie sich an die Norm.

    Zitat von SusiTux

    Aus Sicht des Anwenders sind die Datenbank und dessen Format daher sekundär. Von denen sollte ich gar nichts spüren.

    Genau deshalb mein jein. Nein, da es eine Datenbank ist. Auch bei Apple und Microsoft ist das interne Format nicht vCard, sondern eine Datenbank. An dieser Stelle ist ein eigener Kosmos nichts schlechtes, solange er ausreichend mächtig, dokumentiert und für jeden (Entwickler) nutzbar ist.

    Für den Anwender interessieren diese internen Schnittstellen nicht. Konzeptionell kann unter Android jede App mit den entsprechenden Berechtigungen auf die Datenbank greifen. Ob durch die App nun Google-, vCard- oder GeneralSync-Kontakte laufen ist damit egal. Im Ergebnis kann ich mich als Nutzer darauf verlassen, meine Kontakte-App sowohl mit Google, einer CardDav-App als auch GeneralSync nutzen zu können, sofern sich die App an die Dokumentation des internen Kosmos hält. Das ist der Punkt, an dem ich Google kritisieren würde: Funktionen die in Google und Exchange fehlen sind in den Standard-Apps zum Teil bewusst gesperrt, obwohl sie in der internen Datenbank für Entwickler nutzbar sind.

    Welche Datenbank-bereitstellenden Apps nun vom Hersteller beigelegt werden, variiert. Google stellt z.B. nur Exchange- und Google-Adapter bereit, eine CardDav-Lösung fehlt. Solange eine solche Lösung aber technisch implementiert werden kann und legal vertrieben werden darf, finde ich das akzeptabel. Entsprechend gibt es CardDav-Adapter für Android, die diese Brücke schlagen. Schlimm wäre es hingegen, wenn solche Adapter nicht entwickelt werden könnten oder deren Vertrieb über den Play Store oder andere Kanäle eingeschränkt werden würde. Gerade Apple macht da m.E. eine deutlich schlechtere Figur als Google (aufgrund der Einschränkung von Vertriebswegen).

    Zitat von generalsync

    Auch bei Apple und Microsoft ist das interne Format nicht vCard, sondern eine Datenbank.

    Ja, aber das ist mindestens eine Schicht unterhalb des Protokolls und noch weiter unterhalb des Austauschformates.

    Zitat von generalsync

    Für den Anwender interessieren diese internen Schnittstellen nicht.

    Eben!

    Zitat von generalsync

    Konzeptionell kann unter Android jede App mit den entsprechenden Berechtigungen auf die Datenbank greifen.

    Auch unbestritten. Aber allein der Umstand, dass man auf Nutzerebene eine spezielle App benötigt, die sich dann auch nur mit dieser Datenbank benutzen lässt, ist schon übel.

    Um bei dem Beispiel mit der elektrischen Spannung zu bleiben. Man stelle sich mal vor, Niedersachsen würde ein 240V Spannungsnetz haben und Bayern auf 50V Gleichstrom bestehen. Klar, mit den entsprechenden "Apps", also Wechselrichter usw., könnte man das schon hinbekommen. Aber das wäre doch ein Albtraum.

    Zitat von generalsync

    Funktionen die in Google und Exchange fehlen sind in den Standard-Apps zum Teil bewusst gesperrt, obwohl sie in der internen Datenbank für Entwickler nutzbar sind.

    Was heißt das konkret für das hier diskutierte Problem? Können die Apps, die es zum CardDav-Austausch gibt, KIND und MEMBER nutzen und damit die Gruppen als Listen ins Cardbook bringen, oder wird das schon seitens Google blockiert?

    Zitat von SusiTux

    Ja, aber das ist mindestens eine Schicht unterhalb des Protokolls und noch weiter unterhalb des Austauschformates.

    Ich glaube, wir reden gerade aneinander vorbei: von Android wird nur die oberste Schicht vorgegeben (Datenbank), die von den Kontakt- und Kalender-Apps genutzt werden. Alle Schichten darunter sind Aufgabe von Apps mit sogenannten Synchronisationsadaptern. Die Synchronisationsadapter können dann beliebige Dinge tun, i.d.R. also in ein Austauschformat wandeln und ein Netzwerkprotokoll bedienen.

    Diese Normierung der obersten Schicht ermöglicht es, dass Kalender- und Kontakte-Apps nicht nur mit explizit vom Entwickler unterstützten Lösungen funktionieren, sondern mit allen Synchronisationsprovidern. Wenn Apps das wollen, können sie auch alle Schichten selbst implementieren und sind völlig frei (so z.B. bei mindestens einem Exchange-Client für Android) – können Daten aber nur mit Apps austauschen, die speziell für diesen Datentyp entwickelt wurden.

    Zitat von SusiTux

    Um bei dem Beispiel mit der elektrischen Spannung zu bleiben. Man stelle sich mal vor, Niedersachsen würde ein 240V Spannungsnetz haben und Bayern auf 50V Gleichstrom bestehen. Klar, mit den entsprechenden "Apps", also Wechselrichter usw., könnte man das schon hinbekommen. Aber das wäre doch ein Albtraum.

    Es ist schwer, in deinem Beispiel zu bleiben. Wenn ich es versuchen muss: die Norm ist Hochspannung, und Europa und die USA nutzen in Privathaushalten 240V / 120V mit unterschiedlichen Steckern. Die Stromanbieter müssen für die korrekte Spannung sorgen, die Endkunden können nur Geräte für Ihr Betriebssystem Land nutzen. Letzteres war schon immer so, und stört niemanden.
    Natürlich kann man argumentieren, dass Hochspannung mit einheitlichen Steckern einheitlicher und offener ist, aber sie ist gleichzeitig in Privathaushalten unglaublich unpraktisch. Und ein reines 240V/120V-Netz wäre unglaublich ineffizient. Daher macht es Sinn, beides zu haben. Und da beide Steckertypen/Spannungen für Privathaushalte verschiedene Vor- und Nachteile haben (und natürlich auch, da sich die Stecker/Spannungen historisch entwickelt haben und am Markt etabliert sind!), bleiben auch die unterschiedlichen Normen für Privathaushalte erhalten.

    Zitat von SusiTux

    Können die Apps, die es zum CardDav-Austausch gibt, KIND und MEMBER nutzen und damit die Gruppen als Listen ins Cardbook bringen, oder wird das schon seitens Google blockiert?

    Eine CardDav-App kann eine Gruppen-vCard als "Gruppe" in die Android-Datenbank einfügen und ihre MEMBER entsprechend verknüpfen. Ob und wie sie das tut, ist dem Entwickler überlassen. Google blockiert hier nichts. Problematisch wird es nur, wenn die von Google vorgegebene oberste Schicht eine Information nicht abbilden kann (z.B. kennt Android keine Unterscheidung zwischen einer ausschließlich privaten Mobilfunknummer und einer Mobilfunknummer, die die weder eindeutig privat noch eindeutig geschäftlich ist). Hier muss dann im Einzelfall eine sinnvolle Entscheidung getroffen werden.

    Alternativ kann eine Kontakte-App einen eigenen CardDav-Stack aufbauen und ein eigenes Datenformat nutzen. Andere Apps haben dann jedoch nur Zugriff, wenn sie dieses "eigene" Datenformat kennen UND entsprechende Berechtigungen haben UND die Kontakte-App diesen Zugriff aktiv ermöglicht. Daher wird dieser Weg fast ausschließlich für Apps verwendet, auf deren Daten keine weiteren Apps zugreifen sollen.

    Zitat von generalsync

    Google blockiert hier nichts.

    Wenn Du (oder jemand anderes) jetzt noch eine App kennst/kennt, dann wären wir fast am Ziel. Zusammen mit Cardbook sollte es dann möglich sein, diese Gruppen im TB abzubilden.

    Zitat von generalsync

    kennt Android keine Unterscheidung zwischen einer ausschließlich privaten Mobilfunknummer und einer Mobilfunknummer, die die weder eindeutig privat noch eindeutig geschäftlich ist

    Genau das sind solche Ärgernisse.

    Noch etwas Off-Topic:

    [OT]

    Zitat von generalsync

    von Android wird nur die oberste Schicht vorgegeben (Datenbank)

    In allen Modellen zu Softwareschichten, die ich kenne, ist die Datenbank die unterste Schicht. Darüber kommen dann der Access-Layer, für den Zugriff auf die Datenbank, die Logik und schließlich der Präsentationslayer.

    Zitat von generalsync

    die Norm ist Hochspannung

    Natürlich gibt es auch dafür Normen. Aber das passt nicht zu meinem Beispiel. Die Hochspannung dient ja nur dem Transport und ist nicht für den End-Verbraucher gedacht. Im Kontext meines Beispiels wäre das Hochspannungsnetz eher mit mit den Leitungen bis zum Router zu vergleichen.

    Wenn die in Deutschland geplanten neue Stromtrasse Gleichstrom übertragen werden, muss ich mir als Endverbraucher deshalb ja keine neuen Geräte kaufen. Die Energieversorger müssen sicherstellen, dass in den Haushalten weiterhin 240V Wechselspannung anliegen.

    So sollte es idealerweise auch bei den Kalendern sein: Egal bei wem ich meine Daten ablegen und welche Datenbanken dort benutzt werden, das Endgerät beim Verbraucher sollte sozusagen stets die 240V bekommen.

    Google und Android machen da nicht mit. Bei denen muss ich mir, bildlich gesprochen, einen Transformator kaufen.

    [/OT]

    Zitat von SusiTux

    Wenn Du (oder jemand anderes) jetzt noch eine App kennst/kennt, dann wären wir fast am Ziel.

    Ich dachte, DavDroid könnte das. So gibt es entsprechend aussehende Klassen im Quellcode. Ob diese genutzt werden, weiß ich nicht, aber ich bin bisher davon ausgegangen. Ich hatte irgendwie im Kopf, wir hätten das "wie" hier schon geklärt und es geht nur noch um das "warum" einer separaten Dav-App.

    [OT]

    Zitat von SusiTux

    In allen Modellen zu Softwareschichten, die ich kenne, ist die Datenbank die unterste Schicht

    In Netzwerkschichten ist die Anwendung oben (und die Datenbank ist hier die direkte Schnittstelle zu den Apps). Wenn ich nochmal drüber nachdenke ist die Netzwerksicht für diese Diskussion tatsächlich nur bedingt passend, ist nur eben die Richtung aus der ich entwickle.

    Zitat von SusiTux

    Die Hochspannung dient ja nur dem Transport und ist nicht für den End-Verbraucher gedacht.

    Genau: vCard / CardDav ist nur für den Transport gedacht, und nicht für die interne Verwendung in Anwendungen. Darum ging es mir in meiner (vielleicht verunglückten) Anpassung deiner Analogie. Natürlich wäre es aus Nutzersicht schön, wenn eine Windows-Anwendung auch unter Android liefe (also auch die "Spannungen für Endverbraucher" normiert wären), aber das ist wenig realistisch, schon allein wegen der unterschiedlichen Anforderungen der Geräteklassen und Nutzergruppen.

    Wird der Transport-Standard getauscht (z.B. Google-proprietär gegen GeneralSync) funktionieren Apps weiter ("keine neuen Geräte kaufen"). Wird das Betriebssystem gewechselt ("in Land mit anderer Spannung ziehen"), braucht man neue Apps ("Geräte neu kaufen"), kann aber den Transport (und damit die Daten) weiter benutzen ("es gibt immer noch Strom"). Gerade im letzteren Fall hinkt die Analogie natürlich gewaltig, aber ich hoffe der Punkt wird klarer?

    [/OT]

    Zitat von generalsync

    Ich dachte, DavDroid könnte das.

    Dann wäre es ja möglicherweise ganz einfach. Das sollte dann einer der "Beschwerdeführer" mal aufsetzen und dann ausprobieren, welche der Eigenschaften, die in vCard möglich sind, auch tatsächlich unterstützt werden.

    Hallo zusammen,

    ich hab diesen Faden hier gelesen , bin mir aber nicht sicher ob ich das richtig verstanden habe. Kann man zusammenfassend sagen das Gruppen, welche auf einem Android Smartphone erstellt wurden, nicht via CardDAV (z.B. Davdroid) übertragen werden? Folglich werden sie auch nicht in TB Cardbook auftauchen?

    Umgekehrt gibt es in Cardbook "Kategorien". Diese werden ebenfalls nicht via CardDAV übertragen, richtig?


    Danke.

    Hallo Herrman-san,

    Gruppen die in einem Smartphone erstellt werden, werden in Cardbook übernommen und umgekehrt auch.

    Ich benütze ContactSync ist nicht kostenlos aber sehr gut.

    Gruß EDV-Oldi vvomSmartphone

    Hallo EDVoldi,

    ich benutze Davdroid , welches auch gut ist und für mich nicht kostenlos war. :)

    Jedenfalls, danke für deine Tipp mit ContactSync :thumbsup:

    offensichtlich hab ich eine Oldi-Version von Davdroid auf meinem Androiden , denn inzwischen gibt es wohl auch mit DAVx5 (ehemals Davdroid) Unterstützung für Kontaktgruppen und Kategorien.

    Grüße,

    Hermann-San

  • Community-Bot 3. September 2024 um 20:10

    Hat das Thema geschlossen.