Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

REQ: Support-Ticket System

TCB

New member
Registriert
23. Okt. 2001
Beiträge
245
Reaktionspunkte
0
Hallo,

vielleicht ja der eine oder andere einen Tip(p) für mich.

Und zwar bin ich auf der Suche nach einem Free-Support-Ticket System.

Ich kenne eigentlich nur ein Script welches meinen Anforderungen entspricht, Script Request Tracker, allerdings unterstützt mein jetziger Businessprovider "mod_perl" nicht, so dass es dort nicht läuft.

Hier eine kurze Beschreibung / Ablaufsweise von RT:

- Someone sends email to [email protected] reporting a problem or issue.

- RT records the new issue in its database and sends the user an electronic "ticket stub" which he can refer to in further correspondence about this issue.

- RT forwards the email to a set of staff members.

- One of the staff members takes ownership of the issue and drafts a reply to the user, which RT automatically records and forwards to the user.
- The staff member resolves the ticket and heads down to the pub for a pint.

Kennt jemand ein aehnliches Script, welches vor allem noch kostenlos ist,... und VOR ALLEM - FOR FREE - erhältlich ist?

Am besten PHPx :) aber perl wäre auch kein Problem...

Herzlichen Dank,

Gruß Marco
 
hm... eventuell habe ich etwas gefunden...

phpTickets von InetFlex..

Wenn ihr weitere kennt, bitte trotzdem posten..

Danke
 
>>
You setup one or more POP accounts on your mail server, ex.: [email protected].

You configure the script with the username and password to access this account.

The script gets mail from this account, it checks if it is a new ticket or a reply.

It then lists the tickets in order of priority. It is also possible to use a form located on your website to create a support ticket, no need to send an email, the ticket is automatically added to the database.
<<

hört sich ja gut an. nur das problem ist das ich cronjobs (wäre wohl das einfachste fürs mail checking, bei meinem webhoster - minumum auf 4 stunden setzen kann :(

ist natuerlich nicht das beste, alle 10 minuten selbst http://www.xyz.tld/cgi-bin/mailcheck.php aufzurufen...


aber mal schauen... ich teste es einfach mal :)
 
Hi TCB,

hast Du Dich schon ´mal bei LF unter "Homepage" durchgekämpft?  ;)
Vielleicht ist ja ein passender Link für Dich dabei.

Grüsse
Kinski
 
o.k. installation ist in 1 minute geschafft... nur bekomme ich

Ich bekomme lächerlicherweise einen 50Xer Error Code, was ich eigentlich von Perl Scripten kenne..

Premature end of script headers: index.php  heisst es im error file...

einen fehler im php script kann ich eigentlich ausschliessen, da ich es mitlerweile 3x durchgegangen bin?!

Irgendeine Idee?

>>
WUNDERBAR... JETZT GEHT NIX MEHR... t* hat mal wieder routingprobleme... nicht mal cnn.com lässt sich aufrufen. nach dem zweiten hop ists tod :/
<<

Die Suppentrullis von der t* Hotline dort haben wohl zu viel geschlafen. "NEIN, wir haben keine Routingprobleme! Überprüfen Sie bitte Ihre Einstellungen" :(

komischerweise geht es jetzt wieder...
 
Hi TCB,

hast Du Dich schon ´mal bei LF unter "Homepage" durchgekämpft?
Grüsse
Kinski

LOL... auf diese Idee bin ich natürlich nicht gekommen, obwohl es eine Seite ist, die ich schon unzähligen Personen empfohlen habe.

Wie wäre es wenn Du mal ein paar kleine Buttons der Öffentlichkeit zur Verfügung stellst - zwecks Verlinkung :)

(obiger satz hört sich sehr drohend an, habe ich beim überlesen gemerkt - es soll also in KEINER FORM eine drohung sein LOL)

Danke,

Marco
 
So... hier nun nochmal die Fehlermeldung (beim Aufruf von INDEX.PHP)

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.


Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
 
;D ;D Ich werde doch niemandem drohen wollen, muß jeder selbst wissen, ob er fündig werden will oder nicht.  ;D ;D

Auf die Idee mit den kleinen Button bin ich jetzt noch nicht gekommen. Werde in einer freien Minute welche erstellen und auf LF zur Verfügung stellen. Danke für den Hinweis!  ;)

Grüsse
Kinski
 
;D ;D Ich werde doch niemandem drohen wollen, muß jeder selbst wissen, ob er fündig werden will oder nicht.  ;D ;D

NEEEEEEEE...

ich meinte meinen eigenen satz:

"Wie wäre es wenn Du mal ein paar kleine Buttons der Öffentlichkeit zur Verfügung stellst - zwecks Verlinkung"

LOL.. hört sich nach dem zweimaligen lesen an wie ...

"Seh mal zu dass Du das fertigbringst oder so"  

das war nicht auf DEINEN satz bezogen LOL
 
"Ein Ticketing auf EMail Basis funktioniert fuer unsere Kunden nicht." habe ich gerade bei meinem Webhostingprovider gelesen..

Na klasse... 6 Stunden am script rumarbeiten... und alles umsonst :(
 
Ich kenne 3 Ticket Systeme:


> "Ein Ticketing auf EMail Basis funktioniert fuer unsere Kunden nicht."
> habe ich gerade bei meinem Webhostingprovider gelesen..
Hä? Warum sollte das nicht funktionieren?

Gruss,

Ruediger

Soweit ich weiss, haengt das damit zusammen, dass der Mailserver ein einzelner isolierter Server ist.

Hier nochmal die komplette Antwort von meinem Webhoster:

Ein Ticketing auf EMail Basis funktioniert fuer unsere Kunden nicht. Allerdings muss man nicht immer EMails nehmen, es ist nur fuer viele Kunden der komfortabelste Weg.

Ich hoffe jetzt wendet keiner ein, dass man ja die EMails auf einem anderen Server bearbeiten und per FTP-Upload und anschliessendem URL-Aufruf ja doch in eine Datenbank bekommt. Solche Konstrukte verschweige ich hier mal...

Ist mir abler persönlich ein wenig zu hoch, warum ein TT-System auf E-Mail Basis nicht funktionieren soll?!

Gruß Marco

PS: Danke fuer die Links, schaue ich mir jetzt mal an
 
- gcdb
soweit ich es eben gesehen habe, auch nur web-based, keine aufnahme von neuen tickets per e-mail.

- Web Helpdesk
auch nur web-based für den kunden

- PHP Helpdesk
PHP Helpdesk habe ich auch schon auf vielen Seiten gefunden, nur das Problem bei dem Ticket System ist,
dass der Kunde oder der Interessierte WEB-BASED eine Anfrage stellen muss. Ich persönlich, und ich denke auch Kunden würde eher einfach eine e-mail schicken.

Der Kunde würde dann einfach eine e-mail mit einer einmaligen Ticket-ID und einem Kennwort zurückbekommen. Mit diesen Daten kann er zum einen dann direkt webbasiert überprüfen ob an seinem Ticket schon gearbeitet wurde - und wenn - was für Schritte bereits unternommen wurden.

Und zum anderen kann der Kunden bei einem einer eventuellen Ergänzung (oder wenn der SUpport antwortet - und der Kunde immer noch eine Frage hat) einfach eine e-mail an [email protected] mit dem Betreff [Ticket ID 1234321] senden.

Das einzige Trouble Ticket System auf E-Mail Basis, was ich persönlich -for-free- kenne ist Script Request Tracker. Nur das Problem dabei ist - das es mod_perl benötigt.

verdammt nochmal, ich habe vor kurzem noch so viele von diesen e-mail basierten tt systemen gefunden, leider weiss ich nicht mehr wo :(
 
Bist Du etwas in PHP bewandert?

Dann könntest Du ein Webmail Script für Deine Zwecke abwandeln. --> z.B. PHPOST

POP3 Server abrufen, E-Mails parsen und in Datenbank von
z.B. PHPHelpdesk einpflegen.

Dürfte kein allzu schweres Problem sein.

(Falls jemand ein fertiges Script hat, immer her damit  ;) )

Gruss,

Ruediger
 
Hi Ruediger,

 ich glaube ich habe schon was gefunden.

Da ich in PHP nicht so bewandert bin ist dieses fertige Script schon bissl besser.

Ein Mailparser ist schon dabei und noch ein kleines schönes GetPOP CGI. Habe es gerade auf meinen Webspace geschmissen. Mal schauen ob es funktioniert...

Sobald ich mehr weiss gibt, poste ich hier ein Update...
 
Mal eine dumme Frage.

Es ist doch richtig, dass bei jedem Perl Script / cgi immer der Perl Interpreter angeben werden muss, oder?

#!/usr/bin/perl oder was auch immer.

Es ist doch zwingend notwendig, oder?
 
>>
The GetPOP modification connects to a POP3 account that you specify.  Once connected it downloads all of the mail.  If it finds an e-mail with a ticket number in the subject it takes it as a response to the ticket and enters the information into the database.  If there is no ticket number in the subject the script will issue a new ticket for that e-mail.
<<

Hört sich ja logisch an. Ist ein Add-On für Castle Support
http://castlecgi.castellum.net/page/castle_support.htm das einzige Problem ist, dass ich beim Aufruf des Scripts einen Fehler erhalte. Um was für einen Fehler es sich handelt steht natuerlich weder in der Fehlermeldung noch im Error-File. :(

Wie auch immer, jedenfalls steht in der README dass man einen Cronjob erstellen soll. Da der Provider bei dem ich das Script gerade Teste keine Cronjobs erlaubt frage ich mich ob ein Cronjob denn unbedingt erforderlich ist.

Denn eigentlich kommt es doch gleich ob ich nun das Script selbst per Hand http://www.url.com/cgi-bin/script.cgi aufrufe, oder der Cronjob das für mich erledigt, oder irre ich mich?

Der Cronjob ist doch wirklich nur dafür da dass in einem bestimmten Abstand Script XY automatisch aufgerufen wird, oder?

Irgendwie umständlich erklärt... also nochmal Kurzfassung:

Webbased Trouble Ticket System läuft über Castle Support, funktioniert auch einwandfrei. Zu diesem TT System gibt es ein Add-On namens MOD-GETPOP, welches einen POP3 Server abruft und dann die neuen Mails in die Datenbank von Castle Support schreibt. In der Readme des Add-On steht, dass man einen Cronjob erstellen soll, wodurch dann halt alle X Minuten das Script aufgerufen wird. Da mein Provider keine Cronjobs zulässt, versuche ich das Script MANUELL (testweise chmod+777) über http://www.url.com/cgi-bin/script.cgi aufzurufen, dabei kommt es zu einer Fehlermeldung, die leider nichts - nicht mal im Errorlog - aussagt.
 
JA, der Aufruf der Peal Interpreters ist zwingend erforderlich.

JA, der Cronjob ist nicht zwingend notwendig, sofern Du das
Skript genauso aufrufst wie in der crontab angegeben. Ist dann
halt nicht immer auf dem neuesten Stand.

Einen parse Error gibt es dann aus einem anderen Grund.

Gruss,

Ruediger
 
@Ruediger

Herzlichen Dank. Leider funktioniert es immer noch nicht  :'(

Ich denke fast wieder dass auch dieser Provider den Mailabruf über den Webserver nicht erlaubt, wie mein anderer Provider :(
 
@TCB:
Versuch mal phpost zu installieren:

http://webgadgets.com/phpost/

Super easy, nur ein File anpassen (Pfade), schon
hast Du einen Webmailer. Wenn Du damit einen POP3
Account im Netz abfragen kannst (z.B. Deine gmx/web.de Adresse), sollte es auch mit Deinem anderen Script funktionieren.

Gruss,

Ruediger
 
Zurück
Oben