Feature #48

Таймаут для политики тарификации

Added by Vladimir Pavljuchenkov about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:04/17/2016
Priority:NormalDue date:
Assignee:Vladimir Pavljuchenkov% Done:

0%

Category:-Spent time:-
Target version:-

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. Расширить тесты с учетом нового поля — Тестировать все варианты с нулевым таймаутом, с таймаутом в будущем и в прошлом.


Related issues

Related to Feature #37: Политика тарификации Resolved 08/24/2015

History

#1 Updated by Vladimir Pavljuchenkov about 3 years ago

  • Related to Feature #37: Политика тарификации added

#2 Updated by Vladimir Pavljuchenkov about 3 years ago

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

#3 Updated by Redmine Admin almost 3 years ago

Вова, а как должен срабатывать этот таймаут? Ну вот наступил он, и что дальше? Распиши механику более подробно.

#4 Updated by Vladimir Pavljuchenkov almost 3 years ago

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

#5 Updated by Maxim Mamontov almost 3 years ago

Перестает действовать — это как? Остается, скажем, to_expensive но действует как allow? Или меняется на allow? Или что-то еще?

#6 Updated by Vladimir Pavljuchenkov almost 3 years ago

Перестает действовать — это как? Остается, скажем, to_expensive но действует как allow? Или меняется на allow? Или что-то еще?

Правильнее всего будет добавить в тариф еще один параметр - политика после таймаута.

Смысл тикетов #48 и #37 - дать возможность средствами старгейзера реализовывать (акционные) тарифные планы, которые действуют определенное время. Чаще всего во время акции провайдеры не дают возможность менять тарифные планы на другие на период действия акции. Вот саму акцию можно будет реализовать через политику тарификации, а время действия акции - через таймаут политики тарификации.
После окончания акции (окончания действия тарифного плана), провайдеры:
  • могут дать возможность абоненту менять тарифный план на любой (политика allow)
  • могут дать возможность абоненту менять тарифный план на более дорогой, т.к. акция была очень дешевой и направлена исключительно на привлечение абонентов (политика to_expensive)
  • могут не дать возможность абоненту менять тарифный план вообще (политика deny)

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

Но тут желательно сделать защиту от дурака:
  • если стоит отложенный тарифный план у абонента, который дороже текущего, то или не ставить/удалять его, или не давать ставить политику to_cheap
  • если стоит отложенный тарифный план у абонента, который дешевле текущего, то или не ставить/удалять его, или не давать ставить политику to_expensive
  • если вообще есть отложенный тарифный план, то не давать ставить политику deny, или не давать ставить отложенный тарифный план/убирать его.

#7 Updated by Vladimir Pavljuchenkov almost 3 years ago

Нужно реализовать таймаут действия текущий политики тарификации.
Таймаут представляет собой время, через которое текущая политика тарификации перестанет действовать.
Когда политика тарификации перестает действовать, она меняется на политику allow.
Так как решено, что после таймаута, политика всегда будет allow, то никакие ограничения, описанные выше, смысла не имеют.

#8 Updated by Maxim Mamontov almost 3 years ago

  • Assignee changed from Maxim Mamontov to Helen Mamontova
  • Description updated (diff)

#9 Updated by Maxim Mamontov almost 3 years ago

  • Description updated (diff)

#10 Updated by Maxim Mamontov over 2 years ago

  • Assignee changed from Helen Mamontova to Vladimir Pavljuchenkov

Готово. stg-2.409-rc3 или из репо (все ветки кроме ГТС).

#11 Updated by Vladimir Pavljuchenkov over 2 years ago

Проверил.
Не работает.
Время установленное в '2016-12-26 20:40:00' становится '4774456-12-06 13:41:20' на файловой базе данных.

#12 Updated by Vladimir Pavljuchenkov over 2 years ago

  • Assignee changed from Vladimir Pavljuchenkov to Maxim Mamontov

#13 Updated by Maxim Mamontov over 2 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 часа). Значит проблема с отображением.

#14 Updated by Maxim Mamontov over 2 years ago

Если посмотреть на "внутренности" протокола:

$ ./sgconf -r "<GetTariffs/>" 

То можно увидеть что в ChangePolicyTimeout от сервера приходит некорректное значение:
        <ChangePolicyTimeout value="34032977502152">
        </ChangePolicyTimeout>

А это значит что проблема в plugins/configuration/sgconfig

#15 Updated by Maxim Mamontov over 2 years ago

Отладочный вывод в STG::PARSER::GET_TARIFFS::CreateAnswer показывает:

parser_tariffs.cpp > 22:37:19 > tariff: 'foo', change policy timeout: 3068656372

То есть значение либо некорректно читается из базы, либо некорректно копируется.

#16 Updated by Maxim Mamontov over 2 years ago

Внимательный просмотр FILES_STORE::RestoreTariff следующее:
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. То есть нужно исправить:
  1. Значение по умолчанию - "0".
  2. Вместо readTime использовать str2x.

Альтернативно можно было бы писать в файловую базу значение в формате YYYY-MM-DD HH:MM:SS, но у нас уже исторически так сложилось что мы время храним как просто число - unix timestamp. См. например, LastActivityTime в stat-файле любого юзера:

# grep "LastActivityTime" var/stargazer/users/test/stat
LastActivityTime=1484685443

#17 Updated by Maxim Mamontov over 2 years ago

  • Assignee changed from Helen Mamontova to Vladimir Pavljuchenkov

Исправлено в stg-2.409-rc4 и master.

#18 Updated by Vladimir Pavljuchenkov over 2 years ago

  • Status changed from New to Resolved

Действительно исправлено.
Протестировано.
Работает.

#19 Updated by Vladimir Pavljuchenkov over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF