XML-RPC Inhalt von Emails

  • Hallo Leute,


    muss mich jetzt nochmal an die Community wenden, da ich derzeit ein Problem habe das ich nicht lösen kann.
    Ich habe mein Script von Anlegen einer Neuen Aufgabe über die RPC Schnittstelle nun auf anlegen einer neuen EMail umgestellt. Es Funktioniert auch alles ganz super. Es gibt nur ein kleines Problem mit dem Inhalt der Emails.


    Bei den Aufgaben sah mein Script für den Inhalt so aus


    Das Funktionierte alles gut.


    Wenn ich den Text nun in einer neuen Email haben will ändere ich ja nur eine Zeile

    Code
    1. $call->Properties->Email->EditorData = $text;


    Nun habe ich in meiner Email aber keinen Inhalt.
    Wenn ich aber auf die Mail Antworte die ich anlegen ist der Inhalt in der Antwort wieder da.


    Jetzt dachte ich das Problem liegt daran das die Mail keine HTML Mail ist. folgendes hinzugefügt


    Code
    1. $call->Flags = GhRpcUtils::newSet(rpc_itemslib::ifUseHtml);


    Html Ansicht wird mir angezeigt aber immer noch kein Inhalt.


    In meinem Call sind die Daten vorhanden und bei klick auf Antwort ist der Inhalt auch dort wo er sein soll, nur beim erstellen halt nicht.



    Finde gerade den Fehler den ich mache nicht. Vielleicht kann mir ja jemand weiterhelfen.

  • Hallo,


    leider gibt es in der aktuellen Version der RPC-Schnittstelle noch ein Problem, wenn Elemente vom Typ "E-Mail" mit Status "offen" angelegt werden. Der Inhalt des Elements wird zwar korrekt gesetzt, das Element wird jedoch vom Server nicht gerendert, d.h. der Client zeigt keinen Inhalt an. Bei ausgehenden E-Mails (mit Status "Neu"), Entwürfen oder E-Mails mit Status "Erledigt" tritt das nicht auf, diese werden korrekt gerendert.
    Das Problem haben wir bereits intern auch festgestellt und arbeiten an einer Lösung.


    Bis wir das Problem behoben haben gibt es als Workaround momentan zwei Möglichkeiten:

    • Erzeugen eines anderen Element-Typs (z.B. Telefonnotiz oder Notiz, wobei dann allerdings keine Absender-E-Mail-Adresse gesetzt werden kann, da es sich bei dem Element dann ja nicht um eine E-Mail handelt).
    • Erzeugen der E-Mail mit Status "Entwurf" (das ist die Konstante isDraft). Zusätzlich legt man im GREYHOUND eine Regel an, die als Trigger bei neu erstellten Elementen greift. Die Regel prüft (als Bedingung), ob der Typ "E-Mail" und der Status "Entwurf" ist und ändert dann den Status auf "offen". Zusätzlich macht es Sinn, die E-Mail mit einer speziell dafür angelegten Kennzeichnung zu versehen und auch auf diese in der Regel zu prüfen, damit nicht normal angelegte Entwürfe auch umgewandelt werden. Diese Lösung funktioniert deshalb, weil das Element als Entwurf korrekt gerendert wird und dann der gerenderte Inhalt beim Ändern des Status erhalten bleibt.
      Über die RPC-Schnittstelle lässt sich übrigens der Status einer E-Mail nicht nachträglich auf "offen" ändern (dies quittiert der Server mit einer entsprechenden Fehlermeldung), das ist nur über das Regelsystem möglich.


    Der zweite Weg ist vermutlich der zu bessere, da Du ja das Element sicher nicht ohne Grund als E-Mail anlegen wolltest. ;)
    Ich habe dem Beitrag noch einen Screenshot einer solchen Regel beigefügt:


  • Hallo,


    habe mich für den zweiten Weg entschieden. Funktioniert alles super wen ich die Mail erst als Entwurf anlege und dann per Regel umschreibe.


    Habe ja erst das ganze als Aufgabe, aber hier spielten die Filter nicht mit. Leider haben aufgaben immer den Status Neu.
    Und ich musste sowieso immer eine Kopie als EMail anlegen damit ich auch auf die Aufgabe antworten konnte :)


    Danke für die Hilfe

  • Hi, dieses Thema hat mir selbst schon sehr viel geholfen. Ich möchte an dieser Stelle einhaken und fragen, ob es möglich ist mit Greyhound die neu erstellten E-Mails auch sofort zu versenden, oder müsste man da über eine Regel arbeiten?