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