nightfly

Это говорит о невалидном формате/отсутствии опции BUILD_EXTOPTS. Должно быть что-то типа ; "максимумэтажей,максимумподъездов" BUILD_EXTOPTS="16,12" Вот чего вы должны получить в результате:

Нет. Вы НЕ ХОТИТЕ использовать УКВ. Оно взрывается в руках. По крайней мере в ближайших пару недель в продакшне ему делать вообще нечего. ща проверю.

2 felixio_01 Логика подсказывает, что да - это должно бы быть оно. Если окажется что не так - лучше спросить Jcomm - эта враждебная штука с платами за подключение, полностью его код. А вот по поводу этого можно сказать точно. Да - это ID типов оплат, под видом которых УКВ будет разносить автоматом деньги по ощадкассовским выпискам.

Ой блин, стоило на денек отвлечься, на серую будничную реальность а вас тут уже много всех Итак по порядку. 2 v27s Ну вообще у нас планов, в том числе наполеоновских и прочих тянущих на уютную палату с мягкими стенками всегда валом. Но запиливается новая функциональность / допиливается старая всегда либо под наши конкретные нужды, либо в свете кровавой заказухи, либо когда заняться вообще нечем, а душа жаждет приключений. На данный момент и как минимум в ближайшие несколько недель я усиленно пилю совсем НеАйпиTV (да млин, уже вторая убогая реализация одного и того же аналогового к

Посмотрел по сорцам - оно там действительно пустым в шаблонизатор передается. Почему так - лучше спросить Jcomm-a - это он поддержку DOCX_CHECK зачем-то воротил. А такого макроса отродясь не существовало там. Фиг знает откуда вы его придумали, и что вместо него должно было бы отображаться.

Ага Выбрать в выкидушке внизу "нормальные иконки". Нет Да - 15" CRT сейчас самый писк моды. Меняйте. Никто ж не запрещает. Цвет линков - это основная проблема провайдеров современности.

Итак. Много из того, что было запланировано на ближайшее время не было дописано, но так как обновление уже стремительно начало становиться дико жирным решено было выпустить промежуточный, "типа стабильный" релиз Ubilling 0.5.1 rev 3356. И вот какие веселые изменения вас ждут, в случае если вы таки обновитесь, как любой нормальный, сознательный гражданин: Изменения в структуре БД, см дамп. alter.ini: новая опция BUILD_EXTENDED включающая расширенные параметры (паспорта) домов. alter.ini: новая опция BUILD_OWNERS перечисляющая хозяйствующих субъектов. alter.ini: новая опция BUILD_EXT

2 DarkSpider Да. Давно о этом подумывал, но как это красиво оформить (не показывать же ему все его теги? там мат как правило) пока не дошло. Да, скорее всего начисление по виртуальным сервисам проводяться "влоб" - но опять же надо по сорцам смотреть, уже не помню. Вообще по логике вещей, да - они должны игнорировать мороженных пользователей. Надо бы к 0.5.2 запатчить. Во, вник человек в суть вещей

http://wiki.ubilling.net.ua/doku.php?id=faq Q: Абонент подключился 15 числа месяца при тарифе стоимостью 100 денег, не хочу чтобы он работал до конца месяца на шару, что делать? A: Используйте «Корректировку сальдо» и внесите платеж в -100 денег. Это не испохабит вам общую статистику по приходу денежных средств в отчетах. Либо не используйте - тогда это начисление будет видно как «оплату» вам и клиенту. Q: А если я сильно «честный» и хочу взять с абонента только стоимость половины месяца? A: Ну «скоректируйте сальдо» ему на -50 денег, очевидно же. Q: Абоненту начислена АП, но я с

8.4 amd64. Ставить стандартным скриптом сборки НАС-ов: http://wiki.ubilling.net.ua/doku.php?id=freebsdremotenas

2 DIO Это факт. На бенчмарках stargazer нормально воркает при количествах тарифов == количества юзеров. Но опять же вылезает вопрос самоочевидности и удобства. Всю ту же реальную айпишку (да, она такими маленькими черненькими цифирками написана) нужно как минимум перекликнуть соответствующим модулем + поменять юзеру соответствующий тариф. Опять же эти вот тарифы "с реальными айпишками" придется оформлять в отдельные линейки тарифных планов, в рамках которых будет позволен переход для этих пользователей (мы же не хотим, чтобы они себе выставили тариф без стоимости этой самой айпишки?) + все

Фигово предполагаете. Все взаимодействие с тарифами происходит только посредством stargazer-a. При аккуратной установке UBinstaller-ом на чистую фрю все работает из коробки. в FAQ все расписано.

2 freed Повторюсь - виртуальные сервисы. Точно с тем же успехом вы можете и "забыть" ему реальную айпишку перекликнуть, либо скажем "забыть" денег внести. http://demo.ubilling.net.ua:9999/billing/?module=userprofile&username=zlo_hev11ap8_0nt6 Мне вообще сложно придумать, что то более заметное и вменяемое чем здоровенные, разноцветные теги в профиле пользователя которые символизируют одним своим наличием какую-то дополнительную сущность навешанную на этого пользователя. Хотя... вообще предлагаю круче вариант. Даже два. 1. Делаете всем своим пользователям татушки

Виртуальные сервисы для этого и сделаны. Добавляете тег, на тег вешаете сервис с определенной ценой, тег вешаете на юзера. Раз в месяц дергаете vserviceschargefee из RemoteAPI. Все.

2 Den1xxx О, спасибоньки! Хотя у нас дефолтом и считается memory_limit = 256M но патч всеравно архиполезный и может предотвратить кучку плоходиагностируемых проблем. Ушло в основную ветку.

ок ок не ок да не - все вроде сделали Стукните в общем в аську через пол часика - разберемся с вашими собаками-уведомляками раз и на всегда.

Там используется штатная функция mail() которая просто напросто требует локального, запущенного и работающего MTA. Проверяется ее работа довольно просто при помощи "Консоли разработчика": function testEmail($email,$message) { $sender=__('Watchdog'); $subj='Ubilling '.__('Watchdog'); $message.=' '.date("Y-m-d H:i:s"); $headers = 'From: =?UTF-8?B?' . base64_encode($sender) . '?= <' . $email . ">\n"; $headers .= "MIME-Version: 1.0\n"; $headers .= 'Message-ID: <' . md5(uniqid(time())) . "@" . $sender . ">\n"; $headers .= 'Da

Еще раз повторюсь - оно у вас не "так". Отложенные СМСки будут отправлены работникам при следующем запуске собаки из RemoteAPI. Рекомендуемый собачий период - 10 минут.

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

Вообще никак не связано. Отложенные на будущее СМС-ки для отсылки просто отправляются в фоне при любом вызове собаки-наблюдаки. Как это происходит из remoteAPI или рученьками - не суть важно. Ну вот... по дематериализовавшимся полям на новом шлюзе - саппорт пока что узнает, чего там.

По тому, вернуться ли в жизнь поля `dlr_status`, `credits` и `updated` - все еще пытаюсь выспросить.

Потрындел быриком с их суппортом. Все норм, паника отменяется, изменения более косметические. Там меняется только айпишка хоста шлюза + минус три поля. С марта следует просто заменить 77.120.116.10 на 94.249.146.189 в конфигурации всех штук, использующих TurboSMS для рассылки. После чего стоит в интерфейсе сервиса потыкать "SMS Шлюз" -> "Подключение к шлюзу" -> "SQL" со старым паролем.

ахтыжмлять.....

Вообще свидетельствуют, о том - что при попытке чтения таблички с СМС шлюза TurboSMS какая-то пустая хрень в ответ вернулась.

Ок. Будем считать что здесь все ок. А в настройках СМС собакиных, все хорошо?