Feature #48
closed
Таймаут для политики тарификации
0%
Description
Нужно реализовать таймаут действия текущей политики тарификации.
1. В тариф нужно добавить поле change_policy_timeout типа time_t которое будет содержать UNIX timestamp до которого действует политика тарификации. Нулевое значение должно означать отсутствие ограничения.
2. Поддержку поля нужно добавить в плагины БД и соответствующие БД в виде типа TIMESTAMP.
3. Поддержку поля нужно добавить в sgconfig и rpcconfig в формате YYYY-MM-DD HH:MM:SS.
4. Поддержку поля нужно добавить в sgconf из версии 2.5 в формате YYYY-MM-DD HH:MM:SS.
5. При проверке change_policy теперь нужно учитывать таймаут — если таймаут истек (текущий UNIX timestamp больше указаного в change_policy_timeout и change_policy_timeout не равен нулю) считать change_policy равным allow.
6. Расширить тесты с учетом нового поля — Тестировать все варианты с нулевым таймаутом, с таймаутом в будущем и в прошлом.
Updated by Vladimir Pavljuchenkov over 8 years ago
- Related to Feature #37: Политика тарификации added
Updated by Vladimir Pavljuchenkov over 8 years ago
Нужно реализовать таймаут действия для политики смены тарифа.
По умолчанию у политики таймаута нет.
Updated by Redmine Admin about 8 years ago
Вова, а как должен срабатывать этот таймаут? Ну вот наступил он, и что дальше? Распиши механику более подробно.
Updated by Vladimir Pavljuchenkov about 8 years ago
Нужно реализовать таймаут действия текущий политики тарификации.
Таймаут представляет собой время, через которое текущая политика тарификации перестанет действовать.
Updated by Maxim Mamontov about 8 years ago
Перестает действовать — это как? Остается, скажем, to_expensive но действует как allow? Или меняется на allow? Или что-то еще?
Updated by Vladimir Pavljuchenkov about 8 years ago
Перестает действовать — это как? Остается, скажем, to_expensive но действует как allow? Или меняется на allow? Или что-то еще?
Правильнее всего будет добавить в тариф еще один параметр - политика после таймаута.
Смысл тикетов #48 и #37 - дать возможность средствами старгейзера реализовывать (акционные) тарифные планы, которые действуют определенное время. Чаще всего во время акции провайдеры не дают возможность менять тарифные планы на другие на период действия акции. Вот саму акцию можно будет реализовать через политику тарификации, а время действия акции - через таймаут политики тарификации.После окончания акции (окончания действия тарифного плана), провайдеры:
- могут дать возможность абоненту менять тарифный план на любой (политика allow)
- могут дать возможность абоненту менять тарифный план на более дорогой, т.к. акция была очень дешевой и направлена исключительно на привлечение абонентов (политика to_expensive)
- могут не дать возможность абоненту менять тарифный план вообще (политика deny)
Поэтому гибче всего было бы дать возможность для каждой политики тарификации назначать свою политику, которая будет действовать после таймаута.
Но тут желательно сделать защиту от дурака:- если стоит отложенный тарифный план у абонента, который дороже текущего, то или не ставить/удалять его, или не давать ставить политику to_cheap
- если стоит отложенный тарифный план у абонента, который дешевле текущего, то или не ставить/удалять его, или не давать ставить политику to_expensive
- если вообще есть отложенный тарифный план, то не давать ставить политику deny, или не давать ставить отложенный тарифный план/убирать его.
Updated by Vladimir Pavljuchenkov about 8 years ago
Нужно реализовать таймаут действия текущий политики тарификации.
Таймаут представляет собой время, через которое текущая политика тарификации перестанет действовать.
Когда политика тарификации перестает действовать, она меняется на политику allow.
Так как решено, что после таймаута, политика всегда будет allow, то никакие ограничения, описанные выше, смысла не имеют.
Updated by Maxim Mamontov about 8 years ago
- Description updated (diff)
- Assignee changed from Maxim Mamontov to Helen Mamontova
Updated by Maxim Mamontov almost 8 years ago
- Assignee changed from Helen Mamontova to Vladimir Pavljuchenkov
Готово. stg-2.409-rc3 или из репо (все ветки кроме ГТС).
Updated by Vladimir Pavljuchenkov almost 8 years ago
Проверил.
Не работает.
Время установленное в '2016-12-26 20:40:00' становится '4774456-12-06 13:41:20' на файловой базе данных.
Updated by Vladimir Pavljuchenkov almost 8 years ago
- Assignee changed from Vladimir Pavljuchenkov to Maxim Mamontov
Updated by Maxim Mamontov almost 8 years ago
- Assignee changed from Maxim Mamontov to Helen Mamontova
Версия STG (ветка): 2.409
Версия конфигуратора (ветка): master
База: store_files
Устанавливаем change policy timeout для тарифа foo:
$ ./sgconf -a admin:123456@localhost:5555 --chg-tariff foo --change-policy-timeout "2017-01-17 23:00:00"
Читаем установленное значение:
$ ./sgconf -a admin:123456@localhost:5555 --get-tariff foo | grep "change policy timeout" change policy timeout: -137317466-09-02 08:39:28
Значение некорректное.
Проверяем что записано в базе:
$ grep "ChangePolicyTimeout" ../stargazer/var/stargazer/tariffs/foo.tf ChangePolicyTimeout=1484694000
Переводим в привычное представление:
$ date -d "@1484694000" середа, 18 січня 2017 01:00:00 +0200
То есть в базе значение корректное (2017-01-17 23:00:00 по гринвичу, у нас будет уже 2017-01-18 01:00:00 потому что +2 часа). Значит проблема с отображением.
Updated by Maxim Mamontov almost 8 years ago
Если посмотреть на "внутренности" протокола:
$ ./sgconf -r "<GetTariffs/>"
То можно увидеть что в ChangePolicyTimeout от сервера приходит некорректное значение:
<ChangePolicyTimeout value="34032977502152">
</ChangePolicyTimeout>
А это значит что проблема в plugins/configuration/sgconfig
Updated by Maxim Mamontov almost 8 years ago
Отладочный вывод в STG::PARSER::GET_TARIFFS::CreateAnswer показывает:
parser_tariffs.cpp > 22:37:19 > tariff: 'foo', change policy timeout: 3068656372
То есть значение либо некорректно читается из базы, либо некорректно копируется.
Updated by Maxim Mamontov almost 8 years ago
if (conf.ReadString("ChangePolicyTimeout", &str, "1970-01-01 00:00:00") < 0)
td->tariffConf.changePolicyTimeout = 0;
else
td->tariffConf.changePolicyTimeout = readTime(str);
Т.е. мы храним время как просто число, но пытаемся прочитать его как YYYY-MM-DD HH:MM:SS. То есть нужно исправить:
- Значение по умолчанию - "0".
- Вместо readTime использовать str2x.
Альтернативно можно было бы писать в файловую базу значение в формате YYYY-MM-DD HH:MM:SS, но у нас уже исторически так сложилось что мы время храним как просто число - unix timestamp. См. например, LastActivityTime в stat-файле любого юзера:
# grep "LastActivityTime" var/stargazer/users/test/stat LastActivityTime=1484685443
Updated by Maxim Mamontov almost 8 years ago
- Assignee changed from Helen Mamontova to Vladimir Pavljuchenkov
Исправлено в stg-2.409-rc4 и master.
Updated by Vladimir Pavljuchenkov over 7 years ago
- Status changed from New to Resolved
Действительно исправлено.
Протестировано.
Работает.
Updated by Vladimir Pavljuchenkov over 7 years ago
- Status changed from Resolved to Closed