- lms - lists.lms.org.pl

Re: FreeBSD
by Paweł Rohde 21 Mar '04

21 Mar '04

>Witam! > >Chciałem zaimplementować LMS'a pod FreeBSD. >Czy jest to wykonalne? >Potrzebne są zrodla bo gotowe binaria sie wysypuja ... > > Hmmmm.... A gdzie ty masz binaria? -- pozdrawiam Paweł Rohde -- pozdrawiam Paweł Rohde [patt] [gadu-gadu: 755284 mail:pawel_NOSPAM@rohde.poznan.pl ] [komórka : 501 433 051 ]

1 0

Re: FreeBSD
by Marcin Król 21 Mar '04

21 Mar '04

Użytkownik Woyteck napisał: > Chciałem zaimplementować LMS'a pod FreeBSD. > Czy jest to wykonalne? Ktoś kiedyś to portował na BSD, z daemonem mogą być problemy bo nikt tego na BSD nie testował. > Potrzebne są zrodla bo gotowe binaria sie wysypuja ... Że co? -- Pozdrowienia, [ Marcin Król /Lexx lexx(a)polarnet.gliwice.pl ] [ GSM: +48504202454 GG: 652506 ICQ: 120579624 ] [ Per aspera ad astra Przez ciernie do gwiazd ]

1 0

FreeBSD
by Woyteck 21 Mar '04

21 Mar '04

Witam! Chciałem zaimplementować LMS'a pod FreeBSD. Czy jest to wykonalne? Potrzebne są zrodla bo gotowe binaria sie wysypuja ... pozdr. Woyteck I eat SPAM for breakfast!

1 0

Re: Ponaglenia i inne ...
by Paweł Rohde 21 Mar '04

21 Mar '04

Użytkownik Marcin Król napisał: >> 1. Podczas wyciagania salda userow pobieramy sobie od razu ostatni >> timestamp. > > Rozumiem że pobieramy timestamp ostatniej naliczonej opłaty. Dokładnie >> 2. Robimy z tego timestampa i curenttimestampa ilosc dni >> 3. Jesli saldo < limitu i ilosc dni > limitudni to obslugujemy > > > No to by chyba działało tak jak powinno. Chociaż znalazłem jedno ale: > > - user płaci za konto email 5 zł miesięcznie, > - ten sam user płaci za internet 50 zł miesięcznie, > - limit jest ustawiony na 100 zł, > - czas na zapłatę to 10 dni, odłączenie po 15 dniach, > - opłaty są naliczane 10 każdego miesiąca. > > Jeśli użytkownik będzie regularnie płacił za internet, a za konto > pocztowe nie to może się okazać że zostanie odłączony dopiero za 20 > miesięcy. Pozatym może się okazać że user dostanie upomnienie o > zapłatę np. za internet podczas gdzy za internet zaplacił i zalega z > opłatą za konto pocztowe. Ogolnie mówiąc ten system będzie dzialał > dobrze dla klasycznego przypadku, kiedy odłączamy użyszkodnika w > przypadku jakiegokolwiek (nawet najmniejszego) debetu na koncie, ale > schodki zaczynają się w przypadku używania różnych taryf i dawania > użytkownikom większego czasu na spłatę. Jak dla mnie rozwiązanie > dopiero wtedy będzie uniwersalne, jak wprowadzimy do finansów > możliwość jednoznacznego okreslenia czego dotyczyła dana wpłata. Tylko > że zdaje sie na etapie 1.1 przy konstruowaniu finansów to było dla nas > nie do przeskoczenia ;] Dokładnie doszedłem do tego samego wniosku, ale skoro zakładamy, że user może mieć 100 zł długu to chyba jest ok? Poza tym tak jak mówiesz - jeśli nie będzie powiązania wpłat z tym za co jest wpłata, to inaczej się nie da. pozdrawiam Paweł

1 0

Re: Ponaglenia i inne ...
by Marcin Król 20 Mar '04

20 Mar '04

Użytkownik Paweł Rohde napisał: > W zwiazku z tym, ze moj poprzedni pomysl zostal wykrzyczany jako zly, to > obmyslilem cos takiego: > > 1. Podczas wyciagania salda userow pobieramy sobie od razu ostatni > timestamp. Rozumiem że pobieramy timestamp ostatniej naliczonej opłaty. > 2. Robimy z tego timestampa i curenttimestampa ilosc dni > 3. Jesli saldo < limitu i ilosc dni > limitudni to obslugujemy No to by chyba działało tak jak powinno. Chociaż znalazłem jedno ale: - user płaci za konto email 5 zł miesięcznie, - ten sam user płaci za internet 50 zł miesięcznie, - limit jest ustawiony na 100 zł, - czas na zapłatę to 10 dni, odłączenie po 15 dniach, - opłaty są naliczane 10 każdego miesiąca. Jeśli użytkownik będzie regularnie płacił za internet, a za konto pocztowe nie to może się okazać że zostanie odłączony dopiero za 20 miesięcy. Pozatym może się okazać że user dostanie upomnienie o zapłatę np. za internet podczas gdzy za internet zaplacił i zalega z opłatą za konto pocztowe. Ogolnie mówiąc ten system będzie dzialał dobrze dla klasycznego przypadku, kiedy odłączamy użyszkodnika w przypadku jakiegokolwiek (nawet najmniejszego) debetu na koncie, ale schodki zaczynają się w przypadku używania różnych taryf i dawania użytkownikom większego czasu na spłatę. Jak dla mnie rozwiązanie dopiero wtedy będzie uniwersalne, jak wprowadzimy do finansów możliwość jednoznacznego okreslenia czego dotyczyła dana wpłata. Tylko że zdaje sie na etapie 1.1 przy konstruowaniu finansów to było dla nas nie do przeskoczenia ;] > No i mysle ze jest to najlepsze wyjscie :) > pozdrawiam > Pawel Rohde -- Pozdrowienia, [ Marcin Król /Lexx lexx(a)polarnet.gliwice.pl ] [ GSM: +48504202454 GG: 652506 ICQ: 120579624 ] [ Per aspera ad astra Przez ciernie do gwiazd ]

1 0

Ponaglenia i inne ...
by Paweł Rohde 20 Mar '04

20 Mar '04

Witam ponownie Nie daje mi spokoju sprawa ponaglen, odcinania userow z rozpoznawaniem przeterminowania platnosci ... W zwiazku z tym, ze moj poprzedni pomysl zostal wykrzyczany jako zly, to obmyslilem cos takiego: 1. Podczas wyciagania salda userow pobieramy sobie od razu ostatni timestamp. 2. Robimy z tego timestampa i curenttimestampa ilosc dni 3. Jesli saldo < limitu i ilosc dni > limitudni to obslugujemy No i mysle ze jest to najlepsze wyjscie :) notify trzeba by uruchamiac co dziennie i tyle razy ile stopni ponaglen mamy np: notify <naliczono> 0 notify <termin_7> 7 notify <termin_14> 14 tak samo cutoff (znaczu uruchamiac codziennie) Cutoff wylaczy kompy ludzi ktorzy nie zaplacili ostatniej platnosci w terminie, jesli nie zaplacili wiecej to wylaczy ich wczesniejsze uruchomienie skryptu. Mysle, ze to podejscie jest ok, jesli jeszcze czegos nie zauwazylem to prosze o informacje pozdrawiam Pawel Rohde

1 0

Re: Okresowe naliczanie...
by Łukasz Jarosław Mozer 18 Mar '04

18 Mar '04

Witaj hunter, W Twoim liście datowanym 17 marca 2004 (19:17:13) można przeczytać: > Lukasz, zdanie moje znasz z realizacja jak zwykle trudniej: > Status == deleted, kolumna dodatkowa do taryf i tyle. Nie. > A docelowo "ChangeLog" dla danej taryfy, po koleji: > id, data, id_admina, in, out, cost, type_of_change (1 utworzenie, > 2 modyfikacja, 3 skasowanie, [type of change==3 i id_Admina na 0 i > juz wiemy ze jakis automateusz wyciał.] Nie. Wiesz, może u was w nitronecie to macie tylu kilentów że suma rekordów wszystkich tabel nie przekracza 2^8, to wam szybko chodzi ;-) -- Pozdrowienia, Łukasz Jarosław Mozer

1 0

Re: Okresowe naliczanie...
by hunter 17 Mar '04

17 Mar '04

On Tue, Mar 16, 2004 at 06:11:22PM +0100, Bartosz wrote: > Dobry pomysł z tym 31 dni + kopia :) > P.S. > Przy taryfach, też powinno być info, kto utworzył i modyfikował. > Pozdrawiam Jest taka zasada piszemy _pod_ tym co pisza inni. > Pytanie jest jedno - czy takie naliczenia które już wygasły (minął > termin ich końca) powinny być usuwane? > > ja twierdzę że tak, 31 dni po ich wygaśnięciu, automagicznie przez > lms-payments > alec twierdzi ze natychmiastowo + ewentualnie kopia. Lukasz, zdanie moje znasz z realizacja jak zwykle trudniej: Status == deleted, kolumna dodatkowa do taryf i tyle. A docelowo "ChangeLog" dla danej taryfy, po koleji: id, data, id_admina, in, out, cost, type_of_change (1 utworzenie, 2 modyfikacja, 3 skasowanie, [type of change==3 i id_Admina na 0 i juz wiemy ze jakis automateusz wyciał.] kd. ps. Tak wracam zza grobu. -- Krzysztof Drewicz Podsłuchane na pogrzebie: "Wiem, że to niezręcznie pytać o takie rzeczy w tej chwili, ale przypominasz sobie, żeby on kiedykolwiek wspomniał coś o kodzie źródłowym?" --- Charles Addams

1 0

Re: Okresowe naliczanie...
by Bartosz 16 Mar '04

16 Mar '04

Dobry pomysł z tym 31 dni + kopia :) P.S. Przy taryfach, też powinno być info, kto utworzył i modyfikował. Pozdrawiam -----Original Message----- From: lms-bounce(a)lists.rulez.pl [mailto:lms-bounce@lists.rulez.pl] On Behalf Of Łukasz Jarosław Mozer Sent: Sunday, March 14, 2004 9:55 PM To: lms(a)lists.rulez.pl Subject: [lms] Okresowe naliczanie... Witam. tj. można przypisać do kogoś daną taryfę na pół roku np. Ten feature jest dostępny w wersji CVS. Pytanie jest jedno - czy takie naliczenia które już wygasły (minął termin ich końca) powinny być usuwane? ja twierdzę że tak, 31 dni po ich wygaśnięciu, automagicznie przez lms-payments alec twierdzi ze natychmiastowo + ewentualnie kopia. a wy? -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

Re: ograniczanie
by detekt＠detekt.pl 16 Mar '04

16 Mar '04

Witam Bartosz, > A co jeżeli jest jedna taryfa bez ograniczenia, a druga np.56kbps?? > Jaki transfer będzie miał jeden komputer (jeżeli dodany jest tylko > jeden) a jakie transfery będą, gdy będą dodane dwa lub trzy kompy?? jak bedzie taryfa bez ogranioczen i 56 k to lacznie bedzie 0 +56k = 56k jak bedzie 1 komp to 56k bedzie tylko dla niego a jak bedza 2 to bedzie tez 56 k ale dla dwoch kompow itd ... -- Pozdrawiam Detekt

1 0