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

Änderungen und Fixes im nächsten point Release 1.5.1 von !!Help!!

<< < (3/8) > >>

eknori (retired):
lso, eine Basisfunktionalität wird die fortlaufende Nummer nicht werden. Ich verstehe, daß eine kürze Nummer die Kommunikation erleichtert ... Ich halte es für möglich, eine zusätzliche Funktion einzubauen, die eine solche *würg, schmerz* f.o.r.t.l.a.u.f.e.n.d.e Nummer zusätzlich zu der hübschen, kryptischen Nummer erzeugt.

baces:

--- Zitat von: Thomas Schulte am 07.03.06 - 18:04:54 ---
Also bei uns funktioniert das ....

Aber ich versteh dich da schon, irgendwie, ein wenig, vielleicht .....

Nur für das Wiederfinden im Dispatcher werden wir das nie nutzen. Deswegen MUSS die "kryptische" Nummer immer im Betreff stehen bleiben und ob dann eine Fortlaufend Nummer richtig viel Sinn macht??


--- Ende Zitat ---

Na klar, die krytische hat natürlich ihre Berechtigung und soll auch nicht ersetzt werden. Ich denke wirklich als Extra-Feld. Damit kann diese sorry, erheblich einfachere, Nummer in den Mails verwendet werden, zusätzlich zur Ticket-Id. Wie gesagt, im Augenblick packe ich die Ticket-Id ganz hinten an den Betreff und packe diese *..würg..* - einfache Nummer händisch vorne ran. Ein Feld für Tickets und ein Feld für Aufgaben, Startnummer und Ein/Ausschalter in der Config - als Vorschlag.

Bei unserer ERP-Einführung / Mitentwicklung, sind die Tickets halt sehr lange offen (Projekt läuft schon 3 Jahre und kein Ende abzusehen  :-X - aber es ist kein SAP, das können auch andere...), somit werden diese Tickets nicht mal in 3 Tagen abgeschlossen, sondern werden immer wieder aufgegriffen und werden länger und länger.

Und über Linderung des Seelenschmerz mache ich mir schon Gedanken...  :D

Thomas Schulte:
Okay also basierend auf diesem Post hab ich gestern eine mögliche Lösung für dieses Problem eingebaut:

TicketNewTicketStartWithStatus, Neues Konfigurationsdokument eingeführt. Steuert wie der
Status bei Manuell erstellten neuen Dokumenten gesetzt werden soll. BugReport Feld Status angepasst.

DispatcherNewTicketStartStatus, Neues Konfigurationsdokument eingeführt, Steuert mit welchem Status der Dispatcher ein neues Ticket anlegt. Sourcecode in lib.appl.function (createnewdocument) geändert

TicketReassignSetStatusTo, neues Konfigurationsdokument eingeführt, Steuert welcher Status beim Reassign eines Tickets gesetzt werden soll. Dieser Eintrag kann entweder leer oder 0 oder 1 sein. Bei leer wird der eingestellte Status nicht verändert. bei 0 wird er immer auf null zurückgesetzt und das Ticket wird wieder "neu", bei 1 bleibt das ticket im Bearbeitungs Modus (aktiv) oder wird in den Bearbeitungs Modus versetzt.

TicketAcceptSetCurrentUserAsSpporter, Neues Konfigurationsdokument eingeführt, steuert ob der aktuelle Benutzer als Supporter eingetragen wird wenn er ein Ticket akzeptiert.

Damit kann dann bei Tickets so vorgegangen werden wie bei Aufgaben. Der Benutzer der ein Ticket akzeptiert wird automatisch als Verantwortlicher Supporter eingetragen.

Einen Wermutstropfen habe ich da aber noch. Jedes neue Accept löst noch eine Email an die User aus von denen der Call kommt. Das könnte aber auch noch gelöst werden, wenn man sich darauf einigt, das beim Accept über ein Konfigurationsdokument gesteuert wird das der Eintrag für fldMailIfAccepted auf "NO" gesetzt wird, wenn der ....

Ähh ja, das hab ich jetzt auch gelöst. Dafür gibt es jetzt auch ein Steuerungsdokument damit kann man dann definieren, ob das Ticektinterne Steuerungsfeld für die Mailbenachrichtigung bei dieser Aktion auf "NO" gesetzt wird, was dann weitere Nachrichten unterbindet, bis jemand das Manuell wieder auf "YES" setzt.

Lauff:
Hört sich gut an. Danke.

eknori (retired):
Ich hatte ja angekündigt, dass ich mich mit der Implementierung von erweiterten Systeminformationen in das neue Release beschäftige.
Da wird es auch ein paar neue Sachen geben.
Allerdings wird es hier zunehmend schwieriger, die Sachen in LS abzubilden.

Die WMI Sachen sind nicht in allen Punkten umzusetzen. Zudem wird der Kram mit jeder neuen Abfrage langsamer und langsamer.
Bei manchen Dingen fehlen mir auch Möglichkeiten in LS, die andere Programmiersprachen haben - z.B. Inline-Assembler. Damit wären z.B. INT13 Abfragen zur Festplattenkonfiguration wesentlich einfacher und genauer, als über WMI oder die Windows API.

Ich habe daher angefangen, eine Abfrage der ( Remote ) Computerkonfiguration in C# zu schreiben.

Herauskommen wird am Ende eine DLL, die von LS aus angesprochen werden kann. Einen ersten Eindruck könnt ihr euch schon einmal durch den angehängten Screenshot verschaffen.

Per Default liest der bisherige Code den lokalen Rechner aus; es ist aber auch möglich, sich über ein Connect auf einen Remote Computer aufzuschalten und dessen Config auszulesen.

In einem Windows Netztwerk funktioniert das bereits sehr gut; Probleme bereitet mir aber Novell. Sobald der Novell Client installiert ist, ist Essig mit Remote. Aber das bekomme ich auch noch hin.

Die Abkehr von LS in diesem Bereich hat auch noch einen weiteren Vorteil; z.B. könnte man die Datenbank von ZenWorks anzapfen und die Ergebnisse in LN zur Verfügung stellen.

Momentan steckt das Alles noch in einem sehr frühen Alpha Stadium.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete