- lms - lists.lms.org.pl

Re: PostgreSQL -> MySQL [Emigracja]
by A.L.E.C 01 Lip '04

01 Lip '04

Tomasz Chilinski wrote: > Ciekawa migracja - ja zastanawiam się od dłuższego czasu nad odwrotną Mała dygresja, bo ktoś się przed chwilą na to naciął :), Nie wolno ładować lmsowego backupu podczas migracji przy zastosowaniu narzędzi bazy danych, należy skorzystać w lmsa, czyli robisz backup, zakładasz nową bazę (zgodnie z dokumentacją), uruchamiasz lmsa i odtwarzasz backup z menu 'Bazy danych'. -- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0

Re: PostgreSQL -> MySQL [Emigracja]
by Jakub Walczak 01 Lip '04

01 Lip '04

Użytkownik Tomasz Chilinski napisał: > On Wed, 30 Jun 2004 23:29:55 +0200, Grzegorz Czechowski wrote > >>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. > > > Ciekawa migracja - ja zastanawiam się od dłuższego czasu nad odwrotną :) > tez mialem to napisac, ale sie ugryzlem w jezyk jezeli ktos wykozystuje baze tylko do prostego przechowywania danych, to moze MySQL nawet wystarczy mam co prawda jakiegos prehistorycznego LMS'a, ale dziala calkiem poprawnie (na MySQL'u tez chodzil dobrze) Jaqb

1 0

Re: PostgreSQL -> MySQL [Emigracja]
by Tomasz Chilinski 01 Lip '04

01 Lip '04

On Wed, 30 Jun 2004 23:29:55 +0200, Grzegorz Czechowski wrote > 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. Ciekawa migracja - ja zastanawiam się od dłuższego czasu nad odwrotną :) > g. Pozdrawiam Tomasz Chiliński

1 0

Re: PostgreSQL -> MySQL [Emigracja]
by A.L.E.C 01 Lip '04

01 Lip '04

Grzegorz Czechowski wrote: > Jak się ta w/w sytuacja przedstawia? Czy backup bazy w LMS na bazie > Postgres'a będzie kompatybilny z MySQL? jeśli chodzi o backup lmsowy, to nie powinno być problemów, kiedyś mi się to udawało, nie wiem jak teraz, więc nie daję gwarancji. -- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0

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

01 Lip '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 Cze '04

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

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

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

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

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