Lotus Notes / Domino Sonstiges > Help-Desk Applikation !!Help!!

Fragen zu 1.0.10

<< < (12/16) > >>

regedit:
Da hängt mehr dran als mir bewußt war.  ???

Kann man denn den Dispatcher so anpassen, dass bei Eingang eines Tickets zusätzlich ein Infomail mit Link an eine Mailadresse gesendet wird, welche über Konfig-Dokumente einem "Failuretype" zugewiesen wird?
Mir geht es lediglich nur um ein Infomail bei dem Ersteingang, dann bräuchte doch außer dem Dispatcher nichts mehr geändert werden, oder?

Thomas Schulte:

--- Zitat von: regedit am 14.11.05 - 09:54:17 ---Da hängt mehr dran als mir bewußt war. ???

Kann man denn den Dispatcher so anpassen, dass bei Eingang eines Tickets zusätzlich ein Infomail mit Link an eine Mailadresse gesendet wird, welche über Konfig-Dokumente einem "Failuretype" zugewiesen wird?
Mir geht es lediglich nur um ein Infomail bei dem Ersteingang, dann bräuchte doch außer dem Dispatcher nichts mehr geändert werden, oder?


--- Ende Zitat ---
Hmm und woher soll der Dispatcher wissen was der Fehlertyp war?

Der würde das doch nur mitkriegen wenn das eingehende Mail ein spezielles Format hätte in dem diese Information mit weitergegeben würde.

Also müssten wir die "HelpdeskAnfrage" Maske entsprechend anpassen um das hinzubekommen, damit der Benutzer schon beim Versenden entscheidet, welches Problem er denn hier hat. Sonst kann ich ja keinen Failuretype auswerten. Diese Anpassung ist nur dann sinnvoll wenn man die "Fehlertypen" Hardcoded in diese Maske reinschreibt. Damit verlierst du die Flexibilität das nahezu alles an dem Teil konfigurierbar ist und zusätzlich musst du immer noch hergehen und die eingehenden Calls trotzdem überprüfen denn alle nicht mit dieser Maske erstellten Calls können ja nicht zugeordnet werden.

Eine  andere Alternative wäre ein Benutzer Frontend in den dieser Calls direkt eintragen kann. Aber auch hier gilt, alles was nicht genau diesen Weg nimmt muss nachgearbeitet und zugeordnet werden. Ich erreiche damit eigentlich keine wirkliche Verbesserung des Ablaufes, eher zusätzliche Komplikationen.

Eine dritte Möglichkeit ist mit unterschiedlichen Mail Adressen zu arbeiten. Quasi pro Fehlertyp eine Adresse. Damit könnte man die Zuordnung erreichen. Ich stell mir das allerdings schwierig vor, den "Kunden" draussen beizubringen "Also wenn du ein Druckerproblem hast dann schickst du das nach HelpDrucker@firma.de und bei Problemen mit Office an HelpMS@Firma.de und bei .... ". Du siehst was ich meine oder?

Letzten Endes müsste man mit Semantischen Netzen arbeiten um das im Dispatcher wirklich sauber und flexibel hinzubekommen. So das der entscheiden kann also das gehört jetzt dahin und das dahin und auf Grund dieser Entscheidung benachrichtige ich da den und da den hier.

Ach ja was ich vergessen habe. Man kann sehr wohl hergehen und den Dispatcher Mails verschicken lassen in der Art "Leute hier ist was neues, kümmert euch darum" Dafür gibt es schon Einstellungsdokumente "NewCallMailInformations", NewCallMailSendTo" und "NewCallMailSummary". Das geht schon, halt nur nicht so wirklich spezifisch.

regedit:


--- Zitat ---
--- Ende Zitat ---
Also müssten wir die "HelpdeskAnfrage" Maske entsprechend anpassen um das hinzubekommen, damit der Benutzer schon beim Versenden entscheidet, welches Problem er denn hier hat. Sonst kann ich ja keinen Failuretype auswerten. Diese Anpassung ist nur dann sinnvoll wenn man die "Fehlertypen" Hardcoded in diese Maske reinschreibt. Damit verlierst du die Flexibilität das nahezu alles an dem Teil konfigurierbar ist und zusätzlich musst du immer noch hergehen und die eingehenden Calls trotzdem überprüfen denn alle nicht mit dieser Maske erstellten Calls können ja nicht zugeordnet werden.

--- Zitat ---
--- Ende Zitat ---

Ich hatte ganz vergessen zu erwähnen, dass ich die Maske Helpdeskanfrage um den Block Anwendung mit den Feldern:
"application", "failuretype" und "failuresubtype" erweitert habe. Diese Felder beziehen Ihre Daten aus der !!HELP!!-DB
(BSP: Application:
 key := "application";
value := @DbLookup( "" : "NoCache" ; "Server":"xxx\\Helpdesk.nsf" ; "($LUConfig)" ; key ; 2 );
value

Wir haben bereits eine einfache Störmeldung-DB, bei welcher unsere Mitarbeiter eine ähnliche Meldung wie bei der abgeänderten Helpdeskanfrage tätigen, so sollte es auch kein Problem sein, wenn die Mitarbeiter so das Problem vorab schon Kategorisieren.

Vielleicht habe ich aber auch das Problem falsch verstanden

Thomas Schulte:

--- Zitat von: regedit am 14.11.05 - 11:19:51 ---
Ich hatte ganz vergessen zu erwähnen, dass ich die Maske Helpdeskanfrage um den Block Anwendung mit den Feldern:
"application", "failuretype" und "failuresubtype" erweitert habe. Diese Felder beziehen Ihre Daten aus der !!HELP!!-DB
(BSP: Application:
 key := "application";
value := @DbLookup( "" : "NoCache" ; "Server":"xxx\\Helpdesk.nsf" ; "($LUConfig)" ; key ; 2 );
value

Wir haben bereits eine einfache Störmeldung-DB, bei welcher unsere Mitarbeiter eine ähnliche Meldung wie bei der abgeänderten Helpdeskanfrage tätigen, so sollte es auch kein Problem sein, wenn die Mitarbeiter so das Problem vorab schon Kategorisieren.

Vielleicht habe ich aber auch das Problem falsch verstanden

--- Ende Zitat ---
Ja und nein.

Wenn du die Maske schon so angepasst hast, dann ist es auch kein Problem bei speziell diesen Dokumenten den Dispatcher daraufhin zu triggern, das er die entsprechenden Leute als Supporter einträgt.
Dazu muss man eigentlich nur das hier "createTicketNotification" so umbauen das die direkten Mails nicht an "NewCallMailSendTo" geschickt werden sondern an "NewCallMailSendTo" + FailureType. Außerdem müsste man newTicketDocumentEntryList um den Schlüssel "FailureType" erweitern und das dann in "ProcessMailTicketsAndResponses" wieder verwenden um da den gleichen Effekt zu erzielen. Nur für den Fall das ihr keine Einzel Mails schickt sondern Summaries. Insgesamt ist das warscheinlich ein halber Tag Aufwand um das sauber hinzubekommen.

Nur, diese Lösung würde ausschließlich bei dir funktionieren und nicht in einer wie auch immer gearteten anderen Umgebung mit anderen Server Namen. Deswegen haben wir da ein bis mehrere Probleme das so in ein Release reinfließen zu lassen.

Fehno:
Ich hab mal noch eine Frage zur Wiedervorlage.
Nachdem ich die hier beschriebenen Änderungen vorgenommen habe, bekomme ich keinen Fehler mehr beim Eintragen des Wiedervorlage-Termins. Aber in meiner Maske wird anschließend beim Status des Tickets "lblTicketStatus" angezeigt (rechts oben) ???

Was fehlt mir da ? Und was bewirkt eigentlich die Wiedervorlage ? Bekomme ich dann ein Mail, dass ich ein Ticket zur Wiedervorlage habe ? Oder sehe ich die Tickets in einer speziellen View (hab aber keine gefunden) ?

Oder bekomme ich einen Kalendereintrag ?
oder, oder, oder ...

Danke im voraus für Eure Antworten...

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete