PolybiusBank, Кампания по сбору будет идти 5 недель или до достижения последнего goal?
если просуммировать текущие вложения $ и BTC, то последний goal в 25кк$ почти достигнут.
Переработка и доработка OTRS. И явно не плагинами. Когда 3.x совсем устареет — история повторится.
И плагинами, и не плагинами. Я описывал что плагины это решение, но недостаточно гибкое. Также в планах описал что планируется переход на EventHandler, а значит и обновится будет до новой версии не проблема.
Но там XML-RPC.Но нет. Она просто потому что «Карл». Потратили время, подогрели воздух.
XML-RPC — работает напрямую с ядром, а наше API идет через GenericInterface, предварительно работая с кастомером (Создание и обновление данных которые идут из наших сервисов ). Так же пропадает необходимость писать монструозные запросы к rpc, так как используются уже готовые контроллеры для обработки, например создания заявки, которые проводят всю валидацию данных ( возвращая читаемые ошибки), работу с динамическими полями, создание артиклей, работа с аттачами и т.д.
И этим надо похвастаться на пять экранов на хабре
Интеграция пользователя имеется, все необходимые данные передаются в API. Речь идет о пользователях, которые не авторизованы на сайте, а просто через форму отправляют нам заявки, оставляя произвольный email. По email и дополнительным полям из формы, вытаскиваются данные об услугах, пользователе и т.д. Тут мы просто проверяем, что это не случайный человек хочет удалить свой сервер, указав email и услугу другого пользователя.
Ну-ка, давай поговорим за эффективность.
В статистике достаточно много факторов учитываются, все я их тут не описывал. По нашим графикам вполне неплохо видно кто раздолбай, а кто и большой молодец. Если есть сомнения, то как минимум это повод пристальнее приглядется к сотруднику, который выбивается из общей картины. Как вниз, так и вверх.
А так будет отписка, которую мы часто кстати и видим в ответах различных СТП (включая меня, когда я устал), или пинг-понг между линиями поддержки. Ну вобщем, это попытка пригладить волны. Хотя и популярная.
Есть оценки качества ответа не только от клиентов, но и от других сотрудников. Никто у нас не будет терпеть такого бездумного перекидывания тикета в вышестоящий отдел. Такие умельцы быстро вычисляются и исправляются. Ну или прощаемся с ними.
«Мы не смогли поставить корпоративный джаббер (ни у кого не было 15 минут), поэтму запарились и сделали пуш в браузер».
Могли, конечно же. Но держать джаббер-сервер только для того чтобы один скриптик периодически писал
другим сотрудникам? И еще просить всех сотрудников добавить его к себе в buddy-лист? Слишком большой инструмент для слишком маленькой задачки. Кроме этого, нахождение в jabber не означает что сотрудник реально может отреагировать на тикет. Поэтому PUSH-и для сотрудников на смене, SMS — для критических тикетов в определенные очереди или в не рабочее время.
Писать свой helpdesk — это минимум полгода, а то и год. И всё равно не будет и 30% тех возможностей, которые есть в готовом продукте. К тому же придется пройти все те грабли, которые уже пройдены разработчиками других opensource хелпдесков. Я слабо представляю компанию, у которой есть время и ресурсы на разработку вспомогательного инструментария от которого продажи косвенные, а не прямые.
Оглядываясь назад, могу сказать что желания написать свой helpdesk с нуля всё равно не появилось. Просто потому, что проще и быстрее поправить существующее, чем писать это самому.
И еще далеко не весь базовый функционал выпилен, многое работает как и задумано разработчиками.
Целиком систему отдавать во всеобщее пользование мы вряд ли будем. Отдельные наработки мы стараемся писать максимально независимо от общего кода, чтобы можно было выделить их в расширение для официальной версии OTRS. К примеру, OTRS::SphinxSearch является таким изделием.
Видимо, в своё время кто-то «пропихнул» именно этот инструмент. К нему привыкли, он оброс своими фишками, а дальше уже и не смотрели на другие продукты. Думаю, было именно так.
Статистики нормальной в ОТРС не было. Поиска тоже.
Ну ок, можно какие-то вещи взять из плагинов, которые в интернете в некотором количестве присутствуют.
Поэтому мне не совсем понятно что мы такого сделали, что делать никогда не нужно. Может подробнее опишите? Мнение со стороны полезно будет узнать.
Некоторые частые операции мы упростили.
Типа закрытия, переноса тикетов.
В остальном же вполне удобен. А переходить на какую-то другую helpdesk-систему еще более трудозатратное предприятие. Даже в плане привыкания к «новому» интерфейсу.
Вся стилистика OTRS сохранилась. В основном изменения интерфейса связаны с переработанным блоком информации о тикете и при просмотре заявки. Вместо сухого текста были добавлены динамические иконки, которые меняются (иногда просто в цветовой гамме) в зависимости от состояния тикета, от типа пользователя, блокировки и т.д.
Как-то решается проблема с отсутствием интернета? Уведомления будут приходить только при наличии соединения?
Если да, то, к сожалению, SMS это не сможет заменить.
и еще вопрос: Планируются ли приложения для браузеров или для десктопа? Как это сделано, к примеру, в Pushbullet.
Одно время на этаже офисного здания работал даже не охранник, а скорее вахтер. Сидел себе себе за ноутбуком, клепал сайтики на джумле на заказ. Для фрилансеров самое то иметь работу вахтера.
в Compatibility List существует 11 (одинадцать) различных поддоменов на базе microsoft.com.
Они туда даже свои собственные сайты суют, вместо того, чтобы поддерживать в актуальном «по их мнению» состоянии.
Ого. Я засветился на первой фотографии с пикника 2007-го.
А вообще 404 за свою историю эволюционировал в огромную пьянку (в хорошем смысле) IT-сообщества. Более неформальной конференции не встречал.
у ISP тоже есть видеоуроки.
Я просто хочу сказать что на практике возникает куча проблем с поддержкой этой панели у администраторов. В документации все четко и красиво, а на практике оказывается что nginx не поддерживается (не про современную панель, такое было примерно год назад) или система не может работать с двумя apache на сервере. Т.е. очень требовательна к установленному ПО и шаг в сторону недопустим.
А я имел ввиду именно проблемы администрирования Плеск. И именно на Linux. Не знаю какой он на Windows, но в Линуксе продукт сыроват и баговат. Пользовательский интерфейс там приятный и функций действительно больше чем в ISP, вот только многие из них не работают или работают не так как нужно.
Также есть частая проблема с нетипичным поведением пользователя. Если не следовать строгому соблюдению всех шагов в той или иной функции Плеска, то последствия могут быть плачевными.
А уж если хостеру захотелось как-то расширить или видоизменить функционал Плеска, то тут вообще беда. Архитектура слишком запутана, в базе банально не соблюдается единый стиль именования таблиц и полей. То с большой буквы через тире, то в camelCase, то еще как-то. Внятной документации по администрированию тоже не найдешь.
Естественно, имхо. То что видел я и с чем приходилось сталкиваться.
Забыли упомянуть, что Plesk на стороне клиента только красивый, а внутри черт ногу сломит, и ни о какой кастомизации речи не идет без поллитры. Да и то что из коробки работает через раз.
ISP отличный интерфейс и гораздо стабильнее Плеска. Хотя и свои огрехи есть.
cPanel вообще самая функциональная система, хоть и со страшным интерфейсом. Но её поставил и забыл про проблемы.
Так что статья выглядит сильно заказной для Plesk.
если просуммировать текущие вложения $ и BTC, то последний goal в 25кк$ почти достигнут.
И плагинами, и не плагинами. Я описывал что плагины это решение, но недостаточно гибкое. Также в планах описал что планируется переход на EventHandler, а значит и обновится будет до новой версии не проблема.
XML-RPC — работает напрямую с ядром, а наше API идет через GenericInterface, предварительно работая с кастомером (Создание и обновление данных которые идут из наших сервисов ). Так же пропадает необходимость писать монструозные запросы к rpc, так как используются уже готовые контроллеры для обработки, например создания заявки, которые проводят всю валидацию данных ( возвращая читаемые ошибки), работу с динамическими полями, создание артиклей, работа с аттачами и т.д.
Интеграция пользователя имеется, все необходимые данные передаются в API. Речь идет о пользователях, которые не авторизованы на сайте, а просто через форму отправляют нам заявки, оставляя произвольный email. По email и дополнительным полям из формы, вытаскиваются данные об услугах, пользователе и т.д. Тут мы просто проверяем, что это не случайный человек хочет удалить свой сервер, указав email и услугу другого пользователя.
В статистике достаточно много факторов учитываются, все я их тут не описывал. По нашим графикам вполне неплохо видно кто раздолбай, а кто и большой молодец. Если есть сомнения, то как минимум это повод пристальнее приглядется к сотруднику, который выбивается из общей картины. Как вниз, так и вверх.
Есть оценки качества ответа не только от клиентов, но и от других сотрудников. Никто у нас не будет терпеть такого бездумного перекидывания тикета в вышестоящий отдел. Такие умельцы быстро вычисляются и исправляются. Ну или прощаемся с ними.
Могли, конечно же. Но держать джаббер-сервер только для того чтобы один скриптик периодически писал
другим сотрудникам? И еще просить всех сотрудников добавить его к себе в buddy-лист? Слишком большой инструмент для слишком маленькой задачки. Кроме этого, нахождение в jabber не означает что сотрудник реально может отреагировать на тикет. Поэтому PUSH-и для сотрудников на смене, SMS — для критических тикетов в определенные очереди или в не рабочее время.
Оглядываясь назад, могу сказать что желания написать свой helpdesk с нуля всё равно не появилось. Просто потому, что проще и быстрее поправить существующее, чем писать это самому.
И еще далеко не весь базовый функционал выпилен, многое работает как и задумано разработчиками.
За 2015 год статистика не представлена, т.к. год еще не закончен.
Кроме того, в тикеты от реальных клиентов попадают различные абузы, письма информационного характера (не требующие ответа), дубли и т.д.
Ну ок, можно какие-то вещи взять из плагинов, которые в интернете в некотором количестве присутствуют.
Поэтому мне не совсем понятно что мы такого сделали, что делать никогда не нужно. Может подробнее опишите? Мнение со стороны полезно будет узнать.
Типа закрытия, переноса тикетов.
В остальном же вполне удобен. А переходить на какую-то другую helpdesk-систему еще более трудозатратное предприятие. Даже в плане привыкания к «новому» интерфейсу.
Если да, то, к сожалению, SMS это не сможет заменить.
и еще вопрос: Планируются ли приложения для браузеров или для десктопа? Как это сделано, к примеру, в Pushbullet.
Они туда даже свои собственные сайты суют, вместо того, чтобы поддерживать в актуальном «по их мнению» состоянии.
А вообще 404 за свою историю эволюционировал в огромную пьянку (в хорошем смысле) IT-сообщества. Более неформальной конференции не встречал.
Я просто хочу сказать что на практике возникает куча проблем с поддержкой этой панели у администраторов. В документации все четко и красиво, а на практике оказывается что nginx не поддерживается (не про современную панель, такое было примерно год назад) или система не может работать с двумя apache на сервере. Т.е. очень требовательна к установленному ПО и шаг в сторону недопустим.
Также есть частая проблема с нетипичным поведением пользователя. Если не следовать строгому соблюдению всех шагов в той или иной функции Плеска, то последствия могут быть плачевными.
А уж если хостеру захотелось как-то расширить или видоизменить функционал Плеска, то тут вообще беда. Архитектура слишком запутана, в базе банально не соблюдается единый стиль именования таблиц и полей. То с большой буквы через тире, то в camelCase, то еще как-то. Внятной документации по администрированию тоже не найдешь.
Естественно, имхо. То что видел я и с чем приходилось сталкиваться.
ISP отличный интерфейс и гораздо стабильнее Плеска. Хотя и свои огрехи есть.
cPanel вообще самая функциональная система, хоть и со страшным интерфейсом. Но её поставил и забыл про проблемы.
Так что статья выглядит сильно заказной для Plesk.