Перейти до

Релизы Ubilling


Рекомендованные сообщения

Проблема с отправкой смс...

судя по скрину дело в том, что на шлюз уходят данные с другим часовым поясом. у меня вот +7 на шлюзе судя по всему +2...

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

 

Как поправить? Я не силён в PHP :)

 

В окне "Состояние", отображаются вопросительные знаки...

 

P.S.

Если используется тема отличная от KVT (в моём случае Plain Clean) и не отображаются иконки, необходимо скопировать недостающие(!!!) файлы из /skins/taskbar/ в /skins/%theme_name%/taskbar/

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

 

влияет регистр и все знаки .

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 1,2k
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Да кстати если кому то нужен шаблон для свича то вот  можно воспользоваться такой штукой  шаблоно-генератором

Преувеличиваем? Ничего особенного и нового я не сделал

Ни один единорог не пострадал? =)

Posted Images

 

Проблема с отправкой смс...

судя по скрину дело в том, что на шлюз уходят данные с другим часовым поясом. у меня вот +7 на шлюзе судя по всему +2...

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

 

Как поправить? Я не силён в PHP :)

 

В окне "Состояние", отображаются вопросительные знаки...

 

P.S.

Если используется тема отличная от KVT (в моём случае Plain Clean) и не отображаются иконки, необходимо скопировать недостающие(!!!) файлы из /skins/taskbar/ в /skins/%theme_name%/taskbar/

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

attachicon.gif12.JPG

влияет регистр и все знаки .

Спасибо! С подписью разобрался (подсказали в суппорте TurboSMS), а вот с кодировкой и временем отправки беда... Сообщения на кириллице приходят битые и ответы от шлюза вопросительными знаками... у самого везде всё выставлено в UTF8 более негде проблем не возникает...

Ссылка на сообщение
Поделиться на других сайтах

Благодаря товарищу внесли в код рассылки следующие правки и всё заработало как надо:
 
Правим косяк с кодировками:
 
открываем /modules/general/turbosms/index.php
 
находим строку (71):

            $result = array();

после неё добавляем:

            $TsmsDB->query('SET NAMES utf8');

PROFIT!!! Теперь всё жестко-принудительно :)

 

 

Далее корректировка по часовому поясу (строки указаны с учетом правки кодировки):

 

находим строку (160):

            $date=date("Y-m-d H:i:s");

Заменяем/дописываем:

            $date=date("Y-m-d H:i:s", time()-5*3600);

Где "-5*3600" разница в часах между часовыми поясами сервера отправителя (в моём случае GMT +7) и шлюза TurboSMS (GMT +2).

 

Опять же PROFIT!!! :)

 

Колхозолизация конечно весьма высока, но за то работает :)

Ссылка на сообщение
Поделиться на других сайтах

V27S

Опять же PROFIT!!! :)

Спасибо за указание на актуальные проблемы. В 0.4.0 начиная с ревизии 2471 сетнеймс воткнут как есть, а также можно указывать таймзону более-менее по-человечески:

post-4093-0-72318900-1364490608.png

 

Учитывая что 0.3.9 получился весьма п@зд#цбаговатым фичастым, думаю следует ожидать в скором времени 0.4.0 который будет направлен в первую очередь на "работу над ошибками". Так что с нетерпением жду радостных багрепортов :)

nlo

выздоравливай!

Спасибо :)
Ссылка на сообщение
Поделиться на других сайтах

 

V27S

Опять же PROFIT!!! :)

Спасибо за указание на актуальные проблемы. В 0.4.0 начиная с ревизии 2471 сетнеймс воткнут как есть, а также можно указывать таймзону более-менее по-человечески:

attachicon.giftsms.png

 

Учитывая что 0.3.9 получился весьма п@зд#цбаговатым фичастым, думаю следует ожидать в скором времени 0.4.0 который будет направлен в первую очередь на "работу над ошибками". Так что с нетерпением жду радостных багрепортов :)

Вэлкам! Всегда рад помочь, чем могу :)

Спасибо огромное за ваш труд! :)

Крепкого здоровья вам! :)

Ссылка на сообщение
Поделиться на других сайтах

Релиз Ubilling  0.3.9 - rev 2465

 

 

- Модуль «Консоль разработчика»: мерджнут патч от Den1xxx улучшающий обработку SQL запросов.

это правильно конечно, но заметил в демке, что выполненный SQL запрос не сохраняется в текстареа, что не есть труъ.

Я не правил это на этот раз в коде, т.к. показалось, что этот этап уже был готов:)

Небольшое замечание по Вики, стр. http://wiki.ubilling.net.ua/doku.php?id=openpayz

 

 

Либо так, если у вас полностью цифровые логины у пользователей:

op_customers_login.sql -- transform users.login -> users.login;

CREATE VIEW op_customers (realid,virtualid) AS SELECT users.login, users.login FROM `users`;

 

Насколько я понял, virtualid задуман как уник и цифровой причем.

 

Тогда лучше было бы так, снимая требования на логин по цифре:

 

CREATE VIEW op_customers (realid,virtualid) AS SELECT users.login, CRC32(users.login) FROM `users`;
 
Ссылка на сообщение
Поделиться на других сайтах

При попытке рассылки, высыпает варнинги, из всего списка отсылается только первое сообщение...

настройки php.ini смотрел, лимиты и таймауты расширены до приемлемых значений...

В чем еще может быть дело, куда копать? :(

post-14490-0-84234100-1364554247_thumb.png

Відредаговано V27S
Ссылка на сообщение
Поделиться на других сайтах

post-4093-0-93309300-1364556190_thumb.png

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

А что у вас с 152 и 153 строках? В релизной версии там вообще дефайн  функции tsms_SendSMS($number,$sign,$message,$wappush).

Ссылка на сообщение
Поделиться на других сайтах

tsms.png

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

А что у вас с 152 и 153 строках? В релизной версии там вообще дефайн  функции tsms_SendSMS($number,$sign,$message,$wappush).

Если отправляю конкретному пользователю, то всё норм, а вот если массовая рассылка то вот такие варнинги...

           $number=  mysql_real_escape_string($number);
            $sign=  mysql_real_escape_string($sign);
Відредаговано V27S
Ссылка на сообщение
Поделиться на других сайтах

 

  1. $number= mysql_real_escape_string($number);
  2. $sign= mysql_real_escape_string($sign);

Хм, аналогично. И как не сложно заметить здесь не происходит никаких вызовов mysql_connect порождающих ошибки выше.

 

Сейчас попробую повторить еффект у себя.

Ссылка на сообщение
Поделиться на других сайтах

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

Оно у вас изначально вообще слало массово?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Все, понял откуда растут ноги. Походу они растут из жопы "особенностей" работы mysql_real_escape_string() пытающегося соединяться с БД (Оо) , чтобы получать текущий чарсет.

 

Попробуйте выковырять модуль turbosms из Ubilling CURRENT 0.4.0 rev 2473.

Должно взлететь.

Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах

Все, понял откуда растут ноги. Походу они растут из жопы "особенностей" работы mysql_real_escape_string() пытающегося соединяться с БД (Оо) , чтобы получать текущий чарсет.

 

Попробуйте выковырять модуль turbosms из Ubilling CURRENT 0.4.0 rev 2473.

Должно взлететь.

Вытащил модуль TurboSMS из версии 0.4.0 rev 2475, отработал с косяками, но все смски ушли.

post-14490-0-77378800-1364571032_thumb.png

Ссылка на сообщение
Поделиться на других сайтах

Млин. Моя старый и совсем слепой стал. Так и есть :(

Видимо PHP 5.4.

 

Оооокей, щас нагло хакну :)

Вот молодец! Работаешь не покладая рук! Памятник ставить пора! :)

Сегодня затестить не смогу, ибо 23:00, абоны не оценят ночного спама ))))

 

P.S.

убрал у себя в отслеживании сообщений колонку Msg ID, ибо не понятен смысл куда оно и зачем... + поскольку скин Plain Clear, в данном варианте нормально всё влезает.

Было бы круто, если можно было бы дропать из базы косячные строки, отсылки - т.е. рядом с сообщением красный крестик для удаления, а так же возможность массового удаления, если вдруг по запарке отправил, или отправил что-то не то и оно не ушло еще )

Відредаговано V27S
Ссылка на сообщение
Поделиться на других сайтах

Вот молодец! Работаешь не покладая рук!

Исходя из качества кода, непонятно, что он далеко не руками писан? :D

 

Памятник ставить пора! :)

...посмертно....

 

Сегодня затестить не смогу, ибо 23:00, абоны не оценят ночного спама ))))

Окей, корень зла понятен. Зафиксю - отпишусь.

Ссылка на сообщение
Поделиться на других сайтах

 

Памятник ставить пора! :)

...посмертно....

 

 

/me прописал у nightfly в консоли IDDQD и нажал Enter! :)

Відредаговано V27S
Ссылка на сообщение
Поделиться на других сайтах

Den1xxx

это правильно конечно, но заметил в демке, что выполненный SQL запрос не сохраняется в текстареа, что не есть труъ.

Да, походу на демке эта опция бай дефолт не включена просто

post-4093-0-71125500-1364986826_thumb.png

Я не правил это на этот раз в коде, т.к. показалось, что этот этап уже был готов :)

Да так и есть :)

 

Насколько я понял, virtualid задуман как уник и цифровой причем.

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

Ну логины и так сами по себе уникальны - в случае если они имеют вид 00002, 00003 итд (опции генерации логинов), вариант приведенный в виках просто позволяет пользователю при пополнении счета, терминалом скажем, помнить меньше цифр (ну вместо там номера договора или еще чего-то типа того).  В таком случае CRC32('00002') даст юзеру шанс повводить на терминале что-то типа 2765239769. В случае же нецифровых логинов "изкоробки" да CRC32() вполне себе вариант, как и скажем INET_ATON() и даст вполне себе вменяемый результат. Спасибо, добавил в вику.

 

В общем как сказано в конце примеров "В общем все ограничено только вашей извращенной фантазией ;)"

 

 

 

 

 

 

Кстати, будете смеяться, но OpenPayz изначально планировался и писался как реализация взаимодействия с платежными системами для fnshop ;)

Собственно FastShop подразумевался в виде ромбовидного "Managers interface" на архитектурной схеме. Но как водиться, у кастомера как-то резко кончились деньги и этот самый OpenPayz на скорую руку переточился под Ubilling (а че ж добру пропадать?). Собственно в норме `realid` это должно было быть ничто иное как хорошо известный вам $system->user['username'] либо $order_id.

Ссылка на сообщение
Поделиться на других сайтах

Еще раз отрихтовал в ревизии 0.4.0 rev 2480. Буду плакать кровавыми слезами если и это начнет у вас взрываться.

Спасибо огромное! Всё нормально работает :)

Ссылка на сообщение
Поделиться на других сайтах

эта опция бай дефолт не включена просто

Упс. Не заметил.

 

 

OpenPayz изначально планировался и писался как реализация взаимодействия с платежными системами для fnshop

Собственно такая же задача встала. Решил особо не изобретать велосипед, если есть рабочий вариант.

Правда пока не разобрался ещё.

Надеюсь разобраться и по итогам разработки закинуть что-либо и в Ваш репо, на очереди ipay.by и webmoney.

Відредаговано Den1xxx
Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від ppv
      Проглянув FAQ і Ubilling Wiki. Зацікавило питання чи є в Ubilling якась реалізація reCAPTCHA, чи потрібно додавати руцями, (для прикладу для форми подачі заявок чи для кабінету користувача)?
       
    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від Zend
      Продам сабж.
      2 контроллера CA07336-C001, в каждом по одном интерфейсном модуле CA07336-C009 (2 x 1Gbps iSCSI)
      HDD: 24 x 900GB SAS 10K
      Исправен.
      С ним могу продать шкафчик того же вендора.
       
      Стоимость - $4000, торг
       


×
×
  • Створити нове...