forum.bitel.ru :: Просмотр темы - встоенные отчеты

Как узнать сколько пользователей в момент N находится в каждом тарифном плане?

Каковы их суммарные время, трафик, кол-во потраченых денег?

Почему нельзя редактировать шаблоны админского интерфейса? Лично меня не устраивает запись "Принято/Отправлено", т.к. я хочу видеть 2 стобца: один - "Принято", а другой "Отправлено" и очень хочу иметь возможность сортировки между между ними!

сортировка между ними

При использовании встроенного в DialUp Netflow коллектора я так же хочу видеть отдельные столбцы для каждого типа трафика, а не смотреть их все в одной куче!

Почему не существует разделения на типы аккаунтов в админском интерфейсе? Лично я, как администратор, не хочу показывать тех. саппорту закладки А, В, С или еще какие нибудь не нужные им, на мой взгляд, элементы интерфейса.

Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды.

Отчет по тарифу есть в модуле отчетов.

В ядре глобальных отчетов нет вообще. То что вы называете отчетом - это поиск.

Потому что там нет шаблонов, интерфейс реализуется кодом.

А что такое
Цитата:

Цитата:

сортировка между ними

Мы постараемся реализовать отдельные столбцы в будущих версиях

Просто в текущей версии проблематично сделать динамически изменяемые столбцы таблиц.

Есть система разграничения прав.

Закладки отображаться будут, но данных на них не будет. Разграничивать права сокрытием закладок не совсем корректно, т.к. всегда можно сделать прямой HTTP запрос к серверу биллинга, минуя GUI.

Цитата:

Цитата:
Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды.

Это слишком размытое требование.

Планируется ли web-based интерфейс на каком нибудь xml или php?

Администратор писал(а):
Закладки отображаться будут, но данных на них не будет. Разграничивать права сокрытием закладок не совсем корректно, т.к. всегда можно сделать прямой HTTP запрос к серверу биллинга, минуя GUI.
Вы считаете это правильно? На мой взгляд должны не только скрываться закладки но и сервер должен фильтровать запросы на основе прав а не молча воспринимать запросы посланные кем бы то нибыло. Если следовать Вашей логике то зная правильный запрос его может послать обычный пользователь.

Как ею пользоваться?

В данный момент интерфейс осован полностью на xml. вы можете включить debug в клиенте и смотреть xml-файл на каждый запрос .Т.е можно обрабатывать эти xml-ки самим, т.е написать приложение (в даном случае с web -интерфейсом) которое будет это делать .

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

http://bgbilling.ru/v4.4/doc/ch01s24.html

Цитата:

Как узнать сколько пользователей в момент N находится в каждом тарифном плане?

Отчет по тарифу есть в модуле отчетов.

Спасибо, будем читать. Кстати, попутный вопрос - какой версией мануала лучше всего пользоваться при первоначальном знакомстве и настройке, а так же в процессе тестировании и эксплуатации? v4.3 или v4.4?

Смотря какую версию вы используете ..Если 4.3 то доку к 4.3, если 4.4 alpha, то доку к 4.4 ...

В версии 4.4 документация была переписана по просбам пользователей и там неторые вопросы освещены более структурировано и понятно

Администратор писал(а):

Просто в текущей версии проблематично сделать динамически изменяемые столбцы таблиц.

Всмысле тяжело распасить параметр "traffics" по слешам и на основе этого отрисовать столбцы? Или просто трудно в текущую модель добавить дополнительное кол-во столбцов?

Администратор писал(а):

Есть система разграничения прав.

Как ею пользоваться?

Администратор писал(а):

Вы считаете это правильно? На мой взгляд должны не только скрываться закладки но и сервер должен фильтровать запросы на основе прав а не молча воспринимать запросы посланные кем бы то нибыло. Если следовать Вашей логике то зная правильный запрос его может послать обычный пользователь.

Администратор писал(а):

Цитата:

Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды.

Это слишком размытое требование.

Бог с Вами! Это не требование, это всего лишь пожелание. Просто мне симпатизирует идея web-based админки, т.к. в этом случае она:
- Легко модифицируется.
- Может быть использована из любого места, с любого устройства, т.к. не важно, установлена ли на нем Java или нет, главное чтобы там был WWW браузер.
- Проще обеспечить ее безовасность вынеся ее в отдельный виртуалхост, закрыв доступ через .htaccess и т.д. и т.п. Например как сейчас запретить кому либо использовать GUI клиент я даже не представляю, а мануал на эту тему молчит

Пусть даже глобальные настройки останутся в GUI, а вот управление тарифами и договорами, как наиболее часто (в случае договоров - на дню по 100 раз) используемая функция, будет через веб. Я даже готов все настройки производить в конфигурационных файлах, т.к. биллинг настраивается раз в 100 лет и потом просто выполняет свою работу (касательно BGB - очень хорошо выполняет!). Опять же всеравно надо лезть в консоль (я не использую на серверах M$ Windows) чтобы перегрузить, например RADIUS, так что залезть в текстовый конфиг и там что-то подправить и перегрузить - это не проблема.

Прошу прощения, я случайно поправил ваше сообщение

Здесь про права: http://bgbilling.ru/v4.4/doc/ch01s24.html

Разумеется не сложно распарсить стобец traffics, но у нас единый движок таблиц, который читает загловки из файла, а данные получает с сервера. В данный момент там нет поддержки динамически формируемых заголовков. Это не принципиальная проблема, просто пока не добрались.

Отдельная Web морда для типовых операций - это давняя идея. Но тут возникает проблема выделения типовых операций.. Они разные у каждой организации. А бегать из Web морды в GUI не совсем удобно оператору. А все реализовать в Web морде не совсем удобно для нас, т.к. набор средств HTML проигрывает GUI.

А немного потерялся в этой теме, если какие-то вопросы остались неотвеченными - повторите пожалуйста их.

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

Раз уж ресь зашла об отчетах - почему у Вас есть поняте "месяц", но нет понятия "период"? Допустим я Ваш клиент и я очень хочу узнать свою наработку за квартал или за некий N-й период, допустим с 30.12.2007 по 10.02.2008, как это сделать? Или я администратор и так же хочу узнать нечто подобное, как это сделать?

Не понятно ..Справочники - это глава, котрая находится на том же уровне что и Администрирование, т.е в описании ядра системы, как вы и хотели..Или вы хотите общий обзор типа "про справочники вы можете прочитать в 15. Справочники , а про администрирование прав в 24. Администрирование" ?

snark писал(а):

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

stark писал(а):

В чем суть ограничения? Невозможно отрисовать начальную и конечную даты, затем по их данным сделать, к примеру:

Код:

$mid         = 1;

$start_year  = 2008;
$stop_year   = 2008;

$start_month = 01;
$stop_month  = 02;

for ($i = $start_month; $i <= $stop_month; $i++)
{
    $query = "SELECT * FROM log_session_$mid_$start_year$i";
    execute $query;
    do_something_with_result();
}

Правда пример для отчета в диапазоне одного года, но не думаю что большая проблема сделать это в рамках диапазона лет. Или все же есть какое то иное ограничение?

Вопрос с привязкой групп к тарифам почему-то все время обходится стороной

Т.е сортировки, агрегатные функции и т.п вы хотите делать не на стороне sql сервера ,а в в функции do_something_with_result();?

stark писал(а):

А что Вы видите в этом плохого? MySQL гораздо быстрее выполнит несколько маленьких запросов вместо одного большого, да и легче это перенесет.

stark писал(а):

Ваш переезд на постгрес - это всего лишь вопрос времени..

P.S. Связь логических групп с тарифами, как я понимаю запрещенная к обсуждению тема.

Проблема в том, что sql сервер обычно справляется с этим обычно намного проще , чем приложение ..

snark писал(а):

Ваш переезд на постгрес - это всего лишь вопрос времени..

Забавно, но я об этом почему-то пока не знаю

Цитата:

P.S. Связь логических групп с тарифами, как я понимаю запрещенная к обсуждению тема.

Они просто никак не связаны. В телефонном разговоре я уже предложил вам связать их с помощью встроенных скриптов и думал что вопрос на этом исчерпался...
Вы предлагаете реализовать нам связать группы с тарифами в ядре?

Автор:	snark [ 13 фев 2008, 02:34 ]
Заголовок сообщения:	встоенные отчеты
Господа разработчики, предлагаю Вам решить незамысловатую, но очень нужную провайдерам задачку средставми BGB: Дано: Код: 3 тарифных плана - A, B и C. В каждом из тарифных планов N пользователей. В январе X пользователей заказали себе переход из тарифного плана А в тарифный план В, Y пользователей заказали себе переход из тарифного плана В в тарифный план С и Z пользователей заказали себе переход из тарифного плана С в тарифный план А. В феврале никто из пользователей не переходил из одного тарифного плана в другой. Вопрос: Код: Как узнать сколько пользователей в момент N находится в каждом тарифном плане? Каковы их суммарные время, трафик, кол-во потраченых денег? Как узнать в каком тарифном плане находятся сейчас пользователи не перебирая каждый договор по отдельности? Ответ? Собственно откуда родилась эта задача: тестируя BGB я был удивлен отсутствием в нем такого момента как "Отчет по тарифному плану", можно увидеть отчет по договору или группе договоров но никак нельзя сделать отчет по тарифу Да, у Вас сущестует логическая система деления пользователей на группы, НО! Эти группы никак не могут быть привязаны ни к тарифу ни к чему либо еще кроме договора и получается что, допустим, если существует 10 килодоговоров надо перебрать все дабы указать им их групповую принадлежность. Так же отсутствует механизм задания группы пользователей в шаблоне договов Почему нельзя редактировать шаблоны админского интерфейса? Лично меня не устраивает запись "Принято/Отправлено", т.к. я хочу видеть 2 стобца: один - "Принято", а другой "Отправлено" и очень хочу иметь возможность сортировки между между ними! При использовании встроенного в DialUp Netflow коллектора я так же хочу видеть отдельные столбцы для каждого типа трафика, а не смотреть их все в одной куче! Почему не существует разделения на типы аккаунтов в админском интерфейсе? Лично я, как администратор, не хочу показывать тех. саппорту закладки А, В, С или еще какие нибудь не нужные им, на мой взгляд, элементы интерфейса. Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды.

Автор:	Администратор [ 13 фев 2008, 14:16 ]
Заголовок сообщения:	Re: встоенные отчеты
Цитата: Как узнать сколько пользователей в момент N находится в каждом тарифном плане? Отчет по тарифу есть в модуле отчетов. В ядре глобальных отчетов нет вообще. То что вы называете отчетом - это поиск. Цитата: Каковы их суммарные время, трафик, кол-во потраченых денег? Такого отчета нет. В ядре он нереализуем, т.к. формат хранения данных различен для каждого из модулей. Цитата: Почему нельзя редактировать шаблоны админского интерфейса? Лично меня не устраивает запись "Принято/Отправлено", т.к. я хочу видеть 2 стобца: один - "Принято", а другой "Отправлено" и очень хочу иметь возможность сортировки между между ними! Потому что там нет шаблонов, интерфейс реализуется кодом. А что такое Цитата: сортировка между ними ? Цитата: При использовании встроенного в DialUp Netflow коллектора я так же хочу видеть отдельные столбцы для каждого типа трафика, а не смотреть их все в одной куче! Мы постараемся реализовать отдельные столбцы в будущих версиях, а возможность скрыть/показать есть уже сейчас. Просто в текущей версии проблематично сделать динамически изменяемые столбцы таблиц. Цитата: Почему не существует разделения на типы аккаунтов в админском интерфейсе? Лично я, как администратор, не хочу показывать тех. саппорту закладки А, В, С или еще какие нибудь не нужные им, на мой взгляд, элементы интерфейса. Есть система разграничения прав. Закладки отображаться будут, но данных на них не будет. Разграничивать права сокрытием закладок не совсем корректно, т.к. всегда можно сделать прямой HTTP запрос к серверу биллинга, минуя GUI. Цитата: Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды. Это слишком размытое требование.

Автор:	snark [ 13 фев 2008, 17:44 ]
Заголовок сообщения:	Re: встоенные отчеты
Администратор писал(а): Цитата: Отчет по тарифу есть в модуле отчетов. Да? Странно, излазил доку по этому модулю вдоль и поперек и не увидел ни описания ни примера Sad Просто я, как и многие, сначала читаю и только потом что либо использую. Администратор писал(а): Цитата: В ядре глобальных отчетов нет вообще. То что вы называете отчетом - это поиск. В ядре есть отчеты по пользователям, но почему нет отчетов по тарифам? Понимаете, дело в том что у оператора есть тарифы, их точное количество известно только оператору, ну а клиенту известны лишь те на которые он может перейти и оперировать понятием "тариф", как понятием групповой принадлежности пользователей значительно удобнее и проще нежели оперировать понятием "группа". "Тариф" - это то как пользователи потребляют определенные услуги, это кол-во времени/трафика/денег потребленных пользователями данного тарифа, это аналитика и планирование доходов и расходов в связи с тем как потребляются услиги того или иного тарифа, это, в конце концов, принятие решения о том нужен ли этот тариф вообще на основе самых минимальных данных. Я не думаю что это так сложно сделать табличку с тарифами вида: Код: Код: имя_тарифа_1 кол-во_пользователей суммарное_время суммарный_входящий_трафик суммарный_исходящий_трафик имя_тарифа_2 кол-во_пользователей суммарное_время суммарный_входящий_трафик суммарный_исходящий_трафик имя_тарифа_3 кол-во_пользователей суммарное_время суммарный_входящий_трафик суммарный_исходящий_трафик поль-ли_с_перс._тарифами кол-во_пользователей суммарное_время суммарный_входящий_трафик суммарный_исходящий_трафик ИТОГО: кол-во_пользователей суммарное_время суммарный_входящий_трафик суммарный_исходящий_трафик Которая позволила бы даже при мимолетном взгляде увидеть всю картину потребления услуг. "Группа" - это, как Вы верно подметили в документации, всего лишь логическое разделение пользователей, это возможность указать одним пользователям группу "VIP", другим "халявщики" а третьим вообще ничего не указывать т.к. нет нужды логически отнести их к какой либо группе. "Поиск" - это всего лишь инструмент нахождения догвора/логина/группы. IMHO. Администратор писал(а): Цитата: Потому что там нет шаблонов, интерфейс реализуется кодом. Планируется ли web-based интерфейс на каком нибудь xml или php? Администратор писал(а): Цитата: А что такое Цитата: Цитата: сортировка между ними ? Вот Вам маленький пример, более объемный пример ну и целая подборка примеров. Лично мне более симпатичен 1-й приведенный мною пример т.к. в таблицах, особенно в больших, всегда удобнее ориентироваться когда таблица не однотонная а "полосатая". Администратор писал(а): Цитата: Мы постараемся реализовать отдельные столбцы в будущих версиях Буду с нетерпением ждать! Администратор писал(а): Цитата: Просто в текущей версии проблематично сделать динамически изменяемые столбцы таблиц. Всмысле тяжело распасить параметр "traffics" по слешам и на основе этого отрисовать столбцы? Или просто трудно в текущую модель добавить дополнительное кол-во столбцов? Администратор писал(а): Цитата: Есть система разграничения прав. Как ею пользоваться? Администратор писал(а): Цитата: Закладки отображаться будут, но данных на них не будет. Разграничивать права сокрытием закладок не совсем корректно, т.к. всегда можно сделать прямой HTTP запрос к серверу биллинга, минуя GUI. Вы считаете это правильно? На мой взгляд должны не только скрываться закладки но и сервер должен фильтровать запросы на основе прав а не молча воспринимать запросы посланные кем бы то нибыло. Если следовать Вашей логике то зная правильный запрос его может послать обычный пользователь. Администратор писал(а): Цитата: Цитата: Цитата: Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды. Это слишком размытое требование. Бог с Вами! Это не требование, это всего лишь пожелание. Просто мне симпатизирует идея web-based админки, т.к. в этом случае она: - Легко модифицируется. - Может быть использована из любого места, с любого устройства, т.к. не важно, установлена ли на нем Java или нет, главное чтобы там был WWW браузер. - Проще обеспечить ее безовасность вынеся ее в отдельный виртуалхост, закрыв доступ через .htaccess и т.д. и т.п. Например как сейчас запретить кому либо использовать GUI клиент я даже не представляю, а мануал на эту тему молчит Sad Пусть даже глобальные настройки останутся в GUI, а вот управление тарифами и договорами, как наиболее часто (в случае договоров - на дню по 100 раз) используемая функция, будет через веб. Я даже готов все настройки производить в конфигурационных файлах, т.к. биллинг настраивается раз в 100 лет и потом просто выполняет свою работу (касательно BGB - очень хорошо выполняет!). Опять же всеравно надо лезть в консоль (я не использую на серверах M$ Windows) чтобы перегрузить, например RADIUS, так что залезть в текстовый конфиг и там что-то подправить и перегрузить - это не проблема.

Автор:	stark [ 13 фев 2008, 21:57 ]
Заголовок сообщения:	Re: встоенные отчеты
snark писал(а): Планируется ли web-based интерфейс на каком нибудь xml или php? В данный момент интерфейс осован полностью на xml. вы можете включить debug в клиенте и смотреть xml-файл на каждый запрос .Т.е можно обрабатывать эти xml-ки самим, т.е написать приложение (в даном случае с web -интерфейсом) которое будет это делать . В ближайшее время web-интерфейс для оператора мы сами реализовывать не планируем snark писал(а): Администратор писал(а): Закладки отображаться будут, но данных на них не будет. Разграничивать права сокрытием закладок не совсем корректно, т.к. всегда можно сделать прямой HTTP запрос к серверу биллинга, минуя GUI. Вы считаете это правильно? На мой взгляд должны не только скрываться закладки но и сервер должен фильтровать запросы на основе прав а не молча воспринимать запросы посланные кем бы то нибыло. Если следовать Вашей логике то зная правильный запрос его может послать обычный пользователь. Вы не сможете сделать запроса без авторизации, сервер как раз разграничивает права и не выдает данных, на которые у пользователя нет прав(xml - пустая придет) ..Да любой оператор может сделать запрос - не важно это гуи клиента, просто запрос набранный в браузере или самопсиное приложение. snark писал(а): Как ею пользоваться? http://bgbilling.ru/v4.4/doc/ch01s24.html

Автор:	snark [ 13 фев 2008, 23:14 ]
Заголовок сообщения:	Re: встоенные отчеты
stark писал(а): В данный момент интерфейс осован полностью на xml. вы можете включить debug в клиенте и смотреть xml-файл на каждый запрос .Т.е можно обрабатывать эти xml-ки самим, т.е написать приложение (в даном случае с web -интерфейсом) которое будет это делать . А вот это очень интересно! stark писал(а): Вы не сможете сделать запроса без авторизации, сервер как раз разграничивает права и не выдает данных, на которые у пользователя нет прав(xml - пустая придет) ..Да любой оператор может сделать запрос - не важно это гуи клиента, просто запрос набранный в браузере или самопсиное приложение. Понятно. Получается что без авторизации будет приходить пустота, а при авторизации - все необходимые данные ... замечательно! stark писал(а): http://bgbilling.ru/v4.4/doc/ch01s24.html Спасибо, будем читать. Кстати, попутный вопрос - какой версией мануала лучше всего пользоваться при первоначальном знакомстве и настройке, а так же в процессе тестировании и эксплуатации? v4.3 или v4.4? Все же вернемся к нашим баранам, а именно: Администратор писал(а): Цитата: Как узнать сколько пользователей в момент N находится в каждом тарифном плане? Отчет по тарифу есть в модуле отчетов. Я установил модуль отчетов, увидел что там есть отчет по тарифным планам и ... Господа, скажите пожалуйста, где в этом отчете время/трафик/деньги? Почему нельзя указать период больший нежели 1 день? По всем остальным отчетам прекрасно рисуются отчеты за месяц, а вот по тарифным планам увы нет - это так задумано? Я еще раз повторюсь - тарифный план это принятое повсеместно логическое деление пользователей, говоря проще - скажи мне в каком ты тарифном плане и я скажу что и как будет у тебя считаться, ограничиваться и т.д. и т.п. Например Вы навряд ли знаете в какой именно группе находится Ваша фирма у Вашего провайдера, но Вы точно знаете в каком тарифном плане она находится или каким именно тарифом она пользуется, верно? Понимаете о чем я пытаюсь сказать? Раз в BGB все и везде держится на придуманных Вами логических группах договоров, то скажите пожалуйста, как можно реализовать: Один тарифный план == одна уникальная логическая группа договоров. Т.е. определяя пользователю тарифный план автоматически выбиралась бы соответствующая ему, одна единственная, уникальная группа, либо при изменении группы договору менялся бы тарифный план. Одна группа тарифов - это связанная с каждым из тарифов одна единственная уникальная группа договоров. При переходе договора из одного тарифа в другой изменение его группы. Добавление в группу либо тариф параметров того или иного модуля. Например параметры realm, атрибутов RADIUS для модуля DialUp и т.д. и т.п. Дабы при изменении логической группы можно было бы разом изменять массу параметров. При реализации подобного ничего в текущей структуре глобально менять не надо будет и группы будут иметь бОльший смысл нежели простое логическое деление юзеров на "группа 1", "группа 2" и т.д.

forum.bitel.ru http://forum.bitel.ru/

встоенные отчеты http://forum.bitel.ru/viewtopic.php?f=1&t=749	Страница 1 из 1

Автор:	stark [ 14 фев 2008, 12:26 ]
Заголовок сообщения:	Re: встоенные отчеты
snark писал(а): Спасибо, будем читать. Кстати, попутный вопрос - какой версией мануала лучше всего пользоваться при первоначальном знакомстве и настройке, а так же в процессе тестировании и эксплуатации? v4.3 или v4.4? Смотря какую версию вы используете ..Если 4.3 то доку к 4.3, если 4.4 alpha, то доку к 4.4 ...В версии 4.4 документация была переписана по просбам пользователей и там неторые вопросы освещены более структурировано и понятно

Автор:	snark [ 15 фев 2008, 00:44 ]
Заголовок сообщения:	Re: встоенные отчеты
stark писал(а): Смотря какую версию вы используете ..Если 4.3 то доку к 4.3, если 4.4 alpha, то доку к 4.4 ... Спасибо, я именно так и делаю ... stark писал(а): В версии 4.4 документация была переписана по просбам пользователей и там неторые вопросы освещены более структурировано и понятно Это заметно Она значительно лучше чем 4.3, понятнее что ли ... Приходится правда смотреть в обе, дабы дораскрыть для себя в 4.4 моменты не раскрытые в 4.3 ... Ну а все же, что с остальными вопросами?

Автор:	Администратор [ 15 фев 2008, 12:16 ]
Заголовок сообщения:
To snark Прошу прощения, я случайно поправил ваше сообщение Постарался восстановить все в первозданном виде... Мой ответ: Цитата: Администратор писал(а): Просто в текущей версии проблематично сделать динамически изменяемые столбцы таблиц. Всмысле тяжело распасить параметр "traffics" по слешам и на основе этого отрисовать столбцы? Или просто трудно в текущую модель добавить дополнительное кол-во столбцов? Администратор писал(а): Есть система разграничения прав. Как ею пользоваться? Здесь про права: http://bgbilling.ru/v4.4/doc/ch01s24.html Разумеется не сложно распарсить стобец traffics, но у нас единый движок таблиц, который читает загловки из файла, а данные получает с сервера. В данный момент там нет поддержки динамически формируемых заголовков. Это не принципиальная проблема, просто пока не добрались. Цитата: Администратор писал(а): Закладки отображаться будут, но данных на них не будет. Разграничивать права сокрытием закладок не совсем корректно, т.к. всегда можно сделать прямой HTTP запрос к серверу биллинга, минуя GUI. Вы считаете это правильно? На мой взгляд должны не только скрываться закладки но и сервер должен фильтровать запросы на основе прав а не молча воспринимать запросы посланные кем бы то нибыло. Если следовать Вашей логике то зная правильный запрос его может послать обычный пользователь. Пользователь может знать вопрос, но если у него нет прав, сервер просто не выдаст ему данные. Цитата: Администратор писал(а): Цитата: Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды. Это слишком размытое требование. Бог с Вами! Это не требование, это всего лишь пожелание. Просто мне симпатизирует идея web-based админки, т.к. в этом случае она: - Легко модифицируется. - Может быть использована из любого места, с любого устройства, т.к. не важно, установлена ли на нем Java или нет, главное чтобы там был WWW браузер. - Проще обеспечить ее безовасность вынеся ее в отдельный виртуалхост, закрыв доступ через .htaccess и т.д. и т.п. Например как сейчас запретить кому либо использовать GUI клиент я даже не представляю, а мануал на эту тему молчит Пусть даже глобальные настройки останутся в GUI, а вот управление тарифами и договорами, как наиболее часто (в случае договоров - на дню по 100 раз) используемая функция, будет через веб. Я даже готов все настройки производить в конфигурационных файлах, т.к. биллинг настраивается раз в 100 лет и потом просто выполняет свою работу (касательно BGB - очень хорошо выполняет!). Опять же всеравно надо лезть в консоль (я не использую на серверах M$ Windows) чтобы перегрузить, например RADIUS, так что залезть в текстовый конфиг и там что-то подправить и перегрузить - это не проблема. Отдельная Web морда для типовых операций - это давняя идея. Но тут возникает проблема выделения типовых операций.. Они разные у каждой организации. А бегать из Web морды в GUI не совсем удобно оператору. А все реализовать в Web морде не совсем удобно для нас, т.к. набор средств HTML проигрывает GUI.

Автор:	Администратор [ 15 фев 2008, 12:17 ]
Заголовок сообщения:
А немного потерялся в этой теме, если какие-то вопросы остались неотвеченными - повторите пожалуйста их.

Автор:	snark [ 15 фев 2008, 16:27 ]
Заголовок сообщения:
Администратор писал(а): Прошу прощения, я случайно поправил ваше сообщение Да ладно Вам, все мы люди ... errare humanum est еще никто не отменял Администратор писал(а): Здесь про права: http://bgbilling.ru/v4.4/doc/ch01s24.html Спасибо, я уже понял ... жаль только что этот, столь важный, параграф не входит в общее описание сервера наряду со справочниками и т.п. Логически администрирование относится к ядру, а получается что у него такой же параграф как у какого нибудь модуля или плагина ... я думаю было бы логичнее организовать структуру вида: ядро описание всего относящегося к ядру функционал А функционал B функционал C модуль А описание всего относящегося к модулю А функционал А функционал B функционал C плагин А описание всего относящегося к плагину А функционал А функционал B функционал C модуль/плагин N описание всего относящегося к модулю/плагину N функционал А функционал B функционал C При таком раскладе проще было бы ориентироваться в функционале ядра/модуля/плагина, IMHO. Администратор писал(а): Разумеется не сложно распарсить стобец traffics, но у нас единый движок таблиц, который читает загловки из файла, а данные получает с сервера. В данный момент там нет поддержки динамически формируемых заголовков. Это не принципиальная проблема, просто пока не добрались. В общем то я так и думал ... ну да ничего, подождем ... рано или поздно руки дойдут ... /me мечтательно подумал об "это будет в 4.4" и скрестил пальцы Администратор писал(а): Отдельная Web морда для типовых операций - это давняя идея. Но тут возникает проблема выделения типовых операций.. Они разные у каждой организации. А бегать из Web морды в GUI не совсем удобно оператору. А все реализовать в Web морде не совсем удобно для нас, т.к. набор средств HTML проигрывает GUI. Да, Вы правы, проигрывает ... но, как Вы верно заметили, каждой организации нужны свои данные и вот тут, при наличии у админа правильных /dev/hands и /dev/head, он может сам подправить Ваш интерфейс под свои нужды ... если же у админа кривые /dev/hands и /dev/head (патч не тот наложил или еще что ), то Вы всегда сможете сказать - www интерфейс предоставляется as is, поддержка осуществляется только относительно GUI и за все Ваши действия в отношении www интерфейса разработчик ответственности не несет Администратор писал(а): А немного потерялся в этой теме, если какие-то вопросы остались неотвеченными - повторите пожалуйста их. Тарифы, группы и отчеты ... я говорил о тарифах, группах и отчетах ... Дело в том что у Вас очень большая часть логики интерфейса, отчетов и т.д. завязана на группах и дабы не переделывать очень многое я хотел узнать - как можно привязать тариф к группе? Интересует возможность организации уникальной связки "тариф == группа", дабы и поиск был поудобнее и отчеты рисовались бы красиво ... Раз уж ресь зашла об отчетах - почему у Вас есть поняте "месяц", но нет понятия "период"? Допустим я Ваш клиент и я очень хочу узнать свою наработку за квартал или за некий N-й период, допустим с 30.12.2007 по 10.02.2008, как это сделать? Или я администратор и так же хочу узнать нечто подобное, как это сделать?

Автор:	stark [ 15 фев 2008, 19:32 ]
Заголовок сообщения:
snark писал(а): Спасибо, я уже понял ... жаль только что этот, столь важный, параграф не входит в общее описание сервера наряду со справочниками и т.п. Логически администрирование относится к ядру, а получается что у него такой же параграф как у какого нибудь модуля или плагина ... Не понятно ..Справочники - это глава, котрая находится на том же уровне что и Администрирование, т.е в описании ядра системы, как вы и хотели..Или вы хотите общий обзор типа "про справочники вы можете прочитать в 15. Справочники , а про администрирование прав в 24. Администрирование" ?

Автор:	stark [ 15 фев 2008, 19:38 ]
Заголовок сообщения:
snark писал(а): Раз уж ресь зашла об отчетах - почему у Вас есть поняте "месяц", но нет понятия "период"? Допустим я Ваш клиент и я очень хочу узнать свою наработку за квартал или за некий N-й период, допустим с 30.12.2007 по 10.02.2008, как это сделать? Или я администратор и так же хочу узнать нечто подобное, как это сделать? Чисто функциональное ограничение ..Дело в том , что из-за большого объема таблицы разбиваются по мясяцам, т.е на кадый месяц отделная таблица и отчет обычно строится по месяцам ..А аггрегировать данные по куче разных таблиц - сложнее..Если у администатора есь желание, пусть образщается к этм таблицам и получает нужные ему данные

Автор:	Администратор [ 18 фев 2008, 11:56 ]
Заголовок сообщения:
Вообще для выбора по нескольким таблицам можно UNION использовать.. Но тоже проблемы, например, вывод сумм. Придется давать несколько запросов все равно. Так уж сложилось, что у нас все помесячно..

Автор:	snark [ 19 фев 2008, 23:49 ]
Заголовок сообщения:
stark писал(а): Не понятно ..Справочники - это глава, котрая находится на том же уровне что и Администрирование, т.е в описании ядра системы, как вы и хотели..Или вы хотите общий обзор типа "про справочники вы можете прочитать в 15. Справочники , а про администрирование прав в 24. Администрирование" ? Простите, я затупил ... увидел цифру 24 и подумал что это отдельная глава ... думаю что все же лучше сделать так: Код: 1. Описание основной части программы BGBilling 1.1. Как построено данное руководство 1.2. Логическая структура биллинга 1.3. Программная структура биллинга 1.4. Установка сервера биллинга 1.4.1. Установка сервера биллинга на OS Linux 1.4.2. Установка сервера биллинга на OS Windows ... 1.23. Рассылки 1.24. Администрирование 1.25. Загрузка платежей из файла тогда точно никто и никогда не запутается, например как я, т.к. четко будет видеть раздел где он находится. Почему установки разбиты на подпараграфы? Потому что при добавлении нового параграфа не слетит нумерация следующих за ним параграфов, я думаю так логично. stark писал(а): snark писал(а): Раз уж ресь зашла об отчетах - почему у Вас есть поняте "месяц", но нет понятия "период"? Допустим я Ваш клиент и я очень хочу узнать свою наработку за квартал или за некий N-й период, допустим с 30.12.2007 по 10.02.2008, как это сделать? Или я администратор и так же хочу узнать нечто подобное, как это сделать? Чисто функциональное ограничение ..Дело в том , что из-за большого объема таблицы разбиваются по мясяцам, т.е на кадый месяц отделная таблица и отчет обычно строится по месяцам ..А аггрегировать данные по куче разных таблиц - сложнее..Если у администатора есь желание, пусть образщается к этм таблицам и получает нужные ему данные В чем суть ограничения? Невозможно отрисовать начальную и конечную даты, затем по их данным сделать, к примеру: Код: $mid = 1; $start_year = 2008; $stop_year = 2008; $start_month = 01; $stop_month = 02; for ($i = $start_month; $i <= $stop_month; $i++) { $query = "SELECT * FROM log_session_$mid_$start_year$i"; execute $query; do_something_with_result(); } Правда пример для отчета в диапазоне одного года, но не думаю что большая проблема сделать это в рамках диапазона лет. Или все же есть какое то иное ограничение? Вопрос с привязкой групп к тарифам почему-то все время обходится стороной

Страница 1 из 1	Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/

Автор:	stark [ 20 фев 2008, 13:04 ]
Заголовок сообщения:
snark писал(а): stark писал(а): В чем суть ограничения? Невозможно отрисовать начальную и конечную даты, затем по их данным сделать, к примеру: Код: $mid = 1; $start_year = 2008; $stop_year = 2008; $start_month = 01; $stop_month = 02; for ($i = $start_month; $i <= $stop_month; $i++) { $query = "SELECT * FROM log_session_$mid_$start_year$i"; execute $query; do_something_with_result(); } Правда пример для отчета в диапазоне одного года, но не думаю что большая проблема сделать это в рамках диапазона лет. Или все же есть какое то иное ограничение? Вопрос с привязкой групп к тарифам почему-то все время обходится стороной Т.е сортировки, агрегатные функции и т.п вы хотите делать не на стороне sql сервера ,а в в функции do_something_with_result();?

Автор:	snark [ 20 фев 2008, 17:12 ]
Заголовок сообщения:
stark писал(а): Т.е сортировки, агрегатные функции и т.п вы хотите делать не на стороне sql сервера ,а в в функции do_something_with_result();? А что Вы видите в этом плохого? MySQL гораздо быстрее выполнит несколько маленьких запросов вместо одного большого, да и легче это перенесет. Думаю что проще все возложить на приложение чем на БД, т.к. Ваш переезд на постгрес - это всего лишь вопрос времени, а после переезда не надо будет заново пересочинять мега-запросы, т.к. простейшие запросы выполняются практически всеми СУБД одинаково. Ведь БД по сути - это склад информации с которой работает приложение (считает, отображает, складирует, забирает и т.д. и т.п.) и именно приложению ничего не стоит сделать выборку по куче таблиц и отобразить требуемую информацию, т.е. данные за период. P.S. Связь логических групп с тарифами, как я понимаю запрещенная к обсуждению тема.

Автор:	stark [ 20 фев 2008, 17:32 ]
Заголовок сообщения:
snark писал(а): stark писал(а): Т.е сортировки, агрегатные функции и т.п вы хотите делать не на стороне sql сервера ,а в в функции do_something_with_result();? А что Вы видите в этом плохого? MySQL гораздо быстрее выполнит несколько маленьких запросов вместо одного большого, да и легче это перенесет. Проблема в том, что sql сервер обычно справляется с этим обычно намного проще , чем приложение ..Чтобы выбрать простую сумму в вашем случае нужно сделать полную выборку по всем таблицам, передать эти данные через сеть приложению, которое потом уже внутри вашей функции произведет суммирование и получит ровно одно число .. Теперь предствте что вам нужно получить 100-юу стринцу данных со 100 записями (отсортированными по какому-то полю), подумаете во что это выходит в вашем случае Обычно с эти проще справляется сервер , в вашем случае проще использовать хранимые процедуры чем передавать все данные приложению snark писал(а): stark писал(а): Ваш переезд на постгрес - это всего лишь вопрос времени.. Забавно, но я об этом почему-то пока не знаю

Автор:	Администратор [ 20 фев 2008, 18:20 ]
Заголовок сообщения:
Цитата: P.S. Связь логических групп с тарифами, как я понимаю запрещенная к обсуждению тема. Они просто никак не связаны. В телефонном разговоре я уже предложил вам связать их с помощью встроенных скриптов и думал что вопрос на этом исчерпался... Вы предлагаете реализовать нам связать группы с тарифами в ядре?

Автор:	snark [ 20 фев 2008, 20:41 ]
Заголовок сообщения:
stark писал(а): Проблема в том, что sql сервер обычно справляется с этим обычно намного проще , чем приложение .. Я же привел просто пример ... Вот Вам абсолютно рабочий пример в котором как раз большая часть делается именно на стороне сервера: Код: /* * таблица со статистикой / $query = " SELECT DATE_FORMAT(start_time, '%d.%m.%y %T') AS start_time, DATE_FORMAT(stop_time, '%d.%m.%y %T') AS stop_time, TIMEDIFF(stop_time, start_time) AS online_time, in_bytes, out_bytes, money FROM stat WHERE user = ? AND start_time BETWEEN ? AND ? ORDER BY start_time "; / * итого за месяц / $query = " SELECT SEC_TO_TIME(SUM(TIMEDIFF(stop_time, start_time))) AS online_time, SUM(in_bytes) AS in_bytes, SUM(out_bytes) AS out_bytes, SUM(money) AS money FROM stat WHERE user = ? AND start_time BETWEEN ? AND ? "; / * итого за период / $query = " SELECT SEC_TO_TIME(SUM(TIMEDIFF(stop_time, start_time))) AS online_time, SUM(in_bytes) AS in_bytes, SUM(out_bytes) AS out_bytes, SUM(money) AS money FROM stat WHERE user = ? AND start_time BETWEEN ? AND ? "; Эти запросы просто прогоняются циклом и на выходе получается весьма симпатичная табличка со статистикой, если захотите - могу показать Но, опять же, это всего лишь пример, т.е. никаких JOIN и т.д. здесь нет, в то же время они вполне себе имеют место быть в реально работающих приложениях ... stark писал(а): snark писал(а): Ваш переезд на постгрес - это всего лишь вопрос времени.. Забавно, но я об этом почему-то пока не знаю Рано или поздно биллингу станет тесно в MySQL и захочется большей надежности, скорости и т.д. Опять же тут, на форуме уже говорилось что Вы думаете об постгресе, вот я и сделал подобный вывод ... Даже те же хранимки там на порядки лучше чем в мускуле Администратор писал(а): Цитата:* P.S. Связь логических групп с тарифами, как я понимаю запрещенная к обсуждению тема. Они просто никак не связаны. В телефонном разговоре я уже предложил вам связать их с помощью встроенных скриптов и думал что вопрос на этом исчерпался... Вы предлагаете реализовать нам связать группы с тарифами в ядре? Видите ли, то что у Вас является логической группой вполне может быть реализовано как доп. поле в договоре и тогда лимит на 62 группы отпадет сам собой. Предложение о связке групп с тарифами родилось из за того что сейчас в GUI все построено на группах, и связать группу с тарифом проще чем переписать логику GUI, т.к. на сколько я понял кроме как в GUI группы нигде не используются, ни при тарификации ни при ... насколько я понял - нигде. Все началось с чего? Из за того что при беглом взгляде невозможно хотя бы приблизительно узнать сколько пользователей в каком либо тарифе, сколько они скачали трафика и т.д., потом выяснилось что это вообще невозможно узнать т.к. даже в модуле отчетов (заметьте, отдельно продаваемом модуле) этого функционала так же нет, но зато все что душе угодно можно узнать по группам ... ладно, надо значит как-то связать тариф с группой и все встанет на свои места, даже в тех же отчетах ... ну и я попробывал ... не получилось "что за напасть?" подумал я, значит клиент может переходить из тарифа в тариф по своему желанию, а из группы в группу, на которых строится вся логика GUI, а не биллинга - не может! Т.е. получается я попадаю в ситуацию что есть 2 параметра логической группировки пользователей, а именно: 1 - Группы, повторюсь, легко реализуемые как доп. поле в договоре 2 - Тарифы, т.к. пользователь не может быть без тарифа, но запросто может не состоять ни в одной из групп. Теперь понимаете в чем дело? Поэтому то я и предлагал сделать связку групп с тарифами как решение "здесь и сейчас". Если Вас не затруднит - Выложите, пожалуйста, пример скрипта которым это можно сделать "здесь и сейчас", если Вас конечно не затруднит. В идеале, как я предложил в разговоре по телефону, думаю стоит сделать групповой характеристикой именно тариф, т.к., повторюсь, клиент не может быть вне какого либо тарифа, но вне группы - может, т.к. группы могут быть даже не определены.

Автор:	snark [ 14 мар 2008, 17:57 ]
Заголовок сообщения:
тут я выложил пример того как оно сейчас реально у меня работает и очень хотелось бы подобное видеть в БГБ ...