BiTel

Господа разработчики, предлагаю Вам решить незамысловатую, но очень нужную провайдерам задачку средставми BGB:

Дано:Вопрос:
Ответ?

Собственно откуда родилась эта задача: тестируя BGB я был удивлен отсутствием в нем такого момента как "Отчет по тарифному плану", можно увидеть отчет по договору или группе договоров но никак нельзя сделать отчет по тарифу Да, у Вас сущестует логическая система деления пользователей на группы, НО! Эти группы никак не могут быть привязаны ни к тарифу ни к чему либо еще кроме договора и получается что, допустим, если существует 10 килодоговоров надо перебрать все дабы указать им их групповую принадлежность. Так же отсутствует механизм задания группы пользователей в шаблоне договов Почему нельзя редактировать шаблоны админского интерфейса? Лично меня не устраивает запись "Принято/Отправлено", т.к. я хочу видеть 2 стобца: один - "Принято", а другой "Отправлено" и очень хочу иметь возможность сортировки между между ними! При использовании встроенного в DialUp Netflow коллектора я так же хочу видеть отдельные столбцы для каждого типа трафика, а не смотреть их все в одной куче! Почему не существует разделения на типы аккаунтов в админском интерфейсе? Лично я, как администратор, не хочу показывать тех. саппорту закладки А, В, С или еще какие нибудь не нужные им, на мой взгляд, элементы интерфейса. Говоря проще - необходим более гибкий интерфейс, который можно было бы изменять под свои нужды.

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

Такого отчета нет. В ядре он нереализуем, т.к. формат хранения данных различен для каждого из модулей.

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

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

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

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

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

Да? Странно, излазил доку по этому модулю вдоль и поперек и не увидел ни описания ни примера Sad Просто я, как и многие, сначала читаю и только потом что либо использую.
Администратор писал(а):

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

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

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

Вот Вам маленький пример, более объемный пример ну и целая подборка примеров. Лично мне более симпатичен 1-й приведенный мною пример т.к. в таблицах, особенно в больших, всегда удобнее ориентироваться когда таблица не однотонная а "полосатая".
Администратор писал(а):

Буду с нетерпением ждать!
Администратор писал(а):

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

Как ею пользоваться?
Администратор писал(а):

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

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

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



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


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

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

Все же вернемся к нашим баранам, а именно:Я установил модуль отчетов, увидел что там есть отчет по тарифным планам и ... Господа, скажите пожалуйста, где в этом отчете время/трафик/деньги? Почему нельзя указать период больший нежели 1 день? По всем остальным отчетам прекрасно рисуются отчеты за месяц, а вот по тарифным планам увы нет - это так задумано?

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

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

• Один тарифный план == одна уникальная логическая группа договоров.
  Т.е. определяя пользователю тарифный план автоматически выбиралась бы соответствующая ему, одна единственная, уникальная группа, либо при изменении группы договору менялся бы тарифный план.
• Одна группа тарифов - это связанная с каждым из тарифов одна единственная уникальная группа договоров.
• При переходе договора из одного тарифа в другой изменение его группы.
• Добавление в группу либо тариф параметров того или иного модуля.
  Например параметры realm, атрибутов RADIUS для модуля DialUp и т.д. и т.п. Дабы при изменении логической группы можно было бы разом изменять массу параметров.

При реализации подобного ничего в текущей структуре глобально менять не надо будет и группы будут иметь бОльший смысл нежели простое логическое деление юзеров на "группа 1", "группа 2" и т.д.

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

Спасибо, я именно так и делаю ...Это заметно Она значительно лучше чем 4.3, понятнее что ли ... Приходится правда смотреть в обе, дабы дораскрыть для себя в 4.4 моменты не раскрытые в 4.3 ...

Ну а все же, что с остальными вопросами?

To snark

Прошу прощения, я случайно поправил ваше сообщение Постарался восстановить все в первозданном виде...
Мой ответ:


Здесь про права: http://bgbilling.ru/v4.4/doc/ch01s24.html
Разумеется не сложно распарсить стобец traffics, но у нас единый движок таблиц, который читает загловки из файла, а данные получает с сервера. В данный момент там нет поддержки динамически формируемых заголовков. Это не принципиальная проблема, просто пока не добрались.



Пользователь может знать вопрос, но если у него нет прав, сервер просто не выдаст ему данные.



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

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

Да ладно Вам, все мы люди ... errare humanum est еще никто не отменял Спасибо, я уже понял ... жаль только что этот, столь важный, параграф не входит в общее описание сервера наряду со справочниками и т.п. Логически администрирование относится к ядру, а получается что у него такой же параграф как у какого нибудь модуля или плагина ... я думаю было бы логичнее организовать структуру вида:

• ядро
  описание всего относящегося к ядру
  • функционал А
  • функционал B
  • функционал C
• модуль А
  описание всего относящегося к модулю А
  • функционал А
  • функционал B
  • функционал C
• плагин А
  описание всего относящегося к плагину А
  • функционал А
  • функционал B
  • функционал C
• модуль/плагин N
  описание всего относящегося к модулю/плагину N
  • функционал А
  • функционал B
  • функционал C

При таком раскладе проще было бы ориентироваться в функционале ядра/модуля/плагина, IMHO.В общем то я так и думал ... ну да ничего, подождем ... рано или поздно руки дойдут ...
/me мечтательно подумал об "это будет в 4.4" и скрестил пальцы Да, Вы правы, проигрывает ... но, как Вы верно заметили, каждой организации нужны свои данные и вот тут, при наличии у админа правильных /dev/hands и /dev/head, он может сам подправить Ваш интерфейс под свои нужды ... если же у админа кривые /dev/hands и /dev/head (патч не тот наложил или еще что ), то Вы всегда сможете сказать - www интерфейс предоставляется as is, поддержка осуществляется только относительно GUI и за все Ваши действия в отношении www интерфейса разработчик ответственности не несет Тарифы, группы и отчеты ... я говорил о тарифах, группах и отчетах ... Дело в том что у Вас очень большая часть логики интерфейса, отчетов и т.д. завязана на группах и дабы не переделывать очень многое я хотел узнать - как можно привязать тариф к группе? Интересует возможность организации уникальной связки "тариф == группа", дабы и поиск был поудобнее и отчеты рисовались бы красиво ... Раз уж ресь зашла об отчетах - почему у Вас есть поняте "месяц", но нет понятия "период"? Допустим я Ваш клиент и я очень хочу узнать свою наработку за квартал или за некий N-й период, допустим с 30.12.2007 по 10.02.2008, как это сделать? Или я администратор и так же хочу узнать нечто подобное, как это сделать?

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

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

Вообще для выбора по нескольким таблицам можно UNION использовать.. Но тоже проблемы, например, вывод сумм. Придется давать несколько запросов все равно. Так уж сложилось, что у нас все помесячно..

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


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


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

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

А что Вы видите в этом плохого? MySQL гораздо быстрее выполнит несколько маленьких запросов вместо одного большого, да и легче это перенесет. Думаю что проще все возложить на приложение чем на БД, т.к. Ваш переезд на постгрес - это всего лишь вопрос времени, а после переезда не надо будет заново пересочинять мега-запросы, т.к. простейшие запросы выполняются практически всеми СУБД одинаково. Ведь БД по сути - это склад информации с которой работает приложение (считает, отображает, складирует, забирает и т.д. и т.п.) и именно приложению ничего не стоит сделать выборку по куче таблиц и отобразить требуемую информацию, т.е. данные за период.

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

Проблема в том, что sql сервер обычно справляется с этим обычно намного проще , чем приложение ..Чтобы выбрать простую сумму в вашем случае нужно сделать полную выборку по всем таблицам, передать эти данные через сеть приложению, которое потом уже внутри вашей функции произведет суммирование и получит ровно одно число .. Теперь предствте что вам нужно получить 100-юу стринцу данных со 100 записями (отсортированными по какому-то полю), подумаете во что это выходит в вашем случае

Обычно с эти проще справляется сервер , в вашем случае проще использовать хранимые процедуры чем передавать все данные приложению



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

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

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

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

Видите ли, то что у Вас является логической группой вполне может быть реализовано как доп. поле в договоре и тогда лимит на 62 группы отпадет сам собой. Предложение о связке групп с тарифами родилось из за того что сейчас в GUI все построено на группах, и связать группу с тарифом проще чем переписать логику GUI, т.к. на сколько я понял кроме как в GUI группы нигде не используются, ни при тарификации ни при ... насколько я понял - нигде.
Все началось с чего? Из за того что при беглом взгляде невозможно хотя бы приблизительно узнать сколько пользователей в каком либо тарифе, сколько они скачали трафика и т.д., потом выяснилось что это вообще невозможно узнать т.к. даже в модуле отчетов (заметьте, отдельно продаваемом модуле) этого функционала так же нет, но зато все что душе угодно можно узнать по группам ... ладно, надо значит как-то связать тариф с группой и все встанет на свои места, даже в тех же отчетах ... ну и я попробывал ... не получилось "что за напасть?" подумал я, значит клиент может переходить из тарифа в тариф по своему желанию, а из группы в группу, на которых строится вся логика GUI, а не биллинга - не может! Т.е. получается я попадаю в ситуацию что есть 2 параметра логической группировки пользователей, а именно:
1 - Группы, повторюсь, легко реализуемые как доп. поле в договоре
2 - Тарифы, т.к. пользователь не может быть без тарифа, но запросто может не состоять ни в одной из групп.
Теперь понимаете в чем дело? Поэтому то я и предлагал сделать связку групп с тарифами как решение "здесь и сейчас". Если Вас не затруднит - Выложите, пожалуйста, пример скрипта которым это можно сделать "здесь и сейчас", если Вас конечно не затруднит.
В идеале, как я предложил в разговоре по телефону, думаю стоит сделать групповой характеристикой именно тариф, т.к., повторюсь, клиент не может быть вне какого либо тарифа, но вне группы - может, т.к. группы могут быть даже не определены.

тут я выложил пример того как оно сейчас реально у меня работает и очень хотелось бы подобное видеть в БГБ ...