- lms - lists.lms.org.pl

Re: RT - za³o¿enia
by Grzegorz Jak�bik 30 Cze '04

30 Cze '04

<--- cut here ---> > Dla każdego zgłoszenia generowany jest ID to oczywista sprawa ale > myślę, że jeszcze powinien być generowany ID_DLA_KLIENTA, który miałby > np format CYFRACYFRA-LITERALITERALITERALITERA-CYFRACYFRA i byłby dla > danego zgłoszenia generowany losowo i sprawdzany czy przypadkiem już > nie był użyty. > Dla klienta, który wypełnia formularz na stronie WWW ten identyfikator > pojawiał by się jako potwierdzenie z tekstem typu - "w przypadku > dalszych kontaktów z BOK'iem dotyczacych tej sprawy proszę posługiwać > się tym identyfikatorem". > Dla zgłoszenia z emaila odsyłany byłby email z potwierdzeniem i > identyfikatorem i podobnym tekstem. > > Po co to ? :) > Myślę, że jakoś trzeba powiedzieć klientowi jak ma identyfikować dane > zgłoszenie jeśli np będzie chciał po 2 godzinach zadzownić do biura i > zorientować się na jakim etapie jest rozwiązywanie zgłoszonego > problemu (to tylko przyklad). Wg mnie klient nie powinien wiedzieć, że > zgłoszenie, które wysłał ma numer 10234 - może sobie pomyśleć, że > świadczymy bardzo awaryjne usługi :))) <--- cut here ---> Ja dodam do tego tylko tyle ze mozna zamiast komplikowac sobie sprawe i robic losowo numer zgloszenia ktory nadal moze miec wylosowana jakas duza liczbe i co bardziej inteligentni uzytkownicy sieci mimo jakichs liter na poczatku numeru zgloszenia (dla mydlenia oczu) wymysla sobie ze im wyzsza cyfra tym wiecej zglozen juz minelo to tak jak z numeracja faktur. Zawsze po numerze faktury mozna wiedziec ile juz dana firma od poczatku miesiaca badz roku wystawila faktur :). Ja proponuje rozwiazanie wrecz trywailen kazdy user ma swoje wlasne pole w bazie dotyczace awarii i w nim jest przechowywana liczba awarii i usterek ktore on sam zglaszal i w ten sposob taki Kowalski gdy zglosi awariie bedzie miala numer id_usera_+00001, nastepna id_usera+00002 itp itd. Przy tym jak inny User zglosi swoja awarie system odczyta jego dane i jesli nic nie zglaszal wczesniej dostanie id_usera swoje + tak samo numer awarii swoj czyli jak nic nie zglaszal to 00001 itp. To nam gwarantuje ze nik nie pomysli ze jest duzo awarii oraz kazdy bedzie mial swoj unikalny numer awarii. Co wy na to ? Pozdrawiam Grzegorz Jakóbik

1 0

Re: [lms] RT - założenia
by lukas 30 Cze '04

30 Cze '04

ALEC> Klient zgłasza problem. Operator BOKu rejestruje zgłoszenie (inaczej ALEC> ticket). ALEC> Ticket zawiera nast. informacje: ALEC> id - identyfikator ALEC> id kolejki - o tym niżej ALEC> temat - skrót problemu ALEC> zgłaszający - nazwisko i imię/nazwa klienta (jesli zgłaszający jest ALEC> klientem ALEC> sieci należałoby zapisać jego ID w dodatkowym polu 'userid', jeśli ALEC> zgłaszający ALEC> jest spoza sieci (powiedzmy przyszły klient) to dostaje userid=0) ALEC> data/czas zgłoszenia ALEC> stan (status) - na jakim etapie jest zgłoszenie ALEC> właściciel (owner) - to chyba przypisany do ticketa admin/albo ten co ALEC> rejestrował, a może zrobić dwa pola na tego kto przyjął i komu ALEC> przypisano? ALEC> (przypisywać można później) ALEC> description - opcjonalnie krótki opis zgłoszenia (opcjonalnie, bo treść ALEC> zgłoszenia ALEC> będzie zapisana w wiadomości od zgłaszającego, patrz koniec posta). ALEC> Każde zgłoszenie może mieć następujący status (stan): ALEC> Nowy - w momencie zgłoszenia ALEC> Przypisany - po przypisaniu do admina ALEC> Rozwiązany (Zamknięty?) - wiadomo ALEC> Zwrócony - (?) klient nie potwierdza rozwiązania problemu ALEC> Usunięty - gry zgłoszenie przyszło mailem i okazało się, że to np. spam. ALEC> W dalszej kolejności możnaby dodać pole 'priorytet'. ALEC> Zgłoszenia są pogrupowane wg kategorii i w ten sposób tworzą kolejki ALEC> (queues). Kolejki (kategorie) definiuje się samodzielnie. Dane dla ALEC> kolejki ALEC> to id, nazwa, e-mail (coś jeszcze? docelowo definiowanie uprawnień dla ALEC> operatorów do kolejek). E-mail to adres na który przychodzą zgłoszenia ALEC> mailowe (jak zrobimy backend do tego :) i z którego będą wychodziły ALEC> odpowiedzi do klientów. ALEC> Teraz historia zgłoszenia. Żeby zgłoszenie powstało, ktoś musiał nas ALEC> powiadomić, ALEC> zatem na samym początku tworzymy wiadomość (co automatycznie tworzy ALEC> ticket), ALEC> następnie wszystkie podjęte kroki, korespondencja z klientem to są ALEC> wiadomości. ALEC> Jakie pola będą w wiadomości to można zobaczyć w doc/lms.mysql (tabela ALEC> rtmessages). Wlasnie niedawno opisalem sobie podobny "modul" na papierze i o dziwo jest prawie identyczny ale nie do końca. :) 1. Grupowanie zgłoszeń na temat tego samego problemu. Niewiem czy dobrze rozumiem idee kolejki przedstawioną przez Ciebie, ale chyba to nie to o czym ja myślę. W każdym razie wg mnie należy dodać możliwość grupowania poszczególnych zgłoszeń w "jedno". Mam na myśli sytuację, gdy kilku klientów wyśle zgłoszenia dotyczący tego samego problemu (np awaria czegośtam), wtedy gość siedzący przy lms'ie grupuje tych kilka zgłoszeń w jedno i na liście figurują jako jedno zgłoszenie, ale system pamięta dane wszystkich zgrupowanych zgłoszeń po to, żeby później - po rozwiązaniu problemu można było do każdej z tych osób, które przysłały zgłoszenie dotyczące jednego tematu wysłać powiadomienia o rozwiązaniu problemu. Na liście zgłoszeń widniałyby tylko dane z pierwszego zgłoszenia a gdzieś dalej można by rozwinąć dane zgłoszenie i zobaczyć inne zgrupowane w to jedno zgłoszenia. Trzeba by dodać pole np "parent_ticket_id" które zawierałoby ID zgłoszenia nadrzędnego. Takie grupowanie byłoby "jednopoziomowe" czyli przy grupowaniu zgłoszenia B pod zgłoszenie A sprawdzane by było czy istnieje w systemie zgłoszenie, które ma jako "parent_ticket_id" ustawione id zgłoszenia B. 2. Identyfikator systemowy i identyfikator dla klienta Myślę, że docelowo można założyć iż zgłoszenie może przyjść mailem (pierwotne założenie) ale też np z formularza umieszczonego na stronie WWW danej firmy (czy później z jakiegoś skryptu, który uruchomiony na jednym z serwerów firmy wykryje, że padła jakaś usługa - to już taki daleki przykład :) ). Dla każdego zgłoszenia generowany jest ID to oczywista sprawa ale myślę, że jeszcze powinien być generowany ID_DLA_KLIENTA, który miałby np format CYFRACYFRA-LITERALITERALITERALITERA-CYFRACYFRA i byłby dla danego zgłoszenia generowany losowo i sprawdzany czy przypadkiem już nie był użyty. Dla klienta, który wypełnia formularz na stronie WWW ten identyfikator pojawiał by się jako potwierdzenie z tekstem typu - "w przypadku dalszych kontaktów z BOK'iem dotyczacych tej sprawy proszę posługiwać się tym identyfikatorem". Dla zgłoszenia z emaila odsyłany byłby email z potwierdzeniem i identyfikatorem i podobnym tekstem. Po co to ? :) Myślę, że jakoś trzeba powiedzieć klientowi jak ma identyfikować dane zgłoszenie jeśli np będzie chciał po 2 godzinach zadzownić do biura i zorientować się na jakim etapie jest rozwiązywanie zgłoszonego problemu (to tylko przyklad). Wg mnie klient nie powinien wiedzieć, że zgłoszenie, które wysłał ma numer 10234 - może sobie pomyśleć, że świadczymy bardzo awaryjne usługi :))) ALEC> Pozdrawiam I ja tez pozdrawiam :) -------------------- Łukasz Wojciechowski

1 0

Re: RT - założenia
by Tomasz Chilinski 30 Cze '04

30 Cze '04

On Wed, 30 Jun 2004 11:03:52 +0200, A.L.E.C wrote > Klient zgłasza problem. Operator BOKu rejestruje zgłoszenie (inaczej > ticket). > Ticket zawiera nast. informacje: > id - identyfikator > id kolejki - o tym niżej > temat - skrót problemu > zgłaszający - nazwisko i imię/nazwa klienta (jesli zgłaszający jest > klientem > sieci należałoby zapisać jego ID w dodatkowym polu 'userid', jeśli > zgłaszający > jest spoza sieci (powiedzmy przyszły klient) to dostaje userid=0) > data/czas zgłoszenia > stan (status) - na jakim etapie jest zgłoszenie > właściciel (owner) - to chyba przypisany do ticketa admin/albo ten co > rejestrował, a może zrobić dwa pola na tego kto przyjął i komu > przypisano? > (przypisywać można później) > description - opcjonalnie krótki opis zgłoszenia (opcjonalnie, bo treść > zgłoszenia > będzie zapisana w wiadomości od zgłaszającego, patrz koniec posta). > > Każde zgłoszenie może mieć następujący status (stan): > Nowy - w momencie zgłoszenia > Przypisany - po przypisaniu do admina > Rozwiązany (Zamknięty?) - wiadomo > Zwrócony - (?) klient nie potwierdza rozwiązania problemu > Usunięty - gry zgłoszenie przyszło mailem i okazało się, że to np. spam. > > W dalszej kolejności możnaby dodać pole 'priorytet'. > > Zgłoszenia są pogrupowane wg kategorii i w ten sposób tworzą kolejki > (queues). Kolejki (kategorie) definiuje się samodzielnie. Dane dla > kolejki > to id, nazwa, e-mail (coś jeszcze? docelowo definiowanie uprawnień > dla operatorów do kolejek). E-mail to adres na który przychodzą zgłoszenia > mailowe (jak zrobimy backend do tego :) i z którego będą wychodziły > odpowiedzi do klientów. > > Teraz historia zgłoszenia. Żeby zgłoszenie powstało, ktoś musiał nas > powiadomić, > zatem na samym początku tworzymy wiadomość (co automatycznie tworzy > ticket), > następnie wszystkie podjęte kroki, korespondencja z klientem to są > wiadomości. > Jakie pola będą w wiadomości to można zobaczyć w doc/lms.mysql > (tabela rtmessages). Piękne! Ja cały czas przymierzam się do edycji faktur :) > Pozdrawiam > Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Pozdrawiam Tomasz Chiliński

1 0

RT - założenia
by A.L.E.C 30 Cze '04

30 Cze '04

Klient zgłasza problem. Operator BOKu rejestruje zgłoszenie (inaczej ticket). Ticket zawiera nast. informacje: id - identyfikator id kolejki - o tym niżej temat - skrót problemu zgłaszający - nazwisko i imię/nazwa klienta (jesli zgłaszający jest klientem sieci należałoby zapisać jego ID w dodatkowym polu 'userid', jeśli zgłaszający jest spoza sieci (powiedzmy przyszły klient) to dostaje userid=0) data/czas zgłoszenia stan (status) - na jakim etapie jest zgłoszenie właściciel (owner) - to chyba przypisany do ticketa admin/albo ten co rejestrował, a może zrobić dwa pola na tego kto przyjął i komu przypisano? (przypisywać można później) description - opcjonalnie krótki opis zgłoszenia (opcjonalnie, bo treść zgłoszenia będzie zapisana w wiadomości od zgłaszającego, patrz koniec posta). Każde zgłoszenie może mieć następujący status (stan): Nowy - w momencie zgłoszenia Przypisany - po przypisaniu do admina Rozwiązany (Zamknięty?) - wiadomo Zwrócony - (?) klient nie potwierdza rozwiązania problemu Usunięty - gry zgłoszenie przyszło mailem i okazało się, że to np. spam. W dalszej kolejności możnaby dodać pole 'priorytet'. Zgłoszenia są pogrupowane wg kategorii i w ten sposób tworzą kolejki (queues). Kolejki (kategorie) definiuje się samodzielnie. Dane dla kolejki to id, nazwa, e-mail (coś jeszcze? docelowo definiowanie uprawnień dla operatorów do kolejek). E-mail to adres na który przychodzą zgłoszenia mailowe (jak zrobimy backend do tego :) i z którego będą wychodziły odpowiedzi do klientów. Teraz historia zgłoszenia. Żeby zgłoszenie powstało, ktoś musiał nas powiadomić, zatem na samym początku tworzymy wiadomość (co automatycznie tworzy ticket), następnie wszystkie podjęte kroki, korespondencja z klientem to są wiadomości. Jakie pola będą w wiadomości to można zobaczyć w doc/lms.mysql (tabela rtmessages). -- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0

Re: Mapa sieci - problem
by Dariusz Skarbek 30 Cze '04

30 Cze '04

Teraz przy wywołaniu: http://lms.softintelligent.com.pl/?m=netdevmap&graph=true&start mam komunikat: Nie można wyświetlić strony... Czyli z problemem wersji GD sobie poradziłem. Jeżeli będziecie mi jeszcze w stanie pomóc, to będę wdzięczny. Pozdrawiam Darek ----- Original Message ----- From: "Tomasz Chilinski" <chilek(a)chilan.com> To: <lms(a)lists.rulez.pl> Sent: Wednesday, June 30, 2004 9:33 AM Subject: [lms] Re: Mapa sieci - problem > On Wed, 30 Jun 2004 09:16:09 +0200, Dariusz Skarbek wrote > > Będę wdzięczny za dalsze wskazówki. > > Może chodzi o GD Version? > > Wygląda na to, że tak. > > > Pozdr. > > Darek > > Pozdrawiam > Tomasz Chiliński > > >

1 0

Re: Mapa sieci - problem
by Tomasz Chilinski 30 Cze '04

30 Cze '04

On Wed, 30 Jun 2004 09:16:09 +0200, Dariusz Skarbek wrote > Będę wdzięczny za dalsze wskazówki. > Może chodzi o GD Version? Wygląda na to, że tak. > Pozdr. > Darek Pozdrawiam Tomasz Chiliński

1 0

Re: Mapa sieci - problem
by Dariusz Skarbek 30 Cze '04

30 Cze '04

odinstalowałem pakiet php-gd1 i zainstalowałem php-gd2 i mam teraz: gd GD Support enabled GD Version2.0 or higher FreeType Supportenabled FreeType Linkagewith freetype T1Lib Supportenabled JPG Supportenabled PNG Supportenabled WBMP Supportenabled niestety cały czas mam taki sam problem. Będę wdzięczny za dalsze wskazówki. Pozdr, Darek ----- Original Message ----- From: "Dariusz Skarbek" <dskarbek(a)softintelligent.com.pl> To: <lms(a)lists.rulez.pl> Sent: Wednesday, June 30, 2004 9:16 AM Subject: [lms] Re: Mapa sieci - problem > > Zrób <? phpinfo(); ?> i sprawdź czy masz php z obsługą gd. > > > > wygląda na to, że tak: > > gd > GD Support enabled > GD Version1.6.2 or higher > FreeType Supportenabled > FreeType Linkagewith freetype > T1Lib Supportenabled > JPG Supportenabled > PNG Supportenabled > WBMP Supportenabled > > > Będę wdzięczny za dalsze wskazówki. > Może chodzi o GD Version? > Pozdr. > Darek > > > >

1 0

Re: Mapa sieci - problem
by Dariusz Skarbek 30 Cze '04

30 Cze '04

> Zrób <? phpinfo(); ?> i sprawdź czy masz php z obsługą gd. > wygląda na to, że tak: gd GD Support enabled GD Version1.6.2 or higher FreeType Supportenabled FreeType Linkagewith freetype T1Lib Supportenabled JPG Supportenabled PNG Supportenabled WBMP Supportenabled Będę wdzięczny za dalsze wskazówki. Może chodzi o GD Version? Pozdr. Darek

1 0

Re: Mapa sieci - problem
by Tomasz Chilinski 30 Cze '04

30 Cze '04

On Wed, 30 Jun 2004 08:33:37 +0200, Dariusz Skarbek wrote > Witam > U mnie występuje podobny problem: nie wyświetla się mapa. Po > wpisaniu w przeglądarce: http://lms.softintelligent.com.pl/?m=netdevmap&graph=true&start > dostaję błąd: > Fatal error: imagecreatetruecolor(): requires GD 2.0 or > later in /var/www/lms/lms/modules/netdevmap.php on line > 180 Niby wszystko jasne, ale w moim debianie mam > zainstalowane libgd2. Zauważyłem również, że mam zainstalowane > libgd1. Czy może ktoś wie jak sprawdzić, którą bibliotekę > wykorzystuje lms? albo która jest domyślna? Zrób <? phpinfo(); ?> i sprawdź czy masz php z obsługą gd. > Pozdrawiam > Darek Pozdrawiam Tomasz Chiliński

1 0

Re: Mapa sieci - problem
by Dariusz Skarbek 30 Cze '04

30 Cze '04

Witam U mnie występuje podobny problem: nie wyświetla się mapa. Po wpisaniu w przeglądarce: http://lms.softintelligent.com.pl/?m=netdevmap&graph=true&start dostaję błąd: Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /var/www/lms/lms/modules/netdevmap.php on line 180 Niby wszystko jasne, ale w moim debianie mam zainstalowane libgd2. Zauważyłem również, że mam zainstalowane libgd1. Czy może ktoś wie jak sprawdzić, którą bibliotekę wykorzystuje lms? albo która jest domyślna? Pozdrawiam Darek

1 0