InfoTicket - Roadmap: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Zeile 167: | Zeile 167: | ||
Der Zugriff auf Tickets, die erst kürzlich den Besitzer gewechselt haben muss mit einer geeigneten Fehlermeldung quittiert werden. | Der Zugriff auf Tickets, die erst kürzlich den Besitzer gewechselt haben muss mit einer geeigneten Fehlermeldung quittiert werden. | ||
− | ==Milestone 5 == | + | ==Milestone 5 - Ende Nov. 2010== |
;<span style="color:red">Ticket aus CityCall115 anlegen (Final)</span> | ;<span style="color:red">Ticket aus CityCall115 anlegen (Final)</span> |
Version vom 8. November 2010, 14:30 Uhr
Milestone 1 - Erste präsentierbare Version auf pp.sitepark.com
- Kontaktdaten anlegen
- - Verknüpfung auf einen KontaktDatensatz durch Angabe der ID des Kontaktes oder
- - Verknüpfen durch Angabe der Kontaktdaten in dem 'contact' Feld. Die E-Mail dient als eindeutiger Identifier um den Datensatz im System zu finden. Wird kein Eintrag gefunden, wir der Kontaktdatensatz angelegt und verknüpft.
- Bei Gleichheit von E-Mail-Adresse werden die übergebenen Daten überschrieben.
- Folgende Eigenschaften müssen noch konfigurierbar werden
- OK Verkünpfung zwischen CallCenter-Mandant und InfoTicket-Mandant. Mandant und Nutzer im 'TicketArtikel' des CallCenters konfigurierbar.
- OK InfoTicket-Nutzer als Absender (Temporäre, nur für Milestone 1)
- offen Workflowverhalten (Eskalationszeiten, ...). hart kodiert. Welche Werte? (1 Tag!)
- OK Aussehen der E-Mail.
- Ticket aus dem CallCenter anlegen
- OK Über Bürgeranfrage
- OK Über Mitarbeiter-Visitenkarte - Standard Ticket öffnen
- OK Über Dienstleistung - Standard Ticket öffnen
- Über Mitarbeiter und Dienstleistungen keine Kontaktauswahl. Empfänger (der Mitarbeiter der Visitenkarte oder alle zuständigen Mitarbeiter der Dienstleistung) sind über die E-Mail vorselektiert sofern Sie auch User in InfoTicket sind.
- Wie soll der Ticket-Mandant ermittelt werden, damit beim Login-Fenster keine Auswahl erscheint?
- Antwort:
- Es werden alle Mandanten abgefragt, die aktiv sind und mit dem InfoTicket-Mandanten verknüpft sind. Entspricht nur ein Mandant diesen Kriterien wird keine Auswahl angezeigt und nur dieser verwendet.
- Es kann per URL-Parameter der gewünschte Mandant übergeben werden (ParameterName 'client', Wert ist der Anchor des Mandanten)
- Namensformat
- Nuzternamen können (noch) nicht an allen Stellen über die ID ermittelt werden (Bei einer Suchabfrage müssen select user->name funktionieren), darum wird der Nutzername direkt gespeichert und nicht seine ID. Für diese Fälle muss das Namensformat (Nachname, Vorname, Title) überall gleich sein.
- Fehlerbehandlung
- Auf Serverseite müssen noch ein paar Fehlerzustände abgefangen werden.
- createTicket
- Wenn Email-Adresse in 'participant' nicht gefunden werden kann muss ein Fehler auftreten.
- Wenn ID in 'participant' nicht existiert
- Wenn ID in 'participant' existiert, Nutzer aber keine Email-Adresse hat.
- getTicket
- ID nicht gefunden
- Ticket ist bereist geschlossen
- Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten
- addTicketItem
- ID nicht gefunden
- Ticket ist bereist geschlossen
- Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten
- Übergebene Werte validieren (ticketType, priority, ...)
- closeTicket
- ID nicht gefunden
- Ticket ist bereist geschlossen
- Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten
- Ticket-Eigenschaften
- nächste Wiedervorlagen, nächste Eskalation
- Agenten (Absender des Tickets)
- Globaler IES-Nutzer aus dem Infoticket-Mandant wird als Absender gesetzt.
- Installation auf pp.sitepark.com
- Zwei Mandanten: Master und Work
- Auswahlliste der Empfänger im CallCenter
- Wie kommen die Nutzer in das TicketSystem? Werden per Hand angelegt.
- Sortierreihenfolge von Status, Typ und Aktion
- Status
- Eskalation
- Erinnerung
- offen
- in Arbeit
- (geschlossen?)
- Typ
- Aktennotiz
- Aufgabe
- Beschwerde
- D115-Weiterleitung
- Information
- Rückrufwunsch
- Störungsmeldung
- Aktion (für Ticket-Einträge)
- Neu
- Änderung
- Notiz
- Erinnerung
- Eskalation
- Weiterleitung
- Locking von Tickets
- Kein Locking
- Konzeption: Eigenschaften ändern / Notiz anlegen
- Nachfrage-Dialog für Weiterleitungsbestätigung
- Speichern ohne Kommentar ist so in Ordung
- Subject muss man ändern können
- Wenn eine neue Notiz hinzugefügt wird, werden alle Einträge zugeklappt und nur der letzte geöffnet. Die Einträge, die geöffnet wurde sollen aber weiter offen bleiben. Es soll auch weiterhin zu dem letzten Eintrag gescrollt werden.
- Wenn Ticket-Tag geschlossen wird, muss nachgefragt werden, Wenn Ticket noch einen Message enthält (Wenn 'aktion ausführen' Button akive ist)
- Bei Kontakt ohne Telefon steht 'null', muss durch langen Strich ersetzt werden
- Bei öffnen des Tabs, Sanduhr an Maus bis Tab geöffnet
- Fazit: So nicht zu realisieren.
- Aufbau des Tab ruckelt (Firefox). Prüfen, ob das verhindert werden kann.
- Geprüft. Der unruhige Aufbau läßt sich nicht so einfach nachstellen. Muss wohl an sehr langsamen Rechnern liegen. Habe auch keinen Weg gefunden da etwas zu verbessern.
- Ticket-Einträge müssen nicht ausgewählt werden können. Auch ohne Mouse-over
Milestone 2 - Mo, 27.09.2010
- gestalteter Login-Dialog, Seitenhintergrund
Milestone 3 - Ende Oktober 2010
- Kontaktdaten anlegen
- Kontakte können beim Anlegen von Tickets erstellt werden, wenn keine bestehender Kontakt ausgewählt wurde.
- Wenn Daten gefunden wurden, werden nach Auswahl des Kontakts alle Daten angezeigt.
- Bei Gleichheit von E-Mail Adresse (oder Auswahl eines gefundenen Kontaktes) werden die Datenfelder aktualisiert.
- Ticket aus CityCall115 anlegen (vorläufig)
- An Personendatensatz Ticket öffnen, z.B. Rückrufwunsch
- An Dienstleistung Ticket öffnen
- Personenticket (Kontakt)
- Alle Kontakte der Dienstleistung als Vorschlag
- Geschlossene Tickets anzeigen
- Ist soweit implementiert. Folgendes fehlt noch
- Vorgabe für GUI zum aktivieren/deaktivieren des Filters (Nane)
- Bugfix, geschlossen Tickets haben nicht den Status 'geschlossen' (Ralf)
Milestone 4 Fr, 20.11.2010
- Code-Optimierung (2 Tage)
- GUI Sicht auf Tickets anderer Nutzer (Nutzerauswahl)
Dropdown mit allen Nutzern auf deren Tickets mindestens Leserechte bestehen
- Zusätzlicher Punkt: alle Nutzer
- Nur eigene Tickets im Zugriff -> Dropdown entfällt
- Einfache Ticketsuche
Die Suche ist ein weiterer Filter, der einschränkend wirkt (UND-Verknüpfung)
- die Suche berücksichtigt die Nutzerauswahl, d.h. die Suche ist auf den/die gewählten Nutzer eingeschränkt
- die Suche verwendet die aktiven Filterkriterien
- die Suche wirkt solange als Filter, bis das Suchfeld gelöscht wird
- Kontaktdaten
- Auch innerhalb von InfoTicket müssen die Kontaktdaten bearbeitet werden können. Änderungen an den Kontakten werden im Ticket protokolliert.
- E-Mail-Adressen bei der Darstellung von Kontaktdaten werden mit mailto:-Link versehen.
- Geschlossene Tickets öffnen
- Inhalte geschlossener Tickets müssen einsehbar sein
- Geschlossene Tickets müssen wieder geöffnet werden können
- Besitzerwechsel durch Öffnen
Locking nicht nötig, da wenn Ticket bearbeitet wird immer nur ein Bearbeiter möglich ist.
- Vor der Bearbeitung durch einen Nutzer wird das Ticket den anderen Nutzern entzogen und geht in den Besitz der öffnenden Person über.
- Besitzerwechsel durch öffnen gilt nicht für geschlossene Tickets
- Zugriff auf bereits entzogene Tickets
Der Zugriff auf Tickets, die erst kürzlich den Besitzer gewechselt haben muss mit einer geeigneten Fehlermeldung quittiert werden.
Milestone 5 - Ende Nov. 2010
- Ticket aus CityCall115 anlegen (Final)
- Definition von HTML-Formularen über einen Formulargenerator
- Definition von Pflichtfeldern für Kontaktdaten je Formular konfigurierbar
- Verknüpfung von Organisationseinheiten und Dienstleistungen zu verschiedenen Formularen.
- Darstellung einer Ticket-Formularliste unterhalb des "Unvollständig"-Buttons
- Darstellung eines "Ticket"-Buttons bei allen Kontakten innerhalb der CityCall115-Ausgabe von CityGov 3.
- Formularservice
- Eingabe der Formulardaten
- Eingabe der BürgerKontakt-Daten, nach Einverständnis
- Prüfung/Korrektur der vorausgewählten Empfänger (aus der Dienstleistung oder Visitenkarte)
- Erstellung von Benachrichtigung über einen Dienst, der die Formulardaten auswertet und pdf und/oder xml Dateien erstellt und je nach Konfiguration eine Mail oder ein Ticket erstellt.
Milestone 6
- Rechte
- (Konzeption)
- Nutzer haben Leserechte und / oder Bearbeitungsrechte
- Nutzer sind in Pools organisiert und erhalten ihre Rechte über Rollen
- Es gibt folgende Rollen
- Alle Nachrichten der Nutzer in meinem Pool lesen
- Alle Nachrichten der Nutzer in meinem Pool bearbeiten
- Eigene Nachrichten bearbeiten (Standard) [nur eigene Artikel bearbeiten]
- Ich bin Eskalationsempfänger für diesen Pool
Milestone 6
- Performanz-Tests mit vielen Tickets und parallelen Zugriffen
- Ticket-Typen
- Ticket-Typen müssen frei definierbar (konfigurierbar sein)
- Eigenschaften eines Ticket-Typs sind:
- Name
- Beschreibung (Tooltip?)
- Sortierwert
- Eskalationszeit
- Icon
- Auswahlliste der Empfänger im CallCenter
- Wie kommen die Nutzer in das TicketSystem?
Milestone 7
- Technische Implementierung des Multi-Accordion Layout-Managers für die rechte Spalte.
- allgemeine Favoritenverwaltung
- erweiterter Weiterleiten-Auswahl-Dialog
- Suchfunktion
- Favoritenliste
- verschiedene Ansichten
- Drag `n Drop für Weiterleitungen über die rechte Spalte
- Textvorlagen auswählen , erstellen, löschen, …
- Upload und Verwaltung von Anhängen
- Druckansicht
- Über einen Button wird ein neues Fenster geöffnet, der die Historie eines Tickets ausdruckbar darstellt.
Milestone 8
- Ticket-id soll ohne Typ und Mandanten-Kennung verwendet werden
- Suchabfrage muss diese ID schon so zurückliefern (oder per JavaScript beschneiden)
- Alle RPC-Funktionen des TicketSystems müssen die ID in dem neuen Format lesen können und auch so zurück liefern.
- Mail-Gateway
- Mailversand:
- Als Antwort
- Als Weiterleitung an Extern
- Konfigurationsmöglichkeit für einen zentralen Footer, der durch Variablen Nutzerdaten einfügen kann (Name, Vorname, Abteilung, …)
- Mailempfang:
- E-Mail als Ticket (siehe altes Dokument)
- E-Mail als externe Nachricht am Ticket
- E-Mail als Antwort für Weiterleitung an Extern
Milestone 9
- GUI Nutzerverwaltung / Rechtevergabe
- Neues GUI, als Prototyp für eine Applikation auf Basis der IES Nutzerverwaltung. Die technischen Möglichkeiten des IES / InfoSite bleiben bis auf die obige Erweiterung erhalten und werden durch das neue GUI bedient. Ggf. sind Erweiterungen nötig!?
- Die Nutzerliste im Nutzerpool enthält direkte Hinweise auf die zugewiesenen Rollen des einzelnen Nutzers.
- Agenten (Absender des Tickets)
- Alle Agenten müssen in das InfoTicket-System synchronisiert werden.
Milestone X
- Implementierung einer Funktion zur Wiedervorlage
- Subtickets
- Workflow
- Tickets können durch ihre Definition eine Abfolge von Nutzer(-gruppen) enthalten, die durch eine „Weiter“ und „Zurück“ Navigation durchlaufen werden.
- Integration der D115 Meldungstypen (Empfang und Bearbeitung)
- erweiterte Suchfunktion
- muss noch definiert werden