Fragen zu 1.0.10

[Thomas Schulte]

Das grundsätzliche Verhalten steuert man über die ViewOn.... Parameter und in diesem Speziellen Fall über ViewOnOpen.
zusätzlich dazu kann man noch für bestimmte Benutzer einstellen welchen Frameset sie beim Öffnen mit welcher Ansicht sehen sollen.
Das ist dann mit
STARTFRAMEVorname Nachname zu machen. Als Wert muss da der Name des Frames gefolgt von einem # und dem Namen der zu öffnenden Ansicht drinstehen. Z.B. FS-HELPCENTER#ViewName

[baces]

Wenn ein Ticket abgeschlossen wird, bleibt die Aufgabe im Menü "Annehmen (x)" enthalten ... wie verschwinden denn da abgeschlossene Aufgabe von abgeschlossenen Tickets?

Hmm ein Ticket kannst du eigentlich nur dann abschliesen, wenn alle dazu gehörenden Aufgaben bereits abgeschlossen sind. Beim Akzeptieren der letzten geschlossenen Aufgabe wird automatisch das dazugehörende Ticket geöffnet.
Wenn ich jetzt das Ticket abschließe, ohne das Schließen der Aufgabe akzeptiert zu haben, dann kann ich ohne irgendwelche Folgen befürchten zu müssen das Schließen der Aufgabe immer noch akzeptieren.
Da ist zwar eine "Bedienungslücke" vorhanden aber die akzeptiere ich jetzt einfach mal.

Aber ich blick einen Punkt immer noch nicht ganz  Wann verschwindet der Eintrag aus "Aufgabe in Bearbeitung" -> Annehmen wieder, denn die Teilaufgabe ist ja auch schon in der View abgeschlossene Tickets -> Aufgaben abgeschlossen enthalten   

Wir haben immer noch dieses Problem. Bei uns füllt sich die View Annehmen immer mehr. Wir hätten gerne, dass Aufgaben von abgeschlossenen Tickets aus dieser View verschwinden, bekommen es aber nicht ordentlich gebacken.

Ich stelle mir es in etwas so vor (Pseudo-Code):
SELECT ((Form = "BugTodo":"BugReport") & (BugTodo.Status="99" | BugTodo.Status ="98") & (BugReport.Status!="99") & (@IsAvailable(BugTodo.AcceptCloseStatus) &  BugTodo.AcceptCloseStatus = "1"))

Natürlich haut das so nicht hin, aber ich hoffe es verdeutlicht unser Vorhaben, im View Annehmen nur abgeschlossene Aufgaben von NICHT abgeschlossenen Tickets haben wollen.

Alternative wäre vielleicht, dass abgeschlossene Aufgaben von abgeschlossenen Tickets ihren AcceptCloseStatus auf 0 gesetzt bekämen. Dann würden sie ja mit der original Selection auch nicht mehr im View auftauchen.

ne Idee?

danke & grüße

[Thomas Schulte]

Also das eine ist einfach mal die Tatsache das ihr scheinbar diese Aufgabe des "Jawohl die Aufgabe (Todo) ist abgeschlossen und irgendjemand muss das jetzt auch noch einmal abnicken" (Accept Close) nicht tut. Deswegen sammelt sich das nämlich in dieser Ansicht an.
Wenn ihr das wirklich nicht wollt, dann könnt ihr folgendes tun.
Setzt den Parameter "UseTodoAccepting" auf "NO" dann wird das Steuerungsfeld für das Akzeptieren des Abschlusses einer Aufgabe nicht mehr gesetzt. Damit muss dann der Helpdesk für sich selber entscheiden, ob ein Ticket (Call) insgesamt abgeschlossen werden kann.
Um die Daten aus der Ansicht rauszukriegen reicht dann ein einfacher Agent der das Feld AcceptCloseStatus auf "0" setzt oder löscht.

[baces]

Also das eine ist einfach mal die Tatsache das ihr scheinbar diese Aufgabe des "Jawohl die Aufgabe (Todo) ist abgeschlossen und irgendjemand muss das jetzt auch noch einmal abnicken" (Accept Close) nicht tut. Deswegen sammelt sich das nämlich in dieser Ansicht an.

Hi Thomas,

jetzt muss ich mich entschuldigen aber ich blicke es auf keinem Augen mehr

Ich gehe das jetzt nochmal durch, denn entwender ich verstehe den Sinn von "Annehmen (x)" nicht oder ich verstehe deine Antworten nicht
Deswegen nochmal von vorne...

1. Wir wollen Annehmen benutzen, denn wir wollen, dass abgeschlossenen Aufgaben von irgendwelchen externen Suportern (die können die Aufgabe ja abschliessen) nochmal von uns "abgenickt" werden müssen. Soll heissen ... wir wollen deren fertige Lösung nochmal prüfen, bevor wir die Lösung freigeben und somit auch das Ticket zur Schliessung freigeben.
2. Dazu dachten wir, gibt es dann in "Annehmen (x)" einen Button, mit dem man diese abgeschlossene Aufgabe abnicken (Bestätigen) kann ... und dann kann man erst das Ticket abschliessen
3. Da hast du schon gesagt, dass es das nicht gibt, dass man da halt "Mitdenken" muss.....
soweit so okay

aber wieder die Fragen:
1. Was für einen Sinn macht dann "Annehmen (x)" wenn dieselben abgeschlossenen Aufgaben, auch im View "zu geschlossene Tickets wechseln" --> "abgeschlossene Aufgaben" enthalten sind?? Bei uns ziegen diesen beiden Views im Moment das gleiche an (auch wenn die Select-Condition von annehmen erweiter ist)

2. An die erste Frage schliesst die zweite an. Was macht Annehmen für einen Sinn, wenn da NICHT NUR die abgeschlossenen Aufgaben von nicht abgeschlossenen Tickets enthalten sind? ...denn das sind ja genau die Aufgaben die ich abnicken möchte.
Abgeschlossene Aufgaben von abgeschlossenen Tickets machen in der Annehmen-View in meinen Augen keinen Sinn, da ich diese ja nicht mehr abnicken muss, weil das dazugehörige Ticket eh schon abgeschlossen ist. Dafür ist ja dann die View "abgeschlossene Aufgaben" da.

Und deswegen wollte ich, abgeschlossene Aufgaben von abgeschlossenen Tickets aus "Annehmen (x)" ausblenden (siehe Frage von gestern)

Wie gesagt, ich stehe hier total aufm Schlauch ... und mein Arbeitskollege auch

Ist denn meine Interpretation von "Annehmen (x)" total falsch??
Großen Dank für jede Klärung

viele Grüße,

[Thomas Schulte]

1. Wir wollen Annehmen benutzen, denn wir wollen, dass abgeschlossenen Aufgaben von irgendwelchen externen Suportern (die können die Aufgabe ja abschliessen) nochmal von uns "abgenickt" werden müssen. Soll heissen ... wir wollen deren fertige Lösung nochmal prüfen, bevor wir die Lösung freigeben und somit auch das Ticket zur Schliessung freigeben.

Okay dann dürft ihr den Parameter natürlich nicht ändern.

2. Dazu dachten wir, gibt es dann in "Annehmen (x)" einen Button, mit dem man diese abgeschlossene Aufgabe abnicken (Bestätigen) kann ... und dann kann man erst das Ticket abschliessen

Den Button gibt es auch, aber nicht in der Ansicht annehmenselber, sondern in der Aufgabe (Todo). Dort ist die Aktion in der Regel mit "Schließen Akzeptieren" oder was auch immer ihr hinter die msgTodoActAcceptClose im Sprachdokument gelegt habt bezeichnet. Ein Klick auf diese Aktion setzt dann den Status auf 2 um und damit verschwindet das auch aus dieser Ansicht wieder. Gleichzeitig wird mit protokolliert wer das denn akzeptiert hat.

1. Was für einen Sinn macht dann "Annehmen (x)" wenn dieselben abgeschlossenen Aufgaben, auch im View "zu geschlossene Tickets wechseln" --> "abgeschlossene Aufgaben" enthalten sind?? Bei uns ziegen diesen beiden Views im Moment das gleiche an (auch wenn die Select-Condition von annehmen erweiter ist)

Diese Views zeigen nur dann das gleiche an wenn eben diese Aktion "Schließen Akzeptieren" in der Aufgabe nicht durchgeführt wird.

2. An die erste Frage schliesst die zweite an. Was macht Annehmen für einen Sinn, wenn da NICHT NUR die abgeschlossenen Aufgaben von nicht abgeschlossenen Tickets enthalten sind? ...denn das sind ja genau die Aufgaben die ich abnicken möchte.
Abgeschlossene Aufgaben von abgeschlossenen Tickets machen in der Annehmen-View in meinen Augen keinen Sinn, da ich diese ja nicht mehr abnicken muss, weil das dazugehörige Ticket eh schon abgeschlossen ist. Dafür ist ja dann die View "abgeschlossene Aufgaben" da.

Und deswegen wollte ich, abgeschlossene Aufgaben von abgeschlossenen Tickets aus "Annehmen (x)" ausblenden (siehe Frage von gestern)

Wie gesagt, ich stehe hier total aufm Schlauch ... und mein Arbeitskollege auch

Ist denn meine Interpretation von "Annehmen (x)" total falsch??
Großen Dank für jede Klärung

viele Grüße,

In der Ansicht sind alle abgeschlossenen Aufgaben drin deren "du musst das noch abnicken Status = 1" ist.  Und zwar egal, ob das dazugehörende Ticket jetzt abgeschlossen ist oder nicht. Es geht in dieser Ansicht ausschließlich darum die Aufgaben darzustellen bei denen egal aus welchem Grund noch genickt werden muss.

Vielleicht erklär ich das auch einfach zu kompliziert.

[baces]

2. Dazu dachten wir, gibt es dann in "Annehmen (x)" einen Button, mit dem man diese abgeschlossene Aufgabe abnicken (Bestätigen) kann ... und dann kann man erst das Ticket abschliessen

Den Button gibt es auch, aber nicht in der Ansicht annehmenselber, sondern in der Aufgabe (Todo). Dort ist die Aktion in der Regel mit "Schließen Akzeptieren" oder was auch immer ihr hinter die msgTodoActAcceptClose im Sprachdokument gelegt habt bezeichnet. Ein Klick auf diese Aktion setzt dann den Status auf 2 um und damit verschwindet das auch aus dieser Ansicht wieder. Gleichzeitig wird mit protokolliert wer das denn akzeptiert hat.

Danke und genau da liegt der Hund begraben .....
Das mit dem Button habe ich auf Seite 1 in Posting #9 erwähnt (sogar mit Screenshot von einem Todo ). Bei uns ist dieser Button nicht vorhanden. Du hast dann in Posting #13 die Antwort geschrieben,  ab der wir die Sache mit dem Annehmen nicht mehr verstanden haben (ab da dachte ich, dass dieser Button einfach nicht exisitiert und "Annehmen" irgendwie anders funktionieren" muss).
Das mit dem Button der Status auf 2 gesetzt wird und dann die Dinger aus der View verschwinden, ist ja genau das was wir seit Posting #9 wollen ;  ) ...

Jetzt ist aber defintiv klar, dass uns dieser Button fehlt. In den Sprachdokumenten fehlt uns aber auch dieses msgTodoActAcceptClose. Müssen wir den Button komplett neu erstellen?
Was muss ich denn dafür tun, um diesen Akzeptieren-Button herzukriegen? In der Wiki-Hilfe finde ich dazu nix

Juhu ... der Knoten ist geplatzt, irgendwie haben wir nur aneinander vorbegeredet 

[Thomas Schulte]

Als erstes guck im Designer nach ob er da in der Maske BugTodo vorhanden ist.
Das Ding heist AcceptClose und steht an vorletzter Stelle.

Wenn er da nicht ist, dann ist irgendwas mit der Gestaltungsaktualisierung schiefgegangen. Schau dir dann mal das letzte Template im Designer an.

Anschließend meldest du dich wieder

[baces]

okidoki ...werde nachschauen, komme heute aber nicht dazu ...vielen Dank für deine Hilfe und schönes Wochenende

[regedit]

Ist es möglich unterschiedliche Default-Supporter für z.B. das Feld "application" oder "failuretype" zu vergeben, so dass ein neues Ticket schon einem gewissen Bereich fest zugeordnet werden kann(Produktzuordnung)?

[Thomas Schulte]

Aktuell nicht. Wobei das im Prinzip erst einmal einfach einzubauen wäre, aber hinten raus dann doch wieder einiges an Aufwand bedeutet.

[regedit]

Mein Problem ist, die Supporter sitzen bei uns "breit gefächert".
Wenn also !!HELP!! die Tickets an den Mailpool des Support-Teams des jewiligen "Produkts" senden würde, bräuchte sich nicht "eine zwischen gesetzte Annahmestelle" gedanken zu machen, wer dieses Produkt denn bearbeitet.

[eknori]

Ich habe eine ähnliche Anfrage bekommen. Danach kann man ja der MailInDB mehrere Adressen zuweisen (support@help.de, reklamation@help.de ... )
Auch hier soll dann je nach gewählter Adresse ein Default supporter zugewiesen werden.
Ich denke, daß man die beiden Anforderungen unter einen Hut bringen kann .

[Thomas Schulte]

Wobei es eigentlich genau dafür gedacht ist das sich eben eine dazwischen gesetzte Stelle Gedanken macht. Schließlich muss die Stelle ja klassifizieren was da denn Sache sein soll. Sonst klappt das mit der Zuordnung ja auch nicht so wirklich.

Die Anfrage die Ulrich da bekommen hat ist wirklich Ganz einfach zu lösen, da mus man nur den Dispatcher ein Wenig anpassen und Konfigurationsdokumente dafür vorsehen.

Das andere ist denke ich etwas komplizierter, denn erst einmal muss sich trotzdem jemand hinsetzen und den Call zunächst einmal klassifizieren damit dann bei der Klassifizierung quasi der zuständige Supporter hinten rausfällt. Das darf aber auch nur einmal passieren und was passiert wenn man eine Änderung der Klassifizierung vornimmt. Ändert sich dann auch der Supporter?

Ich denke das da eine ganze Menge Logik dahinter stecken muss damit das richtig funktionieren kann.

[eknori]

quasi der zuständige Supporter hinten rausfällt.

*Boing* Skill Management ...

[Thomas Schulte]

Ja und Service Level Management. Aber da fang ich erst an drüber nachzudenken, wenn ich !!System!! am fliegen habe und unsere interne IT Auftragsdatenbank und das !!Help!! Portal und .....

[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]

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?

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]

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.

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]

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

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...