Перейти к содержимому
Калькуляторы

mrlexus

Пользователи
  • Публикации

    27
  • Зарегистрирован

  • Посещение

Все публикации пользователя mrlexus


  1. Коллеги, кто-то делал отслеживание и обработку события отвязки оборудования от УЗ?
  2. created, timefrom, activated время выставляю в 00:00:00 Воспроизвел у себя такую же ситуацию. После изменения времени напрямую в БД в указанных полях на 00:00:00 перерасчет прошел практически мгновенно. Вероятно, время перерасчета зависит от параметров блокировки и типа списания в тарифном плане. У меня блокировка - Активная, списание - Комбинированно.
  3. Какие поля в таблице меняете?
  4. Еще лучше вынести это в параметр конфига. Приводим функцию к такому виду: public function validateVgid() { if (!yii::app()->params['vgroup_schedule_blocked']) { if ($this->vgroup()->vgroup->blocked) { throw new Exception('Account is blocked'); } } foreach ($this->tarrasp() as $item) { if ($this->byUser($item)) { throw new Exception('Please remove allready scheduled tariff change'); } } } И в конфиг ЛК добавить такие строчки: //Разрешить смену тарифного плана при блокировке УЗ 'vgroup_schedule_blocked' => false, ЗЫ Просто ради интереса, сколько денег попросили бы разработчики за такую доработку?
  5. Посмотрел код ЛК. Оказалось все очень просто. Ищем файл client2/client/components/tariff/changing/Tariff_Changing_Helper.php и приводим в нём функцию к такому виду: public function validateVgid() { /* if ($this->vgroup()->vgroup->blocked) { throw new Exception('Account is blocked'); } */ foreach ($this->tarrasp() as $item) { if ($this->byUser($item)) { throw new Exception('Please remove allready scheduled tariff change'); } } }
  6. Не совсем так. В интерфейсе админки в двух местах (Объекты - УЗ и Объекты - Пользователи - нажать +) есть менюшки управления блокировками, которые как раз используют только текущее время при изменении состояния и изменять это поведение разработчики не намерены. Поэтому выход: либо выпиливать эти менюшки из интерфейса либо бить по рукам операторов, которые ими пользуются. Пытался допилить в ЛК мастер управления пакетами ТВ, с первого захода не осилил. Но там можно взять за образец мастер смены тарифного плана и в коде вычислять нужную дату и время ставить 00:00. Ну и крайний вариант - запрашивать доработку у разработчиков.
  7. Любое обновление ЛБ - это боль, страдание и бессонные ночи. Лучше уточните, какие платформы используете (Интернет, Телефония/IP телефония, ЦТВ/КТВ и т.д.), могу рассказать более детально. ЗЫ Учитывая, что сейчас обновление только с пакетом тех. поддержки, то должно быть проще. Но, не уверен.
  8. Сюда бы разработчиков LANBilling. Очень хочется узнать их опыт платной поддержки, желательно с аналогичными графиками. Особенно интересует процент неоплачиваемого времени техподдержки по причине "DEVBUG".
  9. Согласен удобно. Только этом механизм не годен для полноценной замены учетных записей USBOX. Для привязки оборудования к УЗ все равно надо создавать учетку USBOX. Мы так надеялись, что теперь не придется плодить пустые учетки, но, увы...
  10. 2anichka991 Я понял Вашу позицию. Странно, что представитель СР акцентировал внимание публики, что суд с разработчиком - это одно из конкурентных преимуществ отечественного ПО. Вы начали его поддерживать, переведя тему в политоту, а теперь уходите в сторону таки соблюдения договоренностей между сторонами. Уточните еще один важный момент: договоренности или же договора (бумажные) конкретно у Вашей компании с разработчиком? Это две большие разницы. Мне действительно это интересно в свете последних изменений в сервисной политике разработчика. Гарантированное время решения это хорошо. Только решение решению рознь. Могу рассказать конкретный пример с техническими подробностями, если Вам интересно и Вы готовы дать свои профессиональные комментарии.
  11. В данном конкретном случае все регламенты и прочие бумажки в одночасье становятся фИговыми листочками, которыми можно лишь прикрыться при разборах полетов. Если под большой красной кнопкой написать "НЕ НАЖИМАТЬ", на неё обязательно нажмут, и, наоборот, если написать "НАЖАТЬ ОБЯЗАТЕЛЬНО" - никто не нажмет. Это человеческий фактор и он не решается только административным воздействием. Поэтому необходимо делать техническую реализацию системы положительной или отрицательной связи для контроля возникновения ошибки а работе штатного (!) функционала системы. На реализацию данной системы требуются ресурсы, как временные, так и человеческие. Итог - система работает, но появился очередной костылик под падающий забор. Вы мне уже ответили в первом абзаце. Опуская промежуточные ходы и ответвления итог один - "Идите в суд" (с) Мне ясна Ваша позиция. Если взять конкретный продукт, то без Linux/UNIX, MySQL, Apache, php + extentions, python и умения все это приготовить, LB просто набор байтов. И только в совокупности все это становится БИЛЛИНГОМ. Поэтому Ваше высказывание немного сомнительно. Кроме всего, для того, чтобы все это стало по настоящему АСР, требуется дополнительная обвязка для управления оборудованием, и тут без opensource совсем не обойтись. Даже CoA не послать. К чему я все это. Я вижу, что продукт развивается, местами становится лучше, но в эту бочку меда разработчики своими же руками кидают совсем уж неприличные объемы дегтя. Причем, иногда складывается ощущение, что они сознательно выпускают релиз с некоторой долей ошибок, иногда совсем "детских" и от релиза к релизу повторяющихся. Мне очень хочется, чтобы это было неправдой и с каждым релизом старые ошибки не повторялись, а новые - не появлялись. А описанные мною выше "нежданчики", и, особенно, реакция на них разработчиков - небольшое недоразумение, которое будет решено до окончания срока подписки на обновления. Пока я вижу некоторое улучшение, связанное с приходом нового технического директора в команду СР. Но мне хочется в этом быть уверенным, а не надеяться на нисхождение просветления на ответственные за разработку продукта головы.
  12. Разработчик отмалчивается и не принимает разумные доводы. Ок. Принято. Решение через изменение бизнес-логики - убедить 50 менеджеров (их действия уже доведены практически до автоматизма) делать не так, как они привыкли за 5(!) лет использования системы, а прям вот сейчас делать так, как надо разработчику по его прихоти. Ваши действия?
  13. Ок. Принято. Разработчик в ТТ отвечает, что это не баг, а фича, и доку мы поправим. На неоднократные вопросы о сроках решения проблемы ответа нет несколько месяцев. Доход вашей компании все также теряется... Оба контрагента - резиденты РФ. Ваши действия? P.S Не читайте советских газет до обеда (с) Ф.Ф. Преображенский
  14. anichka991 Интересно Вас читать. Все смешалось в доме Облонских... Машины, деньги, полствола... :) Невольно вспомнилось детство и мультик про полтора землекопа :) Однако, хочется узнать Ваше мнение по более конкретному вопросу. Представьте, что с очередным обновлением ПО (оплаченном), Вы обнаруживаете нештатное поведение системы, которое не описано ни в документации, ни в списке изменений к релизу. Причем это поведение прямо влияет на уменьшение дохода Вашей компании. Ваши действия, как лица, ответственного за функционал этого ПО в Вашей компании?
  15. Создание тикетов в HD доступно? При покупке лицензии на обновление? Доступно. Но решение проблемы не гарантировано. В большинстве случаев проблемы решают, но решение может растянуться на несколько месяцев. Будьте готовы к отпискам со стороны HD.
  16. 10 блокировка может быть установлена только из админки менеджером вручную. Система автоматически не переводит в это состояние никакие УЗ. Равно как и обратно - не выводит из 10 блокировки. Это не может быть глюком. Если только не чьи-то шаловливые ручки... Смените пароли менеджеров в ЛБ, на доступ по ssh, к mysql и пр. разрешите файерволом доступ к админке только с доверенных хостов, проведите аудит системы на предмет нелегального доступа.
  17. Не все так просто. Если УЗ ни разу не была в состоянии "Отключено" (10 блокировка), то это поле в БД имеет значение '0000-00-00 00:00:00',в админке оно отображается прочерком. Если УЗ была в 10-й блокировке - то поле имеет значение даты перехода в это состояние. При включении УЗ поле остается неизвенным. Переход в состояние "Отключено" влияет на на списания абонплаты. В этом состоянии списания не производятся. Вот меня и смущает, откуда такая дата взялась? Еще вопрос: почему дата изменения состояния УЗ - 19.11.2013? Какие действия с УЗ производились в этот день?
  18. На ваших скриншотах, в табличной части Дата подключения УЗ - 19.11.2013, Дата отключения - 30.11.1899
  19. Откуда у вас взялась дата отключения УЗ 30.11.1899 г.?
  20. У Ланбиллинга есть статья на эту тему. Там пример для Linux, но для FreeBSD тоже можно сделать. Чтобы абоненты не ждали таймаута сброса сессий mpd можно в скриптах обработки carp чистить таблицу sessionradius.
  21. http://www.raspberrypi.ru/ Не факт что потянет cacti, как вариант для рассмотрения. Вписывается под требования.
  22. Кусок моего старого скрипта динамического шейпера под utm5. Как один из вариантов управления скоростью: $ebs=floor($speed_shape/8); $cbs=$ebs/2; $if_up="/usr/sbin/ngctl msg ".$interface.":inet.1-0-m setconf { upstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } }"; $if_dw="/usr/sbin/ngctl msg ".$interface.":inet.0-0-m setconf { upstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } }"; exec($if_up); exec($if_dw); Где: $speed_shape - скорость в Кбит/с, $interface - ngXX Соотвественно, надо заранее знать имя ноды. У меня сохранялость в самодельную табличку скриптами up/down значения login/ip/ng* и пр., затем оттуда бралось.
  23. Чтобы правильно работало списание типа "Ежедневно равными долями" нужно в верхней шапке тарифа выставить метод списания - "Динамически". В таком сочетании все работает корректно.
  24. Выделенное значение указывает на то, что максимальный объем выделяемой памяти для одного приложения равен 512 Мб, причем, насколько я понимаю, туда входят и ресурсы всех порожденных дочерних процессов. Данное значение установлено для GENERIC ядра 32-bit систем FreeBSD.Изменить этот параметр можно пересобрав ядро с такими опциями: options MAXDSIZ=(2048UL*1024*1024) где - 2048UL - это размер памяти, выбеляемый для одного приложения (2 ГБ). Данное значение не предтендует на идеальное, я подбирал его для своей конфигурации с 4ГБ памяти. Поэксперементируйте и подберите размер для себя. После пересборки ядра у меня исчезли грабли с mpd, когда процесс самостоятельно, без видимых причин и записей в логах, закрывался и закрывал все соединения.