Фичереквест на NoDeny+

[Efendy]

Выглядит примерно так:

[Efendy]

В генерации можно указывать алфавит кода пополнения. Кстати, можно менять параметры генерации и все ранние будут работать. В ваших версиях, если поменять количество символов в коде пополнения, то старые карты уже не смогут быть активированы. Это неправильно. Да, логин в коде пополнения я прибил - нафига он нужен?

[VitalVas]

приделай ф-ю удаления карточек
как я это реализовал в текущей версии можно найти здесь

[Efendy]

приделай ф-ю удаления карточек
как я это реализовал в текущей версии можно найти здесь

ок. Хотя вопрос: зачем удалять карты, если их можно блокировать?

И походу пару каментов. Перед удалением ты делаешь select чтобы высчитать количество карт, которые будут удалены. Теперь представь, что после select, перед delete изменила состояние какая-либо карта. Будет удалено другое количество карт. Такие редкие ситуация самые плохие т.к проявляются крайне редко, но могут привести к последствиям. Тебе нужно юзать для удаления sql_do(..), который возвращает количество строк, которые были удалены/вставлены, либо обновлены.

Код:

my $rows = sql_do($dbh, 'DELETE FROM uzers');
$rows>0 && Error("Удалены все клиенты!!");
Error("На самом деле не удалены т.к. имя таблицы задано неверно");

Обрати внимание на нюанс - модуль DBI может вернуть 0E0 строк, что будет означать "запрос выполнен, но удалено 0 строк". Поэтому в условиях обязательно нужно ставить сравнение с нулем, а не просто if( $rows ) {...}

Код:

$year = int $F{year};
$year = 0 if ($year eq '');

вторая строка бессмысленна т.к. int всегда выдает число, вне зависимости от того, что получает на входе, хоть поэму "Евгений Онегин".

Код:

$day = '0'.$day if ($day<10);
$month = '0'.$month if ($month<10);

0 добавлять тоже не нужно т.к. unix_timestamp это пофигу.

Код:

alive!='good' AND alive!='bad' AND alive!='move' AND alive!='stock'

понятнее будет

Код:

alive NOT IN ('good','bad','move','stock')

а

Код:

$year ne 0

это сравнение строк, лучше сравнивать арифметическими сравнениями ( ==, >, <)

[VitalVas]

[offtop]
Ну начнем с того, что это было нужно срочно. Начальство сказало, нужно сделать.
И написано было за 2 часа
Лучше делать дополнительные проверки, чем потом разгребать последствия
+ я тогда был под блэкджеком с пивом ><
[/offtop]

[Inzevision]

1. В генерировании паролей для учётных записей исключить похожие символы, например "0" и "O", "l" & "I" ну и так дальше.
2. При создании абонента в поле Логин добавить функцию, "Использовать персональный платежный код как логин абонента".

[Efendy]

1. В генерировании паролей для учётных записей исключить похожие символы, например "0" и "O", "l" & "I" ну и так дальше.
2. При создании абонента в поле Логин добавить функцию, "Использовать персональный платежный код как логин абонента".

ты читаешь мои мысли. Кроме того, будет такая фича: создается безликая учетная запись. Распечатывается бланк настроек. Прикрепляется к договору. Подключаем клиента. Вбиваем настройки, логинимся и получаем первый вопрос "введите номер договора, адрес и т.д".

[ser970]

не плохо было бы = логи билинга и перехода на новый месяц - в отдельную папку .

[Efendy]

не плохо было бы = логи билинга и перехода на новый месяц - в отдельную папку .

да. + я делаю ядро многопоточным с возможностью подключения своих модулей (именно к ядру) с привязкой к событиям

[Inzevision]

Ещё было бы здорово добавить отправку сообщений абонентам на указанной точке топологии.

[Elisium]

Не помню, писали или нет, но хотелось бы следующее:

Выдачу ип адресов клиентам из пула.
Определение "ху из кто" в данный момент времени проводить при помощи авторизатора.
Т.е: Клиент загрузился, получил ип из пула адресов.
Потом загрузил авторизатор, авторизировался в биллинге. Авторизатор передает ип (Ипы) в агент авторизации. Тот их пишет в учетку клиента.
Все время, пока клиент авторизирован, за ним числится этот ип. Клиент выкл авторизатор/комп, авторизация отвалилась по таймауту, ип считается освобожденым (ну, или скидывается в пул резервных ипов, с освобождением, например, через 2 часа - может клиент просто ребутнул комп)
Для роутеров все будет работать, как и раньше - "всегда онлайн" и адреса в биллинге руками.
И запретить автоматическую смену ип адреса авторизатором, если стоит "всегда онлайн".
Както так)

Правда, для этого нужно будет переписать авторизатор + еще немало всего )
Но ведь это и есть фичереквест, верно ? )))

[Efendy]

динамическую выдачу адресов буду делать через pppoe, авторизатор трогать не буду - его нужно будет тогда переписывать на другом языке (для кросплатформенности) и сделать новый протокол - пока не до этого.

[Elisium]

Да. Вдогонку.
Сейчас в карточке юзера есть одно поле, которое может принимать несколько значений, в данном случае - рисунков: ключики зеленый/красный и "сердечко".
В связи с тем, что в соседней теме был предложен патч, который устанавливает этот "зеленый ключик" при наличи трафика К/ОТ КЛИЕНТУ, предлагаю сделать ДВА поля: одно будет по прежнему показывать способ авторизации (ключик/пппое/всегда онлайн/итп.), второе - НАЛИЧИЕ ТРАФИКА к/от клиента, как это сделано сейчас в этом патче.
Почему ? Диспетчера привыкли, что ключик зеленый, значит у клиента инет есть. А в данном случае может быть вариант (неисправность), что клиент авторизировался нормально, а инета НЕТ.
п.с. Тем более, что этот патч вы собирались внедрять в код биллинга.

[0xbad0c0d3]

Да. Вдогонку.
Сейчас в карточке юзера есть одно поле, которое может принимать несколько значений, в данном случае - рисунков: ключики зеленый/красный и "сердечко".
В связи с тем, что в соседней теме был предложен патч, который устанавливает этот "зеленый ключик" при наличи трафика К/ОТ КЛИЕНТУ, предлагаю сделать ДВА поля: одно будет по прежнему показывать способ авторизации (ключик/пппое/всегда онлайн/итп.), второе - НАЛИЧИЕ ТРАФИКА к/от клиента, как это сделано сейчас в этом патче.
Почему ? Диспетчера привыкли, что ключик зеленый, значит у клиента инет есть. А в данном случае может быть вариант (неисправность), что клиент авторизировался нормально, а инета НЕТ.
п.с. Тем более, что этот патч вы собирались внедрять в код биллинга.

Или я дурак или лыжи не едут по асфальту )) Если есть ВХОДЯЩИЙ трафф - значит инет работатет. То, как он работает должны выяснять диспетчера! Иначе в 52-ю ветку нужно будет внедрять "хрустальный шар"...

[Elisium]

При чем тут шар ?
КАК работает у клиента интернет - это второй вопрос.
Первый - интересует само его НАЛИЧИЕ у ДАННОГО клиента в текущий момент времени.
Твой патч делает тоже самое, но рисует зеленый ключик, что В ОРИГИНАЛЕ обозначает - клиент АВТОРИЗИРОВАН, а не то, что там бегает трафик.
Или ты не представляешь варианта, что клиент авторизирован, а инет не работает ?
Поэтому предлагаю ДВА поля: одно с типом авторизации, второе, показывающее наличие трафика между срезами статистики.

п.с. Буквально позавчера ночью менял юзерам ипы - серые на белые.
У нас есть на циске PBR - разбрасывает юзеров налево/направо на разные шейперы. А агент авторизации доступен раньше, чем срабатывает ПБР.
Изза того, что забыл на циске дорисовать правила, получилась ситуация - клиенты авторизированы, все с виду норм - а инета нет.
А заглядываешь в биллинг - там немало зеленых ключиков, тоесть ТОЖЕ вроде все норм.
Поэтому, пока первый клиент не пожаловался сообщением биллинг в полтретьего утра )), так бы ничего и не заподозрил...
А вот было бы поле, где видно есть/нет трафика - было бы, ИМХО, заметно удобней.
п.п.с. и 10 минут клиенты без инета бы не сидели ))