Вы, насколько я понял, предлагаете периодически получать список каналов и обрабатывать результат. Да, если нельзя подписаться на события, то буду делать именно так. Но это не оптимально, зачем мне опрашивать астерикс постоянно.
В том то и дело, что это должно работать в реальном времени. Идет звонок - пользователю инфа о звонке. Мне бы помогла инфа о том, какое именно событие мне надо отслеживать. Еще важно, что текущему пользователю не надо получать инфу о событиях другого пользователя, а события, насколько я понимаю, будут генерится без привязки к пользователю, и не хотелось бы вообще получать не нужные события.
LogManager.GetCurrentClassLogger().Debug("...");
Так использовать не стоит. Операция LogManager.GetCurrentClassLogger() достаточно тяжелая. Кладите полученный логгер в статическую переменную на уровне класа. Пример в ответе ниже.
В целом решение работает. Не не решает мою задачу. Мне надо подменить confirm во всех фреймах, с учетом тогоЮ что во фрейме может быть фрейм. Пробовал подписаться во всех фреймах на эти события, но какой то ад получается. Может быть есть идеи?
Я бы хотел, что бы это было в рамках одного приложения, т.к. есть некое API, которое реализовано на Flask, и мне надо получать данные о подключениях по WebSocket. Т.е. я бы хотел использовать общую память для этого, что бы не пришлось использовать стороннее хранилище, аля memcached or redis, для шаринга данных между WebSocket и flask. Или это не самый лучший подход?
Нет нет. Переносить из Bugzila в TFS и обратно. TFS наш, внутренний. Багзилла будет доступна заказчику. А для внутренней разработки используется TFS. При изменении статуса в TFS надо менять его в багзиле, и наоборот.
В общем попробуем обойтись шаблонами айтемов в TFS. А там видно будет. Дадим ссылку с предзаполненными параметрами и пускай по ней заводят. Посмотрим, может нормально будет. А что будет кастомизироваться нормально, то подгоним. Спасибо за советы!
Артем Воропаев Спасибо за ответ. Хотели те же типы багов, но кастомизировать в зависимости от прав пользователя, как делать, пока не ясно, т.к. некоторые поля, почему то, не хотят обрабатывать ReadOnly Rule. Хотелось бы скрыть то, что пользователь видеть не должен (за счет Area это можно сделать, как выяснилось). И еще много всяких мелочей. Соглашусь что проще поставить BugZilla, но не хочется переносить задачи из багзиллы в TFS и обратно.