Перейти к содержимому
Local

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

Доброго всім часу.
Запустили систему ibox, виникло наступне питання, як передати через поле field  ФІБ ?

щоб абонент бачив свої данні під час оплати, з мануалу зрозумів що це можливо, але як?

Поделиться сообщением


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

посмотреть как сделан фронтенд

прочитать их протокол

внести в фронтенд изменения

протестировать

прислать пулл реквест

  • Like 1

Поделиться сообщением


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: camchatix
      Добрый день
       
      Имеется работающий ubilling 0.8.8 rev 6006
      ponizator + бдком + opt82 - все работает
      Подключил zte c300, добавил в разделе свич оборудование с описание ОЛТ (снмп шаблон выбрал zte 320 ГПОН)
      айпишка пингуется с биллинга
       
      на ЗТЕ есть работающие 3 онушки но при опросе олт - в понизаторе, в списке неизвестных ону нету ону с ЗТЕ.. только с бдком
      с билинга запустил snmpwalk на zte - посыпались данные
       
      дальше поковырялся и в папке billing/exports вижу файлы с опросами ОЛТ
      так вот файлы от бдкома вижу 5 штук (distance, fdb, signals, onuindex, onuinterface) 
      а вот от zte c300 только один IDOLT_OLTSIGNALS (посмотрел что внутри а там все верно - 3 онушки и ихние сигналы)
       
      но в понизаторе в таблице zte c300 пусто
      такое ощущение что в файле snmp не правильные MIBs указаны
       
      поделитесь инфо, или шаблоном snmp
      версия firmware zte c300 1.2.5
    • Автор: pavlabor
      Вопрос дополнения базы данных и биллинга таблицей "все-ко-всем", продиктованы следующими потребностями.
      Есть модуль "Филиалы".
      При подключении данного модуля возникает следующая проблема.
      Не возможно подключить например город или филиалы для филиала, потому как филиал получает доступ ко всей информации о других филиалах.
      Нужно создать условия при которых филиал сможет самостоятельно вносить пользователей, адреса, вести склад при этом не видя информацию в материнской базе и других филиалах.
      Далее филиал не может создавать филиал.
       
      Такие задачи решаются созданием таблицы "все-ко-всем" в которой формируется каскадное вложение филиалов и связкой соответствующих таблиц сервисов.
      При правильном построении форм запроса и проверке на стороне сервера прав, филиал сможет получать доступ только к разрешенным ему модулям, и только его позициям в базе.
      Более того филиал сможет создавать свои филиалы, контролировать в них данные.
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
    • Автор: pavlabor
      Почитал вопросы возникающие вокруг работы ubilling и понял что проблемы связаны с архитектурой  Stargazer
      Насколько я понял проблем очень много, некоторые из них.
      Stargazer работает с базой в памяти и при параллельной работе с базой возникают конфликты с работой, например с внесением оплаты другим приложением.
      При остановке Stargazerа или биллинга идет сбой работы Насов.
      Текущая архитектура может стать ограничением по количеству возможно обслуживаемых клиентов.
       
      Проблемы не все, но этих достаточно чтобы задуматься о альтернативе написания эмулятора  Stargazer-а.
      Мое понимание, эмулятор должен выглядеть как модуль, который можно включить или выключить, или выбор работы или через Stargazer, или через внутренний модуль.
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
    • Автор: pavlabor
      Права, введение расширенной настройки прав.
      Предлагаю рассмотреть формирование и в перспективе реализации расширения следующих прав.
      Имеется, структурированное управление правами, которое не совсем закрывает потребность.
      Имеется.
      Объекты.
      - Модуль.
      - Позиция в модуле, юнит.
      Юзатели.
      - Филиалы.
      - Администраторы.
      Администраторы.
      - Стажер(демо).
      - Специалист.
      - Эксперт.
      Действия.
      - Просмотр.
      - Создание.
      - Редактирование.
      - Удаление.
      Собственно идея в чем. В оператора, или при создании филиала, администраторам могут быть переданы права на работу с модулем.
      В текущий момент, не имеется сквозной политики на права, поэтому они предоставляются выборочно и не совсем понятно по какой системе, по все вероятности "так получилось", как следствие, например.
      При создании филиала и передачи ему права на роботу с модулем город, то админ филиала может удалить город, изменить название, что может привести к проблеме у других филиалах и материнской структуре.
      При реализации единой политики, появляется необсуждаемая возможность и требование к модулям по правам.
      В связи с этим, определенный модуль можно делегировать/не делегировать филиалу, с определенными ограничениями, например филиал может просматривать, вносить города, но не может их редактировать или удалять.
      Внутри филиала, появляется возможность создавать профили уровней сотрудников не беспокоясь о состоянии базы, например создаеются
      - Стажер(демо).
      - Специалист 3 категории.
      - Специалист 2 категории.
      - Специалист 1 категории.
      - Эксперт.
      Взяли на работу чела, дали ему уровень стажера и пусть листает базу пока не прозреет,
      прозрел, дается профиль Специалиста 3 категории, и т.д.
      То же самое и с филиалами.
      Как админ филиала может завести пользователя, а выносить мозг дирекции тоже не каширно, вот и даются оговоренные права что админ филиала пользователя может завести, но редактировать и удалять не может, если другое не оговорено.
       
      Параллельно возникает вопрос с пользователями другого филиала, но этот вопрос будет рассмотрен в разделе "Требуется внесение таблицы "все-ко-всем".
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
       
    • Автор: cetim
      Если сменить view при формировании платежного ID , чем это чревато со стороны приема платежей (кроме недовольства пользователей) ?
×