Mail bei Ticket-Abschluß an andere Personen

[Pjorn]

Hallo,

nachdem wir nun auch !!Help!! einsetzen (wollen), habe ich auch sogleich eine Frage. Zuerst jedoch eine kurze Meldung über die Nutzung: ca. 10 Supporter (First-/Second-/Third-Levelers), keine Nutzung als MailIn-DB.

Da wir die Ticketverwaltung als eine Art "Call-Center" einsetzen wollen (d.h. ein Mitarbeiter erstellt alle Tickets für alle Anfragen von Benutzern), ist ein externer Mailverkehr an die eigentlichen Ticketverursacher zweitrangig. Vielmehr sollen die Benachrichtigungen über abgeschlossene Tickets etc. an die im Config-doc 'DefaultSupporter' bzw. 'SendMailOnBehalf' eingetragene Person gesendet werden.

Gibt es hierfür ebenfalls ein Config-doc oder muss man diese Info im LotusScript bei den einzelnen Aktionen eintragen?

Vielen Dank!
Pjorn

btw: Riesen-Applikation, die Ihr aus dem Ärmel geschüttelt habt. Die Flexibilität ist für Erstkonfigurierer schwer zu durchschauen, aber auf Dauer mehr als gut...

[Thomas Schulte]

Äh nein, wer da jeweils immer benachrichtigt wird ist nicht steuerbar. Wir sind davon ausgegangen, das es immer die definierten Informationswege gibt. In der nächsten Version gibt es eine Möglichkeit bei den Mail Vorlagen einzustellen wer denn zusätzlich noch benachrichtigt werden soll.
Aktuell hast du eigentlich nur die Möglichkeit die Information an dieser Stelle abzuschalten.

[Pjorn]

Schade.
Das wäre für uns brauchbar gewesen, da Fehler für den Kunden "geräuschlos" behoben werden und nur der First-Level-Support, also Erfasser der Tickets, über den Status eines Tickets informiert werden sollte.
So werde ich mich wohl testweise in den LotusScript-Code begeben und mal schauen, ob ich ein oder zwei Zeilen verstehe...

Aber wenn das in der nächsten Version kommt, ist das super. Würde mir hierbei (für unseren Fall)wünschen, dass nicht nur zusätzliche Benachrichtigungen eingestellt werden können, sondern insgesamt alle Empfänger konfiguriert werden können. Aber wahrscheinlich stellt unser Konstrukt den Ausnahmefall dar.

[Thomas Schulte]

Stimmt, das dürfte wohl ziemlich die Ausnahme sein.

So eine Art Stealth Mode gibt es eigentlich schon in der Version 1.5.1 kann man nämlich einen Debug Modus einschalten.
Unter Umständen müsste man das an dieser Stelle noch erweitern.

[Thomas Schulte]

Gehen würde das über die Signaturdokumente. Damit könnte man das Eventabhängig noch einmal steuerbar machen. Wobei da die Logik ziemlich schlimm wird.
Weil woher soll er sich den Namen desjenigen ziehen der da benachrichtigt werden soll.
Mögliche Lösungen:
der eingetragene Supporter,
der Supporter basierend auf irgendeiner Regel (geht aber nur dann wenn du Supporter eingetragen hättest).
irgendein fest eingetragener Wert.

Vielleicht fällt noch jemand anderem dazu etwas ein.

[Pjorn]

Soo schlimm wäre die Logik bei uns nicht einmal.
Wir haben eine Projekt-Maildatenbank, in der (möglichst) die Kommunikation mit unseren externen Kunden abläuft. In diese Mail-DB könnten also auch die Ticket-Status-Mails geschickt werden, da jeder Supporter Zugriff darauf hat (Urlaubsvertretung also schon eingebaut).

Wir brauchen also nur noch eine Unterscheidung, ob das Ticket intern ist, d.h. ob als User ein Name aus unserem Directory eingetragen ist oder nicht, d.h. ein telefonisch erfasstes Ticket.
Im internen Fall soll die Mail an den Directory-Benutzer rausgehen, im anderen Fall einfach in die zentrale Mail-DB. Hab mich im Code schon mal schlau gemacht, ich hoffe ich habe die richtige Stelle identifziert, an der er checkt, ob die Adresse im Directory steht. Wenn so, mache weiter, ansonsten ersetze den Empfänger durch Standard-Supporter.

Mehr Logik brauchen wir nicht, aber so wie mir die DB erscheint, werdet Ihr alles daran setzen, das Ding noch besser, sprich flexibler zu machen (hat mal einer die gesamten Config-Docs gezählt?)

Viele Grüße
Pjorn

[eknori]

hat mal einer die gesamten Config-Docs gezählt?

Bei mir in der Entwicklerversion sind das momentan ca 300