History-Anzeige unterhalb von Account

[vox789]

Die History-Anzeige unterhalb von einem Account enthält unter anderem die Spalte 'Contact'
Leider wird im Falle von Emails dort (unter 'Contact') nichts angezeigt.

Folgendes Beispiel: Aus dem Contact-Modul heraus wird eine Email für einen Contact begonnen zu erstellen (Compose Email).

Im 'Quick Compose' steht dann unter 'Related to' das Modul 'Contacts', daneben der Name.
Da wir später eine History für den Account haben möchten, ändern wir unter 'Related to' das Modul in 'Account' und wählen den dazu passenden Account.

Nach Senden der Email ergibt sich dann folgendes:

Die Email befindet sich in der Account History. Das war zu erwarten, weil wir den Account ja gewählt haben. Leider wird aber der Contact in der entsprechenden Spalte nicht angezeigt.

Weiterhin befindet sich die Email auch in der History des Contacts. Das ist erstaunlich, denn wir haben ja extra im 'Quick Compose' umgeschaltet auf 'Account'. Allerdings ist das Verhalten logisch, denn zu diesem Contact gehört die Email ja. So gesehen ist das Verhalten sogar sehr wünschenswert. Allerdings fehlt auch hier der Name des Contacts in der entsprechenden Spalte.

Hat jemand eine Idee, wie man den Namen des Contacts in der History Liste anzeigen kann? Besonders wichtig wäre die Anzeige in der Account History, da hier ja Emails an mehrere Contacts sichtbar werden.

Im Ergebnis benötigen wir folgendes: Eine History, die ALLES für einen Account enthält, was man mit verschiedenen Contacts 'denn so angestellt hat', also eine Art Vogelperspektive. Wählt man dann einen Contact, erscheint die History für den Contact. Es funktioniert ja auch alles, bis auf das die History für den Account die Namen des Contacts nicht enthält.

Wie kann man das erreichen?

[roblaus]

Sugar mischt hier zwei ganz unterschiedliche Dinge zusammen um den Eindruck entstehen zu lassen dass es logisch wäre - ist es aber nicht.

Die Tabelle Emails enthält einen parent_type (automatisch oder was eben ausgewählt wurde) und eine parent_id (die id des Datensatzes - also in oben erwähntem Beispiel Firma oder Kontakt).
Damit ist auch der Typ der Relation klar - es ist eine 1:n Verbindung und eine E-Mail kann somit gar nicht mehr als einem Datensatz zugehören (könnte auch eine VK Chance oder ein Fall sein).
Die Zuordnung der E-Mail zu einem Kontakt (wenn Account als Relation ausgewählt wurde) ist nur eine view (also wenn man will eine virtuelle Relation) und abhängig von der E-Mail Adresse. Ändert sich diese weil sie mit der Hand überschrieben wurde ist auch die Verbindung zum Kontakt pfutsch.

Um das zu ändern bedarf es einer fundamentalen Änderung des Sugar DB Schemas (also generell weg von den fix verdrahteten 1:n Relationen hin zu n:m) und einer Änderung der Darstellung des Verlaufs. Beides wird wohl nicht so bald gemacht werden schätze ich.

Lösung: eine Zusatzprogrammierung die sich den Kontakt aufgrund der Verbindung über die E-Mail Adresse herausfischt, merkt und dann in Feld schreibt dass es eigentlich gar nicht gibt (das Subpanel Verlauf ist ein ganz eigenes Thema...). Allerdings würde ich dann noch einen Schritt weiter gehen und die Relationen gleich automatisch erstellen...

[vox789]

Herzlichen Dank auch für diese Info.
Langsam kommt Licht ins Dunkel. Ich verstehe, Sugar lässt einen Eindruck entstehen, dass etwas logisch wäre, was aber in der Realität anders ist.
Momentan werden wir Sugar so nehmen wie es ist. Rund um macht das Programm einen hervorragenden Eindruck. Später, wenn wir unsere Strukturen und Anforderungen genauer definieren können, werden wir Programmierungen beauftragen um Dinge zu optimieren, allerdings sehen, dass wir uns nicht mehr als nötig vom Standard entfernen.
Momentan löst der Kinamu Outlook Connector offenbar unser List-View-Problem. Er packt die Emails halt in irgendein Archiv (ich schrieb davon auch in meinem anderen Thread). Wie ist diese Vorgehensweise zu beurteilen? Verbauen wir uns damit etwas für die Zukunft? Interessant ist, dass Kinamu mit den Emails derart anders verfährt als die Standard Sugar Email Ablage. Machen die das, um die List-View vollständig zu haben? Uns ist es letztlich völlig egal, in welcher Form Emails gespeichert werden. Hauptsache, sie sind in beiden List-Views sofort einsehbar, und alle Details sind vorhanden.

[roblaus]

Normalerweise verwendet keiner der am Markt befindlichen Konnektoren irgendwelche speziellen Routinen. Die E-Mail wird über Soap in die Tabelle emails geschrieben (header) mit dem Status "archived". Dann kommen noch x Einträge in email_beans (macht die Relation zu Kontakten, Firmen etc), dann emails_email_addr_rel für die von und zu Adressen und zum Schluss noch emails_text.

Genau das gleiche macht Sugar wenn es selbst E-Mails importiert (=archiviert) oder sendet. Allerdings mit dem Nachteil dass immer nur ein Eintrag in email_beans gemacht wird.

Langer Rede kurzer Sinn: Über die Verwendung eines Tools wie Kinamu oder Opacus verbaut man sich sicher nichts und es läuft alles Sugar konform...

Und zur History Darstellung: Wir haben die für einige Kunden geändert aber das ist weder einfach noch logisch. Deshalb greifen wir das auch nicht mehr an.

[vox789]

Danke auch für diese Nachricht.

was die speziellen Routinen der am Markt befindlichen Konnektoren betrifft, erscheint es mir so, dass Kinamu da schon in irgendeiner Form etwas ergänzt.

Kinamu und Opacus verhalten sich sehr unterschiedlich. Wir haben im Hinblick auf die Funktionen, die wir brauchen, beide getestet. Beide Produkte machen einen guten Eindruck, aber offenbar mit verschiedenen Schwerpunkten.
Der Schwerpunkt bei Opacus scheint zu sein, dass man sehr viel aus Outlook heraus steuern kann. Das ist sicherlich aus der Hauptzweck eines Connectors.
Der Schwerpunkt von Kinamu scheint eher darin zu liegen, Sugar mit gewissen Soap Funktionen zu erweitern, um Dinge zu ermöglichen, die sonst nicht gehen. (... enhances the SOAP Interface in Sugar to enable KINAMU synchronization)

Am Beispiel: Wenn ich in Kinamu eine E-Mail an einen Contact zu einem Account archiviere, ist in der Account History der Contact Name sichtbar, was für uns wichtig ist. Mache ich die Archivierung mit Opacus, so ist der Contact Name nicht sichtbar, so wie es auch der Standard in Sugar ist, wenn ich eine E-Mail eines Contacts zu einem Account 'relate'.

Ein weiterer Unterschied ist, dass es in Kinamu egal ist, ob ich eingehende oder ausgehende E-Mails archiviere, es wird immer der zugehörige Contact UND Account gefunden und angezeigt. Beides ist dann per Check-Box wählbar und archivierbar. Leider lässt sich in Kinamu immer nur eine E-Mail auf die Art Archivieren. Wünschenswert wäre eine Funktion, mehrere E-Mail zu selektieren und zu sagen, immer zu dem jeweiligen Account und Contact zu archivieren.
In Opacus wird bei eingehenden E-Mails der Contact erkannt. Der zugehörige Account muss per Hand gesucht werden. Bei ausgehenden E-Mails sucht Opacus über die Absender-Adresse nach Contacts bzw Accounts und findet logischerweise nichts. Man muss dann sowohl den Contact wie auch den Account per Hand suchen um zu archivieren. Der Vorteil von Opacus ist, dass sich mehrere E-Mails auf einmal archivieren lassen. Diese Funktion haben wir aber nicht näher getestet.