June 2004 - lms - lists.lms.org.pl

Re: PostgreSQL -> MySQL [Emigracja]
by Adrian Smarzewski 01 Jul '04

01 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Grzegorz Czechowski wrote: | Podobno SQL to SQL, ale zapomnij na poziomie wyższym niż "select * from" - -- Pozdrowienia Adrian Smarzewski -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA40tXgnuWEmthbpURAqHdAJ99P0pdk7ZkFN1zjaBcHZzNZRkk0gCgn5hY 5KtCL1g+A43mnRyKkMNEz3I= =yetx -----END PGP SIGNATURE-----

1 0

PostgreSQL -> MySQL [Emigracja]
by Grzegorz Czechowski 30 Jun '04

30 Jun '04

Jak się ta w/w sytuacja przedstawia? Czy backup bazy w LMS na bazie Postgres'a będzie kompatybilny z MySQL? Podobno SQL to SQL, ale wczoraj się przekonałem, że jednak może być problem z taką oto emigracją, a nieco niewygodne byłoby wklepywanie wszystkiego od podstaw. -- g.

1 0

Re: RT - założenia
by peter 30 Jun '04

30 Jun '04

> 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 > > > > Genialne! Ciekawa jest ta elastycznosc w mozliwosci tworzenia kategorii. Umozliwa to dodawanie takich zadan jak: Sprawdzenie mozliwosci technicznej (przydatne przy wifi) dla ludzi zainteresowanych, wykonanie instalacji, itd. Wiadomo kto przyjal i kto zadanie wykonal/zadeklarowal sie wykonac. Takze system obslugiwal by nie tylko awarie. Bomba jak dla mnie. :)

1 0

Re: RT - za3o?enia
by Łukasz Jarosław Mozer 30 Jun '04

30 Jun '04

Witam. W liście z dnia 30 czerwca 2004 (14:10:42) można przeczytać: > a mi się wydaje, że lepiej wbić klientowi do głowy, że system nie słuzy > tylko do zgłaszania awarii, a w szczególności identyfikator zgłoszenia > nie oznacza ilości awarii i jest nadawany losowo. koniec. A ja wychodzę z założenia - LMS2 będzie gotowe do portowania modułów, to zrobię najpierw customerlist i pochodne żebyście mieli przykład jak co gdzie i dlaczego a później wezmę się za RT. -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

Re: RT - za3o?enia
by A.L.E.C 30 Jun '04

30 Jun '04

Grzegorz Jakóbik wrote: > To nam gwarantuje ze nik nie pomysli ze jest duzo awarii oraz kazdy > bedzie mial swoj unikalny numer awarii. a mi się wydaje, że lepiej wbić klientowi do głowy, że system nie słuzy tylko do zgłaszania awarii, a w szczególności identyfikator zgłoszenia nie oznacza ilości awarii i jest nadawany losowo. koniec. -- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0

Re: RT - założenia
by Jakub Walczak 30 Jun '04

30 Jun '04

Użytkownik A.L.E.C napisał: > 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 > > > nie wiem, czy to jest zawarte w powyzszych, czy moze jest sprzeczne (na razie zbyt ogolny opis) ale kiedys uczestniczylem w powstawaniu podobnego systemu (niestety zrodelek nie moge udostepnic - nie sa moje) i prztdala by sie jeszcze mozliwosc przesyslania zgloszenia miedzy adminam'i (uzytkownikami LMS'a) przyklad z zycia: 1. problem przyjmuje np. telefonicznie pani BOK1 stwierdza, ze to trzeba podeslac do admina A1 (bo jest w drugim pokoju) przesyla. 2. admin A1 czyta, ale nie ma dostepu do akurat tego serwera tego zeby to spradzic. przesyla do admin aglownego A2 3. admin A2 sprawdza i okazuje sie, ze to problem sprzetu i odsyla to do serwisanta 4. serwisant robi, albo nie (mialem pecha i serwisant byl len), jak juz zrobi to odsyla do _osoby mogacej zamknac zgloszenie_ (np: BOK1) * kazdy z userow ma liste usterek/zadan przeznaczonych tylko dla niego * do kazdego wlasnego zadania moze dodac swoj komentarz (np: "to nie ja sie tym zajmuje", "serwer dziala - sprawdzic, czy user ma w domu prad", "zrobione", itp) i odeslac dalej (do kogos innego w tym do bok'u) * kazdy user widzi to co dodali inni - widzi co juz bylo robione * dodatkowo bok musi miec podglad w status zlecenia bedacego "w toku" - na podstawie jakiegos-tam-numeru: * usterki/zgoszenia obsluguje w dowolnej kolejnosci - zakladamy dobra wole pracownikow - widzi priorytety i czasy przyjecia zgloszenia w ty czasie, klient jest upierdliwy i wydzwania, albo przychodzi do BOK1 i krzyczy. gdyby BOK1 miala taki system opieprzala by, wspolnie z szefem, S1, a tak przewaznie mi (A1) sie dostawalo, albo A2 :-) nie moge podeslac kodu, ani nie pamietam dokladnie jak to dzialalo(dziala ?) bo nie ja go pisalem, ale moge w niego zerknac i podpowiadac/dopisac czesc funkcjonalnosci i opisac zastosowane rozwiazania i podejscie do tematu program jest dosyc prosty (java - ok 5 dni pracy) dzialal wysmienicie i naprawdze pomogl nam zorganizowac prace Jaqb

1 0

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

30 Jun '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 Jun '04

30 Jun '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 Jun '04

30 Jun '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 Jun '04

30 Jun '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