BiTel

Ув. разработчики, в корневом узле модульного поддерева есть пункт меню "Оповестить об изменениях".
Что это такое и зачем описано в http://bgbilling.ru/v5.2/doc/ch01s19s02.html, тут вопросов нет.

В документации написано:


У меня вопрос. Чем обусловлена необходимость, каждый раз при изменении тарифа, запускать событие "Оповестить об изменениях"?
Почему Вы не можете автоматически, при изменении узлов тарифы, вызывать событие "Оповестить об изменениях"?

Потому что при правке не всегда дерево законченное и работоспособное.
Например, что-то удалили из дерева, а новых веток еще не добавили, при автоматическом обновлении кэша в него легко попадет еще неработоспособное дерево.

Проблема в том, что при редактировании тарифа, можно легко забыть обновить данные в кэше.

Может быть имеет смысл автоматически вызывать событие "Оповестить об изменениях", но только в том случае если "дерево законченное и работоспособное"?

Может быть как-нибудь не давать закрыть вкладку/окно, если есть изменения и не было выполнено оповещение об изменениях?

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Можно например алармы слать, если версии тарифных деревьев расходятся

Ну если конечная цель будет что то типа "Чтобы не забывали", то можно и так.
Идеальный вариант - упростить нам работу, т.е. автоматически оповещать об изменениях.

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

Я думаю, если внесли изменения в работающий тариф и не закоммитили, то ничего страшного не должно произойти - он будет в предыдущем рабочем состоянии. Когда меняешь тариф, всё равно проверяешь его работоспособность - тогда и увидишь, что что-то не так - вспомнишь, что забыл закоммитить.
А вот если автокоммит сделать, можно легко что-нибудь поломать у рабоих клиентов, пока тариф в незавконченном состоянии.

Тут еще проблема в другом. Если манагеры выставляют персональный тариф клиенту, и не коммитят изменения - то наработка не идет.

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Алармы - это было бы круто, я думаю.

зы. Персональные тарифы суть зло великое.

Согласен, но поделать с этим ничего не могу

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Потому, что вместо них нужны скидки
viewtopic.php?p=48654#p48654

Я думаю вопрос не в том завершились изменения или нет. Проблема в том, что работоспособен тариф или нет.
Мне кажется, что сделать элементарную проверку на работоспособность тарифа не составит для вас труда.
Если при изменении тарифа он оказался работоспособным, то автоматически обновлять.
А если он в данный момент не работоспособен, то подсвечивайте узел тарифа.
Вот как то так...

Как-раз таки на данный момент сложно определить, является ли тариф работоспособным.
Для каждого модуля работоспособность своя и может зависеть от дополнительных параметров (например, к какому договору привязан тариф).

Такого модального(!) окошка хватит, ящитаю.

Не хватит т.к. изменения уже сохранены. О них просто не знает шедулер или кто там о них должен знать.
А то из такого окошка кажется что можно откатить изменения ))) Фиг там было.
Требую другой надписи!

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Согласен с тем, что работоспособность для каждого модуля своя.
Но она определима.
Например для модуля NPAY, работоспособность модуля можно определить так:
1. Для каждой услуги, которая определена в тарифе, должна быть прописана цена.
2. Каждый узел типа "период", тоже должен заканчиваться либо ценой (если услуга была определена выше), либо услугой с ценой.
Для модуля NPAY я не вижу особых проблем.
Для других тоже можно придумать аналогичные правила.

По поводу "дополнительных параметров (например, к какому договору привязан тариф)" не совсем понятно, приведите пример пожалуйста.

Вы это кол-во проверок, при каждом добавлении какого-либо пункта в тарифе, представляете?
А если это что нибудь вроде тарифа по телефонии где 100500 узлов с направлениями и прочим?

Аналогично. А так же еще проверять а вдруг период пустой?

И при каждом изменении пункта тарифа писать что нибудь вроде




Лично я за!

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

В противном случае получится одно окно аля "В тарифе что-то где-то неправильно. Попытка сохранения неудачна" )

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Если не считать модуль телефонии, то не так уж и много.
Ну 50 узлов максимум, неужели есть больше?
Проверить 50 узлов тарифа это сколько миллисекунд?


С телефонией все конечно же сложнее.


Я не предлагал при каждом изменении тарифа писать сообщения с ошибками.