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

[Efendy]

Не. Сессия - это идентификатор в базе. Клиент дает куки скрипту, он обращается к БД и смотрит есть ли такая сессия и не просрочена ли она. Короче, проблем не должно быть

[Efendy]

P.S. Товагищи, я тут переписываю практически все файлы NoDeny. Принципиально пока ничего не меняю, просто привожу его в порядок. Но благодаря этому есть возможность быстро внести в него кое-какие мелкие фичи, которые так многим не хватало. Советуйте.

Кстати, модули для клиентской статистики теперь пишутся гораздо проще. Например, модуль пополнения карточками оплаты поместился на один экран монитора

[stix]

хочу массовое удаление платежей.
а то либо через sql, либо руками.
но оператор через mysql не сможет, а руками задолбается.
например удаление суточной абонплаты за месяц
30 раз нажать кнопку удалить и 30 раз подтвердить.

[Elisium]

P.S. Товагищи, я тут переписываю практически все файлы NoDeny. Принципиально пока ничего не меняю, просто привожу его в порядок. Но благодаря этому есть возможность быстро внести в него кое-какие мелкие фичи, которые так многим не хватало. Советуйте.

Там на 4 и 5 странице я писал про некоторые пожелания. Напоминаю.

[Efendy]

P.S. Товагищи, я тут переписываю практически все файлы NoDeny. Принципиально пока ничего не меняю, просто привожу его в порядок. Но благодаря этому есть возможность быстро внести в него кое-какие мелкие фичи, которые так многим не хватало. Советуйте.

Там на 4 и 5 странице я писал про некоторые пожелания. Напоминаю.

ok

[incokeeper]

Предлагаю в 52 ветке переработать механизм тарифных планов и шейпов по направлениям. Это даст возможность отказаться от пресетов.
Сделать что-то подобное:
1. Создаем тариф (обзываем его, указываем тип - абонплата или нет )
2. в этом тарифе добавляем нужные нам направления (будь то мир, украина, локальные ресурсы, пиринги)
3. проставляем приоритет даного направления в % от ста
4. задаем шейп-полисинг вход/выход по каждому направлению

список сетей в направлении задавать по маске либо "Загрузить из файла"

Доп.тарифы сделать как-то так:
Имя доп.тарифи    | Цена услуги | Связь с модулем
Антивирус на мес. | 15 грн.        | drweb.pl

[versus]

Предлагаю в 52 ветке переработать механизм тарифных планов и шейпов по направлениям. Это даст возможность отказаться от пресетов.
Сделать что-то подобное:
1. Создаем тариф (обзываем его, указываем тип - абонплата или нет )
2. в этом тарифе добавляем нужные нам направления (будь то мир, украина, локальные ресурсы, пиринги)
3. проставляем приоритет даного направления в % от ста
4. задаем шейп-полисинг вход/выход по каждому направлению

список сетей в направлении задавать по маске либо "Загрузить из файла"

Доп.тарифы сделать как-то так:
Имя доп.тарифи    | Цена услуги | Связь с модулем
Антивирус на мес. | 15 грн.        | drweb.pl

И как это поможеи избавится от пресета Или не осилил что это такое ?

[elite]

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

[incokeeper]

Предлагаю в 52 ветке переработать механизм тарифных планов и шейпов по направлениям. Это даст возможность отказаться от пресетов.
Сделать что-то подобное:
1. Создаем тариф (обзываем его, указываем тип - абонплата или нет )
2. в этом тарифе добавляем нужные нам направления (будь то мир, украина, локальные ресурсы, пиринги)
3. проставляем приоритет даного направления в % от ста
4. задаем шейп-полисинг вход/выход по каждому направлению

список сетей в направлении задавать по маске либо "Загрузить из файла"

Доп.тарифы сделать как-то так:
Имя доп.тарифи    | Цена услуги | Связь с модулем
Антивирус на мес. | 15 грн.        | drweb.pl

И как это поможеи избавится от пресета Или не осилил что это такое ?

Я то осилил. А других людей часто возникают вопросы, типа: "А на хр*на? А проще нельзя было? и другие"
Если чесно механизм сложноват поначалу.
Я то понимаю что ТАРИФ типа "наследует что-то" от ПРЕСЕТА, но с другой стороны не проще ли это все впихнуть в одно название ТАРИФ.
Имхо я думаю так будет понятнее: такой-то тариф с такой-то скоростью вх/вых на мир и с такой-то на уа-икс, приоретизация по таким-то портам (80,21)
Если я не прав - поправьте!
Тем более, что система на стадии глобальной переаботки!

[incokeeper]

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

2 elite:
Вы говорите все правильно. Я просто предлагаю проставлять направления не в ПРЕСЕТАХ, а в ТАРИФАХ.
Мне кажеться так будет проще и логичнее с точки зрения предоставления услуги конечному пользователю.
Хош в одном тарифе дели мир/уа, хош не дели.

[Efendy]

пресеты - это набор списков. Отдельная сущность. Для тарифа 1,2,3 мы присвоили список номер 1 (пресет номер 1), для 4,5,6 - список номер 2 и т.д. В каждом тарифе сделать свой список? Вы запутаетесь, когда нужно будет поменять один айпишник в нескольких тарифах.

[smallcms]

когда нужно будет поменять один айпишник

Я думал, что уже в 52-й будет отвязка от этого дела (для экономии ip-пулов и т.п.).

[Efendy]

когда нужно будет поменять один айпишник

Я думал, что уже в 52-й будет отвязка от этого дела (для экономии ip-пулов и т.п.).

Вообще-то, я говорил в контексте 50й версии (почитай предыдущие сообщения - будет выпущена промежуточная версия). Но в любом случае, у тебя есть какие-то локальные ресурсы. Это несколько диапазонов ip например. Поменялся ip одного из серверов. Нужно заходить в каждый тариф и там его менять. Речь идет не о клиентских ip

[versus]

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

А если еще и легси тарифы остаются, например порядка 20-30-50 то вобще мрак

[Efendy]

Хух. Сетка забирает 90% времени( Но сегодня я успел поработать хорошо. В общем, я переработал таблицу с картами, которая была слегка анархичной. Сейчас выглядит все так:

cid          - серийный номер карты
cod          - код активации
money        - номинал
tm_create    - время генерации карты
tm_end       - время окончания действия
tm_activate  - время активации
adm_create   - id админа, сгенерировавшего карту
alive        - состоянии карты
uid_activate - id клиента, активировавшего карту
adm_owner    - id администратора владельца карты
adm_move     - id администратора, на которого идет перемещение карты

Время активации tm_activate не равное нулю не гарантирует, что карта активирована. Следует читать так: если карта активирована, то tm_activate указывает на время ее активации.

Состояние карты определяется полем alive, которое может принимать значения:

good      - карта не активирована;
bad       - карта заблокирована;
stock     - карта на складе;
activated - активирована.

Карту можно активировать только в состоянии «good». Состояние «stock» (на складе) указывает на то, что карта пока еще не вошла в обращение. При генерации карт, им всем выставляется статус «на складе», что является элементом безопасности и сделано из таких соображений: предполагается, что администратор производит генерацию большого числа карт и все они отправляются в печать. При этом в реализацию они поступают партиями. Если будет замечена активация карты, которая числится на складе - это может свидетельствовать о том, что произошла утечка кодов пополнений.

Администратор в админке может изменить состояние карт на любое при условии, что владельцем является он (поле adm_owner), а также карта не нахоится в состоянии activated.

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

adm_move указывает на администратора, на которого adm_owner желает передать карту. При этом владельцем карты все равно является adm_owner. При подтверждении передачи, adm_move устанавливается в 0, а adm_owner - в id администратора, принявшему карту.

При отказе приема карты, NoDeny устанавливает поля так, как будто получатель отправляет их назад отправителю.