ticketing rendszer

 ( petik | 2010. január 27., szerda - 12:47 )

Sziasztok!

Szeretnénk bevezetni egy ticketing rendszert, ami valahogy így működik:
- ügyfél weboldalon nyit egy ticketet
- ez bekerül a rendszerbe, kap egy azonosítót, valaki felkapja, vagy escalálódik egy idő után.
- lehet az esethez csatolni fájlokat, megjegyzéseket, ...
- email-integráció: ügyfél kap státuszüzeneteket, ...
+ a létrejött esethez további infókat csatolni email-ben is lehet (ügyfél elküld egy levelet ami tartalmaz case ID van pl. a tárgy mezőben).

Ez az utolsó tűnik olyannak, amit (egyelőre) nem találok az OTRS-nél. Létezik ilyen készen? Valakinek van ötlete, hoyg mivel próbálkozzunk?
Ahogy az eddigi fórumokat néztem, a ticket-kezelő rendszerek közül elsőként az OTRS és a Mantis az, amit érdemes alaposabban megnézni.

Kösz, üdv.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hello,

Az OTRS-t használjuk produktívan több, mint két éve. Abszolút jól működik.
A webes felületét nem használjuk, de nem valami nagy meló beizzítani.
(A userek meg alapból lusták. E-mailt még csak-csak írnak, de egy webes formot kitölteni.. Ahhh.)
Nálunk egy Oracle 10g van alatta, userek LDAP-ból authentikálnak.

+1 OTRS. Nagyon szeretjuk.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

+1. szépen bele lehet csövezni leveleket, a Nagios-t is hozzá lehet drótozni, ráadásul az OTRS::ITSM a teljes nyilvántartásnak jó alapot tud adni, cmdb-vel, sla-val, függőségek kezelésével együtt.

Az ITSM-ben hogyan lehet a gépeket cégekhez (vagy helyekhez) kötni?

sub

Webszerveren hogy oldom meg? Mert ahogy néztem, ssh legalább szükséges a felrakásához.

Mi a bajod az ssh-val?

Gondolom csak egy szimpla LAMP-os tárhelye van - azzal mondjuk nem sokra megy, mert az OTRS Perl-ben készült.

És Perl-t elérsz-e ott, ahova fel szeretnéd pakolni?

CPanel áll rendelkezésemre, ott is sima felhasználóként. Így korlátozottak a lehetőségeim.
Ezt találtam a cPanel felületén, mint lehetőség:
"Perl Module Installer
Perl modules are collections of functions that allow you to perform tasks in Perl. You will need to install a Perl module before you can use it inside a Perl program."
Illetve van "SSH key", gondolom mégis tudom használni az ssh-t. Viszont gondolom nem root-ként értelmez, ezért nem tudok akármit telepíteni.

Még ránézhetsz a Trac illetve Opengoo nevű dologra is. A Trac és a Mantis inkább a fejlesztők számára kényelmesek.
Az otrs inkább adható ki ügyfeleknek használatra, bár azt is tudni kell használni. Az ügyfelek inkább telefonálni szeretnek többségében.

ez szerződés kérdése, hogy mit szeretnek jobban.

Mi mantist használunk. http://www.mantisbt.org/

Az utolsó pont szerintem kis programozást kíván, de megoldható. A Mantis elég jól fejleszthető.

http://kovisoft.hu

Amit keresel, az a redmine http://www.redmine.org/

--
Ami elől menekülsz, az után szaladsz.

+1

Már sokat említettek az előttem szólók. Mi Request Trackert használunk céges szinten. Teljesen elégedett vagyok vele.

+1

+1
---
gameboy rocker

+1

RT4 for prezident :)

Epp most szivok vele. Azt mondja, a requestor cime nem lehet az ami, mert azon a cimen o fogad levelet es igy loop lehet.
persze azon a cimen nem fogad levelet.

Mas nem talalkozott ezzel?

10x
tompos

Valoban, arrol a cimrol nem tudsz neki kuldeni, amin fogadod a leveleket. Miert is akarsz ilyet?

"persze azon a cimen nem fogad levelet"

Jogos, nem figyeltem oda. Muti mar a configodat pls.

Azt, amit a configuration oldalon mutat. Azert kerdezem, mert az egy eleg hosszu vmi.

10x
tompos

pastebinre vele! :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Masold be a RTAddressRegexp erteket legyszi.

Kosz, ez valoszinuleg valoban megoldana. Magamtol nem talaltam meg. Mindenesetre mar egy workaround megoldotta a dolgot es azt mondtak a userek, h most mar maradjon..

tompos

Titok, hogy mi volt a workaround?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igazabol nem teljesen ertem, hogy hogyan hasznaljak, de ok maguknak viszik fel (jobbara?) a dolgokat, ticketeket.
Van ket user, mint kiderult azokra panaszkodott csak, bar az allitasuk szerint ez nem igy van.
A lenyeg, hogy annak a 2 usernek az email cimet megvaltoztattam a rendszerben egy masikra es utana mukodott. Igy volt, h a kecske is megmaradt, meg a kaposzta is jollakott.
Mint kesobb kiderult a fentiek alapjan, mind2 cim szerepel ebben az opcioban, igy gondolom eleg lett volna, ha ezt egyszeruen uresre allitom, mivel amugy email fogadasra egyebkent sem hasznaljak a rendszert.
Az szamomra nem vilagos teljesen, hogy miert szerepeltek ezek a userek ebben az opcioban automatikusan, mivel valoszinuleg vhol meg el van szabva vhol a rendszer melyebben is. Annyira nem foglalkoztatott a dolog.

tompos

+1

bukmark
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

+1
--
Légy derűs! Tégy mindent örömmel!

+1

--
return 0;

sub

sub

Egy nem szorosan a témához tartozó kérdés:

Milyen módszerekkel lehet a felhasználókat rávenni, hogy telefon vagy email helyett inkább weben ticketet nyissanak?

Minden alkalommal elmondod, hogy "Legközelebb weben légyszi" és lassan rászoknak?

Vagy minden alkalommal te magad töltöd ki az űrlapot és nem változik semmi?

Köszi

PHPAdmin - Egyedi felületek készítése

csinálsz egy scriptet ami automatikusan átteszi ticketbe a mailt + kikapcsolod a telefont

Első lépésként VOIP és hozzá egy voice recognition system... :)

Bocs, de nem tudtam kihagyni. Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Azért ezzel óvatosan, mert nem annyira utópia... :-) A Telenornak van már valami hasonló kísérlete.

Francia, Angol nagyobb biznisz szolgáltatóknál is bevett szokás

Osztrak T-Mobilenal is.

egyszerű:

nem fogadod el emailben, telefonon is csak akkor ha nincs internetük, és ez a probléma :)

pl. ez van a támogatási szerződésben mint elsődleges bejelentési felület. Ha nem ezt használják, akkor nem a meghatározott folyamat szerint járnak el, és az SLA sem indul el ... :)
Ha meg felhívnak kritikus esetben, akkor vagy tudatosítod ezt, vagy Te töltöd ki, de úgy, hogy amíg töltöd, addig ő se rakhassa le a telefont.
Nyilván csak a hibajavításhoz szükséges infókat célszerű megkövetelni, illetve azokat, ami alapján ellenőrizhető az, hogy egyáltalán az adott eszközre/rendszerre van-e support.

Legy egy picit ugyfelorientalt: ha az ugyfelnek a kenyelmes felulet egy telefonszam, akkor neki egy telefonszam kell.

A legtobb rendszer tamogatja ezt.

En is hajlamos vagyok a telefonos ugyfelszolgalatok menujeben egy embert keresni, mert meggyozodesem, hogy gyorsabb, kenyelmesebb.

Mi OTRS-ben emailen keresztul vesszuk fel a ticketeket automatikusan. Inkabb arra nehez ravenni a usereket neha, hogy arra valaszoljanak, ne pedig kuldjenek egy mas subjectes email-t, es nyissanak uj ticketet - mert aztan en meg kezzel szerkeszthetem ossze oket :). OTRS-t amugy szeretik nalunk az ugyfelek nekik csak emailt kell kuldeni, ha esetleg telefonon keresnek akkor lehet ugyis felvenni jegyet, utana emailben ertesiteni oket a jegyek allapotarol. A jegyeket webes feluleten bejelentkezve megnezhetik, leellenorizhetik.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

rendszeresen valami kutyut sorsoltok ki azok kozott, akik weben nyitnak ticketet :)

ISO-s munkautasításokban ez van, csak azon keresztül fogadunk el kérést, illetve hiba bejelentést (cégen belül).
Tartani kell oktatást, amiben kiemeled a rendszer előnyeit, ami nektek, illetve a felhasználóknak előny, pl.:
- nyomon követhető lesz
- lehet tudni, hogy ki foglalkozik/foglalkozott vele
- hol tart.

Mert mi van, ha:
- beteg lesz a kolléga,
- nincs rögzítve és elfelejti,
stb.

Szóval próbálni hatni az értelműkre.
A végső érv: CSAK :D

Persze még sokáig próbálkozni fognak, de lassan csökken :)

Webappz - http://sys-admin.hu/

"Milyen módszerekkel lehet a felhasználókat rávenni, hogy telefon vagy email helyett inkább weben ticketet nyissanak?"

Sehogy.
Ez a legkényelmetlenebb módszer, úgysem fogják használni, kár kapálózni....

Megfelelően mély IVR-menü bevezetésével. 4-5 szint már bőven elég :)

"Milyen módszerekkel lehet a felhasználókat rávenni, hogy telefon vagy email helyett inkább weben ticketet nyissanak?"

Ki kell kommunikalni. Jol. Az egyes departmentek vezetoinek, hogy telefonon nem all modotokban requesteket fogadni. Nem biztonsagos, nem azonosithato a user etc.

Ha nem megy, akkor a managementtel le kell szervezni, hogy joval dragabb legyen egy (mondjuk "emergency", "severity 1", "ohhshit!") telefonon erkezett request kezelese, mint a webes.

Ehhez persze a webes rendszernek 100%-osnak kell lennie. Nem lehet lassu, nem lehetnek benne nyilvanvalo bugok.

Vegszukseg eseten a telefon rendszer megreformalasa jelentheti a kiutat. A dept. kap egy, azaz egy darab telefonszamot, amit vilagvege eseten fel lehet hivni. Mindenki mas telefonjarol csak kimeno hivasokat lehet kezdemenyezni.

Ahhh, megint bilibe log a kezem ....

Nem veszed fel a telefont, nem oldod meg a mailben kapott feladatot :) Elég egyszer kikommunikálni, onnantól náluk a labda.

Olyat nem lehet, es felelos vezeto nem is engedhet meg ilyesmit. Es folyamatosan kell kommunikalni. Jon mailba egy ticket: legyszi kuldd ujra a

cimre. Jon telefonon: oke, de legyszi kuldd el emailben a

cimre is a problemadat. Egy ido utan atszoknak, de olyat sosem szabad csinalni, hogy nem reagalunk az ugyfelkeresre semmit. Valamit muszaj.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

és ez? http://osticket.com/
osticket

pro:
kinéz valahogy

kontra:
bugos email processzálás
magyar karakterekkel elszáll
utf8 ismeretlen számára

Ez volt az első ilyen rendszerek egyike, amibe belefutottam annó, majd 2 napig próbáltam az itt-ott megjelenő bugokat betömni, de mivel egy hiba kijavításakor 2 új került elő, a 3. napra kidobtam a francba. Azóta otrs.

Most sasolom, írnál bővebbet mit hogy próbáltál, mert a pro design (a usernek teccik nem teccik ez számit ) az mindent ver, a kontra oldalon meg utf-8 az egész és vígan elvan az ŐŐŐŐŐŐŐŐ betükkel. :)
E-mail-t még nem probáltam.

Most sasolom, írnál bővebbet mit hogy próbáltál, mert a pro design (a usernek teccik nem teccik ez számit ) az mindent ver, a kontra oldalon meg utf-8 az egész és vígan elvan az ŐŐŐŐŐŐŐŐ betükkel. :)
E-mail-t még nem probáltam.

Pedig pont az email feldolgozoja bugos mint a fene... ezzel szivok egy jo ideje, de meg nem sikerult rendre tanitani.

3 év óta is bugos? Felraktam és kiküldte a leveleket ahogy kell. Bár azt nem néztem, hogy mennyi erőforrást eszik.

GLPI-t nézd meg, az pont ezt tudja (meg millió mást) nagyob profi.

Hű, jut eszembe!

Olyan rendszert ismertek, ami ticket és crm is egyben? Egy ilyen rendszer az álmom!

Széles körben használt Bugzilla

--
The Net is indeed vast and infinite...
http://gablog.eu

subscribe

+subscribe

OCS Inventory + GLPI ? Együtt igen jó lehet, de még nem tudtam kipróbálni.

Én Joomla 1.5 CMS (OpenLdap hitelesítés) + Billets komponensel oldottam meg. Kétnyelven, szépen megy, tud mail->ticket konverziót is. Pedig mit kerestem az ingyeneseket! Lehet nem tudtak OpenLdap hitelesítést? Már rég volt, nem emléxem.

Az otrs tud :)

Ki mit használ?

eticket? osticket? otrs?

kayako support suite

jira egesz jo

--
NetBSD - Simplicity is prerequisite for reliability

Szoftverfejlesztős projektekhez tényleg príma, üzemeltetéshez nem tudom, mennyire hegeszthető bele az eszköznyilvántartás.

Legszívesebben felgyújtanám, mint egy marék avart, annyira.

Ezt kurvagyorsan felejtse el mindenki.

Bővebben?

Nekem 1 igazan nagy problemam van vele uzemeltetoi oldalrol: nem ismeri az UID fogalmat.

tompos

lower_user_name? :-D

Ezt nem ertem, hm?

t

atlassian jira? táblaszerkezet? ezekről beszélsz?

Igen, a Jira-rol. A tablaszerkezetet meg soha nem neztem es ilyen tablat nem is latok.

udv,
tompos

ez egy mezo a cwd_user tablaban.

Valoban van ott egy ilyen mezo. Nalam ugyanaz van benne, mint ami a username.
Ugy latom, van itt egyebkent egy ID mezo is, de nem ertem, mire hasznalhatja.
En arrol beszelek, hogy ha az ldapban a tompos usernek 123456 az UID-ja, akkor legyen a jira-ban is az es az alapjan azonositsa a usert mindehol.

Ezt en ugy tudom, nem tudja.

tompos

Mert nem is kell tudnia. Az LDAP-ban a DN szamit, meg esetleg talan a CN. Az uid az pont irrelevans, tekintve, hogy az amugy is csak egy extension, ami akar nem is letezhet, nem kotelezo attributum (oke, a posixAccount-nal az, de pl. a person-nal nem).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Leszarom, mi kotelezo. Kell nekem vmi egyedi. A username nem az.

tompos

LDAP DN. Valahol csak van tarolva az is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hol, a jira-ban? Nincs Vagy nem ertelek.
A konkret problema nem az, h nem kezeli, hanem az ebbol eredo anomalia.

John Smith jon a ceghez, megkapja a john.smith felhasznalot, belep a jira-ba, ott a jira szinten ezzel azonositja. Innentol kezdve meg1 john.smith usernevvel rendelkezo felhasznalo nem lehet a halozatban, mert a jira miatt kotott. Hiaba lepett le, utotte el a villamos, vagy lett vele akarmi, lett egy uj felhasznalni masik uid-dal, john.smith felhasznalonevel, a jira azzal fogja azonositani. Pl. frankon odaadja neki a ticketeket, bejegyzeseket, stb.

tompos

Látom, te is találkoztál ezzel a problémával :)

A korrektseg kedveert egyet sem tudok, ami ezt kezeli, csak legfeljebb azokhoz nem volt ilyen gyakran kozom. Pl. szerintem a redmine hasonlo cipoben jar, bar ott valoszinuleg egy pici barkacsolassal megoldhato.

Ezen kivul ez gondolom ervenyes a verziokezelo rendszereknel is.

tompos

A tortenet akkor lesz igazan vicces , ha egy masik alkalmazas ugy van kitalalava, hogy nem lehet usert torolni, csak deactivalni.
Egy megint masik alkalmaz meg hibakat dobal, ha egy user eltunkt az AD bol es biz. lepeseknel hivatkoznak ra.
Egy harmadik , meg ha atnevezed usert es az e-mail cim nem valtozik, megprobalja importalni, de az egyezo email cim meg tiltott..

Igazabol, ha az AD-ben sem torlunk usert es utana meg sorszamot kapnak a userek, akkor szinte minden alkalmazas boldog lesz.
User atnevezeset meg nem kell engedni. Felolem a hazasagot is betilthatjak :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Emlekezz, hogy hazassagnal csak a nev valtozott, a samaccountname nem. Pont emiatt :-)

Uj vagy meg ott :) Nem mindenutt igaz ez.

cn talan nem valtozik...

Tovabbi infot privatban.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nálad ugyanaz, de ha AD-ből az jön mint sAMAccountName, hogy KissGeza, akkor különbözni fog és te csak kissgeza-val fogsz tudni belépni.

Azt az ID-t meg kizárólag az user preferenciák (nem filterek!) kötésére.

Igen sok mindent nem tud.

Elsőre jó. Szép. Gyors. Letisztult színek. Vannak hozzá pluginek, némelyik free, némelyik fizetős.
Aztán elkezded használni.
Bejövő emailek... kimenő emailek... issue-k... html formátumú emailből betöltött comment szétbassza a template-et...
Közben az userek jönnek, hogy: "Lehessen keresni az issuehoz csatolt állományokban is!" Erre egyetlen (és az is free) plugin van készen, ami működik is, bár 4 éve nem nyúltak hozzá... a jira meg Lucene-t használ, de nem dependencyként, külön jarból, hanem be van húzva a forrása. És módosítva. Mint minden más is.
Ergo mindig, milliméter pontossággal tudnod kell, hogy hol, milyen verziójú jar-t kell letöltened a plugin mellé, hogy illeszkedjen a forrásfába behúzottal. Gyakorlatilag egy igazi, replaced által gyakran fikázott foss projekt, csak még fizethetsz is a supportért, ami a hp openview support portal hatékonyságával vetekszik.
Pl. screenshot készítő applet, aminek a neve hardcodeolva van egy classban (ami annyibol all, hogy hardcode-oltan document.write-ol egy statikus html-t, soronkent egy, ami jquery-n at letrehoz egy applet htmlelementet es a statikusan kirakott valtozokbol betolti az appletet), mint xyapplet.jar, DE az adott könyvtárban jelen levő egyetlen fájl neve 3x olyan hosszú. Szimplán más néven dobták oda a jart és fostak rá, hogy megnézzék, megy-e. Ja, support szerint a kliens java verziója nem jó. Kénytelen voltam egy hardlinket csinálni rá.
Vagy backup: egy zip. benne egy xml. az xml-ben minden. MINDEN. Gyakorlatilag egy 1 évet futott jira, amin van 8ezer user és napi 400 interakció, egy darab, 3GB-os xml-t köp ki backupként, bezippelve. Már ha nem timeoutol az ezt készítő servlet. Importálás is webes felületen át. Igen, tölts fel egy 600 megás zipet.
Létrehozol egy projektet. Később mindent megváltoztathatsz, kivéve a project key-t. Az egyetlen dolgot amihez semmi sem kötődik. Meg szinte mindent megadhatsz kreáláskor, kivéve a metaadatokat, ahhoz nem csak hogy be kell fejezned a kreálást, még admin módból is ki kell lépned, hogy lásd azt a menüpontot!

Többet nem mondok, mert azt nem lenne illendő.

turul16 majd jól beszól, de nekem halálosan faszom kivan a jirával.
Gyere vissza!

turul16? Inkabb majd _Franko_ fog nyuglodni, hogy dehat miert fikazod, mikor olyan jo kis rendszer, nemerteszhozza.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

turultol orokoltem meg.

Nem pont ide illik, de erről a ClearCase/ClearCase Remote Client ugrik be. Elsőre az is egy használható eszköznek tűnik, de ha dolgozni kell vele, akkor jönnek ki a bajai. Egységesen, szívből gyűlöli itt mindenki a cégnél. Aktívan tud akadályozni a munkában.

* Igen, tudom, van egy csomó hely, ahol jól működik, de nálunk nem.
--
http://www.open-st.eu

Mert azok már kicsit elavultak szerintem. Ha már Rational, akkor ott az RTC, ami szerintem sokkal jobb (habár még azért van 1-2 gyerekbetegsége).

Oruj, hogy nem a tobbi ott levo ticketing rendszer melysegeibe kell bele meni.
Es oruj, hogy a tobbi kodjat nem latod, mar a viselkedesuk is sok nekem :)

A jira sokat fejlodott, te mar egy sokkal letisztultabb valtozatot latsz. Nehol valoban nem atgondolt az API, de mintha latnam a fenyt az alagut vegen. Kitartas.

Nem veletlen mondtam, hogy bugzilla az elejen. :)

Nem rosz a jira, csak arra es ugy kene hasznalni amire valo, ahogy valo.

Az attachment plugin migrilasat sajnos nem veletlen felejtettem ki, megmondtam hogy hogyan kene egy ujat implementalni, mert az hivatalosan is hallott plugin es csak sok verzioval ezelotti jiraval kompatibilis. Nem is volna nagy munka..
Mar kezdetekkor szoltam, hogy baj lesz , de ...
Masik lucane jar-t nem volna szabad hasznalnod (duplicalni), meg warningokat is dobal, nem veletlen szoltam az elejen.

Sok plugin letezik a jirahoz, de nem volna szabad hasznalni mindet, sokat mar az alkalmazott technologiak miatt kidobnek mielott magat plugint lattam volna.

Az alap jira nem rosz, es meg igy is masodik legjobbnak tartom.

A zip export csak 4G-ig megy, utana jobb ha kikapcsolod az osszes automatikus xml backupot.

Nem megyek, itt bugzilla van es nem kell meggyoznom senkit, hogy legalabb jirat hasznaljunk :)

Sot a legkiralyabb kernelrol sem kell vitatkozni :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Upgrade-eltunk 5.1-re, valtozott a lucene alatta :)

Többire:
:-D

ahaha, szerencsere en csak hasznalom, de a belso fejleszteseknel sokkal jobb

--
NetBSD - Simplicity is prerequisite for reliability

Én is csak használtam, de az üzemeltetéssel foglalatoskodó kolléga sem igazán szidalmazta :)

.

Az utolso ponthoz hasonlot nezegettem en is, csak nekem forditott a gondom, nekem van egy szimpla adatforrasom, es a customerhez kellene megjeleniteni (pl. hogy milyen csomagja van). Ahogy neztem az OTRS forrasat, meg az API doksikat, elvben van lehetoseg kulonfele panelkeket csinalni, amibe az adatot perl kodbol tolod, es csinalsz hozza egy DTL sablont, amiben meg az adatokat jelenited meg. Engem mondjuk rettenetesen zavar a Perl benne...

Nincs valami olyan kepessegu ticketing rendszer, mint az OTRS, csak PHP-ben? Mondjuk az nem baj, ha free... Irto jo lenne egy csomo mindent piszkalni benne, de a Perl tudasom eleg korlatozott, foleg ami az OOP-t illeti.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Lehet nem akartak kuzdeni a PHP gyermekbetegsegeivel. Perlezni, amennyire ehhez kell meg lehet tanulni egy-ket delutan alatt -- es akkor meg egy nyelvvel bovult a tudasod. Vagy ennyire ellene vagy?

Nem vagyok ellene, valamennyire tudok is perlezni, csak ez a modern, OOP perl ez teljesen kimaradt nekem, es egyaltalan nem latom at, hogy mit es hova, idom meg nincs rendesen megtanulni.

Ezert keresek olyan ticketing rendszert, ami olyan mint az OTRS, csak nem perlben van irva. Java/Ruby/PHP barmi jo, a Perl az pont nem annyira. A JIRA sajnos nagyon nem erre valo, mas hostolhatot meg nem talaltam ertelmeset. Meg WHMCS lenne jo, csak az meg ahhoz kepest draga, hogy nekunk igazabol csak a ticketing modul kell belole, meg az ugyfelnyilvantarto, a tobbihez nagyon sok munka lenne illesztest irni.

De lehet az lesz a vege, hogy van egy jo SOAP szerverem benne, es irok ele valami frontendet.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

az megvan ugye, hogy több jirát egy konténerben nem lehet hostolni :)

En meg egyet se szeretnek :P
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

helyes!

sub

sub

Az otrs ezt mind tudja, csak idő mire rájössz, hol és hogy konfigurald. Javaslom, mert a későbbiekben könnyen lehet vele extra igényeket is kielégíteni.

Nálunk a megoldás otrs: kapcsolatfelvételi ürlap, subject adott típus alapján kitöltve, otrs subject alapján teszi várólistára a ticketeket. Hibás subject esetén meg autoreply: használd a kapcsolatfelvételi űrlapot
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

Hasonlót keresek én is, ezért nem nyitok újabb topicot, ha nem haragszotok.
Nekem egy szerviz forgalmának nyilvántartására kellene egy ticketing rendszer.
Különböző Ügyfelek különböző készülékeket hoznak javítani.
A készülékek kapnak egy egyedi azonosítót (sorszámozott vonalkódos matrica), Ügyfél egy autoincrement ID-t kap.
Egy készülék több Üf.-hez is tartozhat (pl. eladja másnak), ill. több készülék is tartozhat egy Üf.-hez.
Előzményeket, statisztikákat szeretnék látni, javítási folyamatról haladásáról, fejleményekről publikus infókkal e-mailben tájékoztatni Üf.-et, belső megjegyzések, fájlok tárolhatóak, kereshetőek legyenek, ilyesmi.
Elkészültekről automatikus értesítést küldjön, a javításra várók listázhatóak legyenek, stb.
Az OTRS demóját nézegettem, de az szvsz nem pont erre való.

Ha CRM-el, webáruházzal is összeköthető, az lenne a legjobb. :)
Van ötletetek, mit használjak erre a célra?


openSUSE 12.2, vagy ami éppen jön.

GLPI?
Mikor néztem elég sok mindenre lehetett használni. Talán megoldhatóak benne ezek nagy része is.

Nézegetem, egyelőre nagyon ígéretesnek tűnik!
Köszönöm szépen a tippet!


openSUSE 12.2, vagy ami éppen jön.

Talán még nem késő, mert már eltelt pár hónap, de a Kayako-t tudom ajánlani, ha érdekes még dobj egy privat mailt.

Jól sejtem, hogy fizetős?
Free megoldás érdekelne...


openSUSE 12.2, vagy ami éppen jön.

Fizetos miert nem? No offense, csak erdekel, persze, csak ha publikus.

Hosszu tavon behozza az arat, tapasztalatbol tudom.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Például azért, mert ha fizetek valamiért, nem szeretném, hogy még nekem kelljen hegeszteni, hogy úgy működjön, ahogy én akarom.
Vagy megcsinálom magamnak, vagy testreszabnék egy majdnem jót.


openSUSE 12.2, vagy ami éppen jön.

Nem tudom mihez kellene, de ha dobsz egy privát mailt akkor tudok ajánlani egy most induló szolgáltatást.

Ehhez kell.

Dobj egy privát mailt az induló szolgáltatással és ha érdekel, megkereslek.


openSUSE 12.2, vagy ami éppen jön.

Gondolom Kayako alapokon, ha mar ennyire tolod. Lesz free resze is?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Volt szerencsém a Kayako-hoz, a supportja kritikán aluli.:-(

Csak annyit, hogy az ügyfél javítja a hibát a kódban - miután megunta a levelezgetést az ügyben - mert a supportra ugyan várhat... Az indiai srácoknak még van hová fejlődni ezen a téren.

Hmm... India... :)

Érdekesnek tűnik: http://www.combodo.com
Ha egyszer elkészül a 2.0:): http://www.accord5.com/trellis

"we hope to have a stable, documented release by the end of 2011"

Trellist felraktam és a főoldal csupa fehér üres oldal, az admin része oké. Pedig jónak tűnik.

Előző mhelyemen kayako volt, nem hallottam róla sok rosszat. A ticket nyitás egy sima emaillel is működött (bár gőzöm sincs hogy ez default ficsőr vagy valami hegesztés).

--
http://developersideas.blogspot.hu/
http://neurogadget.com/