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

[versus]

Добрый день!

В данной теме собираем все пожелания к NoDeny+.

Из известных:
- динамический белый айпи
- привязка даты снятия абонплаты к дате подключения клиента
- IPv6
- Динамические шейпы от времени суток, скаченого трафика, направления


Чем подробнее будет описание тем больше вероятность, что мы включим предложенный вами функционал в новую версию

Предложения по упрощению и удалению ненужного или устаревшего функционала привествуются.

[stix]

удаление нескольких платежей клиенту.
например поставить checkbox напротив платежей, очень удобно когда стоит суточная абонплата и нужно удалить все эти платежи за несколько десятков дней.

включить в графе изменения ip существующих клиентов выбор свободного ip
вроде делал кто-то

сделать штатной функцией тариф заморозки, аля button - "заморозить" и отмечать в биллинге снежинкой замороженных.
и функция настройки тарифа заморозки, аля какой тариф выбрать тарифом заморозки

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

- привязка даты снятия абонплаты к дате подключения клиента

оно разве не штатное?

[0xbad0c0d3]

Принцип работы плагинов: каждый плагин должен регистироваться в системе аля plugin_init(name,event)
список ивентов четко определен ядром (вызов ф-ии перед снятием абонплаты. ну в общем, что бы можно было управлять действием ядра на то или иное событие.)
т.е. event это подобие trigger_time && trigger_event в MySQL
P.S. Я уже об этом писал. Думаю это упростит развитие системы.

[ale-x]

Функция ведения остатка оборудования: учет остатка кабеля в метрах, его стоимости. Например: заводим учетку для нового абонента, при подключении передаем ему кабель такой-то, столько-то метров, по определенной цене.
Сделать возможность удаления ошибочно внесенного оборудования, хотя бы для админа.

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

[VitalVas]

- привязка даты снятия абонплаты к дате подключения клиента

лучше не к дате подключения, а к дате последнего платежа (см. вложения)

[Efendy]

Это все будет делаться плагинами. Концепция нового NoDeny несколько иная. Сейчас расскажу.

Я уже упоминал о том, что в какой-то из параллельных версий я убрал абсолютно все постоянные поля. Т.е юзаются только дополнительные, включая логин/пароль/ip и т.д.

Есть модуль Data.pm, который управляет:

• отображением поля
• редактированием поля
• проверкой поля на валидность

Сейчас ввел такие типы:

 'целое',
 'целое положительное',
 'вещественное',
 'вещественное положительное',
 'строковое однострочное',
 'строковое многострочное',
 'да/нет',
 'выпадающий список',
 'пароль',
 'трафик',
 'время',
 'дата',
 'деньги'.

Чем интересен вынос всех полей в дополнительные?

1. Можно повыкидывать ненужные/добавить нужные
2. Единообразное (в одном месте) управление созданием/обработкой/сохранением полей (это для меня и разработчиков)
3. Возможность нафигачить доселя неведомые науке схемы. Например, введение нескольких балансов на абонента, бонусные счета, любое количество категорий трафика, много ip адресов без алиасов (алиасов ваще не будет), сети ip адресов, учет времени и времен чего угодно.

Что еще важно - предусмотрел подключение собственных типов полей в плагинах. Это сделает биллинг максимально гибким. Вы можете написать модуль, который выдаст ip адрес из любых соображений, например сделает запрос к какому-нить оборудованию.

Что еще делаю однообразным так это стирание граней между "клиент/работник/оборудование" и т.д. Для NoDeny - это все список объектов в разных группах с разными характеристиками и обработчиками.

В связи  с значительными изменениями концепции (фактически переписываю NoDeny полностью) хотелось бы, что бы разработчики модулей непосредственно принимали участие в написании моделей в то время пока NoDeny пишется. Со своей стороны я делаю максимально простым подключение плагинов

[Efendy]

Еще сделал такую вещь как "словарь" для формированиея выпадающих списков для любой сущности, а не только для улиц. Например, можно создать словарь "города" и подключить этот словарь к полю "город" клиентской записи

[Efendy]

Принцип работы плагинов: каждый плагин должен регистироваться в системе аля plugin_init(name,event)
список ивентов четко определен ядром (вызов ф-ии перед снятием абонплаты. ну в общем, что бы можно было управлять действием ядра на то или иное событие.)
т.е. event это подобие trigger_time && trigger_event в MySQL
P.S. Я уже об этом писал. Думаю это упростит развитие системы.

да, да, принято. Я как раз думаю подсчет денег сделать динамичным в зависимости от подключенных плагинов. Т.е, например, подключил к полю баланс плагин "абонплата" и он добавляет бабки на это поле по какому-то критерию

[VitalVas]

В связи  с значительными изменениями концепции (фактически переписываю NoDeny полностью) хотелось бы, что бы разработчики модулей непосредственно принимали участие в написании моделей в то время пока NoDeny пишется. Со своей стороны я делаю максимально простым подключение плагинов

емм.... как?

[Efendy]

В связи  с значительными изменениями концепции (фактически переписываю NoDeny полностью) хотелось бы, что бы разработчики модулей непосредственно принимали участие в написании моделей в то время пока NoDeny пишется. Со своей стороны я делаю максимально простым подключение плагинов

емм.... как?

как доделаю - дам пример плагина

[VitalVas]

как доделаю - дам пример плагина

типа такое?:

Код:

#уже не надо require 'nHack.pl' unless $PR{1}; т.к. скрипт не cgi-bin
use strict;
use vars qw( &Show &ToTop &ErrTop &ToLeft $Db $Url $DOC %F %A $TblGood );

$A{pr}{2} or &Error('Вам не разрешен доступ.');
$DOC{align}='center'; # выравнивание контента по центру горизонтали

my $Fact=$F{act} || 'tarifstat';

ToTop &div( 'nav',
  $Url->a( 'Статистика по тарифам', 'act'=>'tarifstat').' '.$Url->a( 'Статистика по групам', 'act'=>'grpstat' )
);
......
 Show $tbl->show;

[Efendy]

типа такое?:

Типа такого:

Код:

# в обрабочик поля `баланс` вставляем свой обработчик
main::plugin_init(
    set_data_alias => {
                        'form balance'      => \&form_balance,
    },
);

sub form_balance
{
 my $it = shift;
 # получим данные всех полей, у которых алиас начинается с traf_
 my $traf = $it->get(
    alias => 'traf_%',
 );
 foreach( @$traf )
 {
    $it->{descr} .= $_->{alias}.': '.$_->{val};
    $it->{val} += $_->{val} * 0.01; # трафик идет по 1 коп за Мб
 }
}

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

[dad Min]

...
Сейчас ввел такие типы:

 'целое',
 'целое положительное',
 'вещественное',
 'вещественное положительное',
 'строковое однострочное',
 'строковое многострочное',
 'да/нет',
 'выпадающий список',
 'пароль',
 'трафик',
 'время',
 'дата',
 'деньги'.
...

можно еще добавить тип "список флагов" (checkbox group) или список с множественным выбором (multiselect listbox)
во вложении пример использования (уже в работе)
а то заново придеться допиливать

[Efendy]

можно еще добавить тип "список флагов" (checkbox group) или список с множественным выбором (multiselect listbox)

ок, согласен

[Efendy]

Доступ к группе будет да/нет, а не как сейчас да/нет/ограничен. Мне кажется полезности ограниченного доступа меньше усложнения работы из-за внедрения этой сущности