Einige Fragen zu 1.6

[pur_berger]

So - nachdem ich nun nett daruf hingewiesen wurd doch das Forum zu nutzen (besten Dank nochmals  ) hier bin ich.

Seit etwa einer Woche versuche ich die Mysterien des !!Help!! Projektes zu entschlüsseln - und einige Punkte sind mittlerweile aufgefallen:

Konfiguration -> dependent Keywords funktioniert nicht
Ich habe jetzt Tickettype -> Application (in Keywords leer dafür in dependent Keywords deffinieret) -> Failuretype -> Failuresubtype - aber:

Die erste Verknüpfung zeiget mir alle Untergruppen an sprich wenn ich einen Tickettype auswähle zeigt mir application alle Möglichkeiten an welche bei Tickettype deffiniert sind anstatt nur derer welche unter der ausgeählten Tickettype liegen. Weiter runter wird dann gar nichts mehr angezeigt (sprich auf Failuretype - Failuresubtype) - egal in welcher Kombination

Verknüpfung mit einer externen Mail-IN DB
Wir verwenden ja zur Zeit schon eine Maildatenbank wo alle requests reinkommen - abr eben nicht nur diese sondern auch jede Menge aneder - nicht Supportzugeordneter Dinge wie infomails von versterbenden Servresystemen, Netzwerkausfälle, ... ergo - muß diese bestehen beliben. Ich würde also gerne eine Möglichkeit haben in der Konfig eine Datenbank angeben zu können auf welcher ich auf die Inbox zugreifen kann (über die ReplicaID zum Beispiel) und nicht nur auf meine eigene (was - neben bei bemerkt eine geniale Funktion ist) - Und - da ich kein Entwickler bin - also nur ein bissal kopieren und anpassen kann - stah ich da mit meinem Wissen an ...

Lösungsdaten:Werden nicht angezeigt - warum auch immer. Ich hab' mir mal eine View gemcht und nur das Feld "Solutions" anzeigen lassen - leer. Ebenso sehe ich keine Button (in der alten Version gab s den denke ich) der eine Löungs als "aufhebenswert" markiert.

Möglichkeit ein InfoMail NICHT zu verschickenVon Zeit zu Zeit ist es notwendig keine Infomail an den User zu schicken - sprich ein "Cancel" Button wäre in der Voransicht fein - auch hier reichen meine Developerkenntnisse leider nicht aus

Ja - und so weiter 

Bin natürlich für alle Inputs dankbar (außer des berühmten "Nutz doch die Suchfunktion" - wer sich genötigt fühlt dies als Antwort anzubieten - könnte doch netter Weise gleich den Link zum entsprechenden Forumsbeitrag posten ...)

[Thomas Schulte]

1. Tickettype -> Application ist nicht dependand .... Da musst du die Anwendung an dieser Stelle umbauen. Wei das geht habe ich bei Openntf gerade erst beschrieben.
2. Das würde von der Struktur her aktuell nicht funktionieren. Der Zugriff den wir haben klinkt Mails direkt bei Tickets oder Aufgaben ein. In deinem Fall bräuchten wir dazu eine ganz neue Funktion. (Agent, Button, was auch immer der diese eingehenden Mails 1 zu 1 in !!Help!! hineinkopiert und da dann dem Dispatcher überlässt. Machbar und auch nicht aufwändig, aber erfordert a System und b Entwicklerkenntnisse.
3. Ja den gibt es nicht mehr. Schon seit langem, was man auch daran erkennen kann, das die Maske dafür noch nicht einmal mehrsprachig gemacht worden ist und auch  weil wir die Lösungsdatenbank von der Live DB trennen wollten. !!HEUREKA!! ist in Planung aber noch nicht wirklich soweit.
4. Das gibt es schon und zwar kann auf Ticket bzw. auf Aufgaben Ebene für jede Aufgabe einzeln noch einmal gesteuert werden ob Infomails verschickt werden sollen oder nicht. Schaust du unter Werkzeuge -> Info Mail Erstellung nach ...

[eknori]

@Thomas:

zu 2: er meint die Funktion Mail --> Ticket. Das habe ich ihm bereits in einer Mail beschrieben. Grundsätzlich geht es dabei lediglich um die Methode CreateFromMail in der LS.Ticket. An der Stelle, wo maildb initialisiert wird muss hat statt des db.MailOpen die Datenbank genommen werden, auf die zugegriffen werden soll. Wenn die idealerweiser auch das mailtemplate als Vorlage hat, hast du schon gewonnen. Ansonsten muss man halt noch ein paar Felder ändern im Code ...

[eknori]

den denke ich) der eine Löungs als "aufhebenswert" markiert.

das Feld ist in der Maske mit Hide-When versteckt.

Überprüfe auch mal, wie die Auswahlformel in den Ansichten für die Solutions aussieht. Kann sein, daß die Docs wg. Gross-/Kleinschreibung des Maskenalias nicht angezeigt werden ...

[pur_berger]

1. Tickettype -> Application ist nicht dependand .... Da musst du die Anwendung an dieser Stelle umbauen. Wei das geht habe ich bei Openntf gerade erst beschrieben.

Hm - also - kann ich nicht folgen. Wenn ich das Auswahlkriterium im Feld application auf

keydependsfrom := "Applicationdependandfrom";
dependsfrom := @DbLookup( "" : "" ; "":"" ; "($LUConfig)" ; keydependsfrom ; 2; [FailSilent]);
key := @If(dependsfrom != "";"application~~" + dependsfrom + "~~" + @GetField(dependsfrom);"application");
value := @If(dependsfrom != "";@DbLookup( "" : "" ; "":"" ; "($LUConfigDependand)" ; key ; 2; [FailSilent]);@DbLookup( "" : "" ; "":"" ; "($LUConfig)" ; key ; 2; [FailSilent]));
value

ändere - sollte es die Auswahl anzeigen - nur - es bringt mir eine Liste aller Felder unter welche unter Tickettype deffiniert wurden - und - für das Feld Failuretype gar nichts mehr (das war aber mit dem orginalcode auch schon so ...

Diese Soltions - Sache - vielleicht eine naive Vortsellung - aber - nachdem !!Heureka!! ja wohl ein wenig auf sich warten lassen wird - eine einfache Datenbank welche die Solutions nur zusammensammelt als Übergang? Die Konfig wäre ja schon da (zumindest gibt es von !!Heureka!! schon eine ReplicaID) - aber wenn man diese Daten hat kann man sich selber passende Views basteln - und die Nutzung der 1.6 wäre nicht eingeschränkt (ohne die Solutions zu sammeln - ich weiß nicht ...)

[eknori]

Nachdem wir ja HELP nun ( endlich ) auch bei uns im Unternehmen im Einsatz haben hat sich folgenddes ganz schnell gezeigt:
Lösungen intern zu halten und über die Kategorisierungen danach zu suchen ist nicht praktikabel.
Anbinden externer Datenbanken bringt nicht viel, solange man nicht aus dem Ticket heraus eine intelligente Suche über die zumeist vorhandenen und verstreut liegenden Informationen fährt.
Die Supporter der einzelnen Bereiche wissen eigentlich ganz genau, wo und wie sie in ihren Quellen nach Lösungen suchen. Die Lösungen, die dort gefunden werden, sind aber dann meist nicht Usertauglich. Daher bekommt der User bei uns immer nucr eine kurze für ihn verständliche Beschreibung der Schritte genannt, die sein Problem gelöst haben. Sachen , die er zumeist eh nicht sauber beshreiben und daher auch nicht anhand einer übermittelten Lösung bereinigen kann, schauen wir uns per Fernwartung der Rechner an und lösen dann über diesen Weg oder gleich vor Ort.

Sachen, die immer wieder auftauchen ( meistens verständnisprobleme beim Anwender ) verwursten wir redaktionell und stellen diese Dinge als einfach Artikel mit Screenshots in ein Blog. Da kann der User dann lesen, oder ( wie bei uns ) lässt es einfach sein, weil es ihn eh nicht interessiert.

Ergo, werde ich mich bei HELP nicht mehr weiter um das Thema Lösungsdatenbank kümmern.

[pur_berger]

Jaja - die User - 90% PEBKAC - aber wer traut sich Ihnen das sagen

Na - Im ernst - stimmt sicherlich - ist aber wohl eher ein philosophischer Ansatz. Wir für unseren Teil sind schon ganz froh wenn ein Kollege eine Lösung für ei Problem schon mal in der Doku eingepflegt hat (liegt aber wohl daran das wir zu dritt 500 Maxerl über alle Zeitzonen betreuen müssen - und wenn wer mal auf Urlaub ist - alles kann man einfach nicht wissen ...) - Ist halt schade. Die Funtion wie in 1.5 wieder zu aktivieren - Kompromiß?

[eknori]

aktivieren kannst du das ja. Die designelemente sind alle noch in der DB drin ...

[pur_berger]

Hm - eine Chance zu der Frage "Mail von einer anderen Datenbank importieren als der eigenen" weiterführende Hilfe zu bekommen? Mit der Info kann ich leider garnichts anfangen ...

Ah - gibt es eigentlich Fortschritte Punkte des Datumsproblems (Loop)?

Besten Dank!

[eknori]

weiterführende Hilfe zu bekommen?

wo hapert es denn ??

Ah - gibt es eigentlich Fortschritte Punkte des Datumsproblems (Loop)?

Evtl. kann sich ja auch der eine oder andere mal gedanken machen, wie man das lösen kann. Ehrlich, manchmal habe ich den Eindruck, daß alle Welt denkt: " Ihr habt's verbockt, jetzt biegt das auch mal schön wieder gerade!" ...

[pur_berger]

Prinzipiell das ich keine Tau von Lotus Script habe ... leider. Für jemanden der Programmieren kann ist Dein Hinweis sicherlich perfekt - mir hilft das leider gar nichts. Schau - die ReplicaID von der Datenbank von der ich die Mails übernehmen will ist blablabla - nur wie muß das dann in dem Script aussehen?

"Evtl. kann sich ja auch der eine oder andere mal gedanken machen, wie man das lösen kann. Ehrlich, manchmal habe ich den Eindruck, daß alle Welt denkt: " Ihr habt's verbockt, jetzt biegt das auch mal schön wieder gerade!" ..."

Ähm - das liegt wohl eher daran das die Schar der tatsächlichen Entwickler eher gering ist (also ich kenn gerade mal eine die wirklich was kann - und die arbeited leider nicht mehr für uns) - Ergo ist die Schar der halbwissenden Admins (zu denen ich mich auch zähle) offensichtlich relativ groß. Klar wendet man sich hilfesuchend an die Jungs die die Datenbank geschrieben haben. Und - bei aller Bewunderung für Deine Arbeit - das Teil ist bei Gott keine kleine Application die man mal schnell mit Try & Error durchkonfiguriert ...

[Thomas Schulte]

Nein es ist wirklich keine kleine Anwendung mehr, die mal eben schnell begriffen werden kann. Und insofern ist die Beschreibung bei Openntf auch ein wenig "missverständlich".
Wenn man so wie es bei uns in der Firma ist !!SYSTEM!! !!DRIVERS!! !!SLM!! und die neue Testerstellungs und Verfolgungsdatenbank (Die hat noch keinen Namen, weil !!TEST!! klingt saublöd) einsetzt dann wird das Zusammenspiel richtig komplex.
Von diesem Standpunkt aus wäre es natürlich gut wenn in der Dokumentation mehr Aufwand stecken würde. Doch ...

und jetzt kommen ein paar Aber.

Erstes Aber .... Ulrich und ich haben beide Jobs die uns im Moment bis zum Maximum stressen. Wir haben beide Familien um die wir uns auch ein wenig kümmern sollten. Bei mir kommen im Moment noch ein paar andere, auf die Leistungsfähigkeit extrem einwirkende, Probleme dazu. Also ist der uns zur noch zur Verfügung stehende Zeitrahmen eher gering.

Zweites Aber .... Für eine Dokumentation braucht es keine Entwickler. Nur jemand mit genug Zeit und Willen da etwas zu schreiben und das dann auch zu pflegen. Informationen oder Fragen wie etwas funktioniert und warum das so ist können wir beide (und haben das auch) immer beantworten. Da hat es in der Vergangenheit immer wieder Ansätze gegeben aber die wurden nie bis zum Ende durchgezogen. Dokumentation ist halt einfach ein bitteres Brot.

Drittes Aber .... Wir versuchen soviel Support wie möglich zu geben. Noch mehr wäre nur dann möglich, wenn wir von unserer Arbeit für dieses Projekt leben könnten. Das wäre wenn alle die das aktiv im Einsatz haben jeden Monat einfach einen dreistelligen Betrag überweisen würden warscheinlich sogar machbar. Da das aber keiner tut .... Vollende den Gedankengang einfach selber, von irgendwas müssen wir und unsere Familien schließlich auch leben.

Viertes Aber .... Das ist jetz nicht wirklich eines, aber ein Gedanke der ganz interessant ist. Tom de Marco hat mal ein Buch geschrieben, "Warum ist Software so teuer? Und andere Rätsel des Informationseitalters". Das ist wirklich lesenswert denn darin wird erklärt, warum eigentlich keiner dazu bereit ist Arbeit die in Software steckt wirklich zu honorieren. Das Fazit das er in einem Teil des Buches zieht ist: "Du bekommst immer nur die Qualität für die du auch bereit bist zu bezahlen. Entweder in Zeit, oder in Geld."
Da wir in der Regel kein Geld bekommen ..... Die Schlussfolgerung daraus ist ganz interessant oder?

[pur_berger]

Ah - eh ...

Ned böse sein - aber bei einem OpenSource Project ist das soweit ich weiß eher der Standard ads man davon ned wirklich was hat - oder?

Na - im Ernst - ist ja alles kein Thema - and das man nicht beie jeder Anfarge den User bei der Hand nehmen und zärtlich dorthinführen kann / will ist ja auch klar. Nur - wenn Ihr (also das dynamische Duo) wirklich kommerziell was machen wollt - bitte - es ist doch Teil des Open Source das das Produkt zar gratis - der support aber sehr wohl was kosted.

Also - wenn so Jungs wie ich daherkommen und was brauchen - adaptionen oder Konfigs die sie einfach nicht selber können - bitte - Honorarnote und geht schon. Ich habe kein Problem für PS Leistungen der Firma Geld zu entlocken, sehr wohl aber damit ein System einzuführen das nicht ganz das packt was wir brauchen.

Und das schöne - niemand nimmt Schaden - die welche sich selber auskennen können Ihre Konfugs nach wie vor selber machen, und der Rest kann sich mit gutem Gewissen and die Entwickler wenden. Ist mir ja selber unangenehm immer nachfragen zu müssen ...

Hm - Doku - scheitert wohl hauptsächlich an der Art des Designs. Solange die Konfig dermaßen umfangreich und anpassungsfähig ist - ergo sich auch oft ändert - wird wohl jeder Anlauf in dieser Richtung scheitern

[Thomas Schulte]

Jein. Open Source hat nichts mit nichts davon haben zu tun. Eher mit. Wenn es dir nicht passt kannst du es ja selber ändern und wenn du es nicht ändern kannst oder es schnell brauchst ....

Was Ulrich (ich in letzter Zeit eher nicht) leistet geht weit darüber hinaus.