Задача у нас изначально стоит такая: У клиента есть базовый тарифный план, мы продаем ему некую услугу в качестве дополнения к основному тарифному плану. В нашем случае - локальный трафик с определенной скоростью за определенную абонентскую плату. Т.е. нужно не просто добавить клиенту соответствующую абонплату в договор, но и выдать дополнительные radius-атрибуты. Для реализации подобного придется создавать дублирующие тарифные планы с небольшими изменениями, либо писать скрипты, модифицирующие Radius-атрибуты при их выдаче в зависимости от наличия абонплаты и/или тарифного плана-"пустышки". Сейчас появляется концепция
тарифных опций, но это не совсем то - тарифные опции предполагают разовый бустер на x часов через расход, а не абонплату.
Может быть стоит рассмотреть более общий случай? Скажем, ввести понятие
тарифных модификаторов, частным случаем которых будут опции. Аналогично опциям указываем в тарифном плане узлы, в которых обрабатываем логику модификаторов. Причем сделать эти узлы доступными в любых модулях. Например, в абонплатах - другая цена для той же услуги, в dial-up - другой набор radius-атрибутов, другая цена за мб и пр.
Общие идеи:
- Модификаторы вешаются на договор с определенным периодом.
- Для избежания конфликтов и разночтений ввести позиции, задающие приоритет (аналогично тарифным планам).
- default-модификатор, работающий всегда либо когда не найдено других. Первое кажется проще и логичнее - при необходимости значения переопределяются в узлах других модификаторов. Видимо по такой схеме сейчас сделаны опции (см второй узел опций):
- [опционально] Модификаторы с параметрами. Параметры подставляются в значения узлов договора. Скажем, цена=100*$1 - значит, берем $1 - первый параметр текущего (при обходе дерева) модификатора. Параметры обязательно должны иметь значения по умолчанию. Т.е. нужно будет прогонять все mtree_node.data через специальный eval, делающий подстановки и, возможно, производящий арифметические действия. Конечно слишком круто для реализации, но предоставляет широкие возможности для индивидуальной кастомизации тарифов.
Сейчас для индивидуальной модификации тарифного плана под клиента используется механизм наследования. Но мы например столкнулись с ситуацией, когда необходимо переделать базовый тарифный план и при этом не избежать ручного переделывания всех наследников: при закрытии периодом закрываются и сделанные у наследников изменения. При введении модификаторов мы можем жестко задавать и менять точки входа для индивидуальных изменений в тарифных планах. Сейчас, чтобы немного модифицировать тарифный план, приходится тащить за собой его полностью либо через наследование, либо тупо дублированием с минимальными изменениями (
например).
Т.е. идея в том, чтобы тарифные планы играли роль базы, настраиваемой индивидуально через дополнительные сущности.
ps. Дилера не сдам