Suche SQL-basiertes Ticket/Helpdesk System

[Dalai]

Hallo liebe Leser,

ich weiß, der Titel ist etwas ungenau und ziemlich weit gefasst. Das liegt daran, dass ich nicht weiß, wie man das nennt, was wir suchen/brauchen; ich bin noch nicht einmal sicher, ob die Bezeichnung Helpdesk bzw. Ticket System richtig ist .

Folgende Situation in der Firma: die Mitarbeiter tragen ihre Probleme, Wünsche/Bitten und Problemchen in eine Excel-Tabelle ein, die in (un-)regelmäßigen Abständen von uns Admins eingesehen wird, um darauf reagieren zu können. Dabei geht es um Probleme aller Art wie PC startet nicht mehr, Drucker tut nicht, Bestellung neuer Hardware usw.

Damit sich der Leser selbst ein Bild machen kann, siehe selbiges im Anhang. Die Eintragungen sind natürlich keine echten, aber um das Prinzip zu erkennen, sollte es genügen.

Nun wäre es eben schön, wenn

• das Ganze SQL-basiert wäre (die Nutzer also auch gleichzeitig darauf zugreifen können)
• bei neuen Eintragungen Mails verschickt werden könnten (auch wenn noch kein interner Mailserver existiert, geplant ist er)
• der Admin einen Eintrag durch Klick auf denselben als erledigt markieren kann und ggf. einen Kommentar dazu eintragen kann
• das System bei einem neuen Eintrag den Nutzernamen automatisch einträgt (Windows-Nutzer)

Das Ganze sollte auf einem Ubuntu 8.04 laufen, am liebsten mit MySQL, der eh schon vorhanden ist und auch genutzt wird. Durch die SQL-Basierung ergäben sich noch andere Vorteile, wie z.B. die Möglichkeit der Einbindung in die MOTD (Message of the Day) des Linux-Servers.

Ich bin mir sicher, dass ich nicht der Erste bin, der sowas sucht. Kennt jemand so etwas? Wonach könnte ich suchen bzw. mit welchen Begriffen?

MfG Dalai

 

[pschaefer]

Du suchst ein "Issue Tracking System".

Web-Basierte OpenSource-Varianten sind bspw.

Redmine: http://www.redmine.org
Trac: http://trac.edgewall.org/

Für beides sind Debian-Pakete verfügbar, somit dürfte es das auch für Ubuntu geben; DB ist wahlweise PostgreSQL oder MySQL. Persönlich präferiere ich PostgreSQL, aber das ist Glaubenskrieg...

Ein Single-Sign-On (i.e. Übernahme des Windows-Nutzers) gibt's aber IMHO nicht out-of-the-box, also da wirst Du schon jeweils User in den Systemen selbst anlegen und verwalten müssen. Ggf. kann man vielleicht was mit Apache und mod_sspi erreichen, aber da hab' ich keinen Plan.

 

[Dalai]

Du suchst ein "Issue Tracking System".

Ah, dachte ich mir doch, dass es dafür einen Begriff gibt.

Ein Single-Sign-On (i.e. Übernahme des Windows-Nutzers) gibt's aber IMHO nicht out-of-the-box, also da wirst Du schon jeweils User in den Systemen selbst anlegen und verwalten müssen.

Wenn das System LDAP unterstützt, reicht mir/uns das völlig aus, denn der existiert sowieso, um zusammen mit Samba die Windows-Domäne zu betreiben.

Danke dir erstmal für die Begriffsfindung und die Vorschläge! Wikipedia bietet ja auch einige Informationen dazu und listet einige Vertreter auf. Wir werden uns die Möglichkeiten mal genauer anschauen und eruieren.

MfG Dalai

 

[tomturbo]

OTRS oder RT sind sehr bekannte Vertreter dieser Art und können natürlich auch mit LDAP umgehen.

lg
__tom

 

[pschaefer]

OTRS oder RT sind sehr bekannte Vertreter dieser Art und können natürlich auch mit LDAP umgehen.

Ah! Die kannte ich nicht - was aber nix heißen muss, weil ich halt mehr aus der Entwickler- als aus der Helpdesk-Ecke komme.

Aber - stimmt - bei Redmine oder Trac ist das Ticketing im Vergleich zu den o.g. Vertretern nur "angeflanscht" und der Schwerpunkt liegt auf (Software-)-Projektmanagement. LDAP geht auch da mit beiden (wie meistens im OpenSource-Bereich).

 

[Onkel Homie]

Wenn es nicht zwingend MySQL seien muss, würde ich noch Jira in den Raum werfen. Es läuft mit PostgreSQL und kostet ein Bisschen was.

Nutzen wir hier und nachdem wir das ur-alte Mantis *würg* und auch mal Trac laufen hatten, sind wir mittlerweile doch recht froh darüber zu Jira gewechselt zu sein.

Als Download Variante kostet es einmal 10$ für bis zu 10 User. Wir haben damals das ein spezielles Angebot als komplette Paket mit anderen Modulen für 60$ genommen, wo man auch je nach Modul mehr User mit einbeziehen kann. Dabei waren dann noch Klamotten wie eine Anbindung an eine Art Wiki (Confluence), Projektmanagement Tools (Greenhopper), SVN Anbindung (FishEye) usw. Das Angebot an sich scheint es so aber nicht mehr zu geben. Aber vermutlich kommt man ähnlich raus, wenn man die einzelnen Module die man nutzen kann/will einzeln kauft.

Die Zusatzfunktionen wie Wiki usw. bieten andere durchaus auch, aber auch wenn die Einrichtung von Jira, trotz des netten Here be Dragons Guide, etwas hakelig war, war es insgesamt dennoch deutlich besser und runder als irgendwelche OpenSource Varianten.

Bei uns war es letztendlich einfach eine Zeitfrage, denn die Einarbeitung zur Einrichtung von Trac beispielsweise hätte letztendlich deutlich länger gebraucht um es auf den gleichen Stand zu kriegen den man mit Jira relativ schnell hinbekommt.

 

[Lokadamus]

OTRS[/URL] o...

Wenn es nicht zwingend MySQL seien muss, würde ich noch Jira in den Raum werfen. Es läuft mit PostgreSQL und kostet ein Bisschen was.

OTRS wird bei mir auf der Arbeit auch eingesetzt und es erlaubt sowohl das Anbinden an verschiendene DBs (MySQL, PostgreSQl, MSSQL und Oracle) als auch die Tatsache, dass Emails in einer Oberfläche angezeigt werden. Diese kann ein Mitarbeiter/ Agent sperren und versuchen zu beheben. Was er gemacht hat, kann er als Notiz hinterlegen und per Email die Anfrage beantworten (hat es geklappt oder nicht, bitte auf die Email antworten).

Wie gut die anderen, genannten Produkte funktionieren, weiß ich nicht.
Da der Thread schon etwas älter ist, was wurde den genommen?

 

[Dalai]

Da der Thread schon etwas älter ist, was wurde den genommen?

Noch gar nichts, weil dieses System im Moment nicht so wichtig ist wie andere Dinge (Upgrade des Servers) und weil bisher leider wenig Zeit für Tests war . Aber das wird alles nachgeholt, das ist sicher. Auch wenn es "etwas" länger dauert, so pflege ich, nachgefragte Dinge/Themen mit einer entsprechenden Rückmeldung abzuschließen.

MfG Dalai

 

[Dalai]

Nach laaanger Pause kann ich nun endlich auf dieses Thema zurückkommen.

In den vergangenen Tagen habe ich mir ein paar der Systeme angeschaut, bei anderen hat ein Blick auf die Webseite genügt, um zu entscheiden :

• Jira: proprietär, Fokus auf Softwareentwicklung, Löhnware => abgelehnt
• Mantis: Übersichtlich ist es, aber leider mit Fokus Softwareentwicklung => abgelehnt
• Trac: Fokus Softwareentwicklung => abgelehnt
• RequestTracker (RT): nach ein paar Anlaufschwierigkeiten (angeblicher CSRF/XSRF wegen Verwendung der IP-Adresse statt des Servernamens) machte das Ding einen sehr unübersichtlichen Eindruck, dazu kommt Mischmasch von Deutsch und Englisch => abgelehnt
• OTRS: den Standardlogin zu kennen oder gar bei Installationsende hinzuschreiben, wäre schön gewesen (noch besser wäre, ihn bei der Installation festlegen zu können). Es gibt dort Agenten, Rollen, Gruppen und Kunden. WTH? Scheint mir für einen anderen Anwendungszweck zu sein und für das benötigte Szenario völliger Overkill. Lustig ist auch, dass die für den Nutzer root@localhost vergebene eMail-Adresse der eigenen Plausibilitätsprüfung nicht standhält; will man also Änderungen an diesem Profil vornehmen, meckert er, dass die eMail-Adresse nicht gültig ist => abgelehnt
• treE: theoretisch gut, klein, einfach und schnell. Nur warum zum Teufel dürfen nur Admins dort Tickets anlegen? Und warum erstmal ein leeres Ticket, das erst im Nachgang mit Text befüllt werden kann? Damit ist das Einsatzszenario ein anderes als benötigt und noch viel schmaler dazu => leider abgelehnt

Ich frage nochmal gezielter: Gibt's ein kleines System, das seinen Fokus nicht auf Softwareentwicklung, aber auch nicht auf First/Second Level Support legt (bei dem die Supporter die Einträge machen)? Es sollen die Mitarbeiter selbst Einträge machen können, die dann die Admins "entgegennehmen" und bearbeiten können. Ist dieses Einsatzgebiet so ungewöhnlich? Irgendwie hab ich den Eindruck, sehr häufig andere Anforderungen zu haben als der Rest der Welt . Momentan sieht's so aus, als läuft das auf Selberschreiben hinaus... (reimt sich sogar ).

MfG Dalai

 

[T. the Maniac]

OTRS mit KIX4OTRS kann das was du willst,
es kann Tickets auch per Mail entgegennehmen und man sogar für die extern Kunden einen abgespeckten Webzugang einrichten.

und es gibt eine Unterscheidung zwischen interner und externer Kunde, Helpdesk und Techniker=Admin="ich bau dir das"


ist allerdings beschissen einzurichten oder ihr kaufts bei einem Dienstleister.

 

[flybyray]

...abgelehnt...abgelehnt...abgelehnt...abgelehnt...abgelehnt...

redmine? auch abgelehnt? redmine ist durch viele plugins erweiterbar, es gibt auch einige kommerzielle plugins wenn man was spezielles braucht.
ldap ist gar kein problem.
Leicht einzurichten ist es auch wenn man sich etwas mit aktueller Server Administration auskennt.

 

[Dalai]

redmine? auch abgelehnt?

Hatte ich mir bislang noch nicht angeschaut. Machte bei der Installation aus dem Ubuntu-Repos gar keinen guten Eindruck, das Ubuntu-Wiki schweigt auch zum Standard-Login . Die Oberfläche ist aber sehr aufgeräumt, so ziemlich alles ist konfigurierbar - bislang das beste System, was ich gesehen habe. Der Fokus liegt zwar auch eher auf Softwareentwicklung, aber das kann man, soweit ich gesehen habe, so anpassen, dass man davon nicht mehr viel sieht. Kommt in jedem Fall in die engere "Auswahl" (frei nach Volker Pispers: gibt es nur einen Kandidaten, ist es eine Wahl ). Eine Frage noch dazu: Kann man irgendwo zusammengefasst nachlesen, was sich zwischen Version 1.3 (im Repos) und der aktuellen 2.4 geändert hat? Das Changelog ist da leider viel zu technisch und zu detailliert.

MfG Dalai

 

[PuckPoltergeist]

Ein Single-Sign-On (i.e. Übernahme des Windows-Nutzers) gibt's aber IMHO nicht out-of-the-box, also da wirst Du schon jeweils User in den Systemen selbst anlegen und verwalten müssen. Ggf. kann man vielleicht was mit Apache und mod_sspi erreichen, aber da hab' ich keinen Plan.

Für viele Systeme gibt es mittlerweile Kerberos-Integration, so dass SSO machbar ist. Ob einem das den Aufwand wert ist, ist die andere Frage.

 

[Onkel Homie]

Ich hätte an sich als Erstes Jira bzw. halt ein System von Atlassian empfohlen.
Da kann man auch sehr viel mit machen und es durch Plugins erweitern.

Als ich dann Mantis im Zusammenhang mit Übersicht gelesen habe bin ich ja fast vom Stuhl gefallen. Ich kenne nix Schlimmeres als Mantis.
Redmine haben wir hier im Einsatz...leider.
Da wünsche ich mir glatt das Jira aus der alten Firma zurück. Ist in der Bedienung übersichtlich und unheimlich mächtig. Macht bei der Konfiguration und Installation aber ggf. nicht so viel Spaß. Hat mich einige Nerven gekostet. Aber wenn es dann rennt ist es super. Wir sind dann auch irgendwann dazu übergegangen es direkt bei Atalassian hosten zu lassen. War dann deutlich entspannter.

Aber gut wenn man nix zahlen will...

Oh gerade gesehen das ich mich hier schon mal positiv in der Richtung geäußert hatte
Hab glatt übersehen wie alt der Thread ist hehe.

 

[Lokadamus]

Nach laaanger Pause kann ich nun endlich auf dieses Thema zurückkommen.
[*]OTRS: den Standardlogin zu kennen oder gar bei Installationsende hinzuschreiben, wäre schön gewesen (noch besser wäre, ihn bei der Installation festlegen zu können). Es gibt dort Agenten, Rollen, Gruppen und Kunden. WTH? Scheint mir für einen anderen Anwendungszweck zu sein und für das benötigte Szenario völliger Overkill. Lustig ist auch, dass die für den Nutzer root@localhost vergebene eMail-Adresse der eigenen Plausibilitätsprüfung nicht standhält; will man also Änderungen an diesem Profil vornehmen, meckert er, dass die eMail-Adresse nicht gültig ist => abgelehnt

Ich frage nochmal gezielter: Gibt's ein kleines System, das seinen Fokus nicht auf Softwareentwicklung, aber auch nicht auf First/Second Level Support legt (bei dem die Supporter die Einträge machen)? Es sollen die Mitarbeiter selbst Einträge machen können, die dann die Admins "entgegennehmen" und bearbeiten können. Ist dieses Einsatzgebiet so ungewöhnlich? Irgendwie hab ich den Eindruck, sehr häufig andere Anforderungen zu haben als der Rest der Welt . Momentan sieht's so aus, als läuft das auf Selberschreiben hinaus... (reimt sich sogar ).

Nein, bei OTRS ist Root der Standardname und kann in der Weboberfläche gespeichert oder geändert werden.
Auch macht die Benutzerverwaltung Sinn. Willst du Kunden Zugriff bieten oder nicht? In diesem Moment entscheidest du, ob Kunden ihre eigenen Einträge machen dürfen oder nicht.
Das Prinzip von First/ Second/ Third Level wird dich in dieser Weise immer begleiten. Du kannst auch eine eigene Lösung erstellen, wirst aber früher oder später feststellen, dass du nur eines dieser Ticket Systeme nachprogrammierst.
Die Überprüfung auf @localhost macht einerseits Sinn, andererseits lässt sie sich leicht abschalten. Einfache Überlegung, kommt eine Email, die von Localhost versendet wurde, wieder zurück? Nein, weil Localhost auf 127.0.0.1 definiert ist.
So gesehen macht die einfache Überprüfung Sinn. Andere Adressen werden auch als böse angeschaut, wenn sie intern falsch aufgelöst werden, aber das ist ein lösbares Problem.

Kurz gesagt OTRS kann alles, was du willst. Aber du willst nicht.

 

[Dalai]

Willst du Kunden Zugriff bieten oder nicht?

Nein, will ich nicht. Es gibt keine Kunden, es gibt nur Mitarbeiter, die intern ihre Problemfälle eintragen können sollen.

Das Prinzip von First/ Second/ Third Level wird dich in dieser Weise immer begleiten.

In dem Fall: ganz klar nein. Es ist ein kleines Unternehmen, wo es keinen First/Second/wasauchimmer-Level-sonstwas gibt. Es gibt Mitarbeiter und Admins - mehr is da nich. Da gibt's keinen Supporter, der einen Anruf vom Mitarbeiter bekommt und dann seinerseits den Problemfall in das System einträgt (um es an den Admin weiterzugeben) - nein, die Mitarbeiter sollen das selbst tun (können).

Die Überprüfung auf @localhost macht einerseits Sinn, andererseits lässt sie sich leicht abschalten.

Ich glaub, du hast mich nicht verstanden. Die Standardinstallation legt einen Account namens root@localhost an, mit selbiger eMail-Adresse. Will man nun an diesem Account Änderungen vornehmen, wird die eMail-Adresse aufgrund der Plausibilitätsprüfung abgelehnt (es ist halt keine TLD dran) - das System lehnt also die bei der Installation selbstgewählte (nicht benutzerdefinierte!) Mailadresse ab. Das ist aber Unfug, denn localhost ist immer gültig, wenn sich auf demselben System ein Mailserver befindet. Es macht also überhaupt keinen Sinn, root@localhost als ungültige Mailadresse abzulehnen.

Kurz gesagt OTRS kann alles, was du willst. Aber du willst nicht.

Das mag sein, aber es ist und bleibt Overkill und ist meiner Meinung nach für die Mitarbeiter nicht zu bedienen. Letzteres ist zwar nur Vermutung, weil ich das nicht so weit einrichten wollte/konnte, weil ich die Sache schon vorher abbrach.

-----

Noch ein kleines Update: Redmine hat nun die technische Konfiguration hinter sich, jetzt wird es in den nächsten Tagen/Wochen an die logische Konfiguration gehen, bevor das Ding auf die Mitarbeiter zum Testen losgelassen wird. Bislang gefällt es mir ganz gut, mal schauen, ob die Mitarbeiter das ebenso sehen .

MfG Dalai

 

[TiKu]

Nein, will ich nicht. Es gibt keine Kunden, es gibt nur Mitarbeiter, die intern ihre Problemfälle eintragen können sollen.

Die Mitarbeiter sind Kunden der Admins.

 

[PuckPoltergeist]

Nein, will ich nicht. Es gibt keine Kunden, es gibt nur Mitarbeiter, die intern ihre Problemfälle eintragen können sollen.

Kenne da hier ein PHP-basiertes TTS von uns. An nähere Infos komme ich aber erst nächstes Jahr wieder ran, da ich das Teil selber nur nutze und nicht pflege. Da werde ich nachfragen müssen. Tut aber hausintern für genau diesen Zwecke (Mitarbeiter <-> Admins) ganz gut.

Ich glaub, du hast mich nicht verstanden. Die Standardinstallation legt einen Account namens root@localhost an, mit selbiger eMail-Adresse. Will man nun an diesem Account Änderungen vornehmen, wird die eMail-Adresse aufgrund der Plausibilitätsprüfung abgelehnt (es ist halt keine TLD dran) - das System lehnt also die bei der Installation selbstgewählte (nicht benutzerdefinierte!) Mailadresse ab. Das ist aber Unfug, denn localhost ist immer gültig, wenn sich auf demselben System ein Mailserver befindet. Es macht also überhaupt keinen Sinn, root@localhost als ungültige Mailadresse abzulehnen.

Es ist schon lange nicht mehr gegeben, das ein MTA auf dem lokalen System installiert ist. Erst recht kann man nicht voraussetzen, dass der von localhost was entegen nimmt. Debian hat ja nicht ohne Grund ssmtp entwickelt, um einfach nur weiterleiten zu können. Insofern ist es heute nicht mehr Unfug, $ETWAS@localhost abzulehnen. Auf 90% aller Systeme geht das heute leider schief, da die Admins nicht mehr wissen, was sie da tun (sollten).

 

[Dalai]

Kenne da hier ein PHP-basiertes TTS von uns. An nähere Infos komme ich aber erst nächstes Jahr wieder ran, da ich das Teil selber nur nutze und nicht pflege. Da werde ich nachfragen müssen. Tut aber hausintern für genau diesen Zwecke (Mitarbeiter <-> Admins) ganz gut.

Interessant. Ich bin gespannt, ob es damit vielleicht noch mehr Auswahl gibt .

Es ist schon lange nicht mehr gegeben, das ein MTA auf dem lokalen System installiert ist. Erst recht kann man nicht voraussetzen, dass der von localhost was entegen nimmt. Debian hat ja nicht ohne Grund ssmtp entwickelt, um einfach nur weiterleiten zu können. Insofern ist es heute nicht mehr Unfug, $ETWAS@localhost abzulehnen. Auf 90% aller Systeme geht das heute leider schief, da die Admins nicht mehr wissen, was sie da tun (sollten).

Ich weiß zwar nicht, wo das Problem ist, in einem vertrauenswürdigen Netz Mails von localhost anzunehmen, noch dazu auf dem Server selbst, auf dem Mailserver und Issue Tracking zusammen laufen. Ja, es könnte das LAN kompromittiert werden, so dass dann von dort aus Spam verschickt wird. Aber wenn das denn so ist, dann macht die Maildomain @localhost keinen Sinn. Aber wahrscheinlich wird die eingetragen, um den Admin zu zwingen, sie zu ändern. Naja, offensichtlich ist es zuviel verlangt, gleich bei der Installation nach entsprechenden Infos zu fragen... Jaja, Jammern auf hohem Niveau . Mir fällt sowas halt auf.

MfG Dalai

 

[PuckPoltergeist]

Interessant. Ich bin gespannt, ob es damit vielleicht noch mehr Auswahl gibt .

Muss leider erstmal passen. Nach kurzer Erkundigung heute, ist das ein selbst gebautes System (PHP-Basis), welches es so nicht nochmal gibt, und auf die in-house Bedürfnisse zugeschnitten wurde.

Ich weiß zwar nicht, wo das Problem ist, in einem vertrauenswürdigen Netz Mails von localhost anzunehmen, noch dazu auf dem Server selbst, auf dem Mailserver und Issue Tracking zusammen laufen. Ja, es könnte das LAN kompromittiert werden, so dass dann von dort aus Spam verschickt wird. Aber wenn das denn so ist, dann macht die Maildomain @localhost keinen Sinn. Aber wahrscheinlich wird die eingetragen, um den Admin zu zwingen, sie zu ändern. Naja, offensichtlich ist es zuviel verlangt, gleich bei der Installation nach entsprechenden Infos zu fragen... Jaja, Jammern auf hohem Niveau . Mir fällt sowas halt auf.

Das Problem ist, dass auf heutigen Systemen (ja auch Servern) ein sauber konfigurierter MTA nicht mehr vorausgesetzt werden kann.

 

[Tuxist]

http://www.combodo.com/spip.php?page=rubrique&id_rubrique=8

 

[Stonehedge]

Hallo,

ich hab den Thread nur überflogen, und wollte mal Remedy ins Spiel bringen.

Ich war bis dato in 2 großen Firmen tägig, die beide auf dieses System setzen. Vielleicht der Overkill, vielleicht auch sinnvoll.

Grüße
Stone

 

[TiKu]

Wir setzen Remedy ein (für Supportfälle von Kunden) und so wirklich toll findet es keiner in der Firma. Hauptkritikpunkte sind die relativ verworrene GUI und die schlechte Wiederauffindbarkeit von alten Fällen, d.h. die Nutzung als Knowledge Base funktioniert nicht wirklich toll.
Da man Remedy wohl anpassen kann, kann beides natürlich in unseren Anpassungen bzw. unserer Nutzung begründet sein, aber wie gesagt: Bei uns geht die Tendenz eher weg von Remedy.

 

[Onkel Homie]

Geschmäcker sind da wohl verschieden.
Ich finde Mantis grausig und Redmine ist auch nicht so das das gelbe vom Ei wenn man halt Jira und weitere Atlassian Geschichten kennt (wo die Einrichtung allerdings ein Krampf ist).
Andere kommen damit gut zurecht und finden die Systeme teils auch noch wirklich gut.