-----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-----
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.
> 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. :)
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
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
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
<--- 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
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
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
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
