Сейчас в биллинге два вида блокировок: Административная и Системная.
Системная это по балансу. Возник вопрос, каким образом можно различить Административную блокировку (какую поставил сам пользователь, через личный кабинет к примеру. А какую поставили персонал компании)? Может кто подскажет?
З.Ы. Задача простая, иногда блокируем пользователей сами, за те или иные нарушения. И добавляем коммент. Сейчас хотим реализовать блокировку и разблокировку через ЛК. С первым вопросов нет, вопрос со вторым. Как защититься, что бы пользователь не смогу снять блокировку установленную сотрудниками компании. Через кастомную табличку не вопрос, а как нить средствами биллинга? (базы) можно узнать кто поставил блок?
Как различать блокировку пользвателей
Re: Как различать блокировку пользвателей
В 5.3 уже есть третий тип блокировки, пользовательская.Morbid писал(а):Сейчас в биллинге два вида блокировок: Административная и Системная.
Системная это по балансу. Возник вопрос, каким образом можно различить Административную блокировку (какую поставил сам пользователь, через личный кабинет к примеру. А какую поставили персонал компании)? Может кто подскажет?
З.Ы. Задача простая, иногда блокируем пользователей сами, за те или иные нарушения. И добавляем коммент. Сейчас хотим реализовать блокировку и разблокировку через ЛК. С первым вопросов нет, вопрос со вторым. Как защититься, что бы пользователь не смогу снять блокировку установленную сотрудниками компании. Через кастомную табличку не вопрос, а как нить средствами биллинга? (базы) можно узнать кто поставил блок?
Код: Выделить всё
<?xml version="1.0"?>
<urfa>
<!-- ######################### USAGE: ##############################################
utm5_urfaclient.exe -api api.xml -c bin\utm5_urfaclient_test.cfg -u -l "userlogin" -P "userpass" -a set_user5_voluntary_block -account_id -block_start -block_end
#################################################################################### -->
<parameter name="block_type" value="3"/>
<parameter name="block_start" value="0"/>
<parameter name="block_end" value="1800000000"/>
<!-- Stavim blokirovku -->
<if variable="block_start" value="0" condition="eq">
<set dst="block_start" value="now()"/>
</if>
<call function="rpcf_user5_set_voluntary_blocking"/>
</urfa>Можно юзать встроенные функцию:<parameter name="block_end" value="1800000000"/>
max_time() – возвращает строковое представление максимального значения времени в системе UTM5 в формате unix (2000000000, ~2033 год);
Я вот сам перекатываюсь с 5.2.1-007 на 5.3-003. Для миграции своих костылей делаю следующие выводы:
Пользовательская блокировка ставится только при помощи вызова через urfaclient, личного кабиента или utm5_wintray
База данных:
В таблице accounts следующие поля перестали иметь какое-либо значение:
is_blocked - код блокировки (более не нужен, так как осталось 3 типа блокировки с соотв. типами - 1, 2, 3, которые указаны в blocks_info)
block_recalc_abon - пересчитывать абонентскую плату (задается политикой списания, перенесится без изменений из предыдущей версии, отвечало за списание абонентской платы при наступлении системной блокировки)
block_recalc_prepaid - пересчитывать предоплаченный трафик (задается политикой списания, переносится без изменений из предыдущей версии, отвечало за списание предоплаченного трафика при наступлении системной блокировки)
Наличие блокировки у пользователя определяется лишь присутствием какого-либо значения в поле block_id.
Получается, что раздел документации http://www.netup.ru/UTM5/documentation/ ... ировкиbc-3 с этими кодами блокировки вообще не актуален и оставлен лишь для информации.
В таблице blocks_info так же некоторые поля перестали иметь смысл и перенесы из старой версии без изменений:
unabon и unprep отвечающие соответственно за типы блокировок с пересчитыванием той или иной составляющей.
Помогите разобраться. Для чего были оставлены соответствующие поля в таблицах? Возможно БД у меня некорректно обновилась? Все ли верно я написал?
На версии 5.2.1-007 реализовал следующую логику работы блокировок при помощи самописных костылей, которую безболезненно нужно перенести на 5.3:
- расчетный период равен месяцу
- деньги списываются раз в сутки
- если денег для списания суточной АП недостаточно, наступает блокировка
- блокировка снимается только в том случае, если счет был пополнен на сумму равную или большую месячной АП
Собственно костыль юзал блокировку "Пересчитывать абонентскую плату и трафик". "Пользовательская" же блокировка просто ставится при помощи "Пересчитывать абонентскую плату."
Как видно, первые три пункта моей логики фактически уже есть в новой версии биллинга, но блокировка снимается, как только поступает какая-либо сумма на счет и он становится положительным.
Таким образом хочу реализовать следующее:
- биллинг по встроенной схеме блокирует пользователя при недостатке средств на счете (Системная блокировка)
- скрипт меняет все Системные блокировки на Административные
- скрипт снимает блокировку, если на заблокированном счете появилась необходимая сумма для списания
Можно, но я таким образом дополнительно отличаю данный тип блокировки.dimic писал(а):Можно юзать встроенные функцию:<parameter name="block_end" value="1800000000"/>
max_time() – возвращает строковое представление максимального значения времени в системе UTM5 в формате unix (2000000000, ~2033 год);
Magnum72, слушай, а у тебя это работает?
Я сейчас немного выпал в осадок.
UTM5 сравнивает длину периода блокировки с 0?! WTF? У меня в поле Максимальная длительность указан 0, что как бы подразумевает остутсвие ограничений.
Я сейчас немного выпал в осадок.
Код: Выделить всё
Aug 29 17:08:23 ?Debug : 8c16400 RPCServer@0.0.0.0: unable to set: blocking period too long
Можно вопрос, зачем так все хитро?dimic писал(а): Таким образом хочу реализовать следующее:
- биллинг по встроенной схеме блокирует пользователя при недостатке средств на счете (Системная блокировка)
- скрипт меняет все Системные блокировки на Административные
- скрипт снимает блокировку, если на заблокированном счете появилась необходимая сумма для списания
Ведь системная блокировка, это и есть блокировка по балансу. (бабло закинули, все заработало)
Административная, это когда персонал компании заблокировал пользователя по каким либо причинам. (Расторг договор, мешает работе сети и т.д.) и снять эту блокировку может только персонал компании.
Пользовательская, собственно для блокировки из ЛК.
P.S. Даже если при отрицательном балансе, (сис. блок) ты поставишь административную, то у тебя первая не слетит. Будет одновременно активно две блокировки. И при пополнение баланса, уйдет первая, но останется вторая (Админ. блок)
В том и дело, что нужно смотреть, сколько бабла закинули. Если меньше, чем списывается за месяц, то счет должен оставьтся заблокированным.Morbid писал(а):Ведь системная блокировка, это и есть блокировка по балансу. (бабло закинули, все заработало)
У биллинга на данный момент логика простая. Денег на текущее списание средств достаточно? Ok. Снимаем блокировку.
Если не понятно, привожу пример.
Входные параметры тарифного плана.
Абонентская плата = 300 рублей.
Расчетный период = 1 месяц.
Количество списаний в неделю = 7, то есть деньги списываются ежедневно.
Ситуация
Пусть в текущем расчетном периоде 30 дней, значит в сутки списывается по 10 рублей.
У абонента остается на счету, например, 5 рублей.
Биллинг блокирует счет.
В стандартной логике UTM5 абоненту достаточно докинуть 5 рублей на счет, чтобы приозошло списание и интернет проработал еще день, но нам этого не нужно.
Нужно, чтобы счет не разблокировался, пока на нем не появится сумма, равная абонентской плате за весь расчетный период.
Может есть идеи, как это реализовать без костыля?
Мы реализовали это проще..dimic писал(а):В том и дело, что нужно смотреть, сколько бабла закинули. Если меньше, чем списывается за месяц, то счет должен оставьтся заблокированным.Morbid писал(а):Ведь системная блокировка, это и есть блокировка по балансу. (бабло закинули, все заработало)
У биллинга на данный момент логика простая. Денег на текущее списание средств достаточно? Ok. Снимаем блокировку.
Если не понятно, привожу пример.
Входные параметры тарифного плана.
Абонентская плата = 300 рублей.
Расчетный период = 1 месяц.
Количество списаний в неделю = 7, то есть деньги списываются ежедневно.
Ситуация
Пусть в текущем расчетном периоде 30 дней, значит в сутки списывается по 10 рублей.
У абонента остается на счету, например, 5 рублей.
Биллинг блокирует счет.
В стандартной логике UTM5 абоненту достаточно докинуть 5 рублей на счет, чтобы приозошло списание и интернет проработал еще день, но нам этого не нужно.
Нужно, чтобы счет не разблокировался, пока на нем не появится сумма, равная абонентской плате за весь расчетный период.
Может есть идеи, как это реализовать без костыля?
При наступлении системной блокировки у клиента выполняется скрипт, который устанавливает данному клиенту Кредит минус сумма месячного платежа. К пример -600 руб. До тех пор, пока клиент не закинет на лиц счет больше чем 600 руб системная блокировка у него не снимется. При этом клиент может делать платежи хоть по 1 рублю. При появлении нужной суммы и снятии системной блокировки выполняется скрипт, который возвращает клиенту Кредит 0 (ноль).
При этом логика проверки учитывает событие, когда клиент берет услугу в кредит через личный кабинет.